From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <5435A44F.7080504@thax.hardliners.org> Date: Wed, 08 Oct 2014 22:53:35 +0200 From: Tobias Hoffmann MIME-Version: 1.0 References: <5B66FA40-ED1E-461E-B00F-D5CD6C7DBC30@apple.com> <34701921-5F04-411C-B35C-78CED619AAC3@apple.com> <5432910A.4030500@gmail.com> <54344707.4080604@gmail.com> <54345EF9.5010405@thax.hardliners.org> <54350A8E.1010406@gmail.com> <54354CDA.50401@thax.hardliners.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090306050704040109090009" Subject: Re: [Printing-architecture] Number of copies in pure PDF workflow List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Korobkin Cc: "printing-architecture@lists.linux-foundation.org" , Till Kamppeter This is a multi-part message in MIME format. --------------090306050704040109090009 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > >: > > 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 is specified in the PPD >> file) { >> output it's value as a JCL >> } else if (pdftopdfJCLBegin attributes is specified in the >> PPD file) { >> output "=;" 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 --------------090306050704040109090009 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit 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>:
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

--------------090306050704040109090009--