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

[Tobias Hoffmann <lprint-list@thax.hardliners.org>]

[-- 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 --]