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

Having issues with PDF::API2. We are creating PDF output starting with a watermark/background (lines for the form and a bitmap logo) and then overlay text on top. The database text overlay never has any trouble. It's the background PDF we are wrestling with.

Computer 1: template.pdf is read in by the script, we overlay the text, all is well with the generated PDF. The background form and logo show up with the text on top, just as expected.

Computer 2: template.pdf is read in by the script, and only part of it renders properly in the final PDF. The overlay text renders just fine, so I don't think the PDF gets entirely corrupted. The template files are identical on both computers.

#1 has PDF::API2 version 2.023 and #2 has 2.033, so I thought maybe I could downgrade. But testing with v2.023 on #2 has the same problem.

Experimented with dozens of variations on the template file. Made a simple 3-rectangle background in Illustrator as the template, and that worked fine. Added a white blob with bezier curves on top of the rectangles, updated the template, and then none of the rectangles showed up, either, as if the whole template was empty. Removed the blob and added a white oval (which is also bezier curves), and that worked 100% fine. So far I can't find the pattern.

So I'm concluding that somewhere between my $bg = $pdf->importPageIntoForm( $bg, 1 ); and $page->gfx->formimage( $bg, 0, 0, 1.0 ) something is going south on #2 but not on #1. Right?

Suggestions on how to troubleshoot this are welcome. :/

Replies are listed 'Best First'.
Re: PDF::API2 behaving differently on two computers?
by Corion (Pope) on Apr 08, 2020 at 17:52 UTC

    Can you reduce the program to a very short program that still exhibits the problem? I'm thinking of something like:

    #!perl use strict; use warnings; use PDF::API2; print "Using PDF::API2 version $PDF::API2::VERSION\n"; my $pdf = PDF::API2->new; my $bg_file = 'watermark.pdf'; my $bg = $pdf->importPageIntoForm( $bg_file, 1 ); # ... $page->gfx->formimage( $bg, 0, 0, 1.0 ) # write to another file

    That would help me understand your steps better and maybe point out where the problem(s) might lie.

      Aha, this was a helpful kick in the pants. When I do a simple script as you suggest, everything works swimmingly. So there's something in the home-grown modules in between, that we are using, that's corrupting things. So at least I have a starting point for sleuthing now.

      One thing I've noticed in the past, is that I must disable $pdf->{forcecompress} = 0. Sometimes it's okay even with forcecompress left enabled, other times it really scrambles the presentation when displaying via a PDF reader (text enormous or skewed or mispositioned on the page). Turning it off makes it so there's dependable display of the results.

      Is that common -- where forcecompress causes issues?

Re: PDF::API2 behaving differently on two computers?
by Fletch (Chancellor) on Apr 08, 2020 at 18:25 UTC

    Presuming some form of *NIX if you're completely at a dead end sometimes using strace (or dtruss on OS X) can be enlightening. For something like this you're mainly interested in the lists of files which it tries to call open(2) or stat(2) or the like on. Run on both machines and then compare the two; sometimes it helps to do some post-processing to remove differences (common things would be to smash out the exact file descriptors run returned or addresses of buffers passed and get (say) a list of the files it can or can't open; possibly run those lists through sort and uniq before diff'ing can help).

    Edit: a word.

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

      Good ideas. I hope I can resolve it noodling thru my perl code before getting elbow deep in strace, tho. Thanks for the suggestions! :)

      And perhaps the cake is just an exaggeration.