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

Michael Sweet msweet at apple.com
Mon Oct 6 16:01:59 UTC 2014


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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at apple.com>:
> > > > Alex,
> > > >
> > > > > On Oct 3, 2014, at 3:28 PM, Alex Korobkin <korobkin+op at 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



More information about the Printing-architecture mailing list