v0.48.0 — a form field's font, size and colour, settable at last
A form field's font, size and colour are settable at last
pdfcer edit-field form.pdf --name total \
--font times-bold --font-size 14 --font-color 1,0,0 -o out.pdf
/DA (ISO 32000-1 §12.7.3.3) was readable since the forms layer shipped and
nothing could write it — and the value pdfcer wrote at field creation was
hard-coded /Helv 0 Tf 0 g. So every field pdfcer had ever authored was
black Helvetica, auto-sized, with no way to say otherwise. This is the last
and largest of the four field properties that were readable and unwritable.
--font— any of the 14 standard faces, by hyphenated lower-case name
(helvetica-bold-oblique,times-italic,courier,zapf-dingbats…)--font-resource— a face the document already embeds, by its resource key--font-size— points;0is auto-size, what Acrobat calls Auto and
what a new text field defaults to--font-color— 1 component for gray, 3 for RGB, 4 for CMYK
Choosing a font is not just writing a name
/DA names a font by a resource key, and that key must resolve in the
form's /DR /Font dictionary. A key that does not resolve never fails
loudly — the reader substitutes a face, the field looks entirely normal, and
it is drawn in something nobody chose.
So the two cases are split by what pdfcer can actually promise:
| pdfcer's guarantee | |
|---|---|
--font (standard 14) |
Authors the resource, under Acrobat's own short keys (Helv, TiRo, Cour, ZaDb…), reusing one that is already there. Cannot fail for want of a resource. |
--font-resource |
Checks only. Refused by name if the key is absent — and the refusal lists what is available, because a refusal that is correct and useless is a bug in itself. |
Setting it redraws the field
Writing /DA alone would leave the field claiming one face and drawing
another. Changing any of the three regenerates the baked appearance, so the
file and the pixels agree.
--font-resource face is one pdfcer cannot
measure, so auto-size metrics fall back to Helvetica while the name written is
yours. An embedded face with wider glyphs will auto-size slightly differently
from what a reader finally draws.
Colour here is the text, not the box
--font-color is the colour of the value's glyphs. The box's own fill and
border are edit-widget --background and --border-color — a different
dictionary, set by a different verb, and the likeliest way to end up with a
field that looks nothing like intended.
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 the feature reproduced there at byte level —
setting Courier-Bold 12pt blue produces /CoBo 12 Tf and 0 0 1 rg in the
drawn appearance stream, with both refusals firing as documented.
sha256 of the zip is in the accompanying .sha256 file.