[Phil]

 danisowa commented 8 hours ago

Hello, the following code "destroyes" my PDF documents.

I am getting erros when trying to print the created PDF and when trying to save the created PDF (for fast web view)

i have drilled down the problem to the lines

Code: [Select]

$annotation = $page->annotation();
$annotation->url("http://www.google.de", %option);

Code: [Select]

$position_y = 20;
for $cu_page_number (1 .. $pdf->pages())
{
$page = $pdf->openpage($cu_page_number);
%option=(
-border => [0,0,0],
-rect=>[50,
$position_y + 40,
10,
$position_y,
],
);
$annotation = $page->annotation();
$annotation->url("http://www.google.de", %option);
}
$pdf->saveas('/tmp/test.pdf');

[Phil]

 PhilterPaper commented 7 minutes ago

I'll try to reproduce it later today. Are you using the latest PDF::Builder release (3.009), or an earlier one? When you say it "destroys" the PDF, you're talking about a bad output PDF (/tmp/test.pdf) and not damage to the original input PDF (under a different name, I presume)? Or are you saving it back into the original?

[Phil]

Here is a complete example, using PDF::Builder 3.009 that appears to work OK. Each of the 12 pages (012_pages example is the input) gets a live region (marked with Google) that opens www.google.de successfully. How does your complete program differ? I am writing out a different file -- I don't think you can rewrite the input file (saveas()), if that's what you did. I haven't tried a save().

Code: [Select]

use strict;
use warnings;
use PDF::Builder;

my $pdf = PDF::Builder->open('012_pages.pdf', -compress => 'none');
                  # the default compression 'flate' also works
print "there are ".($pdf->pages())." pages in the input file\n";

# =============================
my $position_y = 20;  # add "my" to all locals
for my $cu_page_number (1 .. $pdf->pages()) {
print "modifying page $cu_page_number\n";
    my $page = $pdf->openpage($cu_page_number);
    my %option=(
        '-border' => [0,0,0],    # -border doesn't seem to work anywhere
        '-rect'   => [50,
                      $position_y + 40,
                      10,
                      $position_y,
                     ],
    );
# url() does not permit an icon, so write "Google" there
my $txt = $page->text();
my $font = $pdf->corefont("Helvetica");
$txt->font($font, 20);
$txt->translate(10, $position_y);
$txt->text("Google");

    my $annotation = $page->annotation();
    $annotation->url("http://www.google.de", %option);
}
$pdf->saveas('test.pdf');   # was /tmp/test.pdf
# =============================
Maybe there's something in your original PDF (source) that doesn't like annotations or even (in general) being updated?

[Phil]

I've been playing with it this evening, and I found a few things of interest. First of all, I don't think the annotation calls have anything to do with it. I removed your annotation lines (and my "Google" print) so that the output should basically be just the input, and it still has the corruption.

• I see it claims to be PDF 1.7 level. PDF::Builder is written for PDF 1.4 with a few 1.5 extensions. Is it possible to "dial back" your PDF creation software to produce PDF 1.4 level? Just to see if there are some 1.5+ features in there which are messing it up.
• All the embedded images seem to be missing, as are some form controls (like the dropdown selection list). Perhaps these are implemented as PDF 1.5+ features that PDF::Builder doesn't handle correctly?
• Is it embedding some TTF fonts? I see some objects that look like they may be embedded fonts, but I'm not sure. You definitely refer to some specific fonts such as Arial-BoldMT which I don't have. My output is lighter weight than yours (input.pdf) which suggests my output is using a different font than what is embedded (or the embedded font is damaged).
• The missing accented characters are multibyte, so I assume they're UTF-8. If the Reader is using a simple ASCII-only font when I display it, that might explain why those characters disappear, even though the output appears to still contain them.
• The text in the lower left corner Elchingen <dot> has (on output) the glyph IDs being rendered as ASCII codes, although "Germany" after it comes out fine.
• There may be something too advanced in the Form which is confusing PDF::Builder. I see a lot of the text labels that are in the form appearing after the %%EOF.

Anyway, if it's possible to start with a PDF 1.4 level document, we could see if the annotation works on that (it does for me). That would suggest that there's something in your input.pdf document that is confusing PDF::Builder, and code to handle it might need to be added. Some PDF writers just slap "1.7" on the header, even if they're producing lower levels, but I suspect there really is something greater than 1.4 here.

[Phil]

PhilterPaper:

Hi,
Did you have a chance to try starting with a PDF 1.4 document, and perhaps seeing if specific 1.5+ elements break PDF::Builder? That would at least give a starting point for any further work in this area. As I said, I don't think it's the annotation itself, but something in the original PDF 1.7 document that isn't being handled well.

[Phil]

I believe that the issue here is the importation of PDF > 1.4 files, and not annotation. As the issue originator has not responded in over 6 months, I will go ahead and close this issue. I can use the sample input for work on handling PDF > 1.4 files (see #27 ([RT 106020] Bug with recognizing PDF files via open_scalar), #39 ([RT 117210] Error: "can't call method "realise" on an undefined value" while open a pdf-file), #65 ([RT 121832] Invalid PDF file in test suite), #66 ([RT 121911] Adding pages to existing documents doesn't work if page tree is anything but very simple (+ maybe fixed)), and #90 (Problem extracting pages from PDF v. 1.6 documents)).