jdtoronto has asked for the wisdom of the Perl Monks concerning the following question:

Esteemed Monks,

I have created some templates for some newsletters in PageMaker (yeah, I know it is out of date, so am I) and exported them as PDF's. When I open a file and use it as a 'form' (using prForm) in PDF::Reuse, I will sometimes (depending on the complexity of the document or some such stupidity) get an error:

Has 2 Pages An error occurred at G:/EngData/EP2058 InContact/EP2058-002/lib/InContact/PDF/Newslette +r.pm line 38 Tk::Error: G:/EngData/EP2058 InContact/EP2058-002/t209.pdf_1 can't be + used as a form. See the documentation under prForm how to concatenate streams More information might be found in error.log at G:/EngData/EP2058 InContact/EP2058-002/lib/InContact/PDF/Newslette +r.pm line 38 (menu invoke)
I read the documentation, but it seems that nothing is having any effect.

Has anyone seen this before? I am using PDF::Reuse because I was having serious trouble with PDF::API2 on Win32 - until this issue PDF::Reuse was doing pretty well!

jdtoronto

Replies are listed 'Best First'.
Re: PDF::Reuse issue with streams
by Khen1950fx (Canon) on Jul 07, 2006 at 07:49 UTC
    Good question! I went over the docs. Three things caught my attention. First, the author mentions 2 versions of PDF::Reuse---1.4 and 1.5. Also, he developed this on Win32 and Abobe, and it's missing meta data and info or hasn't been incorporated into the module yet. Missing items can be added with a batch routine in Adobe. That could be a problem, esp. if you're on a linux box. Second, the author mentions that the mandatory components, prFile and prEnd, must be installed and to double-check that they are indeed working. I would use pmtools to check that out. Basically, retest the module to make sure it is working. Third, he mentions a very specific order in using the components. In this case, you are using prForm; so, the order is prSinglePage, prForm, and prPage. I would suggest redoing your script and start with prSinglePage. If it's still quirky, then prForm, then prPage. He gives each component alternative methods. You might want to play them. All in all, this module appears to me to be rather quirky, but it works---just expect the unexpected. I would try to use prSinglePage instead of prForm.
      Thanks for the info. I am working on Win32 and I have been using PDF::Reuse for well over twelve months. But the documents I was handling were very simple, mainly commercial documents, and PDF::Reuse worked extremely well and is blindingly fast at producing VERY compact documents.

      I found a mailing list for the module yesterday on Google and I got a response this morning from the module author saying pretty much the same thing. He did also say that the concatenation process has on one ocassion not worked for him. So it seems that prSinglePage it is!

      In the meantime I have re-written my code using PDF::API2 and it is working well, but I prefer PDF::Reuse for its speed.

      jdtoronto

Re: PDF::Reuse issue with streams
by jdtoronto (Prior) on Jul 07, 2006 at 18:23 UTC
    For the sake of those who may come after, here is the reply from the module author:
    The error you get occurs when PDF::Reuse tries to transform a page to an "XObject". There are many content streams forming the page and the program doesn't continue. Most often the procedure to concatenate streams really works. I think it has only happened to me once, that it didn't. Then Acrobat refused to change anything with the text. The font was strange and Acrobat couldn't do anything with it. Your case might be one of these cases.

    Anyway, you could perhaps try to use prSinglePage instead. It accepts many content streams for one page, but you have to change your code a little. Look at the documentation. prSinglePage creates a new content stream of all your new text, and adds it to the array of streams. It puts it at the end of the array. So if it is possible, try prSinglePage.

    jdtoronto
Re: PDF::Reuse issue with streams
by Anonymous Monk on Aug 07, 2009 at 10:24 UTC
    I found a simple solution to that problem. Simply put the pdf through Gostscript and everything works fine: gs -q -sPAPERSIZE=a4 -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=out.pdf in.pdf