v0.47.0 — form-field justification, default values and the no-export flag
Form-field justification, default values, and the no-export flag
Three properties the read model had exposed since the forms layer shipped
with no writer anywhere in the crate. All three sit on Acrobat's own
field-properties surface.
pdfcer edit-field in.pdf --name total --quadding 2 -o out.pdf
pdfcer edit-field in.pdf --name total --default-value "0.00" -o out.pdf
pdfcer edit-field in.pdf --name secret --no-export true -o out.pdf
| Key | Was | Now |
|---|---|---|
/Q — justification (Table 233) |
Field::quadding readable, nothing wrote it |
--quadding 0|1|2, --clear-quadding |
/DV — default value (Table 228) |
Field::default_value readable, nothing wrote it |
--default-value, --clear-default-value |
Ff bit 3 — NoExport (Table 226) |
defined and referenced nowhere else in the workspace | --no-export true|false |
/DV matters more than it looks
reset_form reads /DV and removes /V where there is none — so with no
writer, a reset could only ever restore defaults some other application had
authored. A form pdfcer built from scratch reset every field to empty
whatever its author intended, and there was no way to say otherwise.
/DV's type follows /V: a name for a /Btn (an on-state or /Off), a
text string elsewhere. Writing a string onto a check box would produce a
default no reader could match against an appearance state.
Absent, set, and removed are three different things
/Q and /DV distinguish all three. Table 233 defaults /Q to left, so
setting it to 0 and removing it render identically — and are different
facts about the file. A round trip has to preserve which one it met, which is
why --clear-quadding exists alongside --quadding 0 and why the test checks
the raw dictionary rather than the resolved model.
A refusal rather than a clamp
A /Q outside 0..=2 is refused by name and validated before anything is
written, so a bad value changes nothing. Clamping 7 to 2 would silently
right-align a field you meant to do something else with.
Also fixed: a garbled message, and the check that called it clean
The fresh-folder smoke test for this release found a ten-space gap baked
into an operator-facing error message in the shipped binary — from a line
continuation lost while the error was being written.
check-string-gaps had reported PASS on it. Its prose-mode rule was a
hand-written list of characters, and the one after the gap was an opening
parenthesis — the most ordinary way an English sentence introduces a gloss,
absent from the list for no reason anybody chose.
The gate's own comment, written after an earlier miss, had already concluded
that the rule "should be read as anything that starts a word, not as a
list" — and then implemented a list. It now does what its comment says,
measured before widening (20 findings across all literals, all but one
deliberately-aligned report columns; 1 scoped to prose, the defect) and proved
by re-introducing the defect and watching the gate name it.
Verified: fmt, clippy -D warnings, check-core-api-verbs and the
document/CI gates green; CI green on the tagged commit; the portable folder
copied to a fresh path and justification, default value, no-export, the
reset-restores-the-default round trip and the corrected refusal message all
reproduced there in the shipped binary.
sha256 of the zip is in the accompanying .sha256 file.