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

[Federico Mena Quintero <federico helixcode com>]

Robert L Krawitz <rlk@alum.mit.edu> writes:

> 1) You're wasting your time duplicating someone else's work to no good
>    end (as you admit that a PostScript driver could accomplish
>    everything native drivers could).  You have to keep on doing this
>    forever (at least until the sun becomes a red giant), as new
>    printers will constantly be released.
> 
> 2) You cannot do accounting with native printer drivers.  Before you
>    say "I can put accounting in the native printer drivers", let me
>    point out that you're now trying to put accounting in the client,
>    and thus you're trusting the client not to deliberately screw up
>    the accounting.  That's a no-no.
> 
> 3) Whatever Chema was able to do with PCL, not all printer languages
>    can be compressed in this fashion.  You're still talking about a
>    massive excess of spool space and network bandwidth for this.

So what about this:

An application, using the gnome-print drawing API, generates metafile
data that gets piped to a print server process.  This can run on the
same box as the application or on a printer-controlling machine at the
other end of the office.

The print server process rasterizes or otherwise mangles the metafile
data to feed it to a particular printer, using the appropriate driver.

For all I care, the print server process can be a CUPS-provided thing
or something equivalent.

The application then does not have to rasterize in its own process, so
the user will see that he can continue working faster after doing
File/Print.  The print server can take care of accounting by itself or
by querying smart printers, thus eliminating concerns about malicious
clients.

For legacy applications, they can still pipe PostScript data into the
print server using an lpr replacement or similar.

In any case, the important thing here is having a metafile format that
supports the nice GNOME imaging model.

For print previews, the metafile data is replayed by a rasterizer as
appropriate.  Don't scream about whether this rasterizer should run in
the app or in a separate process; I don't care.  It has to run at some
point.

Even if you usually pipe non-raster data to the print server,
sometimes you'll need to rasterize the stuff in the application.
Consider plotting a point cloud of a few hundred million data points:
your "moveto <x> <y> drawdatapoint" stream will be much bigger than
just generating a bitmap on the application side and sending it over.
This does happen, as the authors of the Guppi plotting system will
tell you.

Finally, why not just pipe PostScript all the time to the print
server?  Because it does not provide the imaging model we want.  

And why should the print server not just translate metafiles into
PostScript and print them using Ghostscript?  Again, because it would
be the same thing, and you can do a better job of rasterizing the
metafile yourself if it has operations that PostScript does not
support such as alpha blending.  For "simple" metafiles you can just
translate them to PS and send them to Ghostscript, unless your
rasterizer is really better and then it would be pointless to use
Ghostscript.

  Federico