Skip to main content

Module update

Module update 

Source
Expand description

Incremental updates to an existing file (ISO 32000-1 §7.5.6): the base bytes stay in place and an update section appends new and replaced objects plus a cross-reference section chained to the base’s by /Prev, in the base’s own cross-reference style.

Structs§

Overlay
An update section under construction over an OverlayBase: which objects it holds, new ones numbered from the base’s first free number.
OverlayBase
The facts about a base document an update needs, read once from its trailer and its own newest cross-reference section: refuses an encrypted base or one missing /Root or a startxref to chain from.
Update
A base document plus the update section being built over it.

Functions§

rotate_pages
Stages by degrees of rotation, clockwise, on each of pages (0-based indices) into update: a clone of the page’s own leaf dictionary, its /Rotate set to its current effective rotation plus by, normalized with rem_euclid(360). The staged dictionary is untranslated: it keeps its own /Parent, so it stays exactly where it was in the page tree. A page with no object of its own (inlined directly into /Kids) cannot be staged this way: refused, naming its 1-based page number. by must be a multiple of 90; anything else is refused before any page is touched.
set_metadata_with
Merges meta into existing_info’s dictionary (or a fresh one, staged under a newly reserved number, when existing_info is None): a Some field overwrites its key (Some(String::new()) writes an empty string), a None field leaves whatever key was already there. The merged dictionary is staged into overlay via set and set_info.
start_offset
The base’s length as an update’s write position, plus whether a pad newline must be inserted first: an object header may not follow directly after %%EOF unless the base already ends on a line terminator (\n or \r).
watermark
Draws the first page of overlay over every page of base, returning base’s bytes followed by an incremental update: the overlay page as one form XObject (its resources copied into the base’s object space), and each page’s dictionary rewritten with that form in its resources and its content wrapped in q … Q before the form is drawn. Pages inlined directly into /Kids, having no object of their own, are left as they are. An encrypted base is refused: its new strings and streams would need encrypting too. An encrypted overlay is refused as well: its decrypted content would otherwise copy across into the plain update section.
watermark_under
Like watermark, but draws the overlay beneath each page’s content: the form paints first and the page’s own content paints over it, so opaque content covers the overlay instead of the other way round.
watermark_under_with
Like watermark_with, but draws the overlay beneath each page’s content: the form paints first and the page’s own content paints over it, so opaque content covers the overlay instead of the other way round.
watermark_with
Like watermark, but writes a fresh file through the Writer under options instead of appending an update: every object the base’s catalog reaches is copied over, uncompressed streams are compressed when options.compress is set, and unreachable objects and earlier sections are left behind, so the result is usually smaller than the base. Both base and overlay are refused when locked, through crate::importer::Importer::new; a password-opened encrypted base or overlay copies its plaintext content across like any unencrypted source.