[Printing-architecture] Number of copies in pure PDF workflow

[Tobias Hoffmann]

On 14/10/14 21:17, Alex Korobkin wrote:
> Till,
>
> 2014-10-10 16:58 GMT-04:00 Till Kamppeter <till.kamppeter at gmail.com 
> <mailto:till.kamppeter at gmail.com>>:
>
>     One must check whether modern GNOME/GTK/KDE/Qt/LibreOffice dialogs
>     support the PPD extensions for numerical options,if so and if it is
>     guaranteed that the print queue is not accessed from other platforms,
>
>
> This PPD will be used by Cloud Print, command line, and other 
> non-Gnome/non-KDE apps, so having a custom Copies dialog is not the 
> best idea.
>
> Shouldn't pdftopdf just insert PJL SET COPIES=X without any related 
> code in PPD? PJL SET COPIES seems to be a standard PJL command.

First, the current "solution" does not require knowledge knowledge of 
the particular JCL used. Everything comes from the PPD.
Now, pstops does contain PJL-specific workarouds for certain printers, 
but looks at ppd->jcl_begin to determine if the JCL is the known PJL.

But, as far as I understand the current jcl-insertion code in pdftopdf, 
it will actually *replace* the "Copies" widget under "Advanced" with the 
copies-value from the usual UI location. But the replacement only 
happens after "ENTER LANGUAGE"... so when you use OrderDependency to 
move it before, the
replacement has not happened...

This means:
1) Current design of JCL in pdftopdf is flawed. It's not clear (to me) 
how it should be changed.
2) If the PPD specifies the JCL to be used, I'm not sure how the PPD 
should specify "@PJL SET COPIES=X" for unlimited X. Till did mention 
some PPD-extensions that could allow this, but I don't understand yet, 
where the chosen value should be inserted into the JCL-command template 
(You certainly would not want "...=%d" in the PPD and then use printf on 
that...).
3) Or we hard-code a PJL exception into pdftopdf.

And I do prefer a solution that works the same for both Foomatic and 
native PDF printers / PPDs.

   Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20141014/a08d7a6d/attachment.html>