Skip to content

pdfcer 0.44.1

Choose a tag to compare

@KenM76 KenM76 released this 07 Sep 18:12
· 123 commits to main since this release

Patch release. Fixes two defects in 0.44.0's set-text-annot-style, both reported by the pdfcer-gui project within hours of that release.

Single-folder portable Windows x64 build. Unzip and run pdfcer.exe.

Changing a text box's colour un-wrapped it

A multi-line /FreeText collapsed to a single line when only its colour was changed — silently, destroying layout the operator had.

/FreeText carries no multiline flag (§12.5.6.6 defines none), so the value has to be measured by re-baking the annotation's own text both ways and comparing against the bytes on disk. set-markup-note did that correctly; set-text-annot-style shipped without it.

The fix is one shared helper both verbs call, rather than a second correct call site — the property that failed was two re-bakers of the same subtype disagreeing about a value neither can read.

That measurement also answers a second question, which is now reported instead of discarded: when neither layout reproduces the bytes on disk, the appearance was authored by something other than pdfcer, and re-baking replaces it. set-text-annot-style now prints was_foreign=1 in that case rather than overwriting a designer's stream in silence.

Changing a sticky note's colour rewrote its icon

§12.5.6.4 lists seven icon names and then says "Additional names may be supported as well", so a producer's own icon name is conforming — and pdfcer rewrote it to /Note when an operator changed the note's colour. Somebody else's content, altered by a control that says nothing about icons.

StickyIcon::Other now carries the name verbatim. This costs nothing in the drawing: pdfcer paints the same glyph for all seven icons, so an unmodelled name renders exactly as a modelled one.

Breaking (library consumers only, one day wide)

Both were made public in 0.44.0, yesterday:

  • StickyIcon is no longer CopyOther owns its bytes.
  • StickyIcon::name() takes &self and is no longer const.

Also

rotate-annotation's help and two doc comments claim "the artwork does not grow". That claim is flagged as under investigation, because the operator reported the opposite — the object grows with each application of the tool. It is correct for a single rotation of an unrotated annotation; the repeated case is being measured. Flagged rather than deleted, because a disclosure that quietly disappears is worse than one that says it is in doubt.

Full detail in docs/ROADMAP.md (Pass 253.5).