Menu
▾
▴
Re: [Omniprint-developer] Omni still very buggy
|
From: Pete Z. <pz...@us...> - 2001-10-08 22:02:10
|
Till,
Thank you for reporting this information to us.
Currently we have corrected some of the items and need some additional
feedback on others.
1. Foomatic: in the file db/source/opt/omni-print-model.xml (generated
by the program "Foomatic") the line
<arg_proto>%s -sproperties" </arg_proto>
must read
<arg_proto>%s -sproperties="</arg_proto>
This has been corrected in the latest Foomatic.cpp in Sourceforge.
2. Foomatic: Probably the file Omni/Foomatic/bin/foomaticDB is somehow
machine generated. It need some manual corrections, not only when
sometimes "+" and "Plus" is used in printer names, also when there is a
library file serving for two or more printers, as
"libHP_LaserJet_4Si_4Si_Mx.so". This should not lead to a new printer
entry "HP-LaserJet_4Si_4Si_Mx.xml", but to an association to the HP
LaserJet 4Si which is already in the database ("439570.xml") and to a
new printer "HP-LaserJet_4Si_Mx.xml". The database has entries only for
single printers, not for printer groups.
We originally had them under one driver but they had been moved into
multiple devices so that
device specific options could be applied to each. We will look into how to
resolve this as best
we can.
3. Foomatic: Names of options and choices: Both the machine-readable
short names and the human-readable long names for options and choices
should be as similar as possible to the Foomatic data of already
existing drivers.
We will look into this.
4. Setting both PAPERSIZE and FORM= issues.
Are you saying Ghostscript will not generate the output correctly if both
of these are not set
even though we tell Ghostscript the correct resolution and page size in
pels? Or is this just going
to cause a failure when using CUPS?
5. Omni printer properties information: Some printers have incorrect
properties in Omni: The HP LaserJet 1100 has a maximum resolution of 600
dpi, Omni allows only 300 dpi, the "ljet4" driver of GhostScript does
600 dpi on this printer without problems. The HP LaserJet 2100 and 3200
models have 1200 dpi and Omni allows only 600 dpi. Perhaps there are
wrong properties for many other printers. Many printer properties you
find on www.linuxprinting.org and also in the repository of GIMP-Print.
The laserjet printers only support the higher resolution on the 2100 and
3200 when using PCLXL.
We will report back the PCLxxx (non-PCL6) level of support that is
available in the Omni. Why would
we need to report back something not available in the driver?
6. Omni driver: Borders broken: The LaserJet 2100 driver reports the
correct paper size (I manually started GhostScript, without spooler)
when printing the CUPS test page, but the hole test page is shifted by
around 6mm to the right and 3mm to the top. This leads to the head line
"Printer Test Page" being cut at the top. It seems that it is shifted by
the non-printable left and lower borders. The "ljet4" and the "pxlmono"
driver of GhostScript handle that correctly. They center the page
correctly. Also the output on the Epson Stylus 1270 is shifted to the
upper right by more or less the same distances. This makes the driver
unusable for most applications.
With the printouts that I have been doing, everything seems to be centered
correctly. Is there an
issue of what the physical page dimensions and clip margins do on the
output? Sounds like
something is adding back in margins when the driver already manages them.
Is this possibly
happening? I don't know why a page would be moved to the right unless the
margin was added
back in. Please let me know where I can get a test file that shows this to
me.
7. Yellow on the middle grays with the Epson Stylus Photo 1270.
Are there modifications to the gamma values that will correct this? I
currently do not have a 1270
available for testing so if I could get feedback as to gamma or other
corrections, it would be a
great deal of help.
8. Omni driver: The printout on the Epson Stylus Photo 1270 always stops
around 7cm before the end of the page (the rendering process is still
going on, last two bands), this is independent from the dithering
algorithm.
What resolution is the printer running at and the form that is being used?
I can try the same code (if
I can use LETTER on an 870) and see if the same problem occurs.
9. Omni-driver: Fast diffusion dithering on the Epson Stylus Photo 1270
messes up the printout completely. One sees the test page twice, one at
the side of the other, each with half the original width and the full
original hight. In this case problem (7.) does not appear, but problem
(8.) appears.
Currently only two dithers support multi-bit per pel on Epsons, Stucki and
Steinberg. Other dithers
do not work in multi-bit per modes and we should find a way to disable them
until the dithers are
updated.
10. Omni driver: Omni is terribly slow, on my 350 Mhz test machine
rendering a 600x600 dpi test page for the LaserJet 2100 needs 2:30 min,
the printout is done in a few seconds. All GhostScript drivers
("pxlmono", "ljet4", and even "lj5gray") are WAY faster. This way Omni
is absolutely unsuitable for laser printers.
We have added the -smonodither=GSMONO to the command line in the latest
Foomatic code.
When a device is either mono or configured to print mono, Omni will now use
Ghostscripts mono-
dither and not Omni's. Omni's mono is better than Ghostscript's but the
performance suffers. Now
we will use Ghostscript's and not use the internal Omni code. The driver
should be comparable
with other monochrome drivers out there with this change that we have put
into Foomatic.cpp in
CVS. Yes you are right, the other drivers are WAY faster, or should I say
were faster.
Thanks again,
Peter Zannucci
IBM Linux Technology Center
Open Source Software Development
Omni Print Project http://sourceforge.net/projects/omniprint
Austin, TX - Tel. 512-838-4687 (t/l 678) pz...@us...
Till Kamppeter <til...@gm...>@lists.sourceforge.net on 10/05/2001
04:32:57 PM
Sent by: omn...@li...
To: Pete Zannucci/Austin/IBM@IBMUS, omn...@so...,
Ryan A Harper/Austin/IBM@IBMUS, cru...@re...,
gt...@pi...
cc:
Subject: [Omniprint-developer] Omni still very buggy
Oi,
I have tested Omni 0.4.3 with the Foomatic generator code (all files in
the Omni/Foomatic directory) from today's CVS. There I have found the
fllowing problems:
1. Foomatic: in the file db/source/opt/omni-print-model.xml (generated
by the program "Foomatic") the line
<arg_proto>%s -sproperties" </arg_proto>
must read
<arg_proto>%s -sproperties="</arg_proto>
The "=" was missing and this way GhostScript ignored all the options in
the "properties" string.
2. Foomatic: Probably the file Omni/Foomatic/bin/foomaticDB is somehow
machine generated. It need some manual corrections, not only when
sometimes "+" and "Plus" is used in printer names, also when there is a
library file serving for two or more printers, as
"libHP_LaserJet_4Si_4Si_Mx.so". This should not lead to a new printer
entry "HP-LaserJet_4Si_4Si_Mx.xml", but to an association to the HP
LaserJet 4Si which is already in the database ("439570.xml") and to a
new printer "HP-LaserJet_4Si_Mx.xml". The database has entries only for
single printers, not for printer groups.
3. Foomatic: Names of options and choices: Both the machine-readable
short names and the human-readable long names for options and choices
should be as similar as possible to the Foomatic data of already
existing drivers. This makes the Foomatic data of Omni more
user-friendly and understandable and it also makes it easier to switch
from an old GhostScript driver to Omni with the Foomatic tools, because
the default settings of equally-named options with equally-named choices
are conserved. In addition, the "lpr" command lines get shorter when one
uses option and choice names as the already existing Foomatic drivers
have. Foe example the paper size should have as long name "Page Size",
as short name "PageSize" (this is already done) and the choices should
not contain the prefix "FORM" and should not be all-uppercase. They
should look like:
Short naame Long name
----------------------------
Letter Letter
A4 A4
COM10 Comercial 10
... ...
The other options should be changed similarly. The values really
inserted into the GhostScript command line need not to be changed.
4. Foomatic/GhostScript: Omni needs the paper size to be defined twice
in the GhostScript command line, once as the option "-sPAPERSIZE=..."
(or appropriate prepended PostScript commands) and second as the
"FORM=..." option in the "-sproperties=..." block. Once this makes the
GhostScript command line unnecessarily complicated (I don't know a
situation where one needs to define two different paper sizes here) an
second, it breaks Foomatic. A Foomatic option can modify the GhostScript
command line only in one point, not in two or more, or it can prepend
one PostScript command block. Prepending PostScript and modifying the
command line by one option is also not possible. So I suggest that you
change Omni in a way, that it uses the paper size given to GhostScript
via "-sPAPERSIZE=..." or prepended PostScript for the whole process,
instead of expecting a second definition of the paper size from the
user. For Foomatic you should then generate an option similar to the
already existing option "2.xml", a PostScript-prepending "PageSize"
option, only for Omni, which enables only the available page sizes for
every printer used with the Omni driver. The PostScript-prepending
version should be preferred against a version using "-sPAPERSIZE=...",
because Foomatic extracts the page dimension numbers from the PostScript
commands to set up the "PaperDimension" section in CUPS PPD files.
5. Omni printer properties information: Some printers have incorrect
properties in Omni: The HP LaserJet 1100 has a maximum resolution of 600
dpi, Omni allows only 300 dpi, the "ljet4" driver of GhostScript does
600 dpi on this printer without problems. The HP LaserJet 2100 and 3200
models have 1200 dpi and Omni allows only 600 dpi. Perhaps there are
wrong properties for many other printers. Many printer properties you
find on www.linuxprinting.org and also in the repository of GIMP-Print.
6. Omni driver: Borders broken: The LaserJet 2100 driver reports the
correct paper size (I manually started GhostScript, without spooler)
when printing the CUPS test page, but the hole test page is shifted by
around 6mm to the right and 3mm to the top. This leads to the head line
"Printer Test Page" being cut at the top. It seems that it is shifted by
the non-printable left and lower borders. The "ljet4" and the "pxlmono"
driver of GhostScript handle that correctly. They center the page
correctly. Also the output on the Epson Stylus 1270 is shifted to the
upper right by more or less the same distances. This makes the driver
unusable for most applications.
7. Omni driver: On the Epson Stylus Photo 1270 Cyan, Yellow, Magenta,
Red, Green, and Blue look correctly, but light to middle grays are very
yellowish (720 dpi, Steinberg dither, CcMmYK). If this happens only for
a part of the dithering modes, these dithering modes should be excluded
from this printer.
8. Omni driver: The printout on the Epson Stylus Photo 1270 always stops
around 7cm before the end of the page (the rendering process is still
going on, last two bands), this is independent from the dithering
algorithm.
9. Omni-driver: Fast diffusion dithering on the Epson Stylus Photo 1270
messes up the printout completely. One sees the test page twice, one at
the side of the other, each with half the original width and the full
original hight. In this case problem (7.) does not appear, but problem
(8.) appears.
10. Omni driver: Omni is terribly slow, on my 350 Mhz test machine
rendering a 600x600 dpi test page for the LaserJet 2100 needs 2:30 min,
the printout is done in a few seconds. All GhostScript drivers
("pxlmono", "ljet4", and even "lj5gray") are WAY faster. This way Omni
is absolutely unsuitable for laser printers.
I hope this report helps to make Omni better.
Crutcher, have you the same problems with Omni? Will it be fully
integrated in Red Hat 7.2?
Till
_______________________________________________
Omniprint-developer mailing list
Omn...@li...
https://lists.sourceforge.net/lists/listinfo/omniprint-developer
|
