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

[Robert L Krawitz <rlk alum mit edu>]

   From: Miguel de Icaza <miguel@helixcode.com>
   Date: 19 May 2000 19:02:47 -0400

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

   Ok.  Interesting, so you are basically a raster->printer driver.  I
   want that on gnome-print and I want to work on a common foundation.

It's GPL.  You're welcome to use it in any GPL project.  I'd be happy
to help you (with whatever time I have; I'm already stretched rather
thin), but I want to make sure you know what you're doing here.  I
don't particularly agree with the direction you're trying to take
(doing the rendering yourself), and I think you're just going to get
into trouble in the long run by doing that.

And yes, I say that from the perspective of someone who's already gone
there.  The application -- and application libraries -- isn't the
place to be doing rendering.  Device libraries and drivers should be
doing that.

I've already explained why I started with the Gimp print plugin.  The
Gimp is absolutely the wrong place for the rendering engine.  It's
there because right now we have nowhere else to put it.  Gnome is a
better place than the Gimp, but it's still not the right thing to do.

   If I interrupted in the list, it was only because Sven pointed me that
   GNOME print had not been brought up, and we all want the best for
   Unix.

I don't have a problem with that.  Sven (and Chema) should be telling
you what's going on here, and you're of course welcome to jump in.

   Hey we are using GnomePrint in about eight different applications in
   GNOME constantly, and people are printing their things with it.  The
   sooner we can get raster->printer drivers into GnomePrint, the
   better. 

I disagree with your direction.  The sooner you can hook up with a
good system-level technology, the better.

   The "dump to ghostscript, process, send to printer" solution is
   exactly what I believe to be fully broken for Unix to succeed on the
   desktop.  We have the infrastructure now to do things right, and I
   want to do this.

Right, but Ghostscript isn't what's at fault.  It may be ugly, but
it's not the root of the problem.

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

   I did not say that.  Did I?  I forget saying that.

http://developer.gnome.org/arch/imaging/printing.html:

	Lots of extensions are possible here. PostScript supports bitdepths
	larger than 8bpp, and CMYK color spaces. Other extensions we may want
	to support include larger color spaces (eg 6-color hifi color), and
	RGBA images. But those are best left for another day.

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

   I do not follow this, but it is ok.

That's the root of the whole issue.  We're producing some very high
quality drivers for printers.  Beyond being able to discover and
control their use of features, GNOME shouldn't get involved in that
stuff.

(Sorry.  It's late.  I'm not being too coherent, am I?)