Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionOrion Poplawski
2017-02-22 22:02:05 UTC
Description of problem:
Paycheck PDFs generated by ADP's web portal are not able to be printed with cups due to the following error in pdftopdf which uses libqpdf:
WARNING: document.pdf (object 3 0, file position 22059): stream keyword not
followed by proper line terminator
WARNING: document.pdf (object 11 0, file position 20260): stream keyword not
followed by proper line terminator
WARNING: document.pdf (object 11 0, file position 20260): attempting to
recover stream length
ERROR: Exception: document.pdf (object 11 0, file position 20260): unable to
recover stream data
The PDFs are not compliant, but ghostscript is able to clean it up so that it can be printed with:
gs -sOutputFile=output.pdf -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH input.pdf
which complains:
**** Warning: stream operator isn't terminated by valid EOL.
**** Warning: stream operator isn't terminated by valid EOL.
**** Warning: stream operator isn't terminated by valid EOL.
**** Warning: stream operator isn't terminated by valid EOL.
**** Warning: stream operator isn't terminated by valid EOL.
**** Warning: stream operator isn't terminated by valid EOL.
**** Warning: stream operator isn't terminated by valid EOL.
**** Warning: stream operator isn't terminated by valid EOL.
**** Warning: stream operator isn't terminated by valid EOL.
**** Warning: stream operator isn't terminated by valid EOL.
**** Warning: stream operator isn't terminated by valid EOL.
**** Warning: stream operator isn't terminated by valid EOL.
**** Warning: stream operator isn't terminated by valid EOL.
**** Warning: stream operator isn't terminated by valid EOL.
**** Warning: stream operator isn't terminated by valid EOL.
**** Warning: stream operator isn't terminated by valid EOL.
**** This file had errors that were repaired or ignored.
**** The file was produced by:
**** >>>> PDFOUT v3.8v by Xenos, inc. <<<<
**** Please notify the author of the software that produced this
**** file that it does not conform to Adobe's published PDF
**** specification.
So, while this is clearly an issue with ADP and the PDFOUT/Xenos software, it would be great if qpdf/pdftopdf could be made more robust.
Unfortunately, since these are paycheck information, I'm not sure I can find a sample that I can attach.
The pdf has "stream" followed by a space and then a new-line - from od:
0030440 > sp s t r e a m sp nl q sp 1 9 0 .
203e 7473 6572 6d61 0a20 2071 3931 2e30
From ghostscript-9.20/Resource/Init/pdf_base.ps:
% PDF files are inconsistent about what may fall between the 'stream' keyword
% and the actual stream data, and it appears that no one algorithm can
% detect this reliably. We used to try to guess whether the file included
% extraneous \r and/or \n characters, but we no longer attempt to do so,
% especially since the PDF 1.2 specification states flatly that the only
% legal terminators following the 'stream' keyword are \n or \r\n, both of
% which are properly skipped and discarded by the token operator.
% Unfortunately, this doesn't account for other whitespace characters that
% may have preceded the EOL, such as spaces or tabs. Thus we back up one
% character and scan until we find the \n terminator.
So I believe that qpdf should do the same thing and just keep scanning until the \n terminator is found.
Upstream issue: https://github.com/qpdf/qpdf/issues/104
Version-Release number of selected component (if applicable):
5.0.1-3.el7
Hi Orion,
thank you for reporting this issue and I'm sorry for delay. Patch seems to be small, but I'm not sure if I will be able to reproduce this issue right now without any affected pdf file.
I'm setting CondNACk: reproducer.
Orion,
would you mind contact the support team with the issue? It will help us with prioritizing it.
For information on how to contact the Red Hat production support team, please visit:
https://www.redhat.com/support/process/production/#howto
Created attachment 1656061[details]
Backported patch with upstream test
Backporting was more difficult than expected, but it works now. It took several patches to backport too.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (qpdf bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2020:3857
Description of problem: Paycheck PDFs generated by ADP's web portal are not able to be printed with cups due to the following error in pdftopdf which uses libqpdf: WARNING: document.pdf (object 3 0, file position 22059): stream keyword not followed by proper line terminator WARNING: document.pdf (object 11 0, file position 20260): stream keyword not followed by proper line terminator WARNING: document.pdf (object 11 0, file position 20260): attempting to recover stream length ERROR: Exception: document.pdf (object 11 0, file position 20260): unable to recover stream data The PDFs are not compliant, but ghostscript is able to clean it up so that it can be printed with: gs -sOutputFile=output.pdf -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH input.pdf which complains: **** Warning: stream operator isn't terminated by valid EOL. **** Warning: stream operator isn't terminated by valid EOL. **** Warning: stream operator isn't terminated by valid EOL. **** Warning: stream operator isn't terminated by valid EOL. **** Warning: stream operator isn't terminated by valid EOL. **** Warning: stream operator isn't terminated by valid EOL. **** Warning: stream operator isn't terminated by valid EOL. **** Warning: stream operator isn't terminated by valid EOL. **** Warning: stream operator isn't terminated by valid EOL. **** Warning: stream operator isn't terminated by valid EOL. **** Warning: stream operator isn't terminated by valid EOL. **** Warning: stream operator isn't terminated by valid EOL. **** Warning: stream operator isn't terminated by valid EOL. **** Warning: stream operator isn't terminated by valid EOL. **** Warning: stream operator isn't terminated by valid EOL. **** Warning: stream operator isn't terminated by valid EOL. **** This file had errors that were repaired or ignored. **** The file was produced by: **** >>>> PDFOUT v3.8v by Xenos, inc. <<<< **** Please notify the author of the software that produced this **** file that it does not conform to Adobe's published PDF **** specification. So, while this is clearly an issue with ADP and the PDFOUT/Xenos software, it would be great if qpdf/pdftopdf could be made more robust. Unfortunately, since these are paycheck information, I'm not sure I can find a sample that I can attach. The pdf has "stream" followed by a space and then a new-line - from od: 0030440 > sp s t r e a m sp nl q sp 1 9 0 . 203e 7473 6572 6d61 0a20 2071 3931 2e30 From ghostscript-9.20/Resource/Init/pdf_base.ps: % PDF files are inconsistent about what may fall between the 'stream' keyword % and the actual stream data, and it appears that no one algorithm can % detect this reliably. We used to try to guess whether the file included % extraneous \r and/or \n characters, but we no longer attempt to do so, % especially since the PDF 1.2 specification states flatly that the only % legal terminators following the 'stream' keyword are \n or \r\n, both of % which are properly skipped and discarded by the token operator. % Unfortunately, this doesn't account for other whitespace characters that % may have preceded the EOL, such as spaces or tabs. Thus we back up one % character and scan until we find the \n terminator. So I believe that qpdf should do the same thing and just keep scanning until the \n terminator is found. Upstream issue: https://github.com/qpdf/qpdf/issues/104 Version-Release number of selected component (if applicable): 5.0.1-3.el7