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

["Thomas J. Hubbell" <thubbell compumetric com>]

Michael Sweet wrote:
> 
> Ben Woodard wrote:
> > ...
> > Very simple. In the LPD setup that I have been working on you can
> > insert arbitrary filters into the processing path. That is what I
> > took pstops and turned it into ppdfilt for. I stick it in the filter
> > path just before something is sent to the printer and voila I have
> > PPD support. I figure I can get ppdfilt or another program to do the
> > same sort of thing without much trouble for binary non-PS files.
> > Then I just stick it in the filter chain after gs and viola limited
> > PPD support for non-PS printers.
> 
> Again - why bother with this?  You can make a *real* PPD file that
> sets the options supported by the GS drivers, use pstops/ppdfilt to
> *insert the options for the driver*, and then pass the filtered file
> to GS.  Then GS will produce a printer-specific output stream that
> can be sent to a printer.
> 
> Depending on the printer driver, you may get all of the functionality
> you need; if not, it is *easy* to add new options to drivers (see
> the CUPS GS driver for how easy it is)

If I may make a suggestion and a comment or two (...donning flame-proof
suit).

My inclination is to agree with something along the lines of the "real"
ppd files with extra GS options. It just seems that it would be more
efficient (not to mention easier) than binary filters.

However, Ben's solution does have merit in that it will work with the
existing gnome-print model.

Is there a happy medium? I hope so. Ben mentioned something in an old
post about how Windows uses metafile spooling to get over some of the
problems of sending large amounts of raster data over the network. I saw
no replies to this (maybe if windows was never mentioned, people would
pay more attention!), but I think it deserves more thought.

If I understand it correctly, the idea behind the use of metafiles is to
provide for a small, rather portable (portable in the windows sense of
the word, of course) format that can quickly be rasterized at print time
as needed. This eliminates the need to spool extremely large raster
files and also helps with network traffic.

In many ways PostScript and PCL are small enough and portable enough to
preclude the need for metafiles (if the PCL is more than just glorified
raster data, that is). It is true that a metafile should be much smaller
than a PS or PCL file, but in comparison to large raster files, PS and
PCL are very portable!

Currently, PS sort of serves as the de facto intermediary file format
today in linux. Some of the gnome-print contributors have noted that
they believe PS to be limited in some respects. The use of PS in the
same role as a metafile may not be sufficient for use as an intermediary
file format in all cases, if I follow the gnome-print argument
correctly.

So, after all that, here's is my suggestion. For formats which are
generally portable, that is PS and PCL (with the same caveat as
mentioned above), it makes sense to just output the data directly from
gnome-print. For formats which are much less portable, such as raster
drivers for ink jet printers, perhaps it would be better to have
gnome-print render to some metafile-like intermediary file format. The
gnome-print drivers for these raster formats could then be moved into
the back-end spooler and would handle the conversion from the
intermediary format to the printer's native format. Options (from a PPD
file, for instance) could be passed to the back-end filters through the
spooler to enable device-specific features for these types of printers.

This is just a suggestion. It may not be (and probably isn't) perfect,
but I believe it is a good compromise which doesn't really limit the
functionality or power of the gnome-print system. It should also provide
for an easy way to add device dependencies for all printer types.

--
Thomas Hubbell
CompuMetric Labs, Inc.
thubbell@compumetric.com