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