Re: [Omniprint-developer] Omni still very buggy

[Till K. <til...@gm...>]

I have downloaded Omni from CVS yesterday and now it compiles correctly 
and the pages on the Epson Stylus Color 1290 come out completely. This 
version is on Mandrake's Cooker now as the package "omni". The Foomatic 
data for the Omni driver I have also integrated in Cooker, they are now 
added to the "foomatic" package.

All tests are done by entering the GhostScript command line manually to 
avoid the influence of filters used by the spooler, but some tests of 
using Foomatic with CUPS lead to the same results.

Now to my results with Omni:

1. Printing on Epson Stylus Color 1290: 720x720 dpi and 1440x720 dpi 
give a high quality (tested on plain paper, 24-bit CcMmYK), only the 
grau composed from the colours is yellowish, the red looks somewhat 
orange, and the blue somewhat violet. 2880x720 make the print head 
moving a little bit, but nothing gets printed, 360x360 dpi prints very 
slowly and the paper is completely soaked with ink, it seems that every 
row is printed at least with 10 sweeps loading full ink onto the paper. 
This makes the letters as painted with a thick pen, one can also read 
them on the back side of the paper (the duplex of the poor man?). When 
the printer has to print a row which contains colour and not only black, 
the black ink intensity is OK, but the yellow intensity is much to high, 
the yellow ink is soaking through the paper here and makes all colours 
with yellow participation looking like through yellow glass. All yellow 
free colours are normal. In the draft mode the printer does not even 
switch into graphics mode, I get a lot of weird black ASCII text lines 
on the sheets (as when I would use a driver for a non-Epson printer on 
my Epson).

2. LaserJet 2100 driver: The printout is much faster now, but one has 
similar steps in the grayscale as when one prints with the "ljet4" 
GhostScript driver. Is it not possible to make the dither algorithms 
faster? When I print with GIMP-Print on an HP laser printer, I get a 
nicely dithered printout without any significant delay.

3. Document position: As I already observed in older versions of Omni, 
the document is shifted around 3-6 mm to the right and around 3-6 mm to 
the top of the paper. This effect one sees easily when one prints the 
RedHat (testpage*.ps) or the CUPS (testprint.ps) test pages, but it also 
appears with all other documents. The pages you find on

    http://mandrakesoft.com/~tkamppeter/printer-testpages/

and they can be used with every distro and every spooler. The frames on 
the RedHat pages must have distances to the border of the paper as 
indicated at the frames, the frame on the CUPS test page marks the 
border of the imageable area. The coordinates (relative to the lower 
left corner of the sheet) of the imageable area are also written onto 
the page as numbers. Comparing the numbers with the actual frame 
position shows, that the whole document is printed in the correct size 
but it is shifted to the upper right direction. This happens for all 
drivers, printers, and modes. I have used the "-sPAPERSIZE=A4" 
GhostScript option and "form=FORM_A4" in the "-sproperties=..." string. 
When I prepend the lines

    %!
    <</PageSize[595 842]/ImagingBBox null>>setpagedevice

to the PostScript document and do NOT give the "-sPAPERSIZE=A4" 
GhostScript option, but still the "form=FORM_A4" in the 
"-sproperties=..." string, I have only the shift to the right, the shift 
to the top disappears. This means that the upper and the lower margin 
are correct now, the left margin is too wide and the right too narrow.

4. Paper size setting: According to the docs/Omni.readme.1st file one 
has to specify the paper size twice in the GhostScript command line, 
once by the GhostScript option "-sPAPERSIZE=..." (or an appropriate 
PostScript command in the document or the "-g" option) and second, by 
the "form=..." directive in the "-sproperties=..." string. I have 
checked that when one gives the paper size only once (either GhostScript 
option or "form=..." directive) the output gets wrong, cut off or 
shifted by several centimeters. So giving only one (or two different) 
paper size settings makes no sense. In addition, the Foomatic data for 
Omni only sets the "form=..." option and not the GhostScript option, to 
do it correctly, the "PageSize" option has to change two points in the 
command line, the "-sPAPERSIZE=..." (or "-g") setting and the "form=..." 
setting, but modifying two points is not supported by the current 
Foomatic. Therefore I suggest the Omni driver to be changed that it is 
enough to give only the GhostScript option or only the "form=..." option 
and the other internal variable of the driver/GhostScript is set 
appropriate to the value of the variable for which the user has given 
the option. For example you could remove the "form=..." option and the 
user/Foomatic provides the paper size as prepended PostScript or a 
standard GhostScript option (GhostScript does not need to know all paper 
size names, because the PostScript command and the "-g" option use 
numbers to describe the paper size) the name/size relation and the list 
of allowed paper sizes is provided by the Foomatic data. Then all is 
compliant to the standard.

5. Choices in Foomatic options: The "shortnames" of the choices of the 
Foomatic options are completely independent of the options on the 
command line of GhostScript/the printer driver. So one can make the 
Foomatic data somewhat more user friendly by using shortnames which are 
equal to the ones of other drivers:

    FORM_LETTER          --> Letter
    FORM_A4              --> A4
    RESOLUTION_300_X_300 --> 300x300DPI

so users have much less to type when giving options on the command line 
and when they have more than one printer and some printers are used with 
Omni, others are used with other drivers, they can use the same command 
line options for doing the same things on the different printers. This 
change is only a change on the Foomatic data, the driver itself does not 
need to be changed ("shortname" and "driverval" are independent from 
each other).

6. Manufacturer "HP LaserJet": The following printers have "HP LaserJet" 
as the manufacturer's name in their Foomatic data:

    HP LaserJet 4PJ
    HP LaserJet IIID
    HP LaserJet IIIP
    HP LaserJet IIISi
    HP LaserJet III

This must be simply "HP". Probably more printer entries have that problem.

7. Printer names: All "HP LaserJet II" and "HP LaserJet III" models are 
in the Foomatic database, but as "HP LaserJet 2" and "HP LaserJet 3". 
Can you change the names in Omni appropriately and/or put appropriate 
relations into the Omni/Foomatic/bin/foomaticDB file?

8. The HP LaserJet 1100 still offers only resolutions up to 300 dpi, the 
printer is capable for 600 dpi (with "ljet4" or GIMP-Print).

That's all what I found now.

    Till


Pete Zannucci wrote:

> Till, I wasn't able to reproduce your problem here with the parser.  You
> were using
> the gz file and not CVS correct?
> I put a new Epson High Res Instance.cpp file up with the 0.5 package which
> will
> solve the lost band on the bottom of the page with A4.