Re: [Gimp-print-devel] ANNOUNCEMENT: Foomatic 2.9.0pre1 released!

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

   Date: Sat, 30 Nov 2002 21:15:50 +0100
   From: Till Kamppeter <til...@gm...>

   >      - foomatic-configure is much faster when copying or modifying
   >        print queues now, as it does not rebuild the PPD from the
   >        Foomatic database all the time (as long as one does not force a
   >        rebuild with "-f").
   > 
   > This may be a double-edged sword; if the driver (and hence the master)
   > changes, the PPD file needs to be rebuilt.  This is a bit of a
   > weakness of CUPS, that you have to recreate the queue when you install
   > a new driver.

   So you mean when one updates GIMP-Print and the new version has some new 
   options or choices? In this case the user would have to use the "-f" 
   option in foomatic-configure.

I don't like this "THE USER WOULD HAVE TO".  That just means "The
developer doesn't want to have to figure out how to".

One option would be for Foomatic to store, say, an MD5 checksum of the
base data from which the PPD was derived.  If the base data changes,
Foomatic could automatically update the PPD file.  If there are
conflicts -- the new PPD file wouldn't support options chosen in the
existing one -- it signals an error and asks the user to make the
appropriate changes.

   >    Planned for 3.0/Roadmap for 2.9.x:
   > 
   >      - Collective options: This is a new option type to make it easier
   >        for users to choose the best settings for a certain printing
   >        task, even if the driver has very many options. The idea is to
   >        have an enumerated choice option which does not directly modify
   >        something in the driver's command line but sets several of the
   >        other options.
   > 
   > Roger and I are thinking about something like this, within the
   > Gimp-print context.  It's certainly a good idea.

   Then we should agree to have the same option names, so that when
   some drivers have these collective options built-in and for some it
   is provided by Foomatic, one should have a unique option with the
   same choices for all printers, regardless of the driver. So in a
   distro one could simply refer to that option for newbies. I was
   already thinking that the best for consistance is even to implement
   it in Foomatic for all drivers, but then the native CUPS drivers
   and the GIMP plug-in would not have it.

We can't always do that, due to different capabilities on the part of
the printers, but that's a good suggestion where we can.

   ----------------------------------------------------------------------
   Draft            Plain Paper     360x180 dpi           Very Fast
   Office document  Plain Paper     360x360 dpi           Adaptive Hybrid
   High quality doc Plain Paper     720x720 dpi Highest   Adaptive Hybrid
   Photo            Photo Paper     2880x720 dpi Unidir.  Even Tone

   I don't know exacly what is the highest resolution from which one
   has still an advantage when printing on plain paper. Is it 1440x720
   or 720x720?

Epson doesn't suggest going above 720x720; I've found that 1440x720
(and even 2880x720) yield noticeable quality advantages on plain
paper.  The question is how much quality you want out of plain paper, period.

   >      - Non-printable margins: Both printer and driver XML database entries
   >        should get a new section for unprintable margins, so that the
   >        "*ImageableArea" entries in the PPD files can be correctly set.
   >        Entries should be possible for printers (printer XML file), for
   >        drivers (main part of driver XML file), for printer/driver combos
   >        (in printer list of driver XML file), and they can contain general
   >        margins (valid for all paper sizes) and paper-size-specific margins.
   >        If for one "*ImageableArea" entry in a PPD file more than one of the
   >        above mentioned possible margin entries applies, the "worst case"
   >        (individually determined for each page border) is inserted. If the
   >        unprintable margins of a printer depend on options settings, the
   >        "worst case" is chosen, too.
   > 
   > What about margins controlled by things other than paper sizes
   > (e. g. resolution choice)?

   What I planned is, as I said, to take the "worst case", this means,
   if in 1200 dpi the non-printable margins are 5mm and in 600 dpi
   3mm, always 5 mm is used. If full-bleed is available only for
   certain option settings, one should perhaps full-bleed and normal
   paper sizes ("A4", and "A4.fullbleed") and by an option conflict
   definition in the PPD file make the full-bleed paper sizes
   conflicting with the resolution which does not support full-bleed.

   The problem is in PPDs, they only allow to define unprintable
   margins depending on the paper size not depending on other options.

Urg.  One more reason to hate PPD files.

-- 
Robert Krawitz                                     <rl...@al...>      

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   --    http://gimp-print.sourceforge.net

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