Repository navigation
blocky-writer: a filled application form is a print job — should it be distinguishable? #118
Description
You are downstream of us, one step
blocky-writer fills fixed-layout PDF and application forms. The output of
fill_blocks is a complete PDF byte stream — an AcroForm with values written,
NeedAppearances set so viewers regenerate appearances, and the document
otherwise untouched.
A filled application form is a print job more often than it is anything else. So
you are plausibly the next thing that happens to our output, and we have never
spoken.
What you might use from here
fill_blocks returns Vec<u8> / js_sys::Uint8Array — ordinary PDF bytes, no
wrapper, no sidecar. It writes only /V, /DV and /AS entries and sets
NeedAppearances; it does not re-render, re-compress or re-order the document.
If your print path needs to know that a form arrived already-filled rather than
hand-completed, there is currently no marker distinguishing the two. That
seems worth deciding deliberately rather than leaving to chance.
What we would need from you
Nothing blocking. If you have a position on whether a machine-filled form should
be distinguishable from a hand-filled one — for audit, for routing, for
anything — say so and we will record it in
docs/ecosystem/ECOSYSTEM.adoc.
Activity
fix(rust): clear the rust-core clippy gate; plus docs, wiki, template…
hyperpolymath commentedon Sep 30, 2026
RULING D189 (2026-09-30T14:23Z) · scope: repo · basis: applied-unless-struck (D113; owner approved the full table, none struck)
Yes: record machine-filled provenance as metadata in the print path so audit/routing can distinguish it.
surface: metadatastician/standards#787 (comment)
The open question in this issue is answered by the ruling above; future agents should act on it rather than re-ask.
feat(ffp): form-fill provenance standard — marker, detection, print-p…