|Anonymous | Login | Signup for a new account||11-25-2014 02:16 CET|
|Main | My View | View Issues | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0000220||[PDFedit] =Other (Kernel)=||major||always||03-14-08 08:30||07-03-09 23:54|
|Summary||0000220: Moving page causes page cropping|
If you move a page within a pdf document, save the document and view it then with Adobe Reader, the page dimensions of the moved page have changed. While the page still has the right width, it is too tall because some upper space has been cut off. (210 x 279,4 mm after while being 210 x 297 mm (A4) before)
I assume it has something to do with a clash of DIN and American paper formats, because the Letter format has exactly this height (279 mm).
In PDFedit itself, this problem isn't visible. If I try to edit the page dimensions with the built-in function, it shows me the right dimensions - none others than of the other pages. The same problem occurs when inserting pages from an other pdf document. The inserted pages are too tall.
I think this is exact the same issue like 0000158: Page size is changed after line is drawn into the document.
I use PdfEdit 0.4.1, self-compiled, on a Xubuntu 7.04 machine. The problem occurs with a pre-built PdfEdit 0.3.1 too, it's therefore neither a regression nor a problem of my build environment.
Included are two pdf files, Vorwort_old.pdf shows the original document, Vorwort_new.pdf the corrupted.
Vorwort_new.pdf [^] (139,977 bytes) 03-14-08 08:32
Vorwort_old.pdf [^] (122,347 bytes) 03-14-08 08:32
cropBox-default-fix.patch [^] (1,558 bytes) 03-16-08 18:01
I suspect that this is caused by inherited page attributes (PDF specification page 123 "Inheritance of Page Attributes") but I didn't have time to look closely at it right now (maybe during this weekend).
Technical background information (for record):
Page in PDF is represented by the dictionary data structure. All pages are maintained in B-tree like structure where leaf nodes represent pages (see specification page 117 "3.6.2 Page tree"). Intermediate nodes simply reference leaf nodes or other intermediate nodes and may contain.
You can see this tree in PDFedit with Property editor.
Page dictionary can contain page metrics (hight, width). But it doesn't have to! In a such case attributes from the nearest parent node are used instead.
This technique reduces size of page dictionaries (because they have almost always same metrics) and moreover handle groups of pages with only one set of attributes (all pages under intermediate node with such attributes).
So typical PDF contains metrics in the root node and all pages inherits these values automatically.
If you add page from other document, then it is possible that this page doesn't have its metrics inside and so values from the target document.
Another thing is that if page metrics are not present then we use default values which are A4.
I have checked original and generated documents and they contain most of the metrics directly inside page dictionary:
(page dictionary of the first page)
2 0 obj <<
/Contents 3 0 R
/Resources 1 0 R
/MediaBox [0 0 595.2756 841.8898]
/Parent 8 0 R
MediaBox is present here, but CropBox is not! So that we initialize this to the default value (which is currently A4).
From specification to CropBox:
(Optional; inheritable) A rectangle, expressed in default user space units, defining the visible region of default user space. When the page is displayed or printed, its contents are to be clipped (cropped) to this rectangle
and then imposed on the output medium in some implementation-
defined manner (see Section 10.10.1, “Page Boundaries”). Default value:
the value of MediaBox.
But we are doing (from fillInheritedAttributes):
// MediaBox is required and specification doesn't say anything about
// default value - we are using standard A4 format
// CropBox is optional and specification doesn't say anything about
// default value - we are using standard A4 format
So this is obviously a bug. We want to use mediaBox as default here.
changes default cropBox size to the media box if not specified.
Michael, could you try this patch (simply copy file the the source tree root and type patch -p0 < cropBox-default-fix.patch) and try your scenario again
(you have to recompile the tree first:
rm gui/pdfedit ##### see below
./gui/pdfedit # run compiled pdfedit and try your scenarion again
If it is correct, you just make install again
# this is quick hack which forces gui to be relinked with the updated
# kernel library. Without that only kernel gets recompiled and gui will
# be still linked with the old version of kernel library. This is known
I have tried it on my computer and it seems that it solved the issue.
It works very well. Up to now I haven't experienced this problem anymore.
|03-14-08 08:30||michael_kaeppler||New Issue|
|03-14-08 08:32||michael_kaeppler||File Added: Vorwort_new.pdf|
|03-14-08 08:32||michael_kaeppler||File Added: Vorwort_old.pdf|
|03-14-08 16:14||hockm0bm||Status||new => assigned|
|03-14-08 16:14||hockm0bm||Assigned To||=> hockm0bm|
|03-14-08 16:31||hockm0bm||Note Added: 0000375|
|03-16-08 17:49||hockm0bm||Note Added: 0000377|
|03-16-08 18:01||hockm0bm||File Added: cropBox-default-fix.patch|
|03-16-08 18:01||hockm0bm||Note Added: 0000378|
|03-16-08 18:14||hockm0bm||Note Added: 0000379|
|03-17-08 08:11||michael_kaeppler||Note Added: 0000381|
|03-17-08 09:15||misuj1am||Status||assigned => resolved|
|03-17-08 09:15||misuj1am||Resolution||open => fixed|
|03-17-08 09:15||misuj1am||Note Added: 0000382|
|03-17-08 10:48||hockm0bm||Relationship added||has duplicate 0000158|
|07-03-09 23:54||bilbo||Status||resolved => closed|