http://qs321.pair.com?node_id=603530


in reply to Open page error for PDF::API2

It looks as though one possibility is that an input filter is missing. Did you change machines, or was PDF::API2 updated? If not, it may be due to the template being created on Windows, the prog being run on *nix, and the need of the file to be converted (e.g. newlines). That conversion appears to be done by the filters. Does any of this ring a bell?

--traveler

Replies are listed 'Best First'.
Re^2: Open page error for PDF::API2
by almut (Canon) on Mar 07, 2007 at 02:12 UTC
    ... 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 :)

      I have tried all the suggestions, made sure in the FTP it was sending binary, Compress::Zlib is installed, I doubt it that its the actual perl file being the problem for I have only changed a few text, however i have recently changed the pdf, I still have yet been able to get it to work if you need to see the pdf file i can send it to you if that help, and also put the .pl file in my scratchpad (Its a bit ugly, was a fast hack). I am still trying thing to see what i can come up with
        ... I doubt it that its the actual perl file being the problem ..., however i have recently changed the pdf ...

        Right, I too don't think the problem is with your Perl script. I suppose it's something with the PDF, however. Either it's been garbled for some reason, or Adobe InDesign introduced some feature that PDF::API2 can't handle...   Well, feel free to send me the PDF file (exactly as you have it on the webserver - preferably compute an md5sum too, so I can verify we have the identical file...), and I'll take a look... (I'll /msg you my email).