Re: [Omniprint-developer] Omni still very buggy

[Pete Z. <pz...@us...>]

Till,
Thanks for the updates.  I will look into these items.

As far as number 10 goes and doing mono-dithering, we end up using
RGB generated by Ghostscript and then map it to a gray dither.  This
takes a long time and that's why the code was put in to use the internal
mono dither in Ghostscript.  As time permits, we can go back and
implement other algorithms.

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/09/2001
01:54:54 PM

Sent by:  omn...@li...


To:   Pete Zannucci/Austin/IBM@IBMUS
cc:   Omn...@so...
Subject:  Re: [Omniprint-developer] Omni still very buggy




Here a version of the message for the mailing list with the attached
pages removed. The message got too big for the mailing list limit (40k).
I have uploaded the pages to

   http://mandrakesoft.com/~tkamppeter/samplepages/

   Till

---------Original message----------

All driver tests done with manual usage of GhostScript (no spooler, no
Foomatic used, comand line example attached), A4 paper, test pages as
attached, GhostScript 6.51, Omni 0.4.3 (no CVS).

Foomatic reports about the CVS from the day of the original e-mail.

Pete Zannucci wrote:
>
> 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.
>

Can one not simply say in the Omni/Foomatic/foomaticDB

hp-laserjet_4si_4si_mx:439570
hp-laserjet_4si_4si_mx:HP-LaserJet_4Si_Mx

so that one Omni model/library is assigned to two printer models?

> 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?
>

It is the following:

The user has a certain paper in his printer, with a certain size. When
he wants to print a document it is most convenient for him to set the
page size at one point of the software. For me it does not make sense
when the user has to supply two completely dofferent options at two
different places to set the page size, as it is now with Omni. According
to the documentation you have to give the option "form=FORM_A4" in the
"properties" string and in addition the usual GhostScript option which
is either "-sPAPERSIZE=a4" or a prepended PostScript command. Foomatic
is also made in a way, that the setting of an option always modifies
only one point of the command line, not various points. So it is
much-more user-friendly and much easier for the implementation of
Foomatic data to make Omni simply take the paper size which the user has
supplied by standard GhostScript options. For paper sizes which
GhostScript does not support one can always give the size numerically by
the prepended PostScript:

   % PostScript for A4 paper
   <</PageSize[595 842]/ImagingBBox null>>setpagedevice

> 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?
>

I understand the problem for the 2100 and 3200. They need PCL-XL for
1200 dpi and PCL-XL is not implemented in Omni. But the HP LaserJet 1100
understands only PCL <= 5 and does 600 dpi with the "ljet4" GhostScript
driver. So it should not be a problem for Omni to print 600 dpi on the
LJ 1100.

GIMP-Print also does not print more than 600 dpi on the 2100 and 3200,
also due to lack of PCL-XL, but it prints with 600 dpi on the LaserJet
1100.

> 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.
>

I have attached all files which I have printed. they all show the same
shift. The RedHat test page (testpage-a4.ps) is a static PostScript
file, as an application would produce. The CUPS test page (testprint*)
is a PostScript program which asks the PostScript interpreter for the
device propertes as margins, paper size, and resolution. All data is
printed onto the page, and in addition, there is drawn a black rectangle
on the border of the imageable area (paper size minus unprintable
margins. I have given all GhostScript calls manually, without using a
spooler or Foomatic (see attached sample command line gs_omni_cmd.txt),
so the problem must be the driver. I have used GhostScript 6.51 with
stock Omni 0.4.3, no CVS.

> 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.
>

Perhaps you should contact the GIMP-Print team, with GIMP-Print this
printer works even better than under Windows. They can tell you probably
which gamma and colour balancing settings GIMP-Print uses or whether
even special tricks are applied. I have done the tests on an Epson
Stylus 1290 but as I know this model has the same inks and in addition,
it prints perfectly with the GIMP-Print driver for the 1270.

> 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.
>

The form is A4 and the resolution is 720x720 dpi. It seems to be
independent of the document. The problem appears with both the CUPS and
the RedHat test page. The used RedHat test page was the A4 version
(pages attached).

I have aso tried 360x360 dpi on the Epson Stylus 1270, but this mode is
completely broken: Page shifted as with 720x720dpi. Printing (not
rendering) of page needs around 2 hours (seems that the printer prints
with only one nozzle), paper completely flooded with black, no magenta
came out, "Linux Mandrake" and yellow star very greenish. Here you
should perhaps also contact the GIMP-Print guys. But in this mode only 2
cm of the lower border are missing.

> 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.
>

Is there not an XML description for every printer? One should have a
list of suitable dither algorithms there.

> 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.

There should be a way that a driver with its own dithering algorithms
can also be fast, GIMP-Print has also its own dithering algorithms and
it does not let a laser printer wait for ages to get a complete page.

   Till
cat /usr/share/printer-testpages/testpage-a4.ps | gs -q -dSAFER -dBATCH
-dNOPAUSE -sPAPERSIZE=a4 -sDEVICE=omni -sDeviceName=HP_LaserJet_2100
-sproperties="resolution=RESOLUTION_300_X_300 form=FORM_A4" -sOutputFile=-
- > testfileLJ