From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <543D9108.6050307@thax.hardliners.org> Date: Tue, 14 Oct 2014 23:09:28 +0200 From: Tobias Hoffmann MIME-Version: 1.0 References: <5B66FA40-ED1E-461E-B00F-D5CD6C7DBC30@apple.com> <34701921-5F04-411C-B35C-78CED619AAC3@apple.com> <5432910A.4030500@gmail.com> <54344707.4080604@gmail.com> <54345EF9.5010405@thax.hardliners.org> <54350A8E.1010406@gmail.com> <54354CDA.50401@thax.hardliners.org> <5435A44F.7080504@thax.hardliners.org> <54383C34.6020108@thax.hardliners.org> <5438486E.9050201@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060203010600010801030603" Subject: Re: [Printing-architecture] Number of copies in pure PDF workflow List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Korobkin Cc: "printing-architecture@lists.linux-foundation.org" , Till Kamppeter This is a multi-part message in MIME format. --------------060203010600010801030603 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 14/10/14 21:17, Alex Korobkin wrote: > Till, > > 2014-10-10 16:58 GMT-04:00 Till Kamppeter >: > > 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 --------------060203010600010801030603 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit On 14/10/14 21:17, Alex Korobkin wrote:
Till,

2014-10-10 16:58 GMT-04:00 Till Kamppeter <till.kamppeter@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
--------------060203010600010801030603--