mirror of
https://github.com/storytold/pdfcraft.git
synced 2026-10-24 10:08:00 -06:00
mtlcl410andClaude Opus 5.5
0142a96ca3
ISO 32000-2 §8.6.6.5: "DeviceN colour spaces (PDF 1.3) may contain an arbitrary number of colour components", and scn takes one operand per component. The content parser (vendored hayro-syntax) held ten operands per instruction; pushing the eleventh failed, and the failure ended the whole content stream. A twelve-ink background fill therefore drew nothing, and nothing after it was drawn either: a blank page, no error. hayro-syntax patch (26): an instruction keeps up to 256 operands (enough for the largest DeviceN space the interpreter reads, 255 inks, plus a pattern name). Past that the oldest are dropped, in order, rather than the stream ending: operators already read the operands nearest to them, so this is how stray operands are treated below the cap too. hayro-interpret patch (55): a Separation or DeviceN tint transform that can't be read no longer makes the colour space unreadable (its paints were drawn in DeviceGray from the first tint, white for a full tint); it keeps the space, and like a transform that fails when evaluated it paints that colour in the alternate space's initial colour. Those fallbacks, and a cs/CS colour space that can't be read, were silent: they are reported once per content stream as InterpreterWarning::ColorFallback, which pdfcraft-render records as RenderWarning::ColourFallback and pdfcraft-cli render prints. Tests, each seen failing with its fix reverted: the report's twelve-ink page paints black and draws what follows; a four-ink control; 300 stray operands before rg still draw; a calculator tint transform that pops too much, and an unknown function type, fall back with one warning and the rest of the page drawn; hayro-syntax keeps all twelve scn operands and, past the cap, the latest 256 in order (fails without the reorder). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0175FWj4xFhMhSH3UpMU8DSC