[Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print (fwd)

[Robert L Krawitz <rlk alum mit edu>]

   Date: Thu, 18 May 2000 09:00:42 -0400
   From: Miguel de Icaza <miguel@helixcode.com>

      It has been brought to my attention that you guys have been
   discussing the future of printer drivers and that you are debating
   high quality printer drivers for GIMP.

      I do not know the context of your debate, but I will want to
   introduce gnome-print to you guys, to consider you guys joining our
   effort to provide a complete imaging solution for Unix systems.

I recommend that you read the recent list archives.  Despite the name,
gimp-print is not solely used for the Gimp.  The Epson portion can
also be compiled into Ghostscript as a driver, and there's no
particular reason why the other drivers (HP and Canon) couldn't
receive the same treatment.  Quite a few people use it as a
Ghostscript driver, in fact.

If you take a look at the roadmap I drafted when I started this
project, you'll note that one of the goals is essentially to eliminate
the Gimp Print plugin by having it subsumed into something else (GNOME
Print, or whatever else comes along).  So I don't think we're all that
far out of agreement in the long run (strategically).  Tactically, we
may be.  More below.

   * What is GNOME Print

       GNOME print is an imaging API modeled after the Postscript imaging
       model, that is accessible trough a Gtk+-like C API.  This imaging
       model has two major extensions: support for an alpha channel and
       anti-aliasing.

There's nothing here that's particularly at odds with the gimp-print
engine (the dithering core and the print drivers).  If you grab a copy
of our source tree (or the 3.1.4 release) and look at print.h, you'll
see the following, which implements the interface to the upper part of
the driver (again, we have two upper parts, the Gimp plugin and the
Ghostscript driver).

/*
 * Abstract data type for interfacing with the image creation program
 * (in this case, the Gimp).
 */
typedef void *Image;

extern void Image_init(Image image);
extern int Image_bpp(Image image);
extern int Image_width(Image image);
extern int Image_height(Image image);
extern const char *Image_get_pluginname(Image image);
extern void Image_get_col(Image image, unsigned char *data, int column);
extern void Image_get_row(Image image, unsigned char *data, int row);
extern void Image_progress_init(Image image);
extern void Image_note_progress(Image image, double current, double total);

	   4. RGB rasterizer:  This is the most interesting part: this
	      driver can rasterize the printing commands sent to a
	      printing context and generate output as an RGB buffer for
	      the entire page (as an optimization, the RGB driver works
	      in 1-inch bands).

We can fit very comfortably under that kind of model.

	   5. A generic PCL driver (not yet fully plugged into the
	      system).   This PCL driver is just a "derived" class from
	      the RGB rasterizer.  

	      This driver contains a pretty neat set of compression
	      techniques to reduce the size of the file sent to the
	      printer. 

OK, here's where I think we disagree tactically.  Much of our effort
has been going into improving quality and support for specific
printers (particularly the latest Epson offerings -- the reason for
that is that HP and Canon have not been forthcoming with
information).  The fact that I printed a test image this morning on an
Epson Stylus Photo 870 and got something that really looks a lot like
a photograph (I'd say that the quality equals a marketing print that
Epson themselves made from a 1200) testifies to that.

To the best of my knowledge, there is no other open source software
that comes even close.  There are a few drivers around for the Stylus
Photo 700, a much older printer (two generations back) that is not
even remotely close to the quality of the 870, and our software does
quite well on that printer, too.

I want people who have Epson 800's and 600's and 700's and 740's to
get good output.  I also want people who want to be able to produce
photographic quality output from Linux to be able to do so NOW, not
two years down the road when gnome-print is complete.  I think that
that's just as critical, because people won't wait for everything to
catch up.

The Gimp was a good place for me to start from for a few reasons:

1) It's very demanding of output quality.  Printing photographs
   digitally is a very demanding test of quality.

2) The driver was a lot cleaner than anything else I saw (thanks, Mike
   Sweet!).

   * Why I believe GNOME print is a better solution than GIMP print, even
     for the GIMP.

	The GIMP print output is currently limited to printing bitmaps,
	it has no support for printing anything but that.    This limits
	its usefulness for adding other kind of information on its
	output. 

That's all well and good, but you've done much the same thing with
your PCL driver, and for good reason -- it's a lot more
straightforward that way.  And if you use gimp-print as a Ghostscript
driver, then it can render anything that Ghostscript can render.

	Hence, I would like to encourage people to use GNOME-print as
	your imaging API instead of your current native bitmap interface
	and to get hackers working on GNOME print to make it suit the
	imaging needs of the GIMP. 

Of course.  Maybe we should rename the project, since the name
gimp-print is misleading.

   * The future of GNOME Print

	   3. Add ICC support to GNOME print.

That sounds interesting, although one of our developers is also
working on color management.

	   5. Add support for using more of the features available in the
	      printer for "normal" output (ie, if the user does not use
	      any advanced feature from Postscript and just outputs text,
	      we can use the printer fonts if they happen to match the
	      ones we have, or we can download fonts + outputing just
	      text).

That's great, although a lot of low end printers don't support very
much of that.  But plain text output is already handled pretty well as
it stands; high quality graphics aren't.  And the way things are
moving, graphics output (which includes most text on all but
Postscript printers -- think about kerning and all that) is dominating
the printing scene.

This isn't meant as a flame, but I think there's a lot of stuff you
haven't taken into account here.

If I may offer my own commentary, I think that gnome-print is trying
to bite off too much by getting down to the device rendering and
driver level.  The Caanvas technique of rendering images in
fixed-width bands and sending them directly to the printer won't work
for Epson printers (as an example) because in order to do output
properly to Epson printers you need to interleave output rows in a
rather complicated pattern.  You simply can't render part of a page,
send it to the printer, render the next strip, send it, and so forth.
Well, you can, but you'll lose a lot of quality and/or performance in
the process.  You can render part of a page and send it to the printer
DRIVER, but the driver has to make the final decisions about how to
send the result to the printer.

I think you'd be better off trying to implement the best possible
printing API for GNOME.  The Caanvas stuff looks reasonable (I'm not a
graphics person myself), but the low level stuff needs to be handled
by highly tuned code that's quite printer specific.  You say you want
to leave 6-color output (CcMmYK or CcMmYy, or for that matter CcMmYyK)
for another day, but that's precisely the wrong approach to take for
people who want high quality output on paper.

Once you get down to brass tacks, the output drivers for any of the
cheap, high quality ink jets do basically the same thing -- dither a
bitmap.  None of these printers support PostScript; none of them have
much in the way of built-in fonts (some of them can't even print plain
text shoveled down their throat), but with the right software driver,
even a low end inkjet (like the Epson Stylus 440) can make a laser
printer look like garbage by comparison.

I think Mike has the right idea with CUPS.  Ignore gimp-print for the
moment, and ask yourself whether CUPS could live under gnome-print as
a sort of virtual printer.  I think that properly speaking gimp-print
and gnome should have nothing to do with each other, beyond the fact
that eventually the Gimp will print through something like
gnome-print, which will package everything up for CUPS.  At that
point, the core of gimp-print might be a back end driver within CUPS.

-- 
Robert Krawitz <rlk@alum.mit.edu>      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 lpf@uunet.uu.net
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