Re: [Gimp-print-devel] What direction should we be headed?

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

   Date: Wed, 17 May 2000 21:23:46 -0400
   From: Michael Sweet <mi...@ea...>

   FWIW, none of the printer manufacturers I talk to are willing to
   open source drivers for their entry-level printers; they talk of
   "giving away secrets to their competitors", while we have to
   shake our heads and say "it isn't so!" since we've seen it all
   and *know* it wouldn't make a difference...

I can see their point as far as dither algorithms per se are
concerned.  As far as the programming specs, this is, of course, sheer
nonsense.  All that happens is that we waste some time reverse
engineering their commands.

Epson's been rather more cooperative than most (at least, that's my
opinion).  So maybe Epson will be able to sell more printers into the
Linux market, even if their software folks won't help.

   > Cisco Enterprise Print System:
   >  A set of tools for making the adminstration and support of large
   >  number of printers dramatically easier

   But still based on LPD; they've volunteered to port a lot of their
   stuff to CUPS since it supports IPP and other network stuff they
   like.

LPD must die.  No two ways about it.

   > Open Source Printing:
   >   VA and HP are driving a partnership with the Open Source
   >   community to create great Open Source printing

   for PostScript laser printers from HP, although the group that is
   developing PPD-based filters (using the CUPS code, BTW) is also
   trying to support other vendors' PostScript printers, too...

I suspected as much, given that their entry-level folks have been
completely unwilling to release specs on their printers to us.  Of
course, true PostScript printers are also relatively straightforward
to support.

   > Application Print Services Library:
   >   This project, driven by Corel, provides a unified API for accessing
   >   printing-specific services outside the realm of the graphics API.
   >   This includes querying & controlling features of a given printer
   >   model, sending jobs, accessing queues and configuration.

   This is an attempt at supporting multiple printing systems, and using
   the features available in all of them.  Some of the comments I've
   heard indicate that the API is not as easy to use as some would
   like...

At least one of their mailing lists is essentially dead.  I see almost
no traffic on it.

Notice that one thing that none of these projects is doing is working
on improving print quality on low end printers -- the bread and butter
of the desktop.  We seem to be the only project looking at that very
hard.

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

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