Struct PdfWriter 

pub struct PdfWriter;

Implementations

impl PdfWriter

pub fn new() -> Self

pub fn write( &self, pages: &[LayoutPage], metadata: &Metadata, font_context: &FontContext, tagged: bool, pdfa: Option<&PdfAConformance>, pdf_ua: bool, embedded_data: Option<&str>, attachments: &[Attachment], zugferd: Option<&ZugferdMeta>, flatten_forms: bool, ) -> Result<(Vec<u8>, Vec<String>), FormeError>

Write laid-out pages to a PDF byte vector.

MEMORY NOTE (streaming-serialize investigation, 2026-09 — set aside): the large-document peak (~1GB for a 500-page doc) is NOT here. It is the Vec<LayoutPage> the caller retains (~2MB/page) while this fn borrows it as a slice. This writer is already ~90% streaming-ready: Pass 1 (below) consumes and zlib-compresses everything heavy per page; Pass 2 touches only scalars (width/height) and the lightweight collected lists (annotations, bookmarks). So making write take pages by value and drop each page’s elements after Pass 1 saves nothing on its own — layout() has already materialized the whole tree before write is called. A real peak reduction needs a restartable STREAMING LAYOUT producer (yield page N, serialize, drop), which collides with the sentinel count pass (total page count is needed before page 1 can emit) and touches pagination. Crucially, PDF/A + PDF/UA are NOT a blocker: the structure tree (tagged::TagBuilder), link_slots, and disjoint page/annotation StructParent numbering are a few MB of lightweight metadata that stay whole-document and assemble unchanged at finalize — so streaming frees layout memory earlier without moving a single output byte, and veraPDF stays 9/9 by construction. See scripts/parity/benchmarks.mjs trackedFixes for the full write-up.

Trait Implementations

impl Default for PdfWriter

fn default() -> Self

Returns the “default value” for a type.