|laziness, impatience, and hubris|
Re^2: Open page error for PDF::API2by almut (Canon)
|on Mar 07, 2007 at 02:12 UTC||Need Help??|
... and the need of the file to be converted (e.g. newlines).
I think you meant to say
... and the need of the file not to be converted ... :)
Always treat PDFs as binary files! Line endings conversions will surely ruin the file.
Actually, this could be the problem here. Maybe ikkon uploaded the file to the webserver via FTP, and forgot to set binary mode? Just an idea. It's hard to tell what the real problem is without being able to take a look at the PDF file.
That conversion appears to be done by the filters.
Not quite (at least not if "that" refers to "newline"). The filters handle just the de/encoding of the stream part of the PDF objects1. Typically, filters are being used for compressing data, but there are other uses as well.
In case your PDF file should turn out not to be broken otherwise, maybe it's making use of some fancy filter that PDF::API2 doesn't implement (yet). This might possibly lead to the method infilt being called on an undefined filter object eventually... (which is the error you're observing). Just guessing again.
1 A little background: Roughly speaking, PDF files consist of a series of numbered objects. The numbers allow them to be referenced from within other objects. The objects themselves consist of a dictionary part (meta info), and an optional stream part (data). The latter may hold the drawing primitives that make up the text/graphics content of a page. At the end of every PDF is an index table which lists the byte offsets of all objects in the file. This is mainly for performance / resource usage reasons, so some reader software can directly seek to the respective position where the required object is found, without having to parse the entire file (which makes sense when displaying just a single page from a document with hundreds of pages...). This direct indexing feature is one of the reasons why PDF files must be treated binary. As soon as you move around, or change the size of objects, the index table needs to be recomputed. This of course won't happen automagically when (size-modifying) Windows-to-Unix newline translations are being applied, for example... (though some readers will try to auto-fix a broken file). Hope this helps :)