pdfce v0.13.0 - two conformance patches that were failing for two different reasons

Two conformance patches that were failing for two different reasons

Both carry the same instruction — "No X must be visible when rendered
correctly" — and both showed an X. The causes had nothing to do with each
other, which is why they took two fixes.

1. The same palette, applied twice

A JPEG 2000 image can carry a colour lookup table inside the image file, and
the PDF around it can declare one too. This document had both, holding
identical bytes.

pdfce applied both. The first turned the samples into a colour; the second
then read that colour as if it were a position in the table, looked for
entry 114 in a table with one entry, found nothing, and painted black.

Apply either table alone and the answer is correct. Applying both is the only
way to be wrong — which is exactly why a conformance suite ships the pair.

2. Ink converted to screen colour and back, for no reason

A page destined for print composites in ink. Handed an image whose samples
were already ink, pdfce converted it to screen colour and straight back
again on the way in.

★ And no better conversion would have fixed it. Ink→screen is
many-to-one — a rich black and a plain black look identical on a monitor — so
there is no way back. The fix is not to make the trip.

CMYK images now carry their ink all the way to the compositor. 17 of 51
conformance patches keep their ink where they previously converted it; six
go from thousands of converted pixels to zero.

That includes images whose colour is stored as a one-entry palette, which is
how flat colours normally ship in print files — and which is why the first
attempt at this fix changed nothing at all.

★★ What this is not

Neither patch passes because pdfce's colour matches Acrobat. It doesn't.

	square (drawn as a path)	the image
pdfce, before	(238, 29, 35)	(225, 63, 50)	X visible
pdfce, now	(238, 29, 35)	(238, 29, 35)	X gone
Acrobat	(227, 0, 11)	(227, 0, 11)

pdfce now agrees with itself, which is precisely what these patches test.
It still does not agree with Acrobat, because ICC colour profiles are not
applied — that is a separate, known gap and it is unchanged here.

A self-consistency test passing is not a colour-accuracy claim, and this
release does not make one.

Also corrected: a gap that turned out not to exist

While preparing this release, per-image overprint was going to be built next.
Reading the specification first showed most of it must not be: the table
governing overprint scopes its per-component rule to colours "not in a
sampled image", so for an image the conforming behaviour is to paint it
normally — which pdfce already did.

Our own documentation said the opposite in four places, one of them a heading
telling readers the fix was impossible. All four are corrected. What remains
genuinely outstanding is narrower and is now named precisely.

One change that is not additive

A CMYK image on a print-destined page now composites to different pixels
than in v0.12.0 — correctly, but differently. If you compare renders
byte-for-byte against the previous release, you will see it. The
cmyk_bridged_pixels diagnostic has also changed meaning and reads much lower
on print files; a companion cmyk_native_image_pixels is new.

---

Windows x64, single folder, no installer, no registry writes. Extract and run
pdfce-gui.exe or pdfce-cli.exe. MIT licensed; third-party attributions and
the OCR model weights' own provenance ship in the folder.