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

[Miguel de Icaza <miguel helixcode com>]

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

And I think your work fits nicely in GnomePrint.

I am glad to read your message again Robert.

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.

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

I am sorry if I came out as saying that we had the ultimate solution.
We dont.  The Generic PCL driver is just a technology demostration
that our rasterization system works, and it is obviously our choice as
the "foundation" for continued development.

Here is where I believe both projects should unify.  Again, I am sorry
if people got the wrong impression.  I was just listing the different
kind of "outputs" supported by gnome-print.

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

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. 

But right now, you can see real apps doing real printing (Gnumeric,
SodiPodi, GtkHTML, Evolution are the most important ones)

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

What is handled pretty well in this case?

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.

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

It does not matter.  Just specify that your band is the size of the
page.  Problem solved.  

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

Great.  We can fit this.  

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

At least I dont think I said that recently, as I had a long
conversation with Chema, who enlightened me about this topics.  Then
Tuomas and someone else at the office insisted in talking to me for
two hours about the the levels of cyan.

Anyways, I doubt a lot that I had said such thing.  And if I did, then
I correct myself.

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

Miguel.