Bug 1425969 - Exception: unable to recover stream data on problematic PDFs
Summary: Exception: unable to recover stream data on problematic PDFs
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qpdf
Version: 7.6
Hardware: All
OS: Linux
low
high
Target Milestone: rc
: ---
Assignee: Zdenek Dohnal
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1709724
TreeView+ depends on / blocked
 
Reported: 2017-02-22 22:02 UTC by Orion Poplawski
Modified: 2019-05-17 17:34 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github qpdf qpdf issues 104 None None None 2017-02-22 22:02:49 UTC

Description Orion 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

Comment 2 Orion Poplawski 2017-07-31 17:45:33 UTC
Looks like upstream has checked in a fix to master, and hopefully will release 7.0 with it soon.

Comment 4 Zdenek Dohnal 2018-01-18 14:57:35 UTC
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.

Comment 7 Zdenek Dohnal 2018-10-05 10:22:24 UTC
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

Comment 8 Orion Poplawski 2018-10-05 14:30:09 UTC
I don't have a support contract.

Comment 9 Tomáš Hozza 🤓 2018-11-19 15:39:47 UTC
Hi.

Would you be willing to provide an example PDF to reproduce the issue?

Comment 10 Orion Poplawski 2018-11-19 15:59:46 UTC
Reproducer sent privately.  Still a problem on 7.6.


Note You need to log in before you can comment on or make changes to this bug.