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

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 273 bytes --]

Hi all,

I'm looking at example PPDs for pure PDF workflow, and all of them have
cupsManualCopies: true

Why is that? Is it impossible to tell printer to print a number of copies
with pure PDF workflow?
Maybe pdftopdf can inject @PJL SET COPIES=X into the file?

-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 425 bytes --]

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

[Ira McDonald]

[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]

Hi Alex,

Processing instructions (such as copies) should never be embedded in PDF
files anymore.
On the wire, they should be in the IPP PrintJob or CreateJob request (i.e.,
job ticket).

CUPS or other client should send "copies" through the CUPS filter chain.(so
that client-side
copies can be done, if the target printer does not support multiple copies).

Mike Sweet - can you answer why cupsManualCopies PPD attribute is always
set to "true"?

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434


On Fri, Oct 3, 2014 at 3:28 PM, Alex Korobkin <korobkin+op@gmail.com> wrote:

> Hi all,
>
> I'm looking at example PPDs for pure PDF workflow, and all of them have
> cupsManualCopies: true
>
> Why is that? Is it impossible to tell printer to print a number of copies
> with pure PDF workflow?
> Maybe pdftopdf can inject @PJL SET COPIES=X into the file?
>
> --
> -Alex
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
>
>

[-- Attachment #2: Type: text/html, Size: 2904 bytes --]

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 2453 bytes --]

Hi Ira,

Thanks for your answer. Let me explain it with more details:

Example PPDs for pure PDF workflow are provided by printer manufacturers,
and they have "cupsManualCopies: true" set in them. Now, let's say a client
prints a job: lp -d mypurepdfprinter -n 3 myfile.pdf

As you can see, the number of copies will be passed to all the filters, but
only one copy will be printed if I set cupsManualCopies to false, because
filters don't seem to care about the number of copies in the pure PDF
workflow. At least, I don't see pdftopdf injecting anything but a comment,
nor backend filters setting a number of copies via IPP.

I guess it is a question about cups-filters package, not CUPS itself.


2014-10-03 15:49 GMT-04:00 Ira McDonald <blueroofmusic@gmail.com>:

> Hi Alex,
>
> Processing instructions (such as copies) should never be embedded in PDF
> files anymore.
> On the wire, they should be in the IPP PrintJob or CreateJob request
> (i.e., job ticket).
>
> CUPS or other client should send "copies" through the CUPS filter
> chain.(so that client-side
> copies can be done, if the target printer does not support multiple
> copies).
>
> Mike Sweet - can you answer why cupsManualCopies PPD attribute is always
> set to "true"?
>
> Cheers,
> - Ira
>
>
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: blueroofmusic@gmail.com
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
>
>
> On Fri, Oct 3, 2014 at 3:28 PM, Alex Korobkin <korobkin+op@gmail.com>
> wrote:
>
>> Hi all,
>>
>> I'm looking at example PPDs for pure PDF workflow, and all of them have
>> cupsManualCopies: true
>>
>> Why is that? Is it impossible to tell printer to print a number of copies
>> with pure PDF workflow?
>> Maybe pdftopdf can inject @PJL SET COPIES=X into the file?
>>
>> --
>> -Alex
>>
>> _______________________________________________
>> Printing-architecture mailing list
>> Printing-architecture@lists.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
>>
>>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 4378 bytes --]

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

[Michael Sweet]

Alex,

> On Oct 3, 2014, at 3:28 PM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> 
> Hi all, 
> 
> I'm looking at example PPDs for pure PDF workflow, and all of them have 
> cupsManualCopies: true
> 
> Why is that? Is it impossible to tell printer to print a number of copies with pure PDF workflow? 
> Maybe pdftopdf can inject @PJL SET COPIES=X into the file? 

No, that wouldn't work since the PDF-to-raster filters don't support PJL and (for that matter) most PDF printers do not support PJL.

cupsManualCopies is there because the destination doesn't support generating copies of its own.  If it does, then cupsManualCopies won't be in the PPD - in the case of IPP Everywhere printers the copy count is passed in the job ticket when we create the job from the IPP backend.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]

Hi Michael,

Sorry, I should have been more clear with my question. I'm asking about
OpenPrinting PDF workflow [1], where client sends a PDF, and CUPS uses just
two filters for the job: pdftopdf and a socket/ipp to send the PDF directly
to the printer. No conversion to raster is happening: client sends a PDF,
printer receives a PDF.

cups-filters package ships with a couple of sample PPDs [2], [3] that
basically allow for inserting PJL commands into the job to change its most
common options: tray, duplex, etc.

I'm trying to find out whether making manual copies via cupsManualCopies is
the only way to handle the number of copies. Can pdftopdf or CUPS insert
PJL SET COPIES=X into the job? Can CUPS set the number of copies via IPP
commands? There is also some code in pdftopdf_jcl.cc [4] that is dealing
with a Copies directive in a PPD, but I don't quite understand what it
does.

[1]
http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format
[2]
http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/HP-Color_LaserJet_CM3530_MFP-PDF.ppd
[3]
http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/Fuji_Xerox-DocuPrint_CM305_df-PDF.ppd
[4]
http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/filter/pdftopdf/pdftopdf_jcl.cc#L35

2014-10-04 11:40 GMT-04:00 Michael Sweet <msweet@apple.com>:

> Alex,
>
> > On Oct 3, 2014, at 3:28 PM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> >
> > Hi all,
> >
> > I'm looking at example PPDs for pure PDF workflow, and all of them have
> > cupsManualCopies: true
> >
> > Why is that? Is it impossible to tell printer to print a number of
> copies with pure PDF workflow?
> > Maybe pdftopdf can inject @PJL SET COPIES=X into the file?
>
> No, that wouldn't work since the PDF-to-raster filters don't support PJL
> and (for that matter) most PDF printers do not support PJL.
>
> cupsManualCopies is there because the destination doesn't support
> generating copies of its own.  If it does, then cupsManualCopies won't be
> in the PPD - in the case of IPP Everywhere printers the copy count is
> passed in the job ticket when we create the job from the IPP backend.
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 3586 bytes --]

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

[Tobias Hoffmann]

On 04/10/14 19:36, Alex Korobkin wrote:
> cups-filters package ships with a couple of sample PPDs [2], [3] that 
> basically allow for inserting PJL commands into the job to change its 
> most common options: tray, duplex, etc.
> I'm trying to find out whether making manual copies via 
> cupsManualCopies is the only way to handle the number of copies. Can 
> pdftopdf or CUPS insert PJL SET COPIES=X into the job?
Yes (for resonably recent versions). But the string "PJL SET COPIES" (or 
whatever the printer needs) has to come *from the PPD*. Also the 
emit-jcl must not be disabled in pdftopdf's arguments (mostly relevant 
when pdftopdf is NOT the last filter).

> Can CUPS set the number of copies via IPP commands? There is also some 
> code in pdftopdf_jcl.cc [4] that is dealing with a Copies directive in 
> a PPD, but I don't quite understand what it does.
If the PPD does not specify cupsManualCopies, then the JCL commands *for 
that particular printer* have to be specified in the PPD.
Also keep in mind that the device might not support deviceCopies for 
certain collate settings; the PPD has to contain the necessary "logic" 
for that, too.

 From [4] it follows that certain PPD Attributes /can/ be necessary for 
deviceCopies:
   *JCLToPDFInterpreter, *pdftopdfJCLBegin, *pdftopdfJCLCopies, Copies

   Tobias

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

Hi Tobias,

Thanks for the explanation. Directives pdftopdfJCLCopies and Copies sound
promising, there is a mention of them in README [1], but that's all, I
couldn't find any other documentation.

Do you happen to see a PPD with these options being used? I'd like to see
an example, but cannot find any.

[1]
http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/README#L1021

2014-10-04 15:47 GMT-04:00 Tobias Hoffmann <lprint-list@thax.hardliners.org>
:

> On 04/10/14 19:36, Alex Korobkin wrote:
>
>> cups-filters package ships with a couple of sample PPDs [2], [3] that
>> basically allow for inserting PJL commands into the job to change its most
>> common options: tray, duplex, etc.
>> I'm trying to find out whether making manual copies via cupsManualCopies
>> is the only way to handle the number of copies. Can pdftopdf or CUPS insert
>> PJL SET COPIES=X into the job?
>>
> Yes (for resonably recent versions). But the string "PJL SET COPIES" (or
> whatever the printer needs) has to come *from the PPD*. Also the emit-jcl
> must not be disabled in pdftopdf's arguments (mostly relevant when pdftopdf
> is NOT the last filter).
>
>  Can CUPS set the number of copies via IPP commands? There is also some
>> code in pdftopdf_jcl.cc [4] that is dealing with a Copies directive in a
>> PPD, but I don't quite understand what it does.
>>
> If the PPD does not specify cupsManualCopies, then the JCL commands *for
> that particular printer* have to be specified in the PPD.
> Also keep in mind that the device might not support deviceCopies for
> certain collate settings; the PPD has to contain the necessary "logic" for
> that, too.
>
> From [4] it follows that certain PPD Attributes /can/ be necessary for
> deviceCopies:
>   *JCLToPDFInterpreter, *pdftopdfJCLBegin, *pdftopdfJCLCopies, Copies
>
>   Tobias
>



-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 2789 bytes --]

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

[Michael Sweet]

Alex,

You'll have to confirm with Till, but AFAIK the pdftopdf filter doesn't support PJL options.

Naturally the socket backend cannot provide out-of-band job ticket information, but the IPP backend *can*.  (that goes back to my comment about IPP Everywhere)

> On Oct 4, 2014, at 1:36 PM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> 
> Hi Michael, 
> 
> Sorry, I should have been more clear with my question. I'm asking about OpenPrinting PDF workflow [1], where client sends a PDF, and CUPS uses just two filters for the job: pdftopdf and a socket/ipp to send the PDF directly to the printer. No conversion to raster is happening: client sends a PDF, printer receives a PDF. 
> 
> cups-filters package ships with a couple of sample PPDs [2], [3] that basically allow for inserting PJL commands into the job to change its most common options: tray, duplex, etc. 
> 
> I'm trying to find out whether making manual copies via cupsManualCopies is the only way to handle the number of copies. Can pdftopdf or CUPS insert PJL SET COPIES=X into the job? Can CUPS set the number of copies via IPP commands? There is also some code in pdftopdf_jcl.cc [4] that is dealing with a Copies directive in a PPD, but I don't quite understand what it does. 
> 
> [1] http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format
> [2] http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/HP-Color_LaserJet_CM3530_MFP-PDF.ppd
> [3] http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/Fuji_Xerox-DocuPrint_CM305_df-PDF.ppd
> [4] http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/filter/pdftopdf/pdftopdf_jcl.cc#L35
> 
> 2014-10-04 11:40 GMT-04:00 Michael Sweet <msweet@apple.com>:
> Alex,
> 
> > On Oct 3, 2014, at 3:28 PM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> >
> > Hi all,
> >
> > I'm looking at example PPDs for pure PDF workflow, and all of them have
> > cupsManualCopies: true
> >
> > Why is that? Is it impossible to tell printer to print a number of copies with pure PDF workflow?
> > Maybe pdftopdf can inject @PJL SET COPIES=X into the file?
> 
> No, that wouldn't work since the PDF-to-raster filters don't support PJL and (for that matter) most PDF printers do not support PJL.
> 
> cupsManualCopies is there because the destination doesn't support generating copies of its own.  If it does, then cupsManualCopies won't be in the PPD - in the case of IPP Everywhere printers the copy count is passed in the job ticket when we create the job from the IPP backend.
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> 
> 
> 
> -- 
> -Alex

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 3339 bytes --]

Michael,

I had tested this workflow with ipp backend, and it didn't communicate the
number of copies to the printer. What conditions must be met for ipp
backend to be able to specify the number of copies?

Should printer reply over IPP with "copies-supported"?

2014-10-04 15:48 GMT-04:00 Michael Sweet <msweet@apple.com>:

> Alex,
>
> You'll have to confirm with Till, but AFAIK the pdftopdf filter doesn't
> support PJL options.
>
> Naturally the socket backend cannot provide out-of-band job ticket
> information, but the IPP backend *can*.  (that goes back to my comment
> about IPP Everywhere)
>
> > On Oct 4, 2014, at 1:36 PM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> >
> > Hi Michael,
> >
> > Sorry, I should have been more clear with my question. I'm asking about
> OpenPrinting PDF workflow [1], where client sends a PDF, and CUPS uses just
> two filters for the job: pdftopdf and a socket/ipp to send the PDF directly
> to the printer. No conversion to raster is happening: client sends a PDF,
> printer receives a PDF.
> >
> > cups-filters package ships with a couple of sample PPDs [2], [3] that
> basically allow for inserting PJL commands into the job to change its most
> common options: tray, duplex, etc.
> >
> > I'm trying to find out whether making manual copies via cupsManualCopies
> is the only way to handle the number of copies. Can pdftopdf or CUPS insert
> PJL SET COPIES=X into the job? Can CUPS set the number of copies via IPP
> commands? There is also some code in pdftopdf_jcl.cc [4] that is dealing
> with a Copies directive in a PPD, but I don't quite understand what it does.
> >
> > [1]
> http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format
> > [2]
> http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/HP-Color_LaserJet_CM3530_MFP-PDF.ppd
> > [3]
> http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/Fuji_Xerox-DocuPrint_CM305_df-PDF.ppd
> > [4]
> http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/filter/pdftopdf/pdftopdf_jcl.cc#L35
> >
> > 2014-10-04 11:40 GMT-04:00 Michael Sweet <msweet@apple.com>:
> > Alex,
> >
> > > On Oct 3, 2014, at 3:28 PM, Alex Korobkin <korobkin+op@gmail.com>
> wrote:
> > >
> > > Hi all,
> > >
> > > I'm looking at example PPDs for pure PDF workflow, and all of them have
> > > cupsManualCopies: true
> > >
> > > Why is that? Is it impossible to tell printer to print a number of
> copies with pure PDF workflow?
> > > Maybe pdftopdf can inject @PJL SET COPIES=X into the file?
> >
> > No, that wouldn't work since the PDF-to-raster filters don't support PJL
> and (for that matter) most PDF printers do not support PJL.
> >
> > cupsManualCopies is there because the destination doesn't support
> generating copies of its own.  If it does, then cupsManualCopies won't be
> in the PPD - in the case of IPP Everywhere printers the copy count is
> passed in the job ticket when we create the job from the IPP backend.
> >
> > _________________________________________________________
> > Michael Sweet, Senior Printing System Engineer, PWG Chair
> >
> >
> >
> >
> > --
> > -Alex
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 4830 bytes --]

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

[Michael Sweet]

Alex,

The PPD needs to use the cupsFilter2 keyword that specifies and output format of application/pdf, application/vnd.cups-pdf, or and image/* format.


> On Oct 5, 2014, at 1:03 AM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> 
> Michael, 
> 
> I had tested this workflow with ipp backend, and it didn't communicate the number of copies to the printer. What conditions must be met for ipp backend to be able to specify the number of copies? 
> 
> Should printer reply over IPP with "copies-supported"? 
> 
> 2014-10-04 15:48 GMT-04:00 Michael Sweet <msweet@apple.com>:
> Alex,
> 
> You'll have to confirm with Till, but AFAIK the pdftopdf filter doesn't support PJL options.
> 
> Naturally the socket backend cannot provide out-of-band job ticket information, but the IPP backend *can*.  (that goes back to my comment about IPP Everywhere)
> 
> > On Oct 4, 2014, at 1:36 PM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> >
> > Hi Michael,
> >
> > Sorry, I should have been more clear with my question. I'm asking about OpenPrinting PDF workflow [1], where client sends a PDF, and CUPS uses just two filters for the job: pdftopdf and a socket/ipp to send the PDF directly to the printer. No conversion to raster is happening: client sends a PDF, printer receives a PDF.
> >
> > cups-filters package ships with a couple of sample PPDs [2], [3] that basically allow for inserting PJL commands into the job to change its most common options: tray, duplex, etc.
> >
> > I'm trying to find out whether making manual copies via cupsManualCopies is the only way to handle the number of copies. Can pdftopdf or CUPS insert PJL SET COPIES=X into the job? Can CUPS set the number of copies via IPP commands? There is also some code in pdftopdf_jcl.cc [4] that is dealing with a Copies directive in a PPD, but I don't quite understand what it does.
> >
> > [1] http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format
> > [2] http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/HP-Color_LaserJet_CM3530_MFP-PDF.ppd
> > [3] http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/Fuji_Xerox-DocuPrint_CM305_df-PDF.ppd
> > [4] http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/filter/pdftopdf/pdftopdf_jcl.cc#L35
> >
> > 2014-10-04 11:40 GMT-04:00 Michael Sweet <msweet@apple.com>:
> > Alex,
> >
> > > On Oct 3, 2014, at 3:28 PM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> > >
> > > Hi all,
> > >
> > > I'm looking at example PPDs for pure PDF workflow, and all of them have
> > > cupsManualCopies: true
> > >
> > > Why is that? Is it impossible to tell printer to print a number of copies with pure PDF workflow?
> > > Maybe pdftopdf can inject @PJL SET COPIES=X into the file?
> >
> > No, that wouldn't work since the PDF-to-raster filters don't support PJL and (for that matter) most PDF printers do not support PJL.
> >
> > cupsManualCopies is there because the destination doesn't support generating copies of its own.  If it does, then cupsManualCopies won't be in the PPD - in the case of IPP Everywhere printers the copy count is passed in the job ticket when we create the job from the IPP backend.
> >
> > _________________________________________________________
> > Michael Sweet, Senior Printing System Engineer, PWG Chair
> >
> >
> >
> >
> > --
> > -Alex
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> 
> 
> 
> -- 
> -Alex

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 4821 bytes --]

Thanks, I had no clue cupsFilter2 keyword would have such effect. But
weirdly, after changing cupsFilter to cupsFilter2 the job is now benig
converted to postscript.

I mean, i had this in the PPD:
*cupsFilter: "application/vnd.cups-pdf 0 -"

And these filters were run:

[Job 12] 2 filters for job:
[Job 12] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66)
[Job 12] - (application/vnd.cups-pdf to printer/tiefighter-color, cost 0)

I changed it to
*cupsFilter2: "application/vnd.cups-pdf 0 -"

And now pdftops is somehow invoked:

[Job 13] 3 filters for job:
[Job 13] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66)
[Job 13] pdftops (application/vnd.cups-pdf to
application/vnd.cups-postscript, cost 100)
[Job 13] - (application/vnd.cups-postscript to printer/tiefighter-color,
cost 0)

This is CUPS 1.7.5 with cups-filers 1.0.58. Why would that happen?

2014-10-06 10:12 GMT-04:00 Michael Sweet <msweet@apple.com>:

> Alex,
>
> The PPD needs to use the cupsFilter2 keyword that specifies and output
> format of application/pdf, application/vnd.cups-pdf, or and image/* format.
>
>
> > On Oct 5, 2014, at 1:03 AM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> >
> > Michael,
> >
> > I had tested this workflow with ipp backend, and it didn't communicate
> the number of copies to the printer. What conditions must be met for ipp
> backend to be able to specify the number of copies?
> >
> > Should printer reply over IPP with "copies-supported"?
> >
> > 2014-10-04 15:48 GMT-04:00 Michael Sweet <msweet@apple.com>:
> > Alex,
> >
> > You'll have to confirm with Till, but AFAIK the pdftopdf filter doesn't
> support PJL options.
> >
> > Naturally the socket backend cannot provide out-of-band job ticket
> information, but the IPP backend *can*.  (that goes back to my comment
> about IPP Everywhere)
> >
> > > On Oct 4, 2014, at 1:36 PM, Alex Korobkin <korobkin+op@gmail.com>
> wrote:
> > >
> > > Hi Michael,
> > >
> > > Sorry, I should have been more clear with my question. I'm asking
> about OpenPrinting PDF workflow [1], where client sends a PDF, and CUPS
> uses just two filters for the job: pdftopdf and a socket/ipp to send the
> PDF directly to the printer. No conversion to raster is happening: client
> sends a PDF, printer receives a PDF.
> > >
> > > cups-filters package ships with a couple of sample PPDs [2], [3] that
> basically allow for inserting PJL commands into the job to change its most
> common options: tray, duplex, etc.
> > >
> > > I'm trying to find out whether making manual copies via
> cupsManualCopies is the only way to handle the number of copies. Can
> pdftopdf or CUPS insert PJL SET COPIES=X into the job? Can CUPS set the
> number of copies via IPP commands? There is also some code in
> pdftopdf_jcl.cc [4] that is dealing with a Copies directive in a PPD, but I
> don't quite understand what it does.
> > >
> > > [1]
> http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format
> > > [2]
> http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/HP-Color_LaserJet_CM3530_MFP-PDF.ppd
> > > [3]
> http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/Fuji_Xerox-DocuPrint_CM305_df-PDF.ppd
> > > [4]
> http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/filter/pdftopdf/pdftopdf_jcl.cc#L35
> > >
> > > 2014-10-04 11:40 GMT-04:00 Michael Sweet <msweet@apple.com>:
> > > Alex,
> > >
> > > > On Oct 3, 2014, at 3:28 PM, Alex Korobkin <korobkin+op@gmail.com>
> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I'm looking at example PPDs for pure PDF workflow, and all of them
> have
> > > > cupsManualCopies: true
> > > >
> > > > Why is that? Is it impossible to tell printer to print a number of
> copies with pure PDF workflow?
> > > > Maybe pdftopdf can inject @PJL SET COPIES=X into the file?
> > >
> > > No, that wouldn't work since the PDF-to-raster filters don't support
> PJL and (for that matter) most PDF printers do not support PJL.
> > >
> > > cupsManualCopies is there because the destination doesn't support
> generating copies of its own.  If it does, then cupsManualCopies won't be
> in the PPD - in the case of IPP Everywhere printers the copy count is
> passed in the job ticket when we create the job from the IPP backend.
> > >
> > > _________________________________________________________
> > > Michael Sweet, Senior Printing System Engineer, PWG Chair
> > >
> > >
> > >
> > >
> > > --
> > > -Alex
> >
> > _________________________________________________________
> > Michael Sweet, Senior Printing System Engineer, PWG Chair
> >
> >
> >
> >
> > --
> > -Alex
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 6907 bytes --]

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

[Michael Sweet]

Alex,

The cupsFilter2 keyword has a different value syntax:

    *cupsFilter2: "src/type dst/type cost filter"

For a PDF printer you want:

    *cupsFilter2: "application/pdf application/vnd.cups-pdf 10 pdftopdf"


> On Oct 6, 2014, at 11:07 AM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> 
> Thanks, I had no clue cupsFilter2 keyword would have such effect. But weirdly, after changing cupsFilter to cupsFilter2 the job is now benig converted to postscript. 
> 
> I mean, i had this in the PPD:
> *cupsFilter: "application/vnd.cups-pdf 0 -"
> 
> And these filters were run: 
> 
> [Job 12] 2 filters for job:
> [Job 12] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66)
> [Job 12] - (application/vnd.cups-pdf to printer/tiefighter-color, cost 0)
> 
> I changed it to 
> *cupsFilter2: "application/vnd.cups-pdf 0 -"
> 
> And now pdftops is somehow invoked:
> 
> [Job 13] 3 filters for job:
> [Job 13] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66)
> [Job 13] pdftops (application/vnd.cups-pdf to application/vnd.cups-postscript, cost 100)
> [Job 13] - (application/vnd.cups-postscript to printer/tiefighter-color, cost 0)
> 
> This is CUPS 1.7.5 with cups-filers 1.0.58. Why would that happen?
> 
> 2014-10-06 10:12 GMT-04:00 Michael Sweet <msweet@apple.com>:
> Alex,
> 
> The PPD needs to use the cupsFilter2 keyword that specifies and output format of application/pdf, application/vnd.cups-pdf, or and image/* format.
> 
> 
> > On Oct 5, 2014, at 1:03 AM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> >
> > Michael,
> >
> > I had tested this workflow with ipp backend, and it didn't communicate the number of copies to the printer. What conditions must be met for ipp backend to be able to specify the number of copies?
> >
> > Should printer reply over IPP with "copies-supported"?
> >
> > 2014-10-04 15:48 GMT-04:00 Michael Sweet <msweet@apple.com>:
> > Alex,
> >
> > You'll have to confirm with Till, but AFAIK the pdftopdf filter doesn't support PJL options.
> >
> > Naturally the socket backend cannot provide out-of-band job ticket information, but the IPP backend *can*.  (that goes back to my comment about IPP Everywhere)
> >
> > > On Oct 4, 2014, at 1:36 PM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> > >
> > > Hi Michael,
> > >
> > > Sorry, I should have been more clear with my question. I'm asking about OpenPrinting PDF workflow [1], where client sends a PDF, and CUPS uses just two filters for the job: pdftopdf and a socket/ipp to send the PDF directly to the printer. No conversion to raster is happening: client sends a PDF, printer receives a PDF.
> > >
> > > cups-filters package ships with a couple of sample PPDs [2], [3] that basically allow for inserting PJL commands into the job to change its most common options: tray, duplex, etc.
> > >
> > > I'm trying to find out whether making manual copies via cupsManualCopies is the only way to handle the number of copies. Can pdftopdf or CUPS insert PJL SET COPIES=X into the job? Can CUPS set the number of copies via IPP commands? There is also some code in pdftopdf_jcl.cc [4] that is dealing with a Copies directive in a PPD, but I don't quite understand what it does.
> > >
> > > [1] http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format
> > > [2] http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/HP-Color_LaserJet_CM3530_MFP-PDF.ppd
> > > [3] http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/Fuji_Xerox-DocuPrint_CM305_df-PDF.ppd
> > > [4] http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/filter/pdftopdf/pdftopdf_jcl.cc#L35
> > >
> > > 2014-10-04 11:40 GMT-04:00 Michael Sweet <msweet@apple.com>:
> > > Alex,
> > >
> > > > On Oct 3, 2014, at 3:28 PM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I'm looking at example PPDs for pure PDF workflow, and all of them have
> > > > cupsManualCopies: true
> > > >
> > > > Why is that? Is it impossible to tell printer to print a number of copies with pure PDF workflow?
> > > > Maybe pdftopdf can inject @PJL SET COPIES=X into the file?
> > >
> > > No, that wouldn't work since the PDF-to-raster filters don't support PJL and (for that matter) most PDF printers do not support PJL.
> > >
> > > cupsManualCopies is there because the destination doesn't support generating copies of its own.  If it does, then cupsManualCopies won't be in the PPD - in the case of IPP Everywhere printers the copy count is passed in the job ticket when we create the job from the IPP backend.
> > >
> > > _________________________________________________________
> > > Michael Sweet, Senior Printing System Engineer, PWG Chair
> > >
> > >
> > >
> > >
> > > --
> > > -Alex
> >
> > _________________________________________________________
> > Michael Sweet, Senior Printing System Engineer, PWG Chair
> >
> >
> >
> >
> > --
> > -Alex
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> 
> 
> 
> -- 
> -Alex

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 6094 bytes --]

Thank you, I didn't notice that. With this change it's back to using just
two filters for the job, but still prints only one copy.
The only line in the output that seems to be relevant to copies is this one:

[Job 14] Getting supported attributes...
[Job 14] Get-Printer-Attributes:
successful-ok-ignored-or-substituted-attributes
(successful-ok-ignored-or-substituted-attributes)
[Job 14] copies-supported=1-1

Am I missing any other step to make it pass the number of copies to the ipp
backend?

2014-10-06 11:32 GMT-04:00 Michael Sweet <msweet@apple.com>:

> Alex,
>
> The cupsFilter2 keyword has a different value syntax:
>
>     *cupsFilter2: "src/type dst/type cost filter"
>
> For a PDF printer you want:
>
>     *cupsFilter2: "application/pdf application/vnd.cups-pdf 10 pdftopdf"
>
>
> > On Oct 6, 2014, at 11:07 AM, Alex Korobkin <korobkin+op@gmail.com>
> wrote:
> >
> > Thanks, I had no clue cupsFilter2 keyword would have such effect. But
> weirdly, after changing cupsFilter to cupsFilter2 the job is now benig
> converted to postscript.
> >
> > I mean, i had this in the PPD:
> > *cupsFilter: "application/vnd.cups-pdf 0 -"
> >
> > And these filters were run:
> >
> > [Job 12] 2 filters for job:
> > [Job 12] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66)
> > [Job 12] - (application/vnd.cups-pdf to printer/tiefighter-color, cost 0)
> >
> > I changed it to
> > *cupsFilter2: "application/vnd.cups-pdf 0 -"
> >
> > And now pdftops is somehow invoked:
> >
> > [Job 13] 3 filters for job:
> > [Job 13] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66)
> > [Job 13] pdftops (application/vnd.cups-pdf to
> application/vnd.cups-postscript, cost 100)
> > [Job 13] - (application/vnd.cups-postscript to printer/tiefighter-color,
> cost 0)
> >
> > This is CUPS 1.7.5 with cups-filers 1.0.58. Why would that happen?
> >
> > 2014-10-06 10:12 GMT-04:00 Michael Sweet <msweet@apple.com>:
> > Alex,
> >
> > The PPD needs to use the cupsFilter2 keyword that specifies and output
> format of application/pdf, application/vnd.cups-pdf, or and image/* format.
> >
> >
> > > On Oct 5, 2014, at 1:03 AM, Alex Korobkin <korobkin+op@gmail.com>
> wrote:
> > >
> > > Michael,
> > >
> > > I had tested this workflow with ipp backend, and it didn't communicate
> the number of copies to the printer. What conditions must be met for ipp
> backend to be able to specify the number of copies?
> > >
> > > Should printer reply over IPP with "copies-supported"?
> > >
> > > 2014-10-04 15:48 GMT-04:00 Michael Sweet <msweet@apple.com>:
> > > Alex,
> > >
> > > You'll have to confirm with Till, but AFAIK the pdftopdf filter
> doesn't support PJL options.
> > >
> > > Naturally the socket backend cannot provide out-of-band job ticket
> information, but the IPP backend *can*.  (that goes back to my comment
> about IPP Everywhere)
> > >
> > > > On Oct 4, 2014, at 1:36 PM, Alex Korobkin <korobkin+op@gmail.com>
> wrote:
> > > >
> > > > Hi Michael,
> > > >
> > > > Sorry, I should have been more clear with my question. I'm asking
> about OpenPrinting PDF workflow [1], where client sends a PDF, and CUPS
> uses just two filters for the job: pdftopdf and a socket/ipp to send the
> PDF directly to the printer. No conversion to raster is happening: client
> sends a PDF, printer receives a PDF.
> > > >
> > > > cups-filters package ships with a couple of sample PPDs [2], [3]
> that basically allow for inserting PJL commands into the job to change its
> most common options: tray, duplex, etc.
> > > >
> > > > I'm trying to find out whether making manual copies via
> cupsManualCopies is the only way to handle the number of copies. Can
> pdftopdf or CUPS insert PJL SET COPIES=X into the job? Can CUPS set the
> number of copies via IPP commands? There is also some code in
> pdftopdf_jcl.cc [4] that is dealing with a Copies directive in a PPD, but I
> don't quite understand what it does.
> > > >
> > > > [1]
> http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format
> > > > [2]
> http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/HP-Color_LaserJet_CM3530_MFP-PDF.ppd
> > > > [3]
> http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/Fuji_Xerox-DocuPrint_CM305_df-PDF.ppd
> > > > [4]
> http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/filter/pdftopdf/pdftopdf_jcl.cc#L35
> > > >
> > > > 2014-10-04 11:40 GMT-04:00 Michael Sweet <msweet@apple.com>:
> > > > Alex,
> > > >
> > > > > On Oct 3, 2014, at 3:28 PM, Alex Korobkin <korobkin+op@gmail.com>
> wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I'm looking at example PPDs for pure PDF workflow, and all of them
> have
> > > > > cupsManualCopies: true
> > > > >
> > > > > Why is that? Is it impossible to tell printer to print a number of
> copies with pure PDF workflow?
> > > > > Maybe pdftopdf can inject @PJL SET COPIES=X into the file?
> > > >
> > > > No, that wouldn't work since the PDF-to-raster filters don't support
> PJL and (for that matter) most PDF printers do not support PJL.
> > > >
> > > > cupsManualCopies is there because the destination doesn't support
> generating copies of its own.  If it does, then cupsManualCopies won't be
> in the PPD - in the case of IPP Everywhere printers the copy count is
> passed in the job ticket when we create the job from the IPP backend.
> > > >
> > > > _________________________________________________________
> > > > Michael Sweet, Senior Printing System Engineer, PWG Chair
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > -Alex
> > >
> > > _________________________________________________________
> > > Michael Sweet, Senior Printing System Engineer, PWG Chair
> > >
> > >
> > >
> > >
> > > --
> > > -Alex
> >
> > _________________________________________________________
> > Michael Sweet, Senior Printing System Engineer, PWG Chair
> >
> >
> >
> >
> > --
> > -Alex
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 8554 bytes --]

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

[Michael Sweet]

Alex,

The copies are getting passed.  The printer is saying it doesn't support copies.


> On Oct 6, 2014, at 11:55 AM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> 
> Thank you, I didn't notice that. With this change it's back to using just two filters for the job, but still prints only one copy. 
> The only line in the output that seems to be relevant to copies is this one:
> 
> [Job 14] Getting supported attributes...
> [Job 14] Get-Printer-Attributes: successful-ok-ignored-or-substituted-attributes (successful-ok-ignored-or-substituted-attributes)
> [Job 14] copies-supported=1-1
> 
> Am I missing any other step to make it pass the number of copies to the ipp backend?
> 
> 2014-10-06 11:32 GMT-04:00 Michael Sweet <msweet@apple.com>:
> Alex,
> 
> The cupsFilter2 keyword has a different value syntax:
> 
>     *cupsFilter2: "src/type dst/type cost filter"
> 
> For a PDF printer you want:
> 
>     *cupsFilter2: "application/pdf application/vnd.cups-pdf 10 pdftopdf"
> 
> 
> > On Oct 6, 2014, at 11:07 AM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> >
> > Thanks, I had no clue cupsFilter2 keyword would have such effect. But weirdly, after changing cupsFilter to cupsFilter2 the job is now benig converted to postscript.
> >
> > I mean, i had this in the PPD:
> > *cupsFilter: "application/vnd.cups-pdf 0 -"
> >
> > And these filters were run:
> >
> > [Job 12] 2 filters for job:
> > [Job 12] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66)
> > [Job 12] - (application/vnd.cups-pdf to printer/tiefighter-color, cost 0)
> >
> > I changed it to
> > *cupsFilter2: "application/vnd.cups-pdf 0 -"
> >
> > And now pdftops is somehow invoked:
> >
> > [Job 13] 3 filters for job:
> > [Job 13] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66)
> > [Job 13] pdftops (application/vnd.cups-pdf to application/vnd.cups-postscript, cost 100)
> > [Job 13] - (application/vnd.cups-postscript to printer/tiefighter-color, cost 0)
> >
> > This is CUPS 1.7.5 with cups-filers 1.0.58. Why would that happen?
> >
> > 2014-10-06 10:12 GMT-04:00 Michael Sweet <msweet@apple.com>:
> > Alex,
> >
> > The PPD needs to use the cupsFilter2 keyword that specifies and output format of application/pdf, application/vnd.cups-pdf, or and image/* format.
> >
> >
> > > On Oct 5, 2014, at 1:03 AM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> > >
> > > Michael,
> > >
> > > I had tested this workflow with ipp backend, and it didn't communicate the number of copies to the printer. What conditions must be met for ipp backend to be able to specify the number of copies?
> > >
> > > Should printer reply over IPP with "copies-supported"?
> > >
> > > 2014-10-04 15:48 GMT-04:00 Michael Sweet <msweet@apple.com>:
> > > Alex,
> > >
> > > You'll have to confirm with Till, but AFAIK the pdftopdf filter doesn't support PJL options.
> > >
> > > Naturally the socket backend cannot provide out-of-band job ticket information, but the IPP backend *can*.  (that goes back to my comment about IPP Everywhere)
> > >
> > > > On Oct 4, 2014, at 1:36 PM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> > > >
> > > > Hi Michael,
> > > >
> > > > Sorry, I should have been more clear with my question. I'm asking about OpenPrinting PDF workflow [1], where client sends a PDF, and CUPS uses just two filters for the job: pdftopdf and a socket/ipp to send the PDF directly to the printer. No conversion to raster is happening: client sends a PDF, printer receives a PDF.
> > > >
> > > > cups-filters package ships with a couple of sample PPDs [2], [3] that basically allow for inserting PJL commands into the job to change its most common options: tray, duplex, etc.
> > > >
> > > > I'm trying to find out whether making manual copies via cupsManualCopies is the only way to handle the number of copies. Can pdftopdf or CUPS insert PJL SET COPIES=X into the job? Can CUPS set the number of copies via IPP commands? There is also some code in pdftopdf_jcl.cc [4] that is dealing with a Copies directive in a PPD, but I don't quite understand what it does.
> > > >
> > > > [1] http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format
> > > > [2] http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/HP-Color_LaserJet_CM3530_MFP-PDF.ppd
> > > > [3] http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/Fuji_Xerox-DocuPrint_CM305_df-PDF.ppd
> > > > [4] http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/filter/pdftopdf/pdftopdf_jcl.cc#L35
> > > >
> > > > 2014-10-04 11:40 GMT-04:00 Michael Sweet <msweet@apple.com>:
> > > > Alex,
> > > >
> > > > > On Oct 3, 2014, at 3:28 PM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I'm looking at example PPDs for pure PDF workflow, and all of them have
> > > > > cupsManualCopies: true
> > > > >
> > > > > Why is that? Is it impossible to tell printer to print a number of copies with pure PDF workflow?
> > > > > Maybe pdftopdf can inject @PJL SET COPIES=X into the file?
> > > >
> > > > No, that wouldn't work since the PDF-to-raster filters don't support PJL and (for that matter) most PDF printers do not support PJL.
> > > >
> > > > cupsManualCopies is there because the destination doesn't support generating copies of its own.  If it does, then cupsManualCopies won't be in the PPD - in the case of IPP Everywhere printers the copy count is passed in the job ticket when we create the job from the IPP backend.
> > > >
> > > > _________________________________________________________
> > > > Michael Sweet, Senior Printing System Engineer, PWG Chair
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > -Alex
> > >
> > > _________________________________________________________
> > > Michael Sweet, Senior Printing System Engineer, PWG Chair
> > >
> > >
> > >
> > >
> > > --
> > > -Alex
> >
> > _________________________________________________________
> > Michael Sweet, Senior Printing System Engineer, PWG Chair
> >
> >
> >
> >
> > --
> > -Alex
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> 
> 
> 
> -- 
> -Alex

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[Till Kamppeter]

On 10/06/2014 05:32 PM, Michael Sweet wrote:
> Alex,
> 
> The cupsFilter2 keyword has a different value syntax:
> 
>     *cupsFilter2: "src/type dst/type cost filter"
> 
> For a PDF printer you want:
> 
>     *cupsFilter2: "application/pdf application/vnd.cups-pdf 10 pdftopdf"
> 

What do I have to add to a /usr/share/cups/drv/*.drv filr to generate a
cupsFilter2 line? "Filter" only generates cupsFilter lines.

Or do I need to create completely static PPD files?

   Till

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

[Michael Sweet]

Till,

> On Oct 7, 2014, at 7:49 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> On 10/06/2014 05:32 PM, Michael Sweet wrote:
>> Alex,
>> 
>> The cupsFilter2 keyword has a different value syntax:
>> 
>>    *cupsFilter2: "src/type dst/type cost filter"
>> 
>> For a PDF printer you want:
>> 
>>    *cupsFilter2: "application/pdf application/vnd.cups-pdf 10 pdftopdf"
>> 
> 
> What do I have to add to a /usr/share/cups/drv/*.drv filr to generate a
> cupsFilter2 line? "Filter" only generates cupsFilter lines.
> 
> Or do I need to create completely static PPD files?

Attribute cupsFilter2 "" "src/type dst/type cost filter"

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[Till Kamppeter]

On 10/07/2014 01:55 PM, Michael Sweet wrote:
> Till,
> 
>> On Oct 7, 2014, at 7:49 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>>
>> On 10/06/2014 05:32 PM, Michael Sweet wrote:
>>> Alex,
>>>
>>> The cupsFilter2 keyword has a different value syntax:
>>>
>>>    *cupsFilter2: "src/type dst/type cost filter"
>>>
>>> For a PDF printer you want:
>>>
>>>    *cupsFilter2: "application/pdf application/vnd.cups-pdf 10 pdftopdf"
>>>
>>
>> What do I have to add to a /usr/share/cups/drv/*.drv filr to generate a
>> cupsFilter2 line? "Filter" only generates cupsFilter lines.
>>
>> Or do I need to create completely static PPD files?
> 
> Attribute cupsFilter2 "" "src/type dst/type cost filter"
>

Thanks, I ended up with this, too. I only thought that there is perhaps
something specific.

   Till

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

[Till Kamppeter]

On 10/04/2014 09:48 PM, Michael Sweet wrote:
> Alex,
> 
> You'll have to confirm with Till, but AFAIK the pdftopdf filter doesn't support PJL options.
> 

pdftopdf adds PJL if the printer is a PDF printer. The printer is
considered a PDF printer if there is a "*JCLToPDFInterpreter:" line in
the PPD file.

   Till

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

Hi Till,

You're right, JCLToPDFInterpreter is already set in the example PPDs
shipped with cups-filters [1].
But what needs to be added to those PPDs to have printers make copies in
hardware instead of cupsManualCopies?
There seem to be some code for it in pdftopdf [2], but it is unclear what
exactly needs to be in the PPD for it to work.

[1]
http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/HP-Color_LaserJet_CM3530_MFP-PDF.ppd
[2]
http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/filter/pdftopdf/pdftopdf_jcl.cc#L35


2014-10-06 8:54 GMT-04:00 Till Kamppeter <till.kamppeter@gmail.com>:

> On 10/04/2014 09:48 PM, Michael Sweet wrote:
> > Alex,
> >
> > You'll have to confirm with Till, but AFAIK the pdftopdf filter doesn't
> support PJL options.
> >
>
> pdftopdf adds PJL if the printer is a PDF printer. The printer is
> considered a PDF printer if there is a "*JCLToPDFInterpreter:" line in
> the PPD file.
>
>    Till
>
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
>



-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 2435 bytes --]

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

Till,

I'm not sure if you noticed my question there, sorry for bugging you, but I
have no one else to ask.

Do you know what should be added to a JCL-based PPD in order make pdftopdf
to generate hardware copies on a PDF printer?


2014-10-06 10:06 GMT-04:00 Alex Korobkin <korobkin+op@gmail.com>:

> Hi Till,
>
> You're right, JCLToPDFInterpreter is already set in the example PPDs
> shipped with cups-filters [1].
> But what needs to be added to those PPDs to have printers make copies in
> hardware instead of cupsManualCopies?
> There seem to be some code for it in pdftopdf [2], but it is unclear what
> exactly needs to be in the PPD for it to work.
>
> [1]
> http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/HP-Color_LaserJet_CM3530_MFP-PDF.ppd
> [2]
> http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/filter/pdftopdf/pdftopdf_jcl.cc#L35
>
>
> 2014-10-06 8:54 GMT-04:00 Till Kamppeter <till.kamppeter@gmail.com>:
>
> On 10/04/2014 09:48 PM, Michael Sweet wrote:
>> > Alex,
>> >
>> > You'll have to confirm with Till, but AFAIK the pdftopdf filter doesn't
>> support PJL options.
>> >
>>
>> pdftopdf adds PJL if the printer is a PDF printer. The printer is
>> considered a PDF printer if there is a "*JCLToPDFInterpreter:" line in
>> the PPD file.
>>
>>    Till
>>
>>
>> _______________________________________________
>> Printing-architecture mailing list
>> Printing-architecture@lists.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
>>
>
>
>
> --
> -Alex
>



-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 3240 bytes --]

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

[Till Kamppeter]

On 10/06/2014 04:06 PM, Alex Korobkin wrote:
> Hi Till, 
> 
> You're right, JCLToPDFInterpreter is already set in the example PPDs
> shipped with cups-filters [1]. 
> But what needs to be added to those PPDs to have printers make copies in
> hardware instead of cupsManualCopies? 

pdftopdf uses cupsManualCopies. If cupsManualCopies is set in the PPD
software copies are done, otherwise hardware copies. If the printer
supports PJL, an appropriate command to generate the copies is added to
the PJL header.

How can I make pdftopdf add an IPP attribute to the job which generates
the copies with the attribute being passed on to the printer by the IPP
backend (when output format is set to PDF or PWG Raster by a cupsFilter2
keyword in the PPD.

And for PPD-less printing, how do I set the FINAL_CONTENT_TYPE there? Is
it possible to do it out of a System V interface script?

   Till

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

2014-10-07 16:03 GMT-04:00 Till Kamppeter <till.kamppeter@gmail.com>:

> On 10/06/2014 04:06 PM, Alex Korobkin wrote:
> > Hi Till,
> >
> > You're right, JCLToPDFInterpreter is already set in the example PPDs
> > shipped with cups-filters [1].
> > But what needs to be added to those PPDs to have printers make copies in
> > hardware instead of cupsManualCopies?
>
> pdftopdf uses cupsManualCopies. If cupsManualCopies is set in the PPD
> software copies are done, otherwise hardware copies. If the printer
> supports PJL, an appropriate command to generate the copies is added to
> the PJL header.
>

Till, I've just tested it again on my PDF printer and PJL-based PPD, and
pdftopdf creates software copies regardless of the value of
cupsManualCopies. Shouldn't it insert PJL SET COPIES=X when
cupsManualCopies is False or not present?

How can I make pdftopdf add an IPP attribute to the job which generates
> the copies with the attribute being passed on to the printer by the IPP
> backend (when output format is set to PDF or PWG Raster by a cupsFilter2
> keyword in the PPD.
>
> And for PPD-less printing, how do I set the FINAL_CONTENT_TYPE there? Is
> it possible to do it out of a System V interface script?
>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 1923 bytes --]

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

[Tobias Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

On 07/10/14 23:18, Alex Korobkin wrote:
> 2014-10-07 16:03 GMT-04:00 Till Kamppeter <till.kamppeter@gmail.com 
> <mailto:till.kamppeter@gmail.com>>:
>
>     pdftopdf uses cupsManualCopies. If cupsManualCopies is set in the PPD
>     software copies are done, otherwise hardware copies. If the printer
>     supports PJL, an appropriate command to generate the copies is
>     added to
>     the PJL header.
>
>
> Till, I've just tested it again on my PDF printer and PJL-based PPD, 
> and pdftopdf creates software copies regardless of the value of 
> cupsManualCopies. Shouldn't it insert PJL SET COPIES=X when 
> cupsManualCopies is False or not present?
>

I'm not sure what exactly is happening in your setup.
Maybe your PPD is missing something (- and I'm not an expert for PPD/PJL)?
Maybe you don't have a recent cups-filters (>= 1.0.34)?
Maybe you're hitting some edge-cases that are not handled correctly in 
the current code?

AFAIK no-one else has reported a problem with PJL in a pure pdf 
workflow, and I can't find an obvious flaw in the code which deals with 
PJL in pdftopdf. The code is also basically copied over from the old 
pdftopdf implementation (cups-filters <=1.0.20); if your PPD does hw 
copy with the old implementation, but not with >=1.0.34, I will probably 
be able to fix that.

   Tobias


[-- Attachment #2: Type: text/html, Size: 2358 bytes --]

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]

2014-10-07 17:45 GMT-04:00 Tobias Hoffmann <lprint-list@thax.hardliners.org>
:

>  On 07/10/14 23:18, Alex Korobkin wrote:
>
> 2014-10-07 16:03 GMT-04:00 Till Kamppeter <till.kamppeter@gmail.com>:
>
>> pdftopdf uses cupsManualCopies. If cupsManualCopies is set in the PPD
>> software copies are done, otherwise hardware copies. If the printer
>> supports PJL, an appropriate command to generate the copies is added to
>> the PJL header.
>>
>
>  Till, I've just tested it again on my PDF printer and PJL-based PPD, and
> pdftopdf creates software copies regardless of the value of
> cupsManualCopies. Shouldn't it insert PJL SET COPIES=X when
> cupsManualCopies is False or not present?
>
>
> I'm not sure what exactly is happening in your setup.
> Maybe your PPD is missing something (- and I'm not an expert for PPD/PJL)?
> Maybe you don't have a recent cups-filters (>= 1.0.34)?
> Maybe you're hitting some edge-cases that are not handled correctly in the
> current code?
>
> AFAIK no-one else has reported a problem with PJL in a pure pdf workflow,
> and I can't find an obvious flaw in the code which deals with PJL in
> pdftopdf. The code is also basically copied over from the old pdftopdf
> implementation (cups-filters <=1.0.20); if your PPD does hw copy with the
> old implementation, but not with >=1.0.34, I will probably be able to fix
> that.
>
>
I'm using cups-filters 1.0.58 with CUPS 1.7.5, and currently just testing
this PDF workflow. My normal setup is PDF to PostScript workflow.

From what Till said I understood that if cupsManualCopies is True in the
PPD, pdftopdf will create software copies. If it is set to False or is
omitted, hardware copies will be made (how exactly?).

So I took a sample PPD [1] from cups-filters package and tested job
printing with and without cupsManualCopies. No difference, it always makes
software copies. What needs to be done to make it add code for hardware
copies to be made?

[1]
http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/annotate/head:/ppd/Fuji_Xerox-DocuPrint_CM305_df-PDF.ppd


  Tobias
>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 4151 bytes --]

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

[Till Kamppeter]

On 10/07/2014 11:45 PM, Tobias Hoffmann wrote:
> I'm not sure what exactly is happening in your setup.
> Maybe your PPD is missing something (- and I'm not an expert for PPD/PJL)?
> Maybe you don't have a recent cups-filters (>= 1.0.34)?
> Maybe you're hitting some edge-cases that are not handled correctly in
> the current code?
> 
> AFAIK no-one else has reported a problem with PJL in a pure pdf
> workflow, and I can't find an obvious flaw in the code which deals with
> PJL in pdftopdf. The code is also basically copied over from the old
> pdftopdf implementation (cups-filters <=1.0.20); if your PPD does hw
> copy with the old implementation, but not with >=1.0.34, I will probably
> be able to fix that.
> 

Tobias, do you know for what the call

emitJCLOptions(stdout,ppd,param.deviceCopies);

in the emitPreamble() function in pdftopdf_jcl.cc is good for? For me it
looks like that it serves for inserting JCL options, but inserting JCL
options is already done by

ppdEmitJCL(ppd,stdout,param.jobId,param.user,param.title);

I can even comment out

emitJCLOptions(stdout,ppd,param.deviceCopies);

and the output stays the same.

What I want to have is that if param.deviceCopies is not 1 (= multiple
hardware copies) that

@PJL SET COPIES=...

is added.

Currently all works fine for PPDs with "*cupsManualCopies: True" as
pdftopdf generates software copies then. Without this entry pdftopdf
sends only one copy of the PDF content and adds only a comment for
subsequent filters. It does not add anything to generate the copies on a
PDF printer.

   Till

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

[Tobias Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 3329 bytes --]

On 08/10/14 11:57, Till Kamppeter wrote:
> On 10/07/2014 11:45 PM, Tobias Hoffmann wrote:
>> I'm not sure what exactly is happening in your setup.
>> Maybe your PPD is missing something (- and I'm not an expert for PPD/PJL)?
>> Maybe you don't have a recent cups-filters (>= 1.0.34)?
>> Maybe you're hitting some edge-cases that are not handled correctly in
>> the current code?
>>
>> AFAIK no-one else has reported a problem with PJL in a pure pdf
>> workflow, and I can't find an obvious flaw in the code which deals with
>> PJL in pdftopdf. The code is also basically copied over from the old
>> pdftopdf implementation (cups-filters<=1.0.20); if your PPD does hw
>> copy with the old implementation, but not with>=1.0.34, I will probably
>> be able to fix that.
>>
> Tobias, do you know for what the call
>
> emitJCLOptions(stdout,ppd,param.deviceCopies);
>
> in the emitPreamble() function in pdftopdf_jcl.cc is good for? For me it
> looks like that it serves for inserting JCL options, but inserting JCL
> options is already done by
>
> ppdEmitJCL(ppd,stdout,param.jobId,param.user,param.title);

The code basically comes from the old pdftopdf implementation by Koji 
Otani. The same code is also present in imagetopdf.c .
There is also a section in cups-filter's README about that:

> if (Copies option is specified in the PPD file) {
>     mark Number of copies specified
> } else if (pdftopdfJCLCopies is specified in the PPD file) {
>     output JCL specified with JCLCopies
> }
>
> for (each marked options) {
>     if (pdftopdfJCL<marked option's name> is specified in the PPD file) {
>         output it's value as a JCL
>     } else if (pdftopdfJCLBegin attributes is specified in the PPD file) {
>         output "<option's name>=<marked choice>;" as a JCL
>     }
> }

AFAIUI Koji had to "invent" new pdftopdfJCL* keywords for the PJL + PDF 
case;
and for some reason ppdEmitJCL could not be used for them, so he added 
emitJCLOptions.


> I can even comment out
>
> emitJCLOptions(stdout,ppd,param.deviceCopies);
>
> and the output stays the same.

Probably because the PPD neither contain *Copies nor *pdftopdfJCLCopies?

> What I want to have is that if param.deviceCopies is not 1 (= multiple
> hardware copies) that
>
> @PJL SET COPIES=...
>
> is added.

Have you tried adding something along this lines:

*OpenUI *Copies/Number of Copies: PickOne
*OrderDependency: 100 AnySetup *Copies
*DefaultCopies: 1
*Copies 1/1: "@PJL SET COPIES=1"
*Copies 2/2: "@PJL SET COPIES=2"
*Copies 3/3: "@PJL SET COPIES=3"
*Copies 4/4: "@PJL SET COPIES=4"
...
*CloseUI: *Copies

similar to how Foomatic-based work?

A real PPD also has to take other settings into account here (e.g. 
collate, staple, ...), if the printer-hardware does not support all 
combinations /  has staple-limits / ...

> Currently all works fine for PPDs with "*cupsManualCopies: True" as
> pdftopdf generates software copies then. Without this entry pdftopdf
> sends only one copy of the PDF content and adds only a comment for
> subsequent filters. It does not add anything to generate the copies on a
> PDF printer.
The PPD author (printer manufacturer, ...) chooses to EITHER set 
"*cupsManualCopes: True" OR add *Copies / *pdftopdfJCLCopies / ... (i.e. 
whatever is required to generate correct JCL output for their printer 
model).

   Tobias




[-- Attachment #2: Type: text/html, Size: 4817 bytes --]

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 3931 bytes --]

Making a "Number of Copies" dialog doesn't seem to be a great idea, because
users will never notice that. They will keep setting the number of copies
in the usual place in GUI.

What is this pdftopdfJCLCopies keyword, will it allow to inject PJL SET
COPIES command into the job?
If pdftopdf is capable of inserting a comment about the number of copies
requested, it should be able to insert this command as well, what do you
think?

2014-10-08 10:40 GMT-04:00 Tobias Hoffmann <lprint-list@thax.hardliners.org>
:

>  On 08/10/14 11:57, Till Kamppeter wrote:
>
> On 10/07/2014 11:45 PM, Tobias Hoffmann wrote:
>
>  I'm not sure what exactly is happening in your setup.
> Maybe your PPD is missing something (- and I'm not an expert for PPD/PJL)?
> Maybe you don't have a recent cups-filters (>= 1.0.34)?
> Maybe you're hitting some edge-cases that are not handled correctly in
> the current code?
>
> AFAIK no-one else has reported a problem with PJL in a pure pdf
> workflow, and I can't find an obvious flaw in the code which deals with
> PJL in pdftopdf. The code is also basically copied over from the old
> pdftopdf implementation (cups-filters <=1.0.20); if your PPD does hw
> copy with the old implementation, but not with >=1.0.34, I will probably
> be able to fix that.
>
>
>  Tobias, do you know for what the call
>
> emitJCLOptions(stdout,ppd,param.deviceCopies);
>
> in the emitPreamble() function in pdftopdf_jcl.cc is good for? For me it
> looks like that it serves for inserting JCL options, but inserting JCL
> options is already done by
>
> ppdEmitJCL(ppd,stdout,param.jobId,param.user,param.title);
>
>
> The code basically comes from the old pdftopdf implementation by Koji
> Otani. The same code is also present in imagetopdf.c .
> There is also a section in cups-filter's README about that:
>
> if (Copies option is specified in the PPD file) {
>     mark Number of copies specified
> } else if (pdftopdfJCLCopies is specified in the PPD file) {
>     output JCL specified with JCLCopies
> }
>
> for (each marked options) {
>     if (pdftopdfJCL<marked option's name> is specified in the PPD file) {
>         output it's value as a JCL
>     } else if (pdftopdfJCLBegin attributes is specified in the PPD file) {
>         output "<option's name>=<marked choice>;" as a JCL
>     }
> }
>
>
> AFAIUI Koji had to "invent" new pdftopdfJCL* keywords for the PJL + PDF
> case;
> and for some reason ppdEmitJCL could not be used for them, so he added
> emitJCLOptions.
>
>
>  I can even comment out
>
> emitJCLOptions(stdout,ppd,param.deviceCopies);
>
> and the output stays the same.
>
>
> Probably because the PPD neither contain *Copies nor *pdftopdfJCLCopies?
>
>  What I want to have is that if param.deviceCopies is not 1 (= multiple
> hardware copies) that
>
> @PJL SET COPIES=...
>
> is added.
>
>
> Have you tried adding something along this lines:
>
> *OpenUI *Copies/Number of Copies: PickOne
> *OrderDependency: 100 AnySetup *Copies
> *DefaultCopies: 1
> *Copies 1/1: "@PJL SET COPIES=1"
> *Copies 2/2: "@PJL SET COPIES=2"
> *Copies 3/3: "@PJL SET COPIES=3"
> *Copies 4/4: "@PJL SET COPIES=4"
> ...
> *CloseUI: *Copies
>
> similar to how Foomatic-based work?
>
> A real PPD also has to take other settings into account here (e.g.
> collate, staple, ...), if the printer-hardware does not support all
> combinations /  has staple-limits / ...
>
>  Currently all works fine for PPDs with "*cupsManualCopies: True" as
> pdftopdf generates software copies then. Without this entry pdftopdf
> sends only one copy of the PDF content and adds only a comment for
> subsequent filters. It does not add anything to generate the copies on a
> PDF printer.
>
>  The PPD author (printer manufacturer, ...) chooses to EITHER set
> "*cupsManualCopes: True" OR add *Copies / *pdftopdfJCLCopies / ... (i.e.
> whatever is required to generate correct JCL output for their printer
> model).
>
>   Tobias
>
>
>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 5677 bytes --]

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

[Tobias Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 6276 bytes --]

On 08/10/14 21:41, Alex Korobkin wrote:
> Making a "Number of Copies" dialog doesn't seem to be a great idea, 
> because users will never notice that. They will keep setting the 
> number of copies in the usual place in GUI.
I don't know exactly how PPDs work.
I just found out that Foomatic-based PPDs make Hardware-Copies work 
similar to what I wrote; this might have to do with the ability of PPDs 
to specify constraints like "Hardware copies only work when Collate is 
set to XY".

Also I've seen
*JCLOpenUI
*JCL....

instead of just *OpenUI. Maybe this also makes a difference.

> What is this pdftopdfJCLCopies keyword, will it allow to inject PJL 
> SET COPIES command into the job?
     if ((attr = ppdFindAttr(ppd,"pdftopdfJCLCopies",buf)) != NULL) {
       fputs(attr->value,fp);
       datawritten = 1;
     } else if (withJCL) {
       fprintf(fp,"Copies=%d;",deviceCopies);
       datawritten = 1;
     }

AFAIUI yes. It will write the value that corresponds to the 
*pdftopdfJCLCopies attribute which has the number of copies as specifier 
string, i.e. something along these lines:

*pdftopdfJCLCopies 1: "@PJL SET COPIES=1"
*pdftopdfJCLCopies 2: "@PJL SET COPIES=2"
*pdftopdfJCLCopies 3: "@PJL SET COPIES=3"

> If pdftopdf is capable of inserting a comment about the number of 
> copies requested, it should be able to insert this command as well, 
> what do you think?

It obviously is able. And *Copies seems to be usual way to handle 
Hardware-Copies for PS based printers. pdftopdf (and imagetopdf !) 
allows you to use this mechanism even for PDF based printers, too.
I'm not sure about the "Number of Copies" dialog you were talking about 
... I have not tried it myself ... but if you are correct, it will 
either also appear for PS based PPDs which allow hardware copies, or 
they are somehow able to reuse the existing GUI field for that (you 
might have to ask someone more familiar with PPDs about that) ... or 
your printing dialog fails to handle the *Copies attribute in a sensible 
way?

Either way, pdftopdf has little to do with your issue. imagetopdf uses 
the same code. Foomatic and PS based PPDs work similarly.
That's not to say that PPDs don't have shortcomings; in fact, CUPS has 
deprecated it's PPD API in favor of the Job Ticket API (JTAPI), which, 
AFAIUI, has IPP options (Mike also mentioned them) for hw copy generation.

   Tobias


> 2014-10-08 10:40 GMT-04:00 Tobias Hoffmann 
> <lprint-list@thax.hardliners.org 
> <mailto:lprint-list@thax.hardliners.org>>:
>
>     On 08/10/14 11:57, Till Kamppeter wrote:
>>     On 10/07/2014 11:45 PM, Tobias Hoffmann wrote:
>>>     I'm not sure what exactly is happening in your setup.
>>>     Maybe your PPD is missing something (- and I'm not an expert for PPD/PJL)?
>>>     Maybe you don't have a recent cups-filters (>= 1.0.34)?
>>>     Maybe you're hitting some edge-cases that are not handled correctly in
>>>     the current code?
>>>
>>>     AFAIK no-one else has reported a problem with PJL in a pure pdf
>>>     workflow, and I can't find an obvious flaw in the code which deals with
>>>     PJL in pdftopdf. The code is also basically copied over from the old
>>>     pdftopdf implementation (cups-filters<=1.0.20); if your PPD does hw
>>>     copy with the old implementation, but not with>=1.0.34, I will probably
>>>     be able to fix that.
>>>
>>     Tobias, do you know for what the call
>>
>>     emitJCLOptions(stdout,ppd,param.deviceCopies);
>>
>>     in the emitPreamble() function in pdftopdf_jcl.cc is good for? For me it
>>     looks like that it serves for inserting JCL options, but inserting JCL
>>     options is already done by
>>
>>     ppdEmitJCL(ppd,stdout,param.jobId,param.user,param.title);
>
>     The code basically comes from the old pdftopdf implementation by
>     Koji Otani. The same code is also present in imagetopdf.c .
>     There is also a section in cups-filter's README about that:
>
>>     if (Copies option is specified in the PPD file) {
>>         mark Number of copies specified
>>     } else if (pdftopdfJCLCopies is specified in the PPD file) {
>>         output JCL specified with JCLCopies
>>     }
>>
>>     for (each marked options) {
>>         if (pdftopdfJCL<marked option's name> is specified in the PPD
>>     file) {
>>             output it's value as a JCL
>>         } else if (pdftopdfJCLBegin attributes is specified in the
>>     PPD file) {
>>             output "<option's name>=<marked choice>;" as a JCL
>>         }
>>     }
>
>     AFAIUI Koji had to "invent" new pdftopdfJCL* keywords for the PJL
>     + PDF case;
>     and for some reason ppdEmitJCL could not be used for them, so he
>     added emitJCLOptions.
>
>
>>     I can even comment out
>>
>>     emitJCLOptions(stdout,ppd,param.deviceCopies);
>>
>>     and the output stays the same.
>
>     Probably because the PPD neither contain *Copies nor
>     *pdftopdfJCLCopies?
>
>>     What I want to have is that if param.deviceCopies is not 1 (= multiple
>>     hardware copies) that
>>
>>     @PJL SET COPIES=...
>>
>>     is added.
>
>     Have you tried adding something along this lines:
>
>     *OpenUI *Copies/Number of Copies: PickOne
>     *OrderDependency: 100 AnySetup *Copies
>     *DefaultCopies: 1
>     *Copies 1/1: "@PJL SET COPIES=1"
>     *Copies 2/2: "@PJL SET COPIES=2"
>     *Copies 3/3: "@PJL SET COPIES=3"
>     *Copies 4/4: "@PJL SET COPIES=4"
>     ...
>     *CloseUI: *Copies
>
>     similar to how Foomatic-based work?
>
>     A real PPD also has to take other settings into account here (e.g.
>     collate, staple, ...), if the printer-hardware does not support
>     all combinations /  has staple-limits / ...
>
>>     Currently all works fine for PPDs with "*cupsManualCopies: True" as
>>     pdftopdf generates software copies then. Without this entry pdftopdf
>>     sends only one copy of the PDF content and adds only a comment for
>>     subsequent filters. It does not add anything to generate the copies on a
>>     PDF printer.
>     The PPD author (printer manufacturer, ...) chooses to EITHER set
>     "*cupsManualCopes: True" OR add *Copies / *pdftopdfJCLCopies / ...
>     (i.e. whatever is required to generate correct JCL output for
>     their printer model).
>
>       Tobias
>
>
>
>
>
>
> -- 
> -Alex


[-- Attachment #2: Type: text/html, Size: 9556 bytes --]

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 6459 bytes --]

2014-10-08 16:53 GMT-04:00 Tobias Hoffmann <lprint-list@thax.hardliners.org>
:

>
>  What is this pdftopdfJCLCopies keyword, will it allow to inject PJL SET
> COPIES command into the job?
>
>     if ((attr = ppdFindAttr(ppd,"pdftopdfJCLCopies",buf)) != NULL) {
>       fputs(attr->value,fp);
>       datawritten = 1;
>     } else if (withJCL) {
>       fprintf(fp,"Copies=%d;",deviceCopies);
>       datawritten = 1;
>     }
>
> AFAIUI yes. It will write the value that corresponds to the
> *pdftopdfJCLCopies attribute which has the number of copies as specifier
> string, i.e. something along these lines:
>
> *pdftopdfJCLCopies 1: "@PJL SET COPIES=1"
> *pdftopdfJCLCopies 2: "@PJL SET COPIES=2"
> *pdftopdfJCLCopies 3: "@PJL SET COPIES=3"
>
>
Does it mean that I need to have 300 lines of this if a customer wants to
be able to print up to 300 copies? Is there a better way to specify a
keyword for arbitrary number of copies?

Also, it doesn't really work as expected. If I add these lines to the PPD,
"@PJL SET COPIES=3" is added after @PJL ENTER LANGUAGE = PDF statement and
becomes a part of PDF (and ignored). Why is it added there?

if it were a UI element, I'd add OrderDependency keyword, but it is not and
the keyword doesn't work.

 If pdftopdf is capable of inserting a comment about the number of copies
> requested, it should be able to insert this command as well, what do you
> think?
>
>
> It obviously is able. And *Copies seems to be usual way to handle
> Hardware-Copies for PS based printers. pdftopdf (and imagetopdf !) allows
> you to use this mechanism even for PDF based printers, too.
> I'm not sure about the "Number of Copies" dialog you were talking about
> ... I have not tried it myself ... but if you are correct, it will either
> also appear for PS based PPDs which allow hardware copies, or they are
> somehow able to reuse the existing GUI field for that (you might have to
> ask someone more familiar with PPDs about that) ... or your printing dialog
> fails to handle the *Copies attribute in a sensible way?
>
> Either way, pdftopdf has little to do with your issue.
>

I would disagree here. in a PDF to PS workflow hardware copies code is
added by the last filter, pstops. Now that pdftopdf is the only filter in
the chain, it needs to insert hardware copies code into the chain,
otherwise this whole idea of the pure PDF workflow is futile: everyone
would be forced to use cupsManualCopies and won't be able to use stapling
or punching correctly, for example.


> imagetopdf uses the same code. Foomatic and PS based PPDs work similarly.
> That's not to say that PPDs don't have shortcomings; in fact, CUPS has
> deprecated it's PPD API in favor of the Job Ticket API (JTAPI), which,
> AFAIUI, has IPP options (Mike also mentioned them) for hw copy generation.
>
>   Tobias
>
>
>
>  2014-10-08 10:40 GMT-04:00 Tobias Hoffmann <
> lprint-list@thax.hardliners.org>:
>
>>  On 08/10/14 11:57, Till Kamppeter wrote:
>>
>> On 10/07/2014 11:45 PM, Tobias Hoffmann wrote:
>>
>>  I'm not sure what exactly is happening in your setup.
>> Maybe your PPD is missing something (- and I'm not an expert for PPD/PJL)?
>> Maybe you don't have a recent cups-filters (>= 1.0.34)?
>> Maybe you're hitting some edge-cases that are not handled correctly in
>> the current code?
>>
>> AFAIK no-one else has reported a problem with PJL in a pure pdf
>> workflow, and I can't find an obvious flaw in the code which deals with
>> PJL in pdftopdf. The code is also basically copied over from the old
>> pdftopdf implementation (cups-filters <=1.0.20); if your PPD does hw
>> copy with the old implementation, but not with >=1.0.34, I will probably
>> be able to fix that.
>>
>>
>>  Tobias, do you know for what the call
>>
>> emitJCLOptions(stdout,ppd,param.deviceCopies);
>>
>> in the emitPreamble() function in pdftopdf_jcl.cc is good for? For me it
>> looks like that it serves for inserting JCL options, but inserting JCL
>> options is already done by
>>
>> ppdEmitJCL(ppd,stdout,param.jobId,param.user,param.title);
>>
>>
>>  The code basically comes from the old pdftopdf implementation by Koji
>> Otani. The same code is also present in imagetopdf.c .
>> There is also a section in cups-filter's README about that:
>>
>> if (Copies option is specified in the PPD file) {
>>     mark Number of copies specified
>> } else if (pdftopdfJCLCopies is specified in the PPD file) {
>>     output JCL specified with JCLCopies
>> }
>>
>> for (each marked options) {
>>     if (pdftopdfJCL<marked option's name> is specified in the PPD file) {
>>         output it's value as a JCL
>>     } else if (pdftopdfJCLBegin attributes is specified in the PPD file) {
>>         output "<option's name>=<marked choice>;" as a JCL
>>     }
>> }
>>
>>
>> AFAIUI Koji had to "invent" new pdftopdfJCL* keywords for the PJL + PDF
>> case;
>> and for some reason ppdEmitJCL could not be used for them, so he added
>> emitJCLOptions.
>>
>>
>>  I can even comment out
>>
>> emitJCLOptions(stdout,ppd,param.deviceCopies);
>>
>> and the output stays the same.
>>
>>
>>  Probably because the PPD neither contain *Copies nor *pdftopdfJCLCopies?
>>
>>  What I want to have is that if param.deviceCopies is not 1 (= multiple
>> hardware copies) that
>>
>> @PJL SET COPIES=...
>>
>> is added.
>>
>>
>>  Have you tried adding something along this lines:
>>
>> *OpenUI *Copies/Number of Copies: PickOne
>> *OrderDependency: 100 AnySetup *Copies
>> *DefaultCopies: 1
>> *Copies 1/1: "@PJL SET COPIES=1"
>> *Copies 2/2: "@PJL SET COPIES=2"
>> *Copies 3/3: "@PJL SET COPIES=3"
>> *Copies 4/4: "@PJL SET COPIES=4"
>> ...
>> *CloseUI: *Copies
>>
>> similar to how Foomatic-based work?
>>
>> A real PPD also has to take other settings into account here (e.g.
>> collate, staple, ...), if the printer-hardware does not support all
>> combinations /  has staple-limits / ...
>>
>>  Currently all works fine for PPDs with "*cupsManualCopies: True" as
>> pdftopdf generates software copies then. Without this entry pdftopdf
>> sends only one copy of the PDF content and adds only a comment for
>> subsequent filters. It does not add anything to generate the copies on a
>> PDF printer.
>>
>>  The PPD author (printer manufacturer, ...) chooses to EITHER set
>> "*cupsManualCopes: True" OR add *Copies / *pdftopdfJCLCopies / ... (i.e.
>> whatever is required to generate correct JCL output for their printer
>> model).
>>
>>   Tobias
>>
>>
>>
>>
>
>
>  --
> -Alex
>
>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 10836 bytes --]

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

[Tobias Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 4522 bytes --]

On 10/10/14 20:38, Alex Korobkin wrote:
>
>     *pdftopdfJCLCopies 1: "@PJL SET COPIES=1"
>     *pdftopdfJCLCopies 2: "@PJL SET COPIES=2"
>     *pdftopdfJCLCopies 3: "@PJL SET COPIES=3"
>
>
> Does it mean that I need to have 300 lines of this if a customer wants 
> to be able to print up to 300 copies? Is there a better way to specify 
> a keyword for arbitrary number of copies?

I don't know. How do PPDs for real PostScript printers (i.e. not 
Foomatic) with hardware copying look like?

> Also, it doesn't really work as expected. If I add these lines to the 
> PPD, "@PJL SET COPIES=3" is added after @PJL ENTER LANGUAGE = PDF 
> statement and becomes a part of PDF (and ignored). Why is it added there?

Ok, I see. This truly doesn't seem to make much sense, even with my 
limited understanding of PJL...
I'm not sure why Koji Otani wrote it like that, or whether this order 
was purposely chosen.
Are there PPDs which depend on this (strange) ordering?

> if it were a UI element, I'd add OrderDependency keyword, but it is 
> not and the keyword doesn't work.
>
>>     If pdftopdf is capable of inserting a comment about the number of
>>     copies requested, it should be able to insert this command as
>>     well, what do you think?
>
>     It obviously is able. And *Copies seems to be usual way to handle
>     Hardware-Copies for PS based printers. pdftopdf (and imagetopdf !)
>     allows you to use this mechanism even for PDF based printers, too.
>     I'm not sure about the "Number of Copies" dialog you were talking
>     about ... I have not tried it myself ... but if you are correct,
>     it will either also appear for PS based PPDs which allow hardware
>     copies, or they are somehow able to reuse the existing GUI field
>     for that (you might have to ask someone more familiar with PPDs
>     about that) ... or your printing dialog fails to handle the
>     *Copies attribute in a sensible way?
>
>     Either way, pdftopdf has little to do with your issue.
>
>
> I would disagree here. in a PDF to PS workflow hardware copies code is 
> added by the last filter, pstops.

Yes, that's what I would expect.
I took a look into what pstops.c does beside of generic PPD handling, 
and I found this:

>    /*
>     * Tell the document processor the copy and duplex options
>     * that are required...
>     */
>
>     doc_printf(doc, "%%%%Requirements: numcopies(%d)%s%s\n", doc->copies,
>                doc->collate ? " collate" : "",
>                Duplex ? " duplex" : "");
>
>    /*
>     * Apple uses RBI comments for various non-PPD options...
>     */
>
>     doc_printf(doc, "%%RBINumCopies: %d\n", doc->copies);
>   }
and
>     doc_printf(doc, "%%RBIBeginNonPPDFeature: *NumCopies %d\n", 
> doc->copies);
>     doc_printf(doc,
>                "%d/languagelevel where{pop languagelevel 2 
> ge}{false}ifelse\n"
>                "{1 dict begin/NumCopies exch def currentdict end "
>                "setpagedevice}\n"
>                "{userdict/#copies 3 -1 roll put}ifelse\n", doc->copies);
>     doc_puts(doc, "%RBIEndNonPPDFeature\n");

But foomatic based filters use *Copies in their PPD instead.... with the 
rather dumb "let's repeat the line for 1...100 copies". I've seen a 
similar approach in one other PPD (for a real postscript printer, IIRC) 
on the web; the only difference was, that it used *JCLOpenUI instead of 
*OpenUI, etc.

You wrote in one of your earlier mails:
> Making a "Number of Copies" dialog doesn't seem to be a great idea, 
> because users will never notice that. They will keep setting the 
> number of copies in the usual place in GUI.

Are you basically saying that Foomatic-PPDs "breaks" the GUI in the same 
way as using *Copies for pdftopdf?
Does using *Copies with pdftopdf actually work -- or isn't it actually 
suffering from the same ordering problem you described for 
*pdftopdfJCLCopies?

> Now that pdftopdf is the only filter in the chain, it needs to insert 
> hardware copies code into the chain, otherwise this whole idea of the 
> pure PDF workflow is futile: everyone would be forced to use 
> cupsManualCopies and won't be able to use stapling or punching 
> correctly, for example.

I do agree that pdftopdf has to add the hardware copies code.
And, as you have see, Koji Otani has implement PPD-based JCL-insertion 
in pdftopdf and imagetopdf.
But now you are suggesting that this implementation is basically 
broken-by-design (?).
What is your proposed change wrt. to the already existing 
implementation/design?

   Tobias


[-- Attachment #2: Type: text/html, Size: 7958 bytes --]

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

[Till Kamppeter]

On 10/10/2014 10:06 PM, Tobias Hoffmann wrote:
> On 10/10/14 20:38, Alex Korobkin wrote:
>>
>>     *pdftopdfJCLCopies 1: "@PJL SET COPIES=1"
>>     *pdftopdfJCLCopies 2: "@PJL SET COPIES=2"
>>     *pdftopdfJCLCopies 3: "@PJL SET COPIES=3"
>>
>>
>> Does it mean that I need to have 300 lines of this if a customer wants
>> to be able to print up to 300 copies? Is there a better way to specify
>> a keyword for arbitrary number of copies?
> 
> I don't know. How do PPDs for real PostScript printers (i.e. not
> Foomatic) with hardware copying look like?
> 

Problem of Adobe's PPD format is that it only supports enumerated choice
options and boolean options, no numerical options. Foomatic and CUPS
have PPD extensions for numerical options, but for backward
compatibility with non-CUPS/Foomatic clients there is always a number of
explicitly enumerated choices in a numerical option in the PPD, in case
of "Copies" a list for each possible number of copies, usually from 1 to
99. 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,
one could leave out the explicitly listed choices, or simply raise the
maximum without adding the appropriate choices. One could also think
that if someone wants to print more than 100 copies that it is good
enough to only be able to choose multiples of 10 (like 240 copies, not
243 copies) if the print dialog cannot cope with the PPD extensions and
needs the fallback choices.

>> Also, it doesn't really work as expected. If I add these lines to the
>> PPD, "@PJL SET COPIES=3" is added after @PJL ENTER LANGUAGE = PDF
>> statement and becomes a part of PDF (and ignored). Why is it added there?
> 
> Ok, I see. This truly doesn't seem to make much sense, even with my
> limited understanding of PJL...
> I'm not sure why Koji Otani wrote it like that, or whether this order
> was purposely chosen.
> Are there PPDs which depend on this (strange) ordering?
>

No, this ordering is wrong, the @PJL ENTER LANGUAGE = PDF should always
come last. If this is not the case, the filter has a bug, probably
already introduced by Koji Otani (CCing him).

>> if it were a UI element, I'd add OrderDependency keyword, but it is
>> not and the keyword doesn't work. 
>>
>>>     If pdftopdf is capable of inserting a comment about the number of
>>>     copies requested, it should be able to insert this command as
>>>     well, what do you think?
>>
>>     It obviously is able. And *Copies seems to be usual way to handle
>>     Hardware-Copies for PS based printers. pdftopdf (and imagetopdf !)
>>     allows you to use this mechanism even for PDF based printers, too.
>>     I'm not sure about the "Number of Copies" dialog you were talking
>>     about ... I have not tried it myself ... but if you are correct,
>>     it will either also appear for PS based PPDs which allow hardware
>>     copies, or they are somehow able to reuse the existing GUI field
>>     for that (you might have to ask someone more familiar with PPDs
>>     about that) ... or your printing dialog fails to handle the
>>     *Copies attribute in a sensible way?
>>
>>     Either way, pdftopdf has little to do with your issue.
>>
>>
>> I would disagree here. in a PDF to PS workflow hardware copies code is
>> added by the last filter, pstops.
> 
> Yes, that's what I would expect.
> I took a look into what pstops.c does beside of generic PPD handling,
> and I found this:
> 
>>    /*
>>     * Tell the document processor the copy and duplex options
>>     * that are required...
>>     */
>>
>>     doc_printf(doc, "%%%%Requirements: numcopies(%d)%s%s\n", doc->copies,
>>                doc->collate ? " collate" : "",
>>                Duplex ? " duplex" : "");
>>
>>    /*
>>     * Apple uses RBI comments for various non-PPD options...
>>     */
>>
>>     doc_printf(doc, "%%RBINumCopies: %d\n", doc->copies);
>>   }
> and
>>     doc_printf(doc, "%%RBIBeginNonPPDFeature: *NumCopies %d\n",
>> doc->copies);
>>     doc_printf(doc,
>>                "%d/languagelevel where{pop languagelevel 2
>> ge}{false}ifelse\n"
>>                "{1 dict begin/NumCopies exch def currentdict end "
>>                "setpagedevice}\n"
>>                "{userdict/#copies 3 -1 roll put}ifelse\n", doc->copies);
>>     doc_puts(doc, "%RBIEndNonPPDFeature\n");
> 
> But foomatic based filters use *Copies in their PPD instead.... with the
> rather dumb "let's repeat the line for 1...100 copies".

See my remarks about this above.

> I've seen a
> similar approach in one other PPD (for a real postscript printer, IIRC)
> on the web; the only difference was, that it used *JCLOpenUI instead of
> *OpenUI, etc.
>

AFAIK *JCLOpenUI only tells that the code to insert is PJL and not
PostScript, otherwise it behaves as a normal *OpenUI optionm: Widget for
it in the print dialog, default value, user's choice, ...

> You wrote in one of your earlier mails:
>> Making a "Number of Copies" dialog doesn't seem to be a great idea,
>> because users will never notice that. They will keep setting the
>> number of copies in the usual place in GUI.
> 
> Are you basically saying that Foomatic-PPDs "breaks" the GUI in the same
> way as using *Copies for pdftopdf?
> Does using *Copies with pdftopdf actually work -- or isn't it actually
> suffering from the same ordering problem you described for
> *pdftopdfJCLCopies?
> 

We should tell print dialog designers that if the PPD has an option
named "Copies" to not show it but to send the selection of the normal
copiews facility of the dialog as the choice for this option.

>> Now that pdftopdf is the only filter in the chain, it needs to insert
>> hardware copies code into the chain, otherwise this whole idea of the
>> pure PDF workflow is futile: everyone would be forced to use
>> cupsManualCopies and won't be able to use stapling or punching
>> correctly, for example.
> 
> I do agree that pdftopdf has to add the hardware copies code.
> And, as you have see, Koji Otani has implement PPD-based JCL-insertion
> in pdftopdf and imagetopdf.
> But now you are suggesting that this implementation is basically
> broken-by-design (?).
> What is your proposed change wrt. to the already existing
> implementation/design?
> 
>   Tobias
> 


   Till

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

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.

We should tell print dialog designers that if the PPD has an option
> named "Copies" to not show it but to send the selection of the normal
> copiews facility of the dialog as the choice for this option.



-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 1521 bytes --]

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

[Tobias Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]

On 14/10/14 21:17, Alex Korobkin wrote:
> Till,
>
> 2014-10-10 16:58 GMT-04:00 Till Kamppeter <till.kamppeter@gmail.com 
> <mailto: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

[-- Attachment #2: Type: text/html, Size: 3183 bytes --]

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

[Tobias Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 2342 bytes --]

On 14/10/14 23:09, Tobias Hoffmann wrote:
> On 14/10/14 21:17, Alex Korobkin wrote:
>> 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.
>

Hmm, the biggest problem seems to be that everything from ppd->jcl_begin 
(i.e. for PCL: "\033%-12345X@") until ppd->jcl_ps (set to 
*JCLToPDFInterpreter in pdftopdf, i.e."ENTER LANGUAGE") is written by 
cups's ppdEmitJCL() function.
As far as I understand it, this are the options:

a) stick to what cups provides in terms of PPD settings (and probably 
move the Copies replacement code before ppdEmitJCL),

b) patch cups, namely ppdEmitJCL() in emit.c.
   As cups does detect PCL as JCL here and sets "JOB NAME", "DISPLAY" or 
"RDYMSG DISPLAY" that would be the best place to add PJL SET COPIES.
   But this will affect all PPDs with JCL, e.g. when pure PostScript is 
used... and, in case the patch is not accepted upstream, cups-filters 
has to ship it(?)

c) do not use ppdEmitJCL at all. We would loose e.g. JOB NAME, but have 
better control over the output...
   If you don't set *JCLToPDFInterpreter, and use *pdftopdfJCLBegin, 
together with more pdftopdfJCL* keywords, this could work. The current 
emitJCLOptions implementation does not insert newlines, though. I'm not 
sure if the PPD value could instead contain it, instead...
   I think Koji Otani only used the pdftopdfJCL* insertion to pass stuff 
to pdftoopvp, in a format that only used one line, separated by ";".
   One of his examples is:
>   *OpenUI *PageSize/Page Size: PickOne
>   *DefaultPageSize: A4
>   *PageSize A4/A4:
>   *pdftopdfJCLPageSize A4/A4: "PS=A4;"
>   *PageSize Letter/US Letter:
>   *pdftopdfJCLPageSize Letter/US Letter: "PS=LT;"
>   *CloseUI: *PageSize
   I do not understand his original design fully, yet.

d) We can try a hacky workaround: In pdftopdf_jcl.c, emitPreamble(), set 
ppd->jcl_ps to an empty string. Then ppdEmitJCL will not skip JCL 
processing all together, but it also will not write ENTER LANGUAGE at 
the end. But it will result in an empty line. Would that be a problem in 
PCL? After that we can write SET COPIES and ENTER LANGUAGE ourselves.
Or something like ppd->jcl_ps=concat("...SET COPIES...\n", 
JCLToPDFInterpreter->value) ?

And yes, Till basically has to decide how to proceed.

   Tobias

[-- Attachment #2: Type: text/html, Size: 3367 bytes --]

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

[Till Kamppeter]

On 10/15/2014 12:50 PM, Tobias Hoffmann wrote:
> On 14/10/14 23:09, Tobias Hoffmann wrote:
>> On 14/10/14 21:17, Alex Korobkin wrote:
>>> 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.
>>
> 
> Hmm, the biggest problem seems to be that everything from ppd->jcl_begin
> (i.e. for PCL: "\033%-12345X@") until ppd->jcl_ps (set to
> *JCLToPDFInterpreter in pdftopdf, i.e."ENTER LANGUAGE") is written by
> cups's ppdEmitJCL() function.
> As far as I understand it, this are the options:
> 
> a) stick to what cups provides in terms of PPD settings (and probably
> move the Copies replacement code before ppdEmitJCL),
> 
> b) patch cups, namely ppdEmitJCL() in emit.c.
>   As cups does detect PCL as JCL here and sets "JOB NAME", "DISPLAY" or
> "RDYMSG DISPLAY" that would be the best place to add PJL SET COPIES.
>   But this will affect all PPDs with JCL, e.g. when pure PostScript is
> used... and, in case the patch is not accepted upstream, cups-filters
> has to ship it(?)
> 

I will not ship patches for CUPS in the cups-filters upstream package.
You could post an upstream bug report/feature request on CUPS
(http://www.cups.org/str.php) to let the ppdEmitJCL() function add "PJL
SET COPIES=X" with the number of copies taken from the command line
arguments (4th argument, see "man filter"). We must look into whether we
should generally add "PJL SET COPIES=X", or only under certain
conditions (is another copy generation method supposed to be used?
Should we have some PPD keyword to turn it on or off?).

> c) do not use ppdEmitJCL at all. We would loose e.g. JOB NAME, but have
> better control over the output...

Do you mean using the not very elegant method to copy the code of the
function into cups-filters and modify it there?


> If you don't set *JCLToPDFInterpreter, and use *pdftopdfJCLBegin,
> together with more pdftopdfJCL* keywords, this could work. The current
> emitJCLOptions implementation does not insert newlines, though. I'm not
> sure if the PPD value could instead contain it, instead...

One could add "<0A>" to the ends of the PJL code lines in the PPD file.
This way one could go with only *pdftopdfJCL... keywords in the PPD and
so make CUPS' ppdEmitJCL() do nothing, letting pdftopdf gain full
control. We should try this.

>   I think Koji Otani only used the pdftopdfJCL* insertion to pass stuff
> to pdftoopvp, in a format that only used one line, separated by ";".
>   One of his examples is:
>>   *OpenUI *PageSize/Page Size: PickOne
>>   *DefaultPageSize: A4
>>   *PageSize A4/A4:
>>   *pdftopdfJCLPageSize A4/A4: "PS=A4;"
>>   *PageSize Letter/US Letter:
>>   *pdftopdfJCLPageSize Letter/US Letter: "PS=LT;"
>>   *CloseUI: *PageSize
>   I do not understand his original design fully, yet.
> 

This is a simple way to pass PPD option settings to the next filter (in
this case pdftoopvp), so that the filter does not need to read the PPD
and merge the command line option settings again. Also the next filter
gets note when tasks like copy generation are delegated to it.

> d) We can try a hacky workaround: In pdftopdf_jcl.c, emitPreamble(), set
> ppd->jcl_ps to an empty string. Then ppdEmitJCL will not skip JCL
> processing all together, but it also will not write ENTER LANGUAGE at
> the end. But it will result in an empty line. Would that be a problem in
> PCL? After that we can write SET COPIES and ENTER LANGUAGE ourselves.
> Or something like ppd->jcl_ps=concat("...SET COPIES...\n",
> JCLToPDFInterpreter->value) ?
>  

I do not know whether an empty line between PJL lines in a job causes a
problem, like for example the PJL header being terminated and PCL (not
PJL) entered starting with printing this empty line and after that the
PostScript or PDF as text. So better try the ppd->jcl_ps=concat("...SET
COPIES...\n", JCLToPDFInterpreter->value) approach.

> And yes, Till basically has to decide how to proceed.

So please try the two possibilities of

1. using *pdftopdfJCL... instead of *JCL... in the PPD, with "<0a>" in
the code snippets where line ends are supposed to be.

2. setting ppd->jcl_ps=concat("...SET COPIES...\n",
JCLToPDFInterpreter->value)

The first one can simply tried by editing the PPD file, the second needs
a (simple) code change in pdftopdf. CUPS does not need to get modified
for these tests.

Also make the above-mentioned feature request for CUPS to discuss the
SET COPIES in the ppdEmitJCL() of CUPS.

   Till

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

[Till Kamppeter]

On 10/15/2014 03:12 PM, Till Kamppeter wrote:
> 1. using *pdftopdfJCL... instead of *JCL... in the PPD, with "<0a>" in
> the code snippets where line ends are supposed to be.
> 

This will not work with unmodified pdftopdf, first, newlines are
filtered out of the *pdftopdfJCLBegin, and second, there is no
*pdftopdfJCLtoPDFInterpreter read by pdftopdf. Also if there is any
option without *pdftopdfJCL... entries for each of its choices,
"option=choice;" is inserted for that option. So it seems that this
facility is really only to pass info to the next filter.

   Till

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

[Till Kamppeter]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

On 10/15/2014 03:12 PM, Till Kamppeter wrote:
> 2. setting ppd->jcl_ps=concat("...SET COPIES...\n",
> JCLToPDFInterpreter->value)
> 

I tried this route and got it to actually work with the attached patch.
I have also taken into account to not duplicate "SET COPIES=..." if the
PPD has a "Copies" option (but a ΅Copies" option is not recommended in
the PPD as it is confusing and now not needed any more). The patch is
rather simple.

Please try it out and see whether it works on your printer. If your PPD
has a "Copies" option, try removing it.

And anyone reading this, please tell whether the patch is OK or can
cause problems in certain situations.

   Till


[-- Attachment #2: pdftopdf-pjl-copies.patch --]
[-- Type: text/x-patch, Size: 924 bytes --]

=== modified file 'filter/pdftopdf/pdftopdf_jcl.cc'
--- filter/pdftopdf/pdftopdf_jcl.cc	2012-10-18 17:03:24 +0000
+++ filter/pdftopdf/pdftopdf_jcl.cc	2014-10-15 15:58:54 +0000
@@ -135,8 +135,20 @@
        ppdEmitJCL() actually adds JCL based on the presence on 
        "*JCLToPDFInterpreter:". */
     ppd_attr_t *attr;
+    char buf[1024];
+    snprintf(buf,sizeof(buf),"%d",param.deviceCopies);
     if ( (attr=ppdFindAttr(ppd,"JCLToPDFInterpreter",NULL)) != NULL) {
-      ppd->jcl_ps=strdup(attr->value);
+      if (param.deviceCopies > 1) {
+	if (ppdFindOption(ppd,"Copies") != NULL) {
+	  ppdMarkOption(ppd,"Copies",buf);
+	  ppd->jcl_ps=strdup(attr->value);
+	} else {
+	  snprintf(buf, sizeof(buf), "@PJL SET COPIES=%d<0A>%s",
+		   param.deviceCopies, attr->value);
+	  ppd->jcl_ps = buf;
+	}
+      } else
+	ppd->jcl_ps=strdup(attr->value);
       ppd_decode(ppd->jcl_ps);
     } else {
       ppd->jcl_ps=NULL;

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

[Tobias Hoffmann]

On 15/10/14 18:17, Till Kamppeter wrote:
> And anyone reading this, please tell whether the patch is OK or can 
> cause problems in certain situations.

One more thing I forgot:
In case imagetopdf is called as the last filter, and pdftopdf is not 
used, it will have to be patched, too.
(imagetops containes explicit code for hardware copies in PS, because it 
could be the last filter -- not sure if that's still the case for PDF).

And a minor correction to my earlier mail:
> 2) will only insert @PCL SET COPIES, when jcl_begin uses the known PJL 
> begin sequence (copied from what pstops does wrt. to PCL). 
To be more precise: Copied from cups/emit.c (which is what pstops uses).

   Tobias

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

[Till Kamppeter]

[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

Thanks, Tobias, I have now merged the functionality of our patches and
pushed it into the BZR (rev. 7299). It is basically your patch with
support for the "Copies" option added.

   Till

On 10/15/2014 09:28 PM, Tobias Hoffmann wrote:
> On 15/10/14 18:17, Till Kamppeter wrote:
>> And anyone reading this, please tell whether the patch is OK or can
>> cause problems in certain situations.
> 
> One more thing I forgot:
> In case imagetopdf is called as the last filter, and pdftopdf is not
> used, it will have to be patched, too.
> (imagetops containes explicit code for hardware copies in PS, because it
> could be the last filter -- not sure if that's still the case for PDF).
> 
> And a minor correction to my earlier mail:
>> 2) will only insert @PCL SET COPIES, when jcl_begin uses the known PJL
>> begin sequence (copied from what pstops does wrt. to PCL). 
> To be more precise: Copied from cups/emit.c (which is what pstops uses).
> 
>   Tobias
> 
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture


[-- Attachment #2: pdftopdf-pjl-copies-2.patch --]
[-- Type: text/x-patch, Size: 1637 bytes --]

=== modified file 'filter/pdftopdf/pdftopdf_jcl.cc'
--- filter/pdftopdf/pdftopdf_jcl.cc	2012-10-18 17:03:24 +0000
+++ filter/pdftopdf/pdftopdf_jcl.cc	2014-10-16 15:37:37 +0000
@@ -135,14 +135,35 @@
        ppdEmitJCL() actually adds JCL based on the presence on 
        "*JCLToPDFInterpreter:". */
     ppd_attr_t *attr;
+    char buf[1024];
+    int devicecopies_done = 0;
+    char *old_jcl_ps = ppd->jcl_ps;
+    /* If there is a "Copies" option in the PPD file, assure that hardware
+       copies are implemented as described by this option */
+    if (ppdFindOption(ppd,"Copies") != NULL &&
+	param.deviceCopies > 1) {
+      snprintf(buf,sizeof(buf),"%d",param.deviceCopies);
+      ppdMarkOption(ppd,"Copies",buf);
+      devicecopies_done = 1;
+    }
     if ( (attr=ppdFindAttr(ppd,"JCLToPDFInterpreter",NULL)) != NULL) {
-      ppd->jcl_ps=strdup(attr->value);
+      if (param.deviceCopies > 1 && devicecopies_done == 0 && // HW copies
+	  strncmp(ppd->jcl_begin, "\033%-12345X@", 10) == 0) { // PJL
+	/* Add a PJL command to implement the hardware copies */
+        const size_t size=strlen(attr->value)+1+30;
+        ppd->jcl_ps=(char *)malloc(size*sizeof(char));
+        snprintf(ppd->jcl_ps, size, "@PJL SET COPIES=%d\n%s",
+		 param.deviceCopies, attr->value);
+      } else
+	ppd->jcl_ps=strdup(attr->value);
       ppd_decode(ppd->jcl_ps);
     } else {
       ppd->jcl_ps=NULL;
     }
     ppdEmitJCL(ppd,stdout,param.jobId,param.user,param.title);
     emitJCLOptions(stdout,ppd,param.deviceCopies);
+    free(ppd->jcl_ps);
+    ppd->jcl_ps = old_jcl_ps; // cups uses pool allocator, not free()
   }
 }
 // }}}

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]

Tobias,

Thanks for your attention to details. I was testing your patch this morning
and found out one additional thing.
If multiple pages are printed, they will come out non-collated. However,
when collate is on, just one copy is printed.

Turns out, there should be one additional line for collate to work with
multiple copies and multiple pages:
PJL SET QTY=X

Could you please modify your patch to generate two lines at once: PJL SET
COPIES=X and PJL SET QTY=X?

2014-10-15 15:28 GMT-04:00 Tobias Hoffmann <lprint-list@thax.hardliners.org>
:

> On 15/10/14 18:17, Till Kamppeter wrote:
>
>> And anyone reading this, please tell whether the patch is OK or can cause
>> problems in certain situations.
>>
>
> One more thing I forgot:
> In case imagetopdf is called as the last filter, and pdftopdf is not used,
> it will have to be patched, too.
> (imagetops containes explicit code for hardware copies in PS, because it
> could be the last filter -- not sure if that's still the case for PDF).
>
> And a minor correction to my earlier mail:
>
>> 2) will only insert @PCL SET COPIES, when jcl_begin uses the known PJL
>> begin sequence (copied from what pstops does wrt. to PCL).
>>
> To be more precise: Copied from cups/emit.c (which is what pstops uses).
>
>   Tobias
>
>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 2116 bytes --]

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

[Tobias Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

On 16/10/14 18:52, Alex Korobkin wrote:
> Turns out, there should be one additional line for collate to work 
> with multiple copies and multiple pages:
> PJL SET QTY=X
>
> Could you please modify your patch to generate two lines at once: PJL 
> SET COPIES=X and PJL SET QTY=X?
The attached patch does that. It's based on BZR rev. 7299, which already 
includes the SET COPIES modifications (Till also posted the 
corresponding .patch, earlier).

I did some research, though... and it seem that (only) "SET COPIES" 
should be used for non-collated and only(!) "SET QTY" should be used for 
collated duplicates.
Please do try whether just SET QTY is enough:
           if (param.deviceCollate) {
             snprintf(ppd->jcl_ps, size, "@PJL SET QTY=%d\n%s",
                    param.deviceCopies, attr->value);
          } else {
          [...]

   Tobias




[-- Attachment #2: pjlcollate-v1.patch --]
[-- Type: text/x-patch, Size: 1030 bytes --]

--- filter/pdftopdf/pdftopdf_jcl.cc	2014-10-16 15:48:05 +0000
+++ filter/pdftopdf/pdftopdf_jcl.cc	2014-10-16 20:45:01 +0000
@@ -150,10 +150,15 @@
       if (param.deviceCopies > 1 && devicecopies_done == 0 && // HW copies
 	  strncmp(ppd->jcl_begin, "\033%-12345X@", 10) == 0) { // PJL
 	/* Add a PJL command to implement the hardware copies */
-        const size_t size=strlen(attr->value)+1+30;
+        const size_t size=strlen(attr->value)+1+60;
         ppd->jcl_ps=(char *)malloc(size*sizeof(char));
-        snprintf(ppd->jcl_ps, size, "@PJL SET COPIES=%d\n%s",
-		 param.deviceCopies, attr->value);
+        if (param.deviceCollate) {
+          snprintf(ppd->jcl_ps, size, "@PJL SET COPIES=%d\n@PJL SET QTY=%d\n%s",
+                   param.deviceCopies, param.deviceCopies, attr->value);
+        } else {
+          snprintf(ppd->jcl_ps, size, "@PJL SET COPIES=%d\n%s",
+                   param.deviceCopies, attr->value);
+        }
       } else
 	ppd->jcl_ps=strdup(attr->value);
       ppd_decode(ppd->jcl_ps);

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]

Works beautifully, thank you. And thanks for digging up the exact rules of
QTY and COPIES application.


2014-10-16 16:59 GMT-04:00 Tobias Hoffmann <lprint-list@thax.hardliners.org>
:

> On 16/10/14 18:52, Alex Korobkin wrote:
>
>> Turns out, there should be one additional line for collate to work with
>> multiple copies and multiple pages:
>> PJL SET QTY=X
>>
>> Could you please modify your patch to generate two lines at once: PJL SET
>> COPIES=X and PJL SET QTY=X?
>>
> The attached patch does that. It's based on BZR rev. 7299, which already
> includes the SET COPIES modifications (Till also posted the corresponding
> .patch, earlier).
>
> I did some research, though... and it seem that (only) "SET COPIES" should
> be used for non-collated and only(!) "SET QTY" should be used for collated
> duplicates.
> Please do try whether just SET QTY is enough:
>           if (param.deviceCollate) {
>             snprintf(ppd->jcl_ps, size, "@PJL SET QTY=%d\n%s",
>                    param.deviceCopies, attr->value);
>          } else {
>          [...]
>
>   Tobias
>
>
>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 1775 bytes --]

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

[Till Kamppeter]

[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]

Thank you very much.

Pushed the attached additional patch to the BZR repo (rev. 7300).

   Till

On 10/17/2014 06:22 PM, Alex Korobkin wrote:
> Works beautifully, thank you. And thanks for digging up the exact rules
> of QTY and COPIES application. 
> 
> 
> 2014-10-16 16:59 GMT-04:00 Tobias Hoffmann
> <lprint-list@thax.hardliners.org <mailto:lprint-list@thax.hardliners.org>>:
> 
>     On 16/10/14 18:52, Alex Korobkin wrote:
> 
>         Turns out, there should be one additional line for collate to
>         work with multiple copies and multiple pages:
>         PJL SET QTY=X
> 
>         Could you please modify your patch to generate two lines at
>         once: PJL SET COPIES=X and PJL SET QTY=X?
> 
>     The attached patch does that. It's based on BZR rev. 7299, which
>     already includes the SET COPIES modifications (Till also posted the
>     corresponding .patch, earlier).
> 
>     I did some research, though... and it seem that (only) "SET COPIES"
>     should be used for non-collated and only(!) "SET QTY" should be used
>     for collated duplicates.
>     Please do try whether just SET QTY is enough:
>               if (param.deviceCollate) {
>                 snprintf(ppd->jcl_ps, size, "@PJL SET QTY=%d\n%s",
>                        param.deviceCopies, attr->value);
>              } else {
>              [...]
> 
>       Tobias
> 
> 
> 
> 
> 
> 
> -- 
> -Alex


[-- Attachment #2: pjlcollate-v2.patch --]
[-- Type: text/x-patch, Size: 848 bytes --]

=== modified file 'filter/pdftopdf/pdftopdf_jcl.cc'
--- filter/pdftopdf/pdftopdf_jcl.cc	2014-10-16 15:48:05 +0000
+++ filter/pdftopdf/pdftopdf_jcl.cc	2014-10-17 16:37:10 +0000
@@ -152,8 +152,13 @@
 	/* Add a PJL command to implement the hardware copies */
         const size_t size=strlen(attr->value)+1+30;
         ppd->jcl_ps=(char *)malloc(size*sizeof(char));
-        snprintf(ppd->jcl_ps, size, "@PJL SET COPIES=%d\n%s",
-		 param.deviceCopies, attr->value);
+        if (param.deviceCollate) {
+          snprintf(ppd->jcl_ps, size, "@PJL SET QTY=%d\n%s",
+                   param.deviceCopies, attr->value);
+        } else {
+          snprintf(ppd->jcl_ps, size, "@PJL SET COPIES=%d\n%s",
+                   param.deviceCopies, attr->value);
+        }
       } else
 	ppd->jcl_ps=strdup(attr->value);
       ppd_decode(ppd->jcl_ps);

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

Thanks Till.
Will the same patch be added to imagetopdf?

2014-10-17 12:40 GMT-04:00 Till Kamppeter <till.kamppeter@gmail.com>:

> Thank you very much.
>
> Pushed the attached additional patch to the BZR repo (rev. 7300).
>
>    Till
>
> On 10/17/2014 06:22 PM, Alex Korobkin wrote:
> > Works beautifully, thank you. And thanks for digging up the exact rules
> > of QTY and COPIES application.
> >
> >
> > 2014-10-16 16:59 GMT-04:00 Tobias Hoffmann
> > <lprint-list@thax.hardliners.org <mailto:lprint-list@thax.hardliners.org
> >>:
> >
> >     On 16/10/14 18:52, Alex Korobkin wrote:
> >
> >         Turns out, there should be one additional line for collate to
> >         work with multiple copies and multiple pages:
> >         PJL SET QTY=X
> >
> >         Could you please modify your patch to generate two lines at
> >         once: PJL SET COPIES=X and PJL SET QTY=X?
> >
> >     The attached patch does that. It's based on BZR rev. 7299, which
> >     already includes the SET COPIES modifications (Till also posted the
> >     corresponding .patch, earlier).
> >
> >     I did some research, though... and it seem that (only) "SET COPIES"
> >     should be used for non-collated and only(!) "SET QTY" should be used
> >     for collated duplicates.
> >     Please do try whether just SET QTY is enough:
> >               if (param.deviceCollate) {
> >                 snprintf(ppd->jcl_ps, size, "@PJL SET QTY=%d\n%s",
> >                        param.deviceCopies, attr->value);
> >              } else {
> >              [...]
> >
> >       Tobias
> >
> >
> >
> >
> >
> >
> > --
> > -Alex
>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 2565 bytes --]

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

[Till Kamppeter]

On 10/20/2014 06:23 PM, Alex Korobkin wrote:
> Thanks Till. 
> Will the same patch be added to imagetopdf?
>

If this is all working for you now I will also add it to imagetopdf.

   Till

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 317 bytes --]

Yes, pdftopdf works nicely!

2014-10-20 12:29 GMT-04:00 Till Kamppeter <till.kamppeter@gmail.com>:

> On 10/20/2014 06:23 PM, Alex Korobkin wrote:
> > Thanks Till.
> > Will the same patch be added to imagetopdf?
> >
>
> If this is all working for you now I will also add it to imagetopdf.
>
>    Till
>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 788 bytes --]

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

[Till Kamppeter]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

imagetopdf pushed as rev. 7301 to the BZR (patch also attached). Please
test.

   Till

On 10/20/2014 07:28 PM, Alex Korobkin wrote:
> Yes, pdftopdf works nicely!
> 
> 2014-10-20 12:29 GMT-04:00 Till Kamppeter <till.kamppeter@gmail.com
> <mailto:till.kamppeter@gmail.com>>:
> 
>     On 10/20/2014 06:23 PM, Alex Korobkin wrote:
>     > Thanks Till.
>     > Will the same patch be added to imagetopdf?
>     >
> 
>     If this is all working for you now I will also add it to imagetopdf.
> 
>        Till
> 
> 
> 
> 
> -- 
> -Alex


[-- Attachment #2: imagetopdf-jcl-copies.patch --]
[-- Type: text/x-patch, Size: 1893 bytes --]

=== modified file 'filter/imagetopdf.c'
--- filter/imagetopdf.c	2012-04-04 17:49:42 +0000
+++ filter/imagetopdf.c	2014-10-20 20:26:28 +0000
@@ -1392,9 +1392,39 @@
        the content of ppd->jcl_ps by the value of this keyword, so that
        ppdEmitJCL() actalually adds JCL based on the presence on 
        "*JCLToPDFInterpreter:". */
+    ppd_attr_t *attr;
+    char buf[1024];
+    int devicecopies_done = 0;
+    char *old_jcl_ps = ppd->jcl_ps;
+    /* If there is a "Copies" option in the PPD file, assure that hardware
+       copies are implemented as described by this option */
+    if (ppdFindOption(ppd,"Copies") != NULL && deviceCopies > 1)
+    {
+      snprintf(buf,sizeof(buf),"%d",deviceCopies);
+      ppdMarkOption(ppd,"Copies",buf);
+      devicecopies_done = 1;
+    }
     if ((attr = ppdFindAttr(ppd,"JCLToPDFInterpreter",NULL)) != NULL)
     {
-      ppd->jcl_ps = strdup(attr->value);
+      if (deviceCopies > 1 && devicecopies_done == 0 && /* HW copies */
+	  strncmp(ppd->jcl_begin, "\033%-12345X@", 10) == 0) /* PJL */
+      {
+	/* Add a PJL command to implement the hardware copies */
+        const size_t size = strlen(attr->value) + 1 + 30;
+        ppd->jcl_ps = (char *)malloc(size * sizeof(char));
+        if (deviceCollate)
+	{
+          snprintf(ppd->jcl_ps, size, "@PJL SET QTY=%d\n%s",
+                   deviceCopies, attr->value);
+        }
+	else
+	{
+          snprintf(ppd->jcl_ps, size, "@PJL SET COPIES=%d\n%s",
+                   deviceCopies, attr->value);
+        }
+      } 
+      else
+	ppd->jcl_ps = strdup(attr->value);
       ppd_decode(ppd->jcl_ps);
       pdf_printer = 1;
     } 
@@ -1405,6 +1435,8 @@
     }
     ppdEmitJCL(ppd, stdout, atoi(argv[1]), argv[2], argv[3]);
     emitJCLOptions(stdout,deviceCopies);
+    free(ppd->jcl_ps);
+    ppd->jcl_ps = old_jcl_ps; /* cups uses pool allocator, not free() */
   }
 
  /*

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

Thank you Till, it seems to be working.

2014-10-20 16:30 GMT-04:00 Till Kamppeter <till.kamppeter@gmail.com>:

> imagetopdf pushed as rev. 7301 to the BZR (patch also attached). Please
> test.
>
>    Till
>
> On 10/20/2014 07:28 PM, Alex Korobkin wrote:
> > Yes, pdftopdf works nicely!
> >
> > 2014-10-20 12:29 GMT-04:00 Till Kamppeter <till.kamppeter@gmail.com
> > <mailto:till.kamppeter@gmail.com>>:
> >
> >     On 10/20/2014 06:23 PM, Alex Korobkin wrote:
> >     > Thanks Till.
> >     > Will the same patch be added to imagetopdf?
> >     >
> >
> >     If this is all working for you now I will also add it to imagetopdf.
> >
> >        Till
> >
> >
> >
> >
> > --
> > -Alex
>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 1392 bytes --]

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

[Tobias Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]

On 15/10/14 15:12, Till Kamppeter wrote:
> b) patch cups, namely ppdEmitJCL() in emit.c.
>    As cups does detect PCL as JCL here and sets "JOB NAME", "DISPLAY" or
> "RDYMSG DISPLAY" that would be the best place to add PJL SET COPIES.
>    But this will affect all PPDs with JCL, e.g. when pure PostScript is
> used... and, in case the patch is not accepted upstream, cups-filters
> has to ship it(?)
>
> I will not ship patches for CUPS in the cups-filters upstream package.
> You could post an upstream bug report/feature request on CUPS
> (http://www.cups.org/str.php) to let the ppdEmitJCL() function add "PJL
> SET COPIES=X" with the number of copies taken from the command line
> arguments (4th argument, see "man filter").

Patching upstream would unfortunately require changing the function 
signature of ppdEmitJCL() -- or adding a new ppdEmitJCL2 function. And 
that would be for a deprecated API...

> We must look into whether we
> should generally add "PJL SET COPIES=X", or only under certain
> conditions (is another copy generation method supposed to be used?
> Should we have some PPD keyword to turn it on or off?).

I don't know...?

>
>> c) do not use ppdEmitJCL at all. We would loose e.g. JOB NAME, but have
>> better control over the output...
> Do you mean using the not very elegant method to copy the code of the
> function into cups-filters and modify it there?

Simply put ... yes.


> 2. setting ppd->jcl_ps=concat("...SET COPIES...\n",
> JCLToPDFInterpreter->value)
Attached a (untested) first patch to pdftopdf:
param.deviceCopies will always be 1 for ppd->manual_copies, so SET 
COPIES is only inserted when *cupsManualCopies is not set and more than 
1 copy is requested.

Please review.

> Also make the above-mentioned feature request for CUPS to discuss the
> SET COPIES in the ppdEmitJCL() of CUPS.
>
See my comment above.

   Tobias


[-- Attachment #2: pjlcopies-v1.patch --]
[-- Type: text/x-patch, Size: 1450 bytes --]

--- filter/pdftopdf/pdftopdf_jcl.cc	2012-10-18 17:03:24 +0000
+++ filter/pdftopdf/pdftopdf_jcl.cc	2014-10-15 16:01:41 +0000
@@ -128,6 +128,8 @@
   ppdEmit(ppd,stdout,PPD_ORDER_EXIT);
 
   if (param.emitJCL) {
+     char *old_jcl_ps = ppd->jcl_ps;
+
     /* pdftopdf only adds JCL to the job if the printer is a native PDF
        printer and the PPD is for this mode, having the "*JCLToPDFInterpreter:"
        keyword. We need to read this keyword manually from the PPD and replace
@@ -136,13 +138,23 @@
        "*JCLToPDFInterpreter:". */
     ppd_attr_t *attr;
     if ( (attr=ppdFindAttr(ppd,"JCLToPDFInterpreter",NULL)) != NULL) {
-      ppd->jcl_ps=strdup(attr->value);
-      ppd_decode(ppd->jcl_ps);
+      if ( (param.deviceCopies>1)&&(strncmp(ppd->jcl_begin, "\033%-12345X@", 10)==0) ) { // PJL
+        const size_t size=strlen(attr->value)+1+30;
+        ppd->jcl_ps=(char *)malloc(size*sizeof(char));
+        snprintf(ppd->jcl_ps, size, "@PJL SET COPIES=%d\n%s",param.deviceCopies,attr->value);
+        ppd_decode(ppd->jcl_ps); // will not change SET COPIES
+      } else {
+        ppd->jcl_ps=strdup(attr->value);
+        ppd_decode(ppd->jcl_ps);
+      }
     } else {
       ppd->jcl_ps=NULL;
     }
     ppdEmitJCL(ppd,stdout,param.jobId,param.user,param.title);
     emitJCLOptions(stdout,ppd,param.deviceCopies);
+
+    free(ppd->jcl_ps);
+    ppd->jcl_ps = old_jcl_ps; // cups uses pool allocator, not free()
   }
 }
 // }}}

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 2253 bytes --]

Till, your patch works for me, at least for pure PDF workflow. I haven't
tested all cases yet, just a JCL-based PPD and a PDF printing.

Tobias, I haven't tested your patch. Is it different from Till's patch?

2014-10-15 12:22 GMT-04:00 Tobias Hoffmann <lprint-list@thax.hardliners.org>
:

> On 15/10/14 15:12, Till Kamppeter wrote:
>
>> b) patch cups, namely ppdEmitJCL() in emit.c.
>>    As cups does detect PCL as JCL here and sets "JOB NAME", "DISPLAY" or
>> "RDYMSG DISPLAY" that would be the best place to add PJL SET COPIES.
>>    But this will affect all PPDs with JCL, e.g. when pure PostScript is
>> used... and, in case the patch is not accepted upstream, cups-filters
>> has to ship it(?)
>>
>> I will not ship patches for CUPS in the cups-filters upstream package.
>> You could post an upstream bug report/feature request on CUPS
>> (http://www.cups.org/str.php) to let the ppdEmitJCL() function add "PJL
>> SET COPIES=X" with the number of copies taken from the command line
>> arguments (4th argument, see "man filter").
>>
>
> Patching upstream would unfortunately require changing the function
> signature of ppdEmitJCL() -- or adding a new ppdEmitJCL2 function. And that
> would be for a deprecated API...
>
>  We must look into whether we
>> should generally add "PJL SET COPIES=X", or only under certain
>> conditions (is another copy generation method supposed to be used?
>> Should we have some PPD keyword to turn it on or off?).
>>
>
> I don't know...?
>
>
>>  c) do not use ppdEmitJCL at all. We would loose e.g. JOB NAME, but have
>>> better control over the output...
>>>
>> Do you mean using the not very elegant method to copy the code of the
>> function into cups-filters and modify it there?
>>
>
> Simply put ... yes.
>
>
>  2. setting ppd->jcl_ps=concat("...SET COPIES...\n",
>> JCLToPDFInterpreter->value)
>>
> Attached a (untested) first patch to pdftopdf:
> param.deviceCopies will always be 1 for ppd->manual_copies, so SET COPIES
> is only inserted when *cupsManualCopies is not set and more than 1 copy is
> requested.
>
> Please review.
>
>  Also make the above-mentioned feature request for CUPS to discuss the
>> SET COPIES in the ppdEmitJCL() of CUPS.
>>
>>  See my comment above.
>
>   Tobias
>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 3772 bytes --]

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

[Tobias Hoffmann]

On 15/10/14 19:06, Alex Korobkin wrote:
> Till, your patch works for me, at least for pure PDF workflow. I 
> haven't tested all cases yet, just a JCL-based PPD and a PDF printing.
>
> Tobias, I haven't tested your patch. Is it different from Till's patch?
>

Till's patch only reached me after if sent mine, but, the basic idea is 
obviously the same.
My patch
1) also fixes an existing issue of memory ownership when ppd->jcl_ps is 
replaced
2) will only insert @PCL SET COPIES, when jcl_begin uses the known PJL 
begin sequence (copied from what pstops does wrt. to PCL).

3) but it does not handle *Copies specially. That did not seem that 
important to me; it probably makes some  sense for the 
"*JCLToPDFInterpreter exists, but it's not PCL" case.

IMO a final patch should include 1) and 2), and might also include 3).

   Tobias

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

[Tobias Hoffmann]

Some more comments ... below.

On 15/10/14 21:02, Tobias Hoffmann wrote:
> On 15/10/14 19:06, Alex Korobkin wrote:
>> Till, your patch works for me, at least for pure PDF workflow. I 
>> haven't tested all cases yet, just a JCL-based PPD and a PDF printing.
>>
>> Tobias, I haven't tested your patch. Is it different from Till's patch?
>>
>
> Till's patch only reached me after if sent mine, but, the basic idea 
> is obviously the same.
> My patch
> 1) also fixes an existing issue of memory ownership when ppd->jcl_ps 
> is replaced
> 2) will only insert @PCL SET COPIES, when jcl_begin uses the known PJL 
> begin sequence (copied from what pstops does wrt. to PCL).

That should be tested.

> 3) but it does not handle *Copies specially. That did not seem that 
> important to me; it probably makes some  sense for the 
> "*JCLToPDFInterpreter exists, but it's not PCL" case.

Specifically, what happens here is: The "Extended Settings" UI element's 
(generated for *Copies) value is replaced by the generic copies UI 
setting. I don't think it's that good of an idea, esp. as Foomatic-PPDs 
(which are about the only PPDs that use Copies) will not the PJL 
insertion feature from pdftopdf ... and thus will not have their UI 
value replaced. But IF printer dialogs handle *Copies specially, for 
Foomatic, then no code is needed in pdftopdf, as well...

   Tobias

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

[Michael Sweet]

Till,

> On Oct 7, 2014, at 4:03 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> How can I make pdftopdf add an IPP attribute to the job which generates
> the copies with the attribute being passed on to the printer by the IPP
> backend (when output format is set to PDF or PWG Raster by a cupsFilter2
> keyword in the PPD.

You don't have control over that; if the output format (FINAL_CONTENT_TYPE) is application/pdf, application/vnd.cups-pdf, or image/*, then the backend will generate suitable IPP Job Template attributes based on the PPD.

> And for PPD-less printing, how do I set the FINAL_CONTENT_TYPE there? Is
> it possible to do it out of a System V interface script?

Through the CUPS filter chain, you don't.  A queue using an interface script will NEVER send IPP Job Template attributes. (interface scripts are strictly for backwards compatibility and their days are numbered...)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair