Skip Menu |

This queue is for tickets about the CAM-PDF CPAN distribution.

Report information
The Basics
Id: 76513
Status: open
Priority: 0/
Queue: CAM-PDF

People
Owner: Nobody in particular
Requestors: futuramedium [...] yandex.ru
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: When saving, generation number of object is incremented, though it shouldn't.
Hi, Suppose we run simple program on attached in_.pdf: use warnings; use strict; use CAM::PDF; my $doc = CAM::PDF->new('in_.pdf'); my $p = $doc->getPageContent(1); $doc->setPageContent(1, $p); $doc->output('out_.pdf'); Actually, in this example we just modify one object. Modified PDF (out_.pdf) opens as blank page in Adobe Reader. In case of real files and real programs, when several objects are modified, Reader might report error opening file. Other viewers might demonstrate different behaviour. In xref table, added by CAM-PDF, we find 12 1 0000004096 00001 n I.e. generation number was increased. According to PDF specification, GN of modified object should remain the same. Only if object is deleted, and later we re-use object number from free list, GN is incremented. If we change GN (1 byte in out_.pdf) to 0, file opens as expected. Problem could be solved modifying one line in procedure save, from: $self->{versions}->{$key}++; to: if ($self->{versions}->{$key}==-1) {$self->{versions}->{$key}++}; though it requires further tests. It works with my files and my scenarios of CAM-PDF usage. As a side note, this problem seems always to have existed. No-one ever uses "output"? Only "cleanoutput"? Strange... Best regards, Vadim
Subject: out_.pdf
Download out_.pdf
application/pdf 4.4k

Message body not shown because it is not plain text.

Subject: in_.pdf
Download in_.pdf
application/pdf 4k

Message body not shown because it is not plain text.

Another remarkable find, Vadim. As you say, I think everyone uses clean(). I think this error was introduced before CAM-PDF 1.0 and was caused by me misreading the spec. The fix will be in 1.58. My fix is different from yours, and I'd appreciate it if you would look it over when 1.58 is available.
From: futuramedium [...] yandex.ru
Chris, 1.58 version works on my examples "out of the box" i.e. without my awkward "patches". Thanks for fixes, and many thanks for your wonderful library, it's a treasure. But, still, a case of 2 'startxref's in last 1024 bytes is not artificial at all. I now have a project with multi-stage fixes to files, all done with CAM::PDF. Of course, some other software always increments PDF by more than 1024 bytes e.g. appending XMP. But CAM::PDF does only what I ask it for -- therefore last 1024 bytes really may contain 2 'startxref's. I leave 'clean' to the very last stage because i think changes should be non-destructive as long as possible. Anyway, now it works as i like it, so i'm happy :) Thank you.