pdfce v0.16.0 - a colour your file asked for, and a diagnostic that was lying about it

v0.16.0: a colour your file asked for, and a diagnostic that was lying about it

Workspace version 0.15.0 -> 0.16.0. A minor bump: rendered colour changes on
print-destined files, and a new SourceKind variant in pdfce-render.

WHAT AN OPERATOR GETS

If you open a print-ready PDF -- one that declares an output intent, which is
most files that came from a prepress workflow -- pdfce was rendering some of
its colours wrong.

Not subtly. On a measured test page, a green the file specified exactly was
coming out with 40% of its yellow ink missing and a black component invented
from nothing that the file never asked for. It rendered as a duller, bluer
green than any viewer would show you.

The cause: pdfce threw away the exact ink values the file stated and re-derived
them from its own on-screen approximation of that colour. A one-way trip. The
file said "75% cyan, no magenta, 100% yellow, no black" and pdfce painted
something else.

That is fixed. The colour pdfce paints is now the colour the file specified,
and it is closer to Acrobat on every channel.

★ AND THE DIAGNOSTIC THAT SHOULD HAVE CAUGHT IT

pdfce carries a counter whose entire job is to say "this page was composited
from approximations rather than from the ink the file stated". While the above
was happening across 40,000 pixels, that counter read ZERO -- byte-identical to
a page rendered perfectly.

So pdfce approximated and reported that it had not. That is the project's
"never sneaky" rule broken rather than an accuracy gap, and it is why the bug
took six hypotheses and a wrong test to find instead of one render. The counter
now reports honestly, and is verified in both directions -- because a counter
stuck at zero looks exactly like a correct one.

WHAT WAS DELIBERATELY NOT DONE

The one-line version of this fix would have relabelled the colour space as
plain CMYK. That makes the colour correct AND silently changes how overprinting
inks composite on every such file, because that label is the single place the
standard attaches a special overprint rule (§8.6.7, Table 149 Row 1). It trades
a colour bug for an overprint bug, and nothing in the conformance suite would
have caught it.

A separate classification was added instead, which answers the two questions
independently: yes the ink values are readable, no this is not a DeviceCMYK
source. A test exists solely to fail if a future change takes the shortcut.

The change is narrow on purpose: four-component ICC spaces over DeviceCMYK,
outside image samples, only. Every other ICC-tagged space renders exactly as it
did in v0.15.0.

VERIFICATION

conformance suite ..... 51 patches, 6 FAIL / 29 pass / 16 unresolved,
0 render errors -- IDENTICAL to v0.15.0's baseline.
No verdict moved and none should have: the affected
panel already passed its own criterion, which cannot
see colour accuracy.
bash tools/run-gates.sh ......... 28 commands
cargo fmt --all --check / cargo clippy -D warnings clean
portable package built and smoke-tested from a fresh folder

No dependency changes since v0.14.0, so THIRD_PARTY_LICENSES.md is unchanged.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01AcgfF2qoRL3i9NtC9JXRit