Hi Dax,

This seems to be an issue with an invalid document catalog created by PDF

The catalog object looks like this (taken from your example PDF):

22 0 obj <<
/Type /Catalog
/Pages 9 0 R
/Names 21 0 R
*/Version 1.5*
>> endobj

Now, the problem is the key /Version 1.6. According to the PDF Reference,
Version must be of type name. So, /1.5 would be valid. Unfortunately, PDF
Tex seems to write a number here, which is not valid. Please see the PDF


*(Optional; PDF 1.4) The version of the PDF specification to which the*
*document conforms (for example, 1.4) if later than the version specified*
*in the file’s header (see Section 3.4.1, “File Header”). If the header
*fies a later version, or if this entry is absent, the document conforms to*
*the version specified in the header. This entry enables a PDF producer*
*application to update the version using an incremental update; see Sec-*
*tion 3.4.5, “Incremental Updates.” (See implementation note 33 in Ap-*
*pendix H.)*

*Note: The value of this entry is a name object, not a number, and
*must be preceded by a slash character (/) when written in the PDF file
*example, /1.4).*

Still, I committed a fix to PoDoFo SVN, to just ignore such invalid
entries, unless in strict mode.

Best regards,

On Wed, Sep 14, 2016 at 8:53 PM, Dax Kelson <dkel...@gurulabs.com> wrote:

> Hi Dominik,
> In further examination, all my PDFs generated by pdfetex have this same
> problem being parsed with podofo.
> Other tools seem to work OK with the PDFs though.
> For example (although I'm not sure how comprehensive this is), here is
> running qpdf against the same file I sent you:
> $ qpdf --check GL314S-R7-H01.cover.pdf
> checking GL314S-R7-H01.cover.pdf
> PDF Version: 1.5
> File is not encrypted
> File is not linearized
> No syntax or stream encoding errors found; the file may still contain
> errors that qpdf cannot detect
> My pdfetex is from a CentOS7 box from this package:
> texlive-pdftex-bin-svn27321.0-38.20130427_r30134.el7.x86_64
Podofo-users mailing list

Reply via email to