Re: What I'm up to

   From: Roger Leigh <rleigh@xxxxxxxxxxxxxxxxxxxx>
   Date: Tue, 20 Jul 2004 18:56:05 +0100

   >     <printers>
   >       <printer name="EPSON Stylus Color 480" driver="escp2-480" 
manufacturer="Epson"/>
   >       <printer name="EPSON Stylus C20SX" driver="escp2-480" 
manufacturer="Epson"/>
   >       ...
   >     </printers>
   >
   > I suppose we could ultimately allow overriding of parameters in the
   > printer declaration, but my intent at this point is to not allow that.

   OK.  That seems just fine (and allowing overriding here may not make a
   lot of sense, since if you need to override, it's effectively a
   different driver).  It might be simpler (to understand) if drivers can
   inherit their properties from other drivers, and override what's
   different, and leave the printer out of it.

   > This can all be done without any API change at all, other than the
   > fact that there will no longer be a 1-1 mapping between printers and
   > drivers, so stp_get_printer_by_driver would have to return something
   > arbitrary, like perhaps the first printer encountered that uses a
   > particular driver.  However, it would be useful to allow applications
   > to get drivers as well as printers, so that e. g. test programs don't
   > have to keep a list of what drivers they've already seen.

   I'm not sure stp_get_printer_by_driver() is particularly useful
   now--what would a normal application need it for?  I guess the test
   program case is special, but surely they can just maintain a list of
   previously-seen drivers?

   > We could choose to preserve compatibility by keeping all of the
   > stp_printer calls (which would essentially be shorthand) or not.

   When considering backward compatibility, what other applications
   (outside our source tree) are making use of libgimpprint directly?  I
   only know of CinePaint.  If there's noone using them, we could remove
   them.

I'm getting nervous about this.  It's trickier than I first thought.
Among other things, it causes problems with PPD file generation and
Foomatic.

I suppose this could be handled by keeping around all of the different
Epson drivers, but that still wouldn't entirely solve the PPD file
issues, and it would defeat some of the purpose.

What I think I'll do is do the parameter syntax changes (which are
fully compatible, and give us a lot more power), but the printer
vs. driver stuff will wait for 5.1.

-- 
Robert Krawitz                                     <rlk@xxxxxxxxxxxx>

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

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


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click