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

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

   Date: Wed, 17 May 2000 08:50:00 +0200
   From: Thomas Tonino <tt...@bi...>

   Or would this still be to inefficient? I also see an open area with
   printer control etc, page size, quality settings (how does the
   information about printer capabilities go up all the way to the user
   interface? Maybe a stupid system: the driver is always identified via
   full (network) path name and can be queried directly).

Well, it's stuff like this that the Unix printing system doesn't
handle at all.  PDQ does something like this, although it's open loop
(the knowledge is encapsulated in the printer's PDQ description, not
queried from the driver, which means that the description needs to be
kept up to date).  But again, it's all a bunch of little pieces, and
there's no integration.

   > But in the
   > long run, projects such as this simply MUST get absorbed into the
   > infrastructure.  In my opinion, of course.

   And that infrastructure would better be general. A lot of apps can only
   print PostScript: so Ghostscript should be part of that infrastructure.

No objection there.  In fact, I think that all printing applications
*should* produce PostScript, and despite my reservations about the
actual implementation of Ghostscript, it's a perfectly valid thing to
have for printers that don't speak Postscript natively.

   The Gimp plugin would be the first app fully excercising the printer
   control features, something sorely missing from Ghostscript. I think it
   needs some very straightforward thinking. Why, for example, doesn't
   Ghostscript allow folks to change some command line parameters through
   (say) PostScript comments? Should save lots of folks all those printer
   queues for 300 dpi, 600 dpi, color, etc.

And in that regard, I think we're performing a valuable service.  It
would be a darn sight more valuable if we'd really come up with a
general mechanism for exposing printer-specific features back to the
application.  Right now we have a specific set of features that we
expose (paper size, paper type, paper source, and so on), and in some
cases we're rather abusing them.  We shouldn't be.  We should allow
printers to define their own sets of attributes.

When I say "exposing printer-specific features back to the
application", I'm referring to a combination of the Gimp and parts of
the plugin.  I think of the "application" in this case as being
primarily print.c, which is the only piece of code that really has
Gimp-specific interfaces embedded within it (*main_window.c and
*color_window.c aren't pure, but they do basically form a generic
printer dialog box).

The current architecture (where the plugin itself generates native
printer output) isn't the right factorization of the problem.  I think
that the right pieces are there, but due to the nature of how things
are right now they're all glommed together (albeit with a
semi-coherent interface).  The actual generation of the printer output
should be done at the very bottom of the stack.  This would allow for
a clean abort of a print job (there is apparently a proper way of
aborting an Epson print job that allows the printer to reset itself
properly), and for printers with bidirectional protocols (like Epson
remote mode).  The Postscript interpreter should be just above that,
and above that should be the queueing system (which is where Unix is
already strong).  Above that should be the a generic printer layer,
which generates Postscript.  So it looks something like this:


APPLICATION			PRINTING SUBSYSTEM	DRIVER

Application
Parts of printer dialog box	Parts of printer	Parts of
				  dialog box		  printer dialog box
							Printer capabilities
PostScript generation
				Job queue
				Generic print filters
				GhostScript or passthrough
				Generic print filters
				Open physical link to
				  printer
							Generate raw output
							  and send to printer

("Open physical link to printer" refers to opening the file descriptor
that will be used to talk to the printer.  This usually requires some
kind of privilege, and we don't want printer drivers themselves to run
with any privilege.)

Now, obviously I'm not proposing that we architect, design, and
implement this ourselves.  It's a big job, and it needs everyone to
buy in to it.  But this seems schematically the right idea, and I want
to think about what we can do to drive the process.

We already have a Gnome representative on this list.  For
completeness' sake, I will contact KDE also.  But a lot of this stuff
needs to happen at lower levels than that.

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