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

[Michael Weghorn]

Hi Michael,

thank you for that explanation. However, I am not yet sure whether I
have already fully understood (s. questions below).

On 2017-02-09 16:43, Michael Sweet wrote:
> Using the Job Ticket API bypasses all of these issues, because it allows
> the printing system to map options and Do The Right Thing™ for each printer.

That is what I was basically hoping for. And my hope was that by having
the printing system do this, it would not play any role whether the
PPD's contain PostScript commands or PJL commands or something even
different, as long as the printing system is able to properly map this.

And I thought that using PPDs with the "JCLToPDFInterpreter" and
"JCLSetup" keywords etc. was already supported by CUPS (or some CUPS
filter) right now, just as embedding the PostScript commands into
PostScript documents is currently handled by CUPS (or one of its filters).

> 
> In the case of PPD files, most options embed PostScript commands for
> device control, so they are only useful when sending PostScript to the
> printer (although CUPS does implement a very small subset of PostScript
> for interpreting settings for raster printer drivers, too).  Options in
> the "JCLSetup" section ("JCL" is PPD-speak for PJL) are applied outside
> the document data (PostScript, PDF, whatever) which allows for some
> device control over "dumb" communications links (basically everything
> but IPP).

Are there any problems when using this in conjunction with IPP and the
Job Ticket API?

What I was expecting so far:

In both cases, PPD options are mapped to IPP attributes by CUPS. The
application can use the Job Ticket API to query available options.

* When using PPDs that contain PostScript commands, those are inserted
into the print document by a CUPS filter.
* When using PPDs that contain PJL commands, those are applied outside
the actual document data (e.g. wrapped as header and footer around the
actual document) by a CUPS filter.

The print document (potentially wrapped in PJL commands) is sent to the
printer.


In the end, there is no difference from the application point of view
when PostScript commands are used or PJL is used, as those are handled
inside CUPS, so using any of those would basically be equivalent (as
long as the same amount of options is supported for both cases).

Is that basically correct?

If so, do your concerns as expressed in your previous email still apply
about considering the usage of PJL (and have CUPS or a CUPS filter
handle it in the background)?

Or is there some other difference between handling of PJL and PostScript
commands in PPDs that makes up a good reason to avoid PJL (e.g. only a
small subset of options available as PostScript commands can also be set
using PJL)?

Maybe my previous emails were not clear enough on what I was considering
(sorry for that!), or there is something I still have not understood.


    Michael