PDF::Builder::Page(3pm) | User Contributed Perl Documentation | PDF::Builder::Page(3pm) |
PDF::Builder::Page - Methods to interact with individual pages
This method is Deprecated, and will likely be removed in the future. Use the global ($pdf) or page ($page) mediabox() call with no parameters instead.
This method is Deprecated, and will likely be removed in the future. Use the global ($pdf) or page ($page) cropbox() call with no parameters instead.
This method is Deprecated, and will likely be removed in the future. Use the global ($pdf) or page ($page) bleedbox() call with no parameters instead.
This method is Deprecated, and will likely be removed in the future. Use the global ($pdf) or page ($page) trimbox() call with no parameters instead.
This method is Deprecated, and will likely be removed in the future. Use the global ($pdf) or page ($page) artbox() call with no parameters instead.
(This allows you to auto-rotate to landscape without changing the mediabox!)
Do not confuse this "rotate()" call with the graphics context rotation (Content.pm) "rotate()", which permits any angle, is of opposite direction, and does not shift the origin!
You may have more than one gfx object. They and text objects will be output as objects and streams in the order defined, with all actions pertaining to this gfx object appearing in one stream. However, note that graphics and text objects are not fully independent of each other: the exit state (linewidth, strokecolor, etc.) of one object is the entry state of the next object in line to be output, and so on.
If you intermix multiple gfx and text objects on a page, the results may be confusing. Say you have $gfx1, $text1, $gfx2, and $text2 on your page (created in that order). PDF::Builder will output all the $gfx1->action calls in one stream, then all the $text1->action calls in the next stream, and likewise for $gfx2 usage and finally $text2.
Then it's PDF's turn to confuse you. PDF will process the entire $gfx1 object stream, accumulating the graphics state to the end of the stream, and using that as the entry state into $text1. In a similar manner, $gfx2 and $text2 are read, processed, and rendered. Thus, a change in, say, the dash pattern in the middle of $gfx1, after you have output some $gfx2, $text1, and $text2 material, may suddenly show up at the beginning of $text1 (and continue through $gfx2 and $text2)!
It is possible to use multiple graphics objects, to avoid having to change settings constantly, but you may want to consider resetting all your settings at the first call to each object, so that you are starting from a known base. This may most easily be done by using $type->restore() and ->save() just after creating $type:
$text1 = $page->text(); $text1->save(); $grfx1 = $page->gfx(); $grfx1->restore(); $grfx1->save(); $text2 = $page->text(); $text2->restore(); $text2->save(); $grfx2 = $page->gfx(); $grfx1->restore();
Please see the discussion above in "gfx()" regarding multiple graphics and text objects on one page, how they are grouped into PDF objects and streams, and the rendering consequences of running through one entire object at a time, before moving on to the next.
The text object has many settings and attributes of its own, but shares many with graphics (gfx), such as strokecolor, fillcolor, linewidth, linedash, and the like. Thus there is some overlap in attributes, and graphics and text calls can affect each other.
Example:
$co->resource('Font', $fontkey, $fontobj); $co->resource('XObject', $imagekey, $imageobj); $co->resource('Shading', $shadekey, $shadeobj); $co->resource('ColorSpace', $spacekey, $speceobj);
Note: You only have to add the required resources if they are NOT handled by the *font*, *image*, *shade* or *space* methods.
2021-03-28 | perl v5.32.1 |