mirror of
https://github.com/storytold/pdfcraft.git
synced 2026-10-27 11:37:59 -06:00
aiongg
0a30b4e081
content_colour parsed each content stream into a full list of operators before looking at any of them, so a small compressed stream of millions of tiny operators became gigabytes of parsed operators in memory. The content parser's loop is now an iterator (pdfcraft_content::ops), which parse collects; preflight reads it one operator at a time and stops once gray, RGB and CMYK are all found.
pdfcraft-content
Layer L2: content streams (ISO 32000-2 §7.8.2, §8, §9).
let parsed = parse(&stream.decoded()?); // operators with operands and source spans
for op in &parsed.ops { if op.is("Tj") { /* … */ } }
let bytes = serialize_ops(&parsed.ops); // write back (inline images kept whole)
let m = Matrix::from_operands(&op.operands); // cm / Tm arithmetic, invert, bbox
The parser is tolerant (unreadable bytes are skipped and counted, never fatal) and never
panics. redact and (later) edit build their interpreters on it; the graphics-state tracker
and the Patch API of architecture §6 grow here.
Unfiltered inline images with built-in or Indexed colour spaces, and image masks, use their
sample layout (including per-row byte padding) to locate EI. This preserves pixel bytes
that look like the terminator. Filtered images and resource-defined colour spaces retain
the tolerant delimiter heuristic; damaged or truncated layouts fall back to it too.