Printer specific Option Choices [ was Re: [Gimp-print-devel] RE: Epson 1520 issues ]

[Karl H. K. <kh...@kh...>]

Robert L Krawitz <rl...@al...> said: 
[ ... ]
> 
> We really need a GUI (and a system architecture) that allows the
print
> driver to pass arbitrary printer-specific option choices through to
> the user.  PDQ does a lot of this.  It would be nice to figure out a
> way to leverage PDQ or snarf some of its code (I think it's GPL).

Before we go out and use these functions from PDQ, we should try
to understand exactly what we need. 

We are already using some degree of printer specific options for 
PostScript devices. This means that a rudimentary PPD parser is
already in the plugin code. PPDs are of course very PostScript 
specific and it probably does not make a lot of sense to use them
without modifying the concept a little bit. Just in case you are
not familiar with the PPD concept, here's a very brief introduction:

Adobe uses PPDs for PostScript printers to create a common device
driver interface for both Windows and Macs. The PPD files contain
information about which commands need to be send to the printer in
order to select a feature. So if you want to have your document 
printed duplex you (or your driver) looks through the PPD file until
you find the Duplex setting and just send down the string that's
listed to the printer. Pretty easy and straight forward. Now what
makes PPDs really interesting is their connection to the GUI. For
every feature there is information about how to display the selection
dialog, the strings to use for the options and lots of information
about constraints. These constraints are rules identifying conditions
when a certain option can be displayed or can not be displayed. It
does e.g. not make a lot of sense to select to print on transparency
material in duplex mode. So the PPD has some mechanisms in place to
identify these conditions so that the driver can disallow them.

The CUPS project has a full blown PPD parser.

Another solution that we should look at is using XML to define the
printer specific options. Again, we already have a parser that can
handle XML files.

Regardless of which format we use to identify the printer specific
options, we still need two things: A user interface concept that 
can deal with these options and a way to communicate the settings
to the plugin which then will use some kind of logic to decide what
to send to the printer. If we want to be really generic then this
sounds like we also need some kind of extension language that can
be used to create small (or not so small) procedures that will be
called from within the plugin to "compute" the commands we need
to send to the printer.

Any comments?

Karl Heinz