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

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

   Date: Tue, 16 May 2000 11:16:27 -0400
   From: Michael Sweet <mi...@ea...>

   Basically we have a choice - turn the print plug-in into a monolithic
   giant that supports hundreds or thousands of printers, rivally the
   size of the main GIMP application, or develop the printer drivers
   so they can be used initially from the print plug-in and then
   from Ghostscript and/or CUPS to support high-quality printing from
   all applications.

   UNIX/Linux will not be successful without printer support.  The
   current support for printers sucks.  I've been doing UNIX printer
   drivers for 7 years now, and the general solution to printing is the
   one that works, not writing drivers for individual applications.

I can't find a single word to disagree with here.

One of the original items I put in when I first wrote a roadmap for
this is the eventual elimination of the print plug-in except as glue
code.  That still stands.  The fact that this plug-in is as
comprehensive as it is points to how weak the printing support is in
UNIX.

The UNIX printing system was originally designed at Berkeley to
support networked line printers at the UCB computer center (and if you
look at the man page for lpr, you can *still*, over 20 years later,
find Berkeleyisms -- not BSD, but actual University of California at
Berkeley).  It did a decent job of that.  When System V came along in
the early 1980's or so ATT did it slightly differently.  The commands
have different names, but essentially do the same thing.

Basically, the UNIX printing system is a transport layer.  It does a
good job of transporting bits over the wire to the printer, and
precious little else.  Most everything that has happened in recent
years -- apsfilter and the like -- tries to simplify configuration of
the transport layer, and little else.

Windows, of course, sucks at transport layers.  It's very common for
large organizations to put their networked printers on Unix boxes
(which excel at transport), and the Windows applications print over
the network to a Unix box running Samba.  Since true winprinters
(printers that really need real time control) are still rare, this
works well.

Ghostscript is ugly as sin.  It's precisely the monolithic giant that
Mike refers to.  It's a maintenance nightmare.  It has to be
recompiled for every new output device you want to add.  Yes,
recompiled.  There are no loadable modules (dll's, so's, whatever you
want to call them).  Everything's in a single global namespace.
Yuck.  Yet despite that, for now it's still the best thing out there,
and that's why I consider the Ghostscript driver to be of more
strategic value than the Gimp plugin itself.  Judging by the mail,
there are probably more people using the Ghostscript driver than the
print plugin itself (except for the 2.0 and 3.0 versions bundled with
the Gimp), despite the fact that installing it is a real pain.  Mike's
dead right -- people need the ability to print from ALL applications,
not just from the Gimp.

So why, you may ask, did I start with the Gimp plugin (with Mike's
plugin, that is!)?  Well, it was simple enough.  It was about the only
thing out there I could find that was possible to understand quickly,
the basic architecture was reasonable, and I had just bought a
photo-quality printer that I wanted to use to print images that were,
of course, edited in the Gimp.  I still had a laser printer for other
stuff.

We have a lot more than we started with (I started from Mike's 2.0,
and this project started when I spun off 3.1 from my last 3.0).  We
support more printers, the quality is higher, and we have the
Ghostscript driver.  I believe that we have the best quality printing
available on low-cost printers on Unix.  I'm not aware of any other
free driver that supports anything more than the Stylus Photo EX or
Stylus Color 740, and the Photo EX output I've seen from any other
source is very poor.  We support the 870 -- a current generation
printer -- quite well.  Not perfectly, but quite well.

I see promising stuff going on, with PDQ, gnome-print, and the like.
I think we have useful knowledge to feed into those projects.  We're
driving printers hard, and we're learning what capabilities they have,
and this can be valuable to help the infrastructure folks develop the
necessary API's required for applications to be able to print to these
printers.  We have good drivers.  But in infrastructure, we're weak.

I think that in the short term our direction is good.  We're providing
a target for the infrastructure people to aim at, in terms of what we
can do from the Gimp.  Improving the drivers, of course, enables Unix
folks to use high quality, low cost printers to good effect, and
strengthens the ability of Unix to work on the desktop.  But in the
long run, projects such as this simply MUST get absorbed into the
infrastructure.  In my opinion, of course.

I'd still like to see more discussion over what direction we should
head in.  This is free software, after all, and just because I'm
currently the project lead doesn't mean that I'm the big boss.  Maybe
we're all in agreement here, and we need to figure out how we're going
to help the infrastructure teams absorb our work.  But I do want to
spark some debate.

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