[cups] PPD API: Status, future and alternatives to handle printer-specific options

[Michael Weghorn]

Hi Michael,

On 2017-02-09 15:33, Michael Sweet wrote:
> Please, let's not go down the path of embedding printer drivers in
> applications again.  Leave the printer communications and format
> conversion to the printing system and focus on providing good content
> (i.e. PDFs) for printing using the recommended APIs.
> 
> And IIRC, cups-filters already supports a JCLToPDFInterpreter keyword to
> handle this implementation detail for you...

I was not thinking about doing any handling of the PJL options in the
application (framework) itself.

> And IIRC, cups-filters already supports a JCLToPDFInterpreter
> keyword to handle this implementation detail for you...

The sample PPDs in cups-filters that "stephanwib" posted a link to do
contain that keyword.

My (maybe too naive) thought was that the handling in the application's
(or framework's) print dialog would be agnostic of what the PPD actually
contains as code for the respective option (be it PostScript commands or
PJL commands or something completely different), but this would only be
used by the printing system (and its additional components, like CUPS
filters).

Would using PJL commands in PPDs using that "JCLToPDFInterpreter"
keyword not work using the Job Ticket API to query available options (in
case those are properly mapped from the PPD to IPP)?


    Michael