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

[S. M. <sm...@rn...>]

Karl Heinz Kremer wrote:
> 
> 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
>  
What your describing is suspiciously close to C++ inheritance (which
would probably solve some of these issues, but not all).  I'm still
trying to figure out what a good gui approach might be.  I do plan on
converting the existing dialog to a tabbed notebook type thing (once I
figure out exactly how).  Perhaps one or more tabs could be built from a
config table of "extra" capabilities.  The table would have to have
callbacks of some kind - I guess maybe some type of language would come
in handy here.

Steve

-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------