* [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.