-
Notifications
You must be signed in to change notification settings - Fork 21
Description
use strict;
use warnings;
use feature 'say';
use PDF::API2;
my $pdf = PDF::API2-> new;
my $p = $pdf-> page;
$p-> boundaries(
media => [ 0, 0, 600, 400 ],
crop => [ 50, 50, 600, 400 ],
);
$p-> rotation( 180 );
my $f = $pdf-> font( 'Times-Roman' );
$p-> text
-> font( $f, 96 )
-> position( 100, 300 )
-> text( 'Hello, PDF!' );
$pdf = PDF::API2-> from_string( $pdf-> to_string );
$pdf-> open_page( 1 ); # no-op? nope (*)
$pdf-> save( 'visual_test.pdf' );
Initial PDF, serialized to string, simulates a file from external source. Boxes (e.g. CropBox
here) is non-symmetrical relative to MediaBox
, and page was rotated. The content is just chosen to be clearly seen if deformed/cropped. Comment/uncomment the star (*) marked line and inspect the output. This affects opening files and then adding content to a page, as well as importing a page to another document. Gaps between (Crop|Trim|Bleed|Art)Box
and MediaBox
should stay the same on top/left/bottom/right edges of un-rotated page, as they were on rotated page. If I get it right. Looks like this bug is primordial i.e. 20+ y.o. I'll try to supply a fix unless someone comes with better idea.
Edit: Actually, MediaBox
on its own is enough to observe a bug, e.g. replace in the above with:
my $p = $pdf-> page;
$p-> boundaries(
media => [ 50, 50, 600, 400 ],
);
$p-> rotation( 90 );
The "un-rotating" code in PDF/API2.pm
does at least something to boxes boundaries in case of 90 and 270 degrees, and nothing for 180. Here we see that the bug is not because nothing was done for 180, but the whole logic appears to be simplistic and flawed.