* [Printing-architecture] Different Collate option handling in pdftopdf and pstops @ 2013-12-09 13:40 Andrey Makhalkin 2013-12-09 14:55 ` Michael Sweet 0 siblings, 1 reply; 5+ messages in thread From: Andrey Makhalkin @ 2013-12-09 13:40 UTC (permalink / raw) To: Open Printing Hi, Our testing group has found an issue with printing of multiple copies with collate option turned on. cups-filters version is 1.0.40-0ubuntu1 When PDF workflow is used, pdftopdf filter doesn't put collated copies of document pages in output pdf file. With the same PPD file and print options pstops filter produces N * (numpages) pages in output PS file, which seems to be a correct behavior. There is an attribute *cupsManualCopies in PPD file, which is set to False. There is no Collate option inside the PPD file. This printer doesn't seem to support hardware collate, but it supports hardware page copies. The expected filter behavior is to produce collated copies of the document. When we change its value to "True", pdftopdf filter produces the expected number of pages (does copies manually). Could you please explain, which filter behaves correctly? Is it a bug in pdftopdf filter? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Printing-architecture] Different Collate option handling in pdftopdf and pstops 2013-12-09 13:40 [Printing-architecture] Different Collate option handling in pdftopdf and pstops Andrey Makhalkin @ 2013-12-09 14:55 ` Michael Sweet 2013-12-09 15:09 ` Andrey Makhalkin 0 siblings, 1 reply; 5+ messages in thread From: Michael Sweet @ 2013-12-09 14:55 UTC (permalink / raw) To: Andrey Makhalkin; +Cc: printing-architecture@lists.linux-foundation.org Andrey, One could argue that pdftopdf should support the cupsManualCopies keyword and generate page references to effectively do multiple copies. However, given that PDF is NOT a streaming format (at least not for the printer, since it needs the entire document to print an arbitrary PDF file) it seems inconceivable that you would have a PDF printer that does not support (collated) copy generation. And in fact it is a hard requirement for IPP Everywhere printers that support PDF. How are you printing the PDF to the printer? (output of lpstat -v would be useful) What driver are you using? On Dec 9, 2013, at 8:40 AM, Andrey Makhalkin <a.makhalkin@samsung.com> wrote: > Hi, > > Our testing group has found an issue with printing of multiple copies > with collate option turned on. > cups-filters version is 1.0.40-0ubuntu1 > > When PDF workflow is used, pdftopdf filter doesn't put collated copies > of document pages in output pdf file. > With the same PPD file and print options pstops filter produces N * > (numpages) pages in output PS file, which seems to be a correct behavior. > > There is an attribute *cupsManualCopies in PPD file, which is set to False. > There is no Collate option inside the PPD file. > This printer doesn't seem to support hardware collate, but it supports > hardware page copies. > > The expected filter behavior is to produce collated copies of the document. > > When we change its value to "True", pdftopdf filter produces the > expected number of pages (does copies manually). > > Could you please explain, which filter behaves correctly? > Is it a bug in pdftopdf filter? > > _______________________________________________ > Printing-architecture mailing list > Printing-architecture@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture _______________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Printing-architecture] Different Collate option handling in pdftopdf and pstops 2013-12-09 14:55 ` Michael Sweet @ 2013-12-09 15:09 ` Andrey Makhalkin 2013-12-09 15:53 ` Michael Sweet 0 siblings, 1 reply; 5+ messages in thread From: Andrey Makhalkin @ 2013-12-09 15:09 UTC (permalink / raw) To: Michael Sweet; +Cc: printing-architecture@lists.linux-foundation.org Dear Michael, It is not a PDF printer. I print to a raster printer using CUPS in Linux Mint 16(a VM for testing purposes). CUPS filters pipe is the following: D [09/Dec/2013:14:34:00 +0400] [Job 16] texttopdf (text/plain to application/pdf, cost 32) D [09/Dec/2013:14:34:00 +0400] [Job 16] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66) D [09/Dec/2013:14:34:00 +0400] [Job 16] gstoraster (application/vnd.cups-pdf to application/vnd.cups-raster, cost 99) D [09/Dec/2013:14:34:00 +0400] [Job 16] rastertospl (application/vnd.cups-raster to printer/test, cost 0) rastertospl is proprietary filter, which converts CUPS raster data to Samsung's SPL PDL. Sincerely yours, Andrey Makhalkin On 12/09/2013 06:55 PM, Michael Sweet wrote: > Andrey, > > One could argue that pdftopdf should support the cupsManualCopies keyword and generate page references to effectively do multiple copies. > > However, given that PDF is NOT a streaming format (at least not for the printer, since it needs the entire document to print an arbitrary PDF file) it seems inconceivable that you would have a PDF printer that does not support (collated) copy generation. And in fact it is a hard requirement for IPP Everywhere printers that support PDF. > > How are you printing the PDF to the printer? (output of lpstat -v would be useful) > > What driver are you using? > > > On Dec 9, 2013, at 8:40 AM, Andrey Makhalkin <a.makhalkin@samsung.com> wrote: > >> Hi, >> >> Our testing group has found an issue with printing of multiple copies >> with collate option turned on. >> cups-filters version is 1.0.40-0ubuntu1 >> >> When PDF workflow is used, pdftopdf filter doesn't put collated copies >> of document pages in output pdf file. >> With the same PPD file and print options pstops filter produces N * >> (numpages) pages in output PS file, which seems to be a correct behavior. >> >> There is an attribute *cupsManualCopies in PPD file, which is set to False. >> There is no Collate option inside the PPD file. >> This printer doesn't seem to support hardware collate, but it supports >> hardware page copies. >> >> The expected filter behavior is to produce collated copies of the document. >> >> When we change its value to "True", pdftopdf filter produces the >> expected number of pages (does copies manually). >> >> Could you please explain, which filter behaves correctly? >> Is it a bug in pdftopdf filter? >> >> _______________________________________________ >> Printing-architecture mailing list >> Printing-architecture@lists.linux-foundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture > _______________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Printing-architecture] Different Collate option handling in pdftopdf and pstops 2013-12-09 15:09 ` Andrey Makhalkin @ 2013-12-09 15:53 ` Michael Sweet 2013-12-09 16:58 ` Andrey Makhalkin 0 siblings, 1 reply; 5+ messages in thread From: Michael Sweet @ 2013-12-09 15:53 UTC (permalink / raw) To: Andrey Makhalkin; +Cc: printing-architecture@lists.linux-foundation.org Andrey, OK, then that is clearly a pdftopdf bug then, which you can report here: https://bugs.launchpad.net/ubuntu/+source/cups-filters On Dec 9, 2013, at 10:09 AM, Andrey Makhalkin <a.makhalkin@samsung.com> wrote: > Dear Michael, > > It is not a PDF printer. > I print to a raster printer using CUPS in Linux Mint 16(a VM for testing > purposes). > CUPS filters pipe is the following: > > D [09/Dec/2013:14:34:00 +0400] [Job 16] texttopdf (text/plain to > application/pdf, cost 32) > D [09/Dec/2013:14:34:00 +0400] [Job 16] pdftopdf (application/pdf to > application/vnd.cups-pdf, cost 66) > D [09/Dec/2013:14:34:00 +0400] [Job 16] gstoraster > (application/vnd.cups-pdf to application/vnd.cups-raster, cost 99) > D [09/Dec/2013:14:34:00 +0400] [Job 16] rastertospl > (application/vnd.cups-raster to printer/test, cost 0) > > rastertospl is proprietary filter, which converts CUPS raster data to > Samsung's SPL PDL. > > Sincerely yours, > Andrey Makhalkin > > On 12/09/2013 06:55 PM, Michael Sweet wrote: >> Andrey, >> >> One could argue that pdftopdf should support the cupsManualCopies keyword and generate page references to effectively do multiple copies. >> >> However, given that PDF is NOT a streaming format (at least not for the printer, since it needs the entire document to print an arbitrary PDF file) it seems inconceivable that you would have a PDF printer that does not support (collated) copy generation. And in fact it is a hard requirement for IPP Everywhere printers that support PDF. >> >> How are you printing the PDF to the printer? (output of lpstat -v would be useful) >> >> What driver are you using? >> >> >> On Dec 9, 2013, at 8:40 AM, Andrey Makhalkin <a.makhalkin@samsung.com> wrote: >> >>> Hi, >>> >>> Our testing group has found an issue with printing of multiple copies >>> with collate option turned on. >>> cups-filters version is 1.0.40-0ubuntu1 >>> >>> When PDF workflow is used, pdftopdf filter doesn't put collated copies >>> of document pages in output pdf file. >>> With the same PPD file and print options pstops filter produces N * >>> (numpages) pages in output PS file, which seems to be a correct behavior. >>> >>> There is an attribute *cupsManualCopies in PPD file, which is set to False. >>> There is no Collate option inside the PPD file. >>> This printer doesn't seem to support hardware collate, but it supports >>> hardware page copies. >>> >>> The expected filter behavior is to produce collated copies of the document. >>> >>> When we change its value to "True", pdftopdf filter produces the >>> expected number of pages (does copies manually). >>> >>> Could you please explain, which filter behaves correctly? >>> Is it a bug in pdftopdf filter? >>> >>> _______________________________________________ >>> Printing-architecture mailing list >>> Printing-architecture@lists.linux-foundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture >> _______________________________________________________________ >> Michael Sweet, Senior Printing System Engineer, PWG Chair >> >> > _______________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Printing-architecture] Different Collate option handling in pdftopdf and pstops 2013-12-09 15:53 ` Michael Sweet @ 2013-12-09 16:58 ` Andrey Makhalkin 0 siblings, 0 replies; 5+ messages in thread From: Andrey Makhalkin @ 2013-12-09 16:58 UTC (permalink / raw) To: Michael Sweet Cc: printing-architecture@lists.linux-foundation.org, Mikhail Elhimov [-- Attachment #1: Type: text/plain, Size: 311 bytes --] Michael, I have created a bug report: https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1259240 On 12/09/2013 07:53 PM, Michael Sweet wrote: > Andrey, > > OK, then that is clearly a pdftopdf bug then, which you can report here: > > https://bugs.launchpad.net/ubuntu/+source/cups-filters > > [-- Attachment #2: Type: text/html, Size: 994 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-12-09 16:58 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-12-09 13:40 [Printing-architecture] Different Collate option handling in pdftopdf and pstops Andrey Makhalkin 2013-12-09 14:55 ` Michael Sweet 2013-12-09 15:09 ` Andrey Makhalkin 2013-12-09 15:53 ` Michael Sweet 2013-12-09 16:58 ` Andrey Makhalkin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.