omniprint-developer — Discussion of the Omni driver by developers

[Omniprint-developer] Re: [Gimp-print-devel] Re: Problem on the stp web page/with Omni

[Robert L K. <rl...@al...>]

   Date: Wed, 31 Oct 2001 02:28:35 +0100
   From: Till Kamppeter <til...@gm...>

   I mean ONE of the three methods, not all at the same time.

OK, that makes more sense.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for Gimp Print/stp --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Omniprint-developer] Re: [Gimp-print-devel] Re: Problem on the stp web page/with Omni

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

I mean ONE of the three methods, not all at the same time.

    Till


Robert L Krawitz wrote:

>    Date: Wed, 31 Oct 2001 01:11:07 +0100
>    From: Till Kamppeter <til...@gm...>
> 
>        2. A cron job checks the download sites of Omni and GIMP-Print. When
> 	  a new release appears, the update starts.
> 
>        3. The server account is subscribed to the GIMP-Print and Omni
> 	  mailing lists and a script is started through the ~/.forward file.
> 	  When a mail announcing a new release arrives, the update is
> 	  triggered. This requires the subject line of the announcement
> 	  following certain rules, as always being:
> 
> 	     ANNOUNCE: gimp-print-4.2.1 released!
> 
> If you must, but this seems redundant with (2).
> 
> 

[Omniprint-developer] Re: Problem on the stp web page/with Omni

[Robert L K. <rl...@al...>]

   Date: Tue, 30 Oct 2001 17:05:40 -0500
   From: Grant Taylor <gt...@pi...>

   >>>>> Till Kamppeter <til...@gm...> writes:

   > I would suggest to always have the newest GIMP-Print/Omni
   > Foomatic data online and some older versions (3 or so). The older
   > versions should be chosen depending on when changes to the
   > Foomatic data of a certain GIMP-Print version occur. Every time
   > when a new GIMP-Print version appears and its Foomatic data is
   > not compatible to the previous version, a new Foomatic data set
   > should be added. Then also the oldest can be removed. The
   > GIMP-Print 4.0 data should conserved for some more tims as
   > "gimp-print-4.0", for GIMP-Print 4.2.0 there should be a
   > "gimp-print-4.2.0", when 4.2.2 will need new Foomatic data there
   > will be a "gimp-print-4.2.2", if there are more than three driver
   > entries for GIMP-Print 4.2.x, the oldest will be removed.

   Ugh.  No, this is the ugliness we want to avoid.  Use "omni" and
   "omni-unstable"; and "gimp-print" and "gimp-print-unstable".  Or
   perhaps "-devel".

Ick.  Not to you, Grant.  I like your approach to it.  It's the
versioning stuff I want to stay away from.

<soapbox>

For drivers like Gimp-print (4.2, at any rate) and Omni, there's *no*
reason for people to download Foomatic kits from linuxprinting.org.
For legacy drivers that are never going to be changed (like most of
the Ghostscript drivers), it's reasonable to do this.  For
current-generation drivers, which support tons of printers with tons
of features, and are largely data-driven (even if Gimp-print currently
compiles in its data, the interfaces are data-driven), static kits are
absolutely the wrong way to go.  The distribution should build its own
foomatic kit.  Peter Zannucci and I discussed this on the Foomatic
development list a while back, and as I recall we were in complete
agreement on this.

The *only* reason to have a snapshot of this in the database is for
the benefit of the printer and driver listings on the
linuxprinting.org web site.

</soapbox>

For Gimp-print, I think having "gimp-print" and "gimp-print-devel"
listings in the database is reasonable.  "gimp-print" gets populated
from the latest stable release (4.2.0, when we release it, and then
each 4.2.x point release as it comes along -- our rules do allow
adding printers and certain kinds of features in stable upgrades).
"gimp-print-devel" gets populated from the latest development release
(not the CVS repository, please).  Omni should make a similar decision
based on their release rules.

   When gimp makes a new release, switch the website to that data.
   Don't try to track all manner of previous releases; that's
   hopeless.  Just flog gimp-print binary distributors into shipping
   the foomatic kits no matter what else they may do.  Perhaps Robert
   would put a two-line "thou shalt configure your gimp-print thusly
   for binary distribution" blurb in his readme.

That's actually a good suggestion.  Now let's just decide what those
rules should be.

   > All options must be versioned, too (ex: option ID:
   > "gimp-print-4.2.0-PageSize", file name:
   > "gimp-print-4.2.0-PageSize.xml", short name: "PageSize", long name:
   > "Page Size"), so that the different GIMP-Print versions do not
   > interfere.

   Yes, but only inasmuch as there is a normal and -unstable driver name.

Perhaps we should use the soname of the library for this purpose?  If
you use shared libraries, you won't be able (without some nasty
LD_LIBRARY_PATH hacking) to have 4.2.0 and 4.2.1 installed
simultaneously, because the library sonames will be the same.

   > This requires from both the authors of Omni and GIMP-Print that
   > they inform Grant and me about every release and which release
   > needs new Foomatic data, so that we can keep linuxprinting.org
   > up-to-date.

   For all releases just do the update exercise regardless; you pretty
   much do this now as a function of making libgimpprint and omni
   rpms.

Right.  Just grab each release as it comes along.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for Gimp Print/stp --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Omniprint-developer] Re: Problem on the stp web page/with Omni

[Robert L K. <rl...@al...>]

   Date: Wed, 31 Oct 2001 01:11:07 +0100
   From: Till Kamppeter <til...@gm...>

       2. A cron job checks the download sites of Omni and GIMP-Print. When
	  a new release appears, the update starts.

       3. The server account is subscribed to the GIMP-Print and Omni
	  mailing lists and a script is started through the ~/.forward file.
	  When a mail announcing a new release arrives, the update is
	  triggered. This requires the subject line of the announcement
	  following certain rules, as always being:

	     ANNOUNCE: gimp-print-4.2.1 released!

If you must, but this seems redundant with (2).

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for Gimp Print/stp --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Omniprint-developer] Re: Problem on the stp web page/with Omni

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

Grant Taylor wrote:

> Probably the least intrusive thing for driver folks is for you to use
> one of those web page change polling services to be told about
> updates.


What are these web page change services? How do they work? Which 
programs do I need?

> But if Robert or Pete can work up a ping of some sort,
> that's great.
>


This means that they give a signal to trigger the script?

 
> 
>>The authors should also have a decent comment in the driver XML files. 
>>
> 
> Yes, help them out with this; IIRC we pretty much provided the
> templates in the first place.  And of course it's so horribly painful
> to edit our file format ;(
>


I could do so and send patches containing the text. They can also send 
me the text in HTML and then I make an appropriate patch for the driver 
source tarballs out of that.

   Till

[Omniprint-developer] Re: Problem on the stp web page/with Omni

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

We will take a look back through these last several notes and see how we
can help solidify
what we are doing from a driver perspective.  Hopefully we can make
supporting the different
drivers as transparent as possible while we add additional support and
features.

Thanks,


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


Grant Taylor <gt...@pi...> on 10/30/2001 05:26:22 PM

To:   Till Kamppeter <til...@gm...>
cc:   Robert L Krawitz <rl...@al...>,
      gim...@so..., Pete Zannucci/Austin/IBM@IBMUS,
      Omn...@so...
Subject:  Re: Problem on the stp web page/with Omni



>>>>> Till Kamppeter <til...@gm...> writes:

> triggered by one of the following mechanisms:

Probably the least intrusive thing for driver folks is for you to use
one of those web page change polling services to be told about
updates.  But if Robert or Pete can work up a ping of some sort,
that's great.

> The authors should also have a decent comment in the driver XML files.

Yes, help them out with this; IIRC we pretty much provided the
templates in the first place.  And of course it's so horribly painful
to edit our file format ;(

--
Grant Taylor - gt...@pi... - http://www.picante.com/~gtaylor/
    Linux Printing Website and HOWTO:  http://www.linuxprinting.org/

[Omniprint-developer] Re: Problem on the stp web page/with Omni

[Grant T. <gt...@pi...>]

>>>>> Till Kamppeter <til...@gm...> writes:

> triggered by one of the following mechanisms:

Probably the least intrusive thing for driver folks is for you to use
one of those web page change polling services to be told about
updates.  But if Robert or Pete can work up a ping of some sort,
that's great.

> The authors should also have a decent comment in the driver XML files. 

Yes, help them out with this; IIRC we pretty much provided the
templates in the first place.  And of course it's so horribly painful
to edit our file format ;(

--
Grant Taylor - gt...@pi... - http://www.picante.com/~gtaylor/
    Linux Printing Website and HOWTO:  http://www.linuxprinting.org/

[Omniprint-developer] Re: Problem on the stp web page/with Omni

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

So I will make it this way:

The following driver names will be used:

    gimp-print
    gimp-print-unstable
    omni-unstable

gimp-print will always carry the data of the newest GIMP-Print 
(currently 4.2.x). gimp-print-unstable will carry the newest release of 
the unstable series (currently 4.3). From Omni there is only a 
development version, so there is only an "omni-unstable" driver entry.

Updating will not be done by the usual install script for the rest of 
the site. It will be done by a special script, triggered by one of the 
following mechanisms:

    1. Manually when we get notice of a new release of one of the
       drivers. For this we need the info of a new release appearing as
       fast as possible, also from the Omni folks.

    2. A cron job checks the download sites of Omni and GIMP-Print. When
       a new release appears, the update starts.

    3. The server account is subscribed to the GIMP-Print and Omni
       mailing lists and a script is started through the ~/.forward file.
       When a mail announcing a new release arrives, the update is
       triggered. This requires the subject line of the announcement
       following certain rules, as always being:

          ANNOUNCE: gimp-print-4.2.1 released!

The script should do the following:

    1. Download new driver release

    2. "make" but not "make install" it

    3. Remove old option and driver XML files from server.

    4. "foomatic-kitload" the new Foomatic data.

    5. e-mail the successful execution to Grant and me.

If one of these steps failed the script should not execute any 
subsequent steps and mail a log to Grant and me.

This keeps the server always as up-to-date as possible, especially when 
the script is triggered by a mailing list announcement or by an hourly 
cron job.

For this the authors should cooperate by providing machine-readable 
announcement titles, easy recognizable robot-downloadable source 
tarballs, foomatic data being built always in the same directory, always 
the same steps for building being used.

The authors should also have a decent comment in the driver XML files. 
It should give a good, human-readable description of the driver, tell 
that the Foomatic data is only for the current release (include version 
number here), cross-reference between development and stable release 
with links, warn users about possible bugs in unstable and that unstable 
can be useful for them when stable does not support their printer.

WDYT about that?

    Till


Grant Taylor wrote:

>>>>>>Till Kamppeter <til...@gm...> writes:
>>>>>>
> 
>>I would suggest to always have the newest GIMP-Print/Omni Foomatic
>>data online and some older versions (3 or so). The older versions
>>should be chosen depending on when changes to the Foomatic data of a
>>certain GIMP-Print version occur. Every time when a new GIMP-Print
>>version appears and its Foomatic data is not compatible to the
>>previous version, a new Foomatic data set should be added. Then also
>>the oldest can be removed. The GIMP-Print 4.0 data should conserved
>>for some more tims as "gimp-print-4.0", for GIMP-Print 4.2.0 there
>>should be a "gimp-print-4.2.0", when 4.2.2 will need new Foomatic
>>data there will be a "gimp-print-4.2.2", if there are more than
>>three driver entries for GIMP-Print 4.2.x, the oldest will be
>>removed.
>>
> 
> Ugh.  No, this is the ugliness we want to avoid.  Use "omni" and
> "omni-unstable"; and "gimp-print" and "gimp-print-unstable".  Or
> perhaps "-devel".
> 
> When a user installs a new gimp-print foomatic kit, make kitload
> automagically uninstall the previous one, and respin all existing
> configurations against the new data.
> 
> When gimp makes a new release, switch the website to that data.  Don't
> try to track all manner of previous releases; that's hopeless.  Just
> flog gimp-print binary distributors into shipping the foomatic kits no
> matter what else they may do.  Perhaps Robert would put a two-line
> "thou shalt configure your gimp-print thusly for binary distribution"
> blurb in his readme.
> 
> 
>>All options must be versioned, too (ex: option ID:
>>"gimp-print-4.2.0-PageSize", file name:
>>"gimp-print-4.2.0-PageSize.xml", short name: "PageSize", long name:
>>"Page Size"), so that the different GIMP-Print versions do not
>>interfere.
>>
> 
> Yes, but only inasmuch as there is a normal and -unstable driver name.
> 
> Don't go all whacky putting in actual numbers; this will break many
> things including upgrades.
> 
> The gimp-print release cycle allows the foomatic generator code there
> to know if it needs to put -devel on the end or not, so this can be
> all automagic.  Dunno what goes on in OMNI.
> 
> 
>>This requires from both the authors of Omni and GIMP-Print that they
>>inform Grant and me about every release and which release needs new
>>Foomatic data, so that we can keep linuxprinting.org up-to-date.
>>
> 
> For all releases just do the update exercise regardless; you pretty
> much do this now as a function of making libgimpprint and omni rpms.
> 
> 
>>The impact for the database is probably not so high, the server has 
>>plenty of resources
>>
> 
> That's not the point.  *We* don't scale that way, and even if we were
> to arrange to it wouldn't actually solve a problem.
> 
> 
>>>Yes, this highlights one thing we need in foomatic: dependency
>>>checks.  PDQ has a scheme for this, whereby you plug in shell code to
>>>
> 
>>You mean that Foomatic should check which drivers are installed on
>>the local machine (GS driver in "gs --help", filter in $PATH, for
>>UPP driver upp file available, and version check, shell script for
>>doing these checks should be in a field of the driver's DB entry)
>>and "foomatic-configure -O" only list ths combos which will work on
>>the current system?
>>
> 
> Foomatic shouldn't be that clever.  It should simply offer a warning
> at configure time saying "such-and-such driver is not present, setting
> up anyway".  People can either install the driver or pick a different
> one.
> 
> Not listing it with -O means that people will never figure out that
> there is a or a better driver in the world for them.  And the -O is
> used for autodetection as well, remember, so there may be no pruning
> there.
> 
> We can get fancy about how to find and install missing drivers later;
> first things first.
> 

[Omniprint-developer] Re: Problem on the stp web page/with Omni

[Grant T. <gt...@pi...>]

>>>>> Till Kamppeter <til...@gm...> writes:

> I would suggest to always have the newest GIMP-Print/Omni Foomatic
> data online and some older versions (3 or so). The older versions
> should be chosen depending on when changes to the Foomatic data of a
> certain GIMP-Print version occur. Every time when a new GIMP-Print
> version appears and its Foomatic data is not compatible to the
> previous version, a new Foomatic data set should be added. Then also
> the oldest can be removed. The GIMP-Print 4.0 data should conserved
> for some more tims as "gimp-print-4.0", for GIMP-Print 4.2.0 there
> should be a "gimp-print-4.2.0", when 4.2.2 will need new Foomatic
> data there will be a "gimp-print-4.2.2", if there are more than
> three driver entries for GIMP-Print 4.2.x, the oldest will be
> removed.

Ugh.  No, this is the ugliness we want to avoid.  Use "omni" and
"omni-unstable"; and "gimp-print" and "gimp-print-unstable".  Or
perhaps "-devel".

When a user installs a new gimp-print foomatic kit, make kitload
automagically uninstall the previous one, and respin all existing
configurations against the new data.

When gimp makes a new release, switch the website to that data.  Don't
try to track all manner of previous releases; that's hopeless.  Just
flog gimp-print binary distributors into shipping the foomatic kits no
matter what else they may do.  Perhaps Robert would put a two-line
"thou shalt configure your gimp-print thusly for binary distribution"
blurb in his readme.

> All options must be versioned, too (ex: option ID:
> "gimp-print-4.2.0-PageSize", file name:
> "gimp-print-4.2.0-PageSize.xml", short name: "PageSize", long name:
> "Page Size"), so that the different GIMP-Print versions do not
> interfere.

Yes, but only inasmuch as there is a normal and -unstable driver name.

Don't go all whacky putting in actual numbers; this will break many
things including upgrades.

The gimp-print release cycle allows the foomatic generator code there
to know if it needs to put -devel on the end or not, so this can be
all automagic.  Dunno what goes on in OMNI.

> This requires from both the authors of Omni and GIMP-Print that they
> inform Grant and me about every release and which release needs new
> Foomatic data, so that we can keep linuxprinting.org up-to-date.

For all releases just do the update exercise regardless; you pretty
much do this now as a function of making libgimpprint and omni rpms.

> The impact for the database is probably not so high, the server has 
> plenty of resources

That's not the point.  *We* don't scale that way, and even if we were
to arrange to it wouldn't actually solve a problem.

>> Yes, this highlights one thing we need in foomatic: dependency
>> checks.  PDQ has a scheme for this, whereby you plug in shell code to

> You mean that Foomatic should check which drivers are installed on
> the local machine (GS driver in "gs --help", filter in $PATH, for
> UPP driver upp file available, and version check, shell script for
> doing these checks should be in a field of the driver's DB entry)
> and "foomatic-configure -O" only list ths combos which will work on
> the current system?

Foomatic shouldn't be that clever.  It should simply offer a warning
at configure time saying "such-and-such driver is not present, setting
up anyway".  People can either install the driver or pick a different
one.

Not listing it with -O means that people will never figure out that
there is a or a better driver in the world for them.  And the -O is
used for autodetection as well, remember, so there may be no pruning
there.

We can get fancy about how to find and install missing drivers later;
first things first.

--
Grant Taylor - gt...@pi... - http://www.picante.com/~gtaylor/
    Linux Printing Website and HOWTO:  http://www.linuxprinting.org/

[Omniprint-developer] Re: Problem on the stp web page/with Omni

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

Grant Taylor wrote:

> Yes, this is likely to be a problem.  We want to have only a few
> popular versions online to prevent a new performance problem ;)
> 
> Till, the thing to do is to blow away the db/ part of the served
> foomatic checkout (ie ~gtaylor/lporg_html/foomatic/db/) each time we
> update, and have a script that does a foomatic-kitload of a gimp or
> two and omni.  Under no circumstances put anything that comes as a kit
> into our cvs.
> 
> We will need version numbers, alas, unless we only provide for
> "stable"; this has an unpleasing property of making configuration
> version specific when it shouldn't be.  I don't like that one bit.
> Perhaps we should use the names gimp-print and gimp-print-devel or
> somesuch.  Then the problem is minimal.
> 


I would suggest to always have the newest GIMP-Print/Omni Foomatic data 
online and some older versions (3 or so). The older versions should be 
chosen depending on when changes to the Foomatic data of a certain 
GIMP-Print version occur. Every time when a new GIMP-Print version 
appears and its Foomatic data is not compatible to the previous version, 
  a new Foomatic data set should be added. Then also the oldest can be 
removed. The GIMP-Print 4.0 data should conserved for some more tims as 
"gimp-print-4.0", for GIMP-Print 4.2.0 there should be a 
"gimp-print-4.2.0", when 4.2.2 will need new Foomatic data there will be 
a "gimp-print-4.2.2", if there are more than three driver entries for 
GIMP-Print 4.2.x, the oldest will be removed.

All options must be versioned, too (ex: option ID: 
"gimp-print-4.2.0-PageSize", file name: "gimp-print-4.2.0-PageSize.xml", 
short name: "PageSize", long name: "Page Size"), so that the different 
GIMP-Print versions do not interfere.

For Omni it should be proceeded in the same way.

This requires from both the authors of Omni and GIMP-Print that they 
inform Grant and me about every release and which release needs new 
Foomatic data, so that we can keep linuxprinting.org up-to-date. If the 
authors have special wishes about what to keep and which version's 
Foomatich data to keep and which to drop we can do i appropriately, too. 
I also ask the GIMP-Print/Omni authors to change their Foomatic data 
generation scripts, so that they produce versioned option and driver 
files (as shown above) in all coming releases of their drivers.

The impact for the database is probably not so high, the server has 
plenty of resources, especially where the printer/driver combos are 
computed by C code and not by Perl any more. There is also a lot of free 
disk space. For downloading one could package the CVS (=Foomatic core 
database without GIMP-Print/Omni kits) and the GIMP-Print/Omni kits of 
each currently supported GIMP-Print/Omni version separately. A user 
without need for GIMP-Print/Omni will get the fast small core database, 
a distro takes the core and generates the kits from the actually used 
GIMP-Print and Omni source tarballs. A user who wants to have Foomatic 
data for GIMP-Print/Omni in his local database downloads the core plus 
the desired kit from linuxprinting.org.

The core is already automatically made available every 24 hours from 
CVS. For the kits one could compile the new releases of GIMP-Print and 
Omni on the linuxprinting server and then set up table with the 
locations of the kits, so that our install script installs the core from 
CVS and adds all kits from the table. Obsolete kits will simply be 
removed from the table to not get in when the database is updated. The 
database will be deleted before rebuild to remove obsolete drivers.


> Yes, this highlights one thing we need in foomatic: dependency
> checks.  PDQ has a scheme for this, whereby you plug in shell code to
> check that various executables ro anything else you want are present
> on the system; we'll need something along these lines to help guard
> against gratuitously poor foomatic/gimp-print pairings.
> 

You mean that Foomatic should check which drivers are installed on the 
local machine (GS driver in "gs --help", filter in $PATH, for UPP driver 
upp file available, and version check, shell script for doing these 
checks should be in a field of the driver's DB entry) and 
"foomatic-configure -O" only list ths combos which will work on the 
current system?

    Till

Re: [Omniprint-developer] New Foomatic Generator

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

Till,
Thank you, we really appreciate your help in this area.
I am currently looking at a couple of the other problems that you told us
about.
I will pull down your updates and integrate them into our code.
I am updating the HP 1100 and going back and checking on what can be done
about the Epson items.  I will send you a note as to the outcome along with
these
current items.
I see you are on the list for the Print Summit.  Look forward to meeting
you there
and working though some of the other issues.

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/21/2001
01:18:45 PM

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


To:   Omn...@so..., Pete Zannucci/Austin/IBM@IBMUS
cc:
Subject:  [Omniprint-developer] New Foomatic Generator



Oi,

I have done major changes on the Foomatic data generator
Omni/Foomatic/Foomatic.cpp to address many of the issues which I
reported in the mails before. It has the following changes:

1. Clean-up of printer names: There is no manufacturer called "KS" or
"HP-LaserJet". Now all manufacturer names are correctly resolved.
Generic drivers (as "Generic 9-pin 80 col.") are under the manufacturer
name "Generic". For four printers I didn't know the manufacturer name
and I put them under "Others":

    BJ-230
    HDMF-NONE-FF
    LG-GIP 3000Q/3000+
    VP-6570K

Here I ask you for help. Which are the manufacturers of these printers.
The BJ-230 is probably not a Canon, because Omni has already a BJ-230
under "Canon".

2. Removed slashes and parantheses from the XML file names, this
prevented some files from being written.

3. Made the Foomatic-database ID matching mechanism more reliable.

4. Made the page size (form) option not only setting the "form=..." in
"-sproperties=...", but also adding a PostScript command to tell the
page size to GhostScript itself ("-sPAPERSIZE=..." does not support all
paper sizes which Omni supports).

5. Made the "-smonodither=GSMONO" option user-switchable, so that the
user can choose between speed and quality. GhostScript dithering is the
default.

6. Changed the Foomatic names of the options and choices to better fit
to the names of other drivers, to PPD conventions, or simply to be
shorter to type.

7. Changed the comment of the Omni-generated printer database entries
and removed the printer name out of the "consumables" comment.

8. Because the generated Foomatic data is only usable on a machine with
installed Foomatic, Foomatic printer entries for printers already listed
in Foomatic are not generated any more. So installing the Foomatic data
generated by Omni with the help of "foomatic-kitload" does not overwrite
any files.

The modified Foomatic.cpp file and some additional files you can download
on

    http://mandrakesoft.com/~tkamppeter/Omni-New-Foomatic.tar.gz

The files are the following:

1. Foomatic.cpp: The modified Foomatic data generator, put it into the
Omni/Foomatic/ directory and then build as usual.

2. Omni-Foomatic.patch: This is a patch to make the new Foomatic.cpp out
of the one currently on CVS. Here you can easily see my changes.

3. foomatic-omni-printerlist: Run this on a machine with installed
Foomatic to get the table for the printer name/Foomatic-ID relations.

4. newDB: the Foomatic-ID table generated with foomatic-omni-printerlist
from the current CVS of Foomatic. Note that the format has changed,
between manufacturer and model is a dash now (the new Foomatic.cpp does
not work with the old format).

During my tests of this new Foomatic data I found two additional bugs in
Omni:

1. Okidata ML 321 only spills an empty page instead of printing the job,
switching between the three compatibility modes "IBM Graphics printer",
"IBM Proprinter", and "Epson FX" does not help. I have checked that it
is not caused by Foomatic. Once the Foomatic-generated GhostScript
command line is absolutely correct, and second, The same problem happens
when calling GhostScript manually.

2. Epson Stylus Photo 1290 prints gibberish when a PostScript command
for the paper size is prepended to the PostScript file. This is also not
caused by Foommatic. The command line is correct and manually calling
GhostScript with a document with the PostScript for the paper size
inserted leads to the same problem. Removing the PostScript command
reproduces the image again, but with some part at the top missing
(because GhostScript assumes Letter size without the PostScript
command). These tests are done with A4 paper size.

The HP LaserJet 2100 prints correctly, with the Foomatic-supplied
PostScript command the image is printed completely in A4 format and with
the correct y offset, it is only shifted to the right (as I told you
already before). So the Foomatic data must be correct.

    Till



_______________________________________________
Omniprint-developer mailing list
Omn...@li...
https://lists.sourceforge.net/lists/listinfo/omniprint-developer

[Omniprint-developer] New Foomatic Generator

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

Oi,

I have done major changes on the Foomatic data generator 
Omni/Foomatic/Foomatic.cpp to address many of the issues which I 
reported in the mails before. It has the following changes:

1. Clean-up of printer names: There is no manufacturer called "KS" or 
"HP-LaserJet". Now all manufacturer names are correctly resolved. 
Generic drivers (as "Generic 9-pin 80 col.") are under the manufacturer 
name "Generic". For four printers I didn't know the manufacturer name 
and I put them under "Others":

    BJ-230
    HDMF-NONE-FF
    LG-GIP 3000Q/3000+
    VP-6570K

Here I ask you for help. Which are the manufacturers of these printers. 
The BJ-230 is probably not a Canon, because Omni has already a BJ-230 
under "Canon".

2. Removed slashes and parantheses from the XML file names, this 
prevented some files from being written.

3. Made the Foomatic-database ID matching mechanism more reliable.

4. Made the page size (form) option not only setting the "form=..." in 
"-sproperties=...", but also adding a PostScript command to tell the 
page size to GhostScript itself ("-sPAPERSIZE=..." does not support all 
paper sizes which Omni supports).

5. Made the "-smonodither=GSMONO" option user-switchable, so that the 
user can choose between speed and quality. GhostScript dithering is the 
default.

6. Changed the Foomatic names of the options and choices to better fit 
to the names of other drivers, to PPD conventions, or simply to be 
shorter to type.

7. Changed the comment of the Omni-generated printer database entries 
and removed the printer name out of the "consumables" comment.

8. Because the generated Foomatic data is only usable on a machine with 
installed Foomatic, Foomatic printer entries for printers already listed 
in Foomatic are not generated any more. So installing the Foomatic data 
generated by Omni with the help of "foomatic-kitload" does not overwrite 
any files.

The modified Foomatic.cpp file and some additional files you can download on

    http://mandrakesoft.com/~tkamppeter/Omni-New-Foomatic.tar.gz

The files are the following:

1. Foomatic.cpp: The modified Foomatic data generator, put it into the 
Omni/Foomatic/ directory and then build as usual.

2. Omni-Foomatic.patch: This is a patch to make the new Foomatic.cpp out 
of the one currently on CVS. Here you can easily see my changes.

3. foomatic-omni-printerlist: Run this on a machine with installed 
Foomatic to get the table for the printer name/Foomatic-ID relations.

4. newDB: the Foomatic-ID table generated with foomatic-omni-printerlist 
from the current CVS of Foomatic. Note that the format has changed, 
between manufacturer and model is a dash now (the new Foomatic.cpp does 
not work with the old format).

During my tests of this new Foomatic data I found two additional bugs in 
Omni:

1. Okidata ML 321 only spills an empty page instead of printing the job, 
switching between the three compatibility modes "IBM Graphics printer", 
"IBM Proprinter", and "Epson FX" does not help. I have checked that it 
is not caused by Foomatic. Once the Foomatic-generated GhostScript 
command line is absolutely correct, and second, The same problem happens 
when calling GhostScript manually.

2. Epson Stylus Photo 1290 prints gibberish when a PostScript command 
for the paper size is prepended to the PostScript file. This is also not 
caused by Foommatic. The command line is correct and manually calling 
GhostScript with a document with the PostScript for the paper size 
inserted leads to the same problem. Removing the PostScript command 
reproduces the image again, but with some part at the top missing 
(because GhostScript assumes Letter size without the PostScript 
command). These tests are done with A4 paper size.

The HP LaserJet 2100 prints correctly, with the Foomatic-supplied 
PostScript command the image is printed completely in A4 format and with 
the correct y offset, it is only shifted to the right (as I told you 
already before). So the Foomatic data must be correct.

    Till

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.

Re: [Omniprint-developer] Omni still very buggy

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

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.

Thanks,


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...> on 10/12/2001 06:23:15 PM

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



I have downloaded Omni 0.5.0 and get the following error when compiling it:

make[1]: Entering directory
`/home/tkamppeter/rpm/BUILD/printer-drivers-1.0/ghostscript-6.51/src/Omni/XMLParser'

c++ -fPIC -Wall -I .. -g -DDEBUG=1 -c MyErrorHandler.cpp
c++ -fPIC -Wall -I .. -g -DDEBUG=1 -c OmniDomParser.cpp
OmniDomParser.cpp: In method `bool OmniDomParser::processDriver
(xmlNode *)':
OmniDomParser.cpp:4732: `parseSize' undeclared (first use this
function)
OmniDomParser.cpp:4732: (Each undeclared identifier is reported only
once for each function it appears in.)
make[1]: *** [OmniDomParser.o] Error 1
make[1]: Leaving directory
`/home/tkamppeter/rpm/BUILD/printer-drivers-1.0/ghostscript-6.51/src/Omni/XMLParser'

make: *** [XMLParser.make] Error 2
error: Bad exit status from /home/tkamppeter/tmp/rpm-tmp.80692 (%build)


RPM build errors:
     Bad exit status from /home/tkamppeter/tmp/rpm-tmp.80692 (%build)

It seems that something is missing in Omni.

    Till



Pete Zannucci wrote:

> Till,
>
> Thanks for bringing the problem with A4 forms to my attention.
> I am investigating what in the commands going down is causing
> this.  The older Color Stylus printers handle it fine but the newer
> printers are not.
> It looks like the form size information is not set up correctly for the
> printer.
>
>
>
>
> 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...
>
>
>

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

Re: [Omniprint-developer] Omni still very buggy

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

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

Re: [Omniprint-developer] Omni still very buggy

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

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

Re: [Omniprint-developer] Omni still very buggy

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

I do not mean that you should change the options of the GhostScript
command line. Foomatic can give any form of option on the command line
which it bulds (as the "driverval"). I mean that you should change the
option names with which the user and/or a frontend is dealing (the
"shortname" and the "longname"), so you only need to change Foomatic,
not the driver itself.

You are using:

   Long name     Short name          driverval(=gs command line opt)
   =================================================================
   A4            FORM_A4             FORM_A4
   Letter        FORM_LETTER         FORM_LETTER
   ...

I think it is more user- and frontend-friendly when you use

   Long name     Short name          driverval(=gs command line opt)
                 (Change to this:)   (Do not change, is for driver)
   =================================================================
   A4            A4                  FORM_A4
   Letter        Letter              FORM_LETTER
   ...

Foomatic has no problem when choices do not indicate to which option
they belong. The user also has to give always an option/choice pair to
set an option and not only the choice. For the example above the user
says

   lpr -P <printer> -o PageSize=A4 <file>

(and I think it is much more user-friendly than needing to enter

   lpr -P <printer> -o PageSize=FORM_A4 <file>

In addition, when the user used ljet4 before and had PageSize=A4 as
default and he changes to Omni by using the "foomatic-configure" command
or Mandrake's "printerdrake" he would get his setting conserved when the
short name is "A4" but not when it would be "FORM_A4")

For the paper sizes which GhostScript and GIMP-Print do not support, you
can freely choose a name, but also here it is easier to enter when one
leaves out the "FORM_" in the short names of Foomatic.

   Till



Mark Hamzy wrote:
> 
> Hello Till,
> 
> 
> Why should they be similiar?  I thought that the purpose of foomatic was to
> provide a mapping
> between printer-driver-readable options and a human-readable dialog.
> The omni's options were designed to be consistant and easy to understand
> what value goes
> with what key.  For instance, how does one know that Hagaki and Chou are
> trays or forms?
> 
> Also, omni supports 190 forms.  Does ghostscript support that many?  Can
> there be a 1 to 1 mapping
> between ghostscript forms and omni forms so that we can include the second
> parameter?
> 
> I think that this discussion is what should be covered in the Linux
> Printing Summit.  It would be
> a good goal to have every printer driver support common job properties.
> The printer working
> group over at www.pwg.org is working on a set of standard form names and
> how they should
> be expressed.  I am sure that everyone's input would be appreciated on how
> it should look.
> 
> Mark
> 
> Take a look at the Linux Omni printer driver at
> http://www.ibm.com/linux/ltc/projects/omni/

[Omniprint-developer] Re: [Foomatic] Re: draft printing , not readable

[Robert L K. <rl...@al...>]

   From: "Mark Hamzy" <ha...@us...>
   Date: Mon, 8 Oct 2001 22:06:58 -0500

   ESC/P looks nothing like ESCP/2 in terms of raster format but it is
   not that hard to implement support for it.  You can use the omni
   code as a guide.  I can also answer any questions...

Thanks.  This sounds like a post 4.2 activity that we might be able to
back port later.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for Gimp Print/stp --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Omniprint-developer] Re: [Foomatic] Re: draft printing , not readable

[Mark H. <ha...@us...>]

> Till Kamppeter wrote:
>
> > Perhaps you should either try the "Epson 9-Pin" or "Epson 24-Pin"
> > drivers of CUPS (www.cups.org) or the IBM Omni drivers
> > (http://www-124.ibm.com/developerworks/oss/linux/projects/omni/). They
> > are perhaps both better than the stock GhostScript drivers. Foomatic
> > data for the Omni driver is under development by the IBM people (the
> > driver package contains an experimental Foomatic generator, the
> > resulting files need some tweaking).
>
> Does anyone know offhand how similar the language used by these impact
> printers is to the ESCP/2 raster used by Epson inkjets?  In other words,
> how hard would it be for Gimp-print to support these printers?

ESC/P  looks nothing like ESCP/2 in terms of raster format but it is not
that
hard to implement support for it.  You can use the omni code as a guide.
I can also answer any questions...

Mark

Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/

Re: [Omniprint-developer] Omni still very buggy

[Mark H. <ha...@us...>]

Hello Till,

I appreciate your feedback.

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

Why should they be similiar?  I thought that the purpose of foomatic was to
provide a mapping
between printer-driver-readable options and a human-readable dialog.
The omni's options were designed to be consistant and easy to understand
what value goes
with what key.  For instance, how does one know that Hagaki and Chou are
trays or forms?

Also, omni supports 190 forms.  Does ghostscript support that many?  Can
there be a 1 to 1 mapping
between ghostscript forms and omni forms so that we can include the second
parameter?

I think that this discussion is what should be covered in the Linux
Printing Summit.  It would be
a good goal to have every printer driver support common job properties.
The printer working
group over at www.pwg.org is working on a set of standard form names and
how they should
be expressed.  I am sure that everyone's input would be appreciated on how
it should look.

Mark

Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/

Re: [Omniprint-developer] Omni still very buggy

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

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