[Lpr-discuss] extending support for non-PS printers

[Ben W. <be...@va...>]

Earlier today we formulated a plan to begin figuring out what we need
to do to being supporting non-PS printers with the enhanced print
system that we put together.

Grant Taylor has this new thing called foomatic. It creates perl
include files which have embedded data structures which supposedly
configure ghostscript to access device specific features. This is used
by, printerconf a new tool by RH.

Mark Pruett, is going to build a prototype script which downloads the
foomatic include files and turns them into PPD files. The hope is that
in the process of doing this, Mark will discover the caveats inherant
in the foomatic system. Knowing the quality of Grant's other work, I
expect that there will be several problems. At that point, we will
look at trying to engage Grant to adapt his database so that it has
the flexibility to do the things we need. If accomidation cannot be
reached we may have to make a seperate database. 

This much has been agreed upon and this should be finished in the
middle of next week. Everything else is still tentative but my feeling
is that we are close to agreeing to these following steps.

In the mean time we are investigating making libppd handle an XML file
format in addition to PPD files. The first extension to PPD files that
this new file format will support will be allow for multiple
languages. Probably what we will do, is make a tool that allows us to
read in multiple PPD files and spit out one XML file which supports
all various languages. This will allow us to create the strings that
gpr and friends pass to ghostscript or the PS printers.

The we expect that most of the normal ghostscript drivers will have
spotty support for the various printers. The next part of the puzzle
is to make sure that ghostscript supports all of the features that we
want for our target printers. One possibility that we are considering
is working with the people developing the IBM omni driver. The thing
that is really cool about the omni driver is that it is data driven as
opposed to other drivers which have the code that generates the
printer's native language hard coded into them. This means that we
could distribute a copy of ghostscript with only one driver compiled
into it, the omni driver, and then we could supply data files for each
and every one of the printers that we want to support.

The ideal situation would be if we could extend the XML file format
that I discussed previously with regard to libppd such that it
provides all of the information that the omni driver needs to render
the page. If we could do that, then printer vendors could simply
provide one data file and it would provide everything that a linux
needs to print to that kind of printer. 

Setting up a printer would go like this:

* run some sort of configuration too which uses the autodetection
code to identify what kind of printer we are dealing with.

* configuration app goes to internet database to download the XML
file which describes how to render for this printer as well as how to
tell ghostscript to access the various device features. The printer is
now setup. 

* user runs gpr which laods in the XML file to create a GUI for the
user to select which options the user wants applied to the print job.

* gpr passes the selected attributes to the print system when it
submits the print job.

* the print filters pick up those options and insert them into the
postscript for the print job at the appropriate locations.

* the omni driver inside of ghostscript reads in the XML file for that
printer and uses it to render the document with the selected features
into the printer's native language.

comments anyone?

-ben