pdfce v0.9.0 - gradient meshes draw

Gradient meshes draw

pdfce could already paint the two simple gradient kinds — the straight-line and
circular ones. The other four, where the gradient's shape is stored as a packed
grid of triangles or curved patches rather than as a formula, it recognised,
counted, and refused. On a page that used one, you got nothing where the
artwork belonged.

All four now render: ShadingType 4 (free-form Gouraud triangle meshes),
5 (lattice-form), 6 (Coons patches) and 7 (tensor-product patches),
ISO 32000-1 §8.7.4.5.5–.8. Both ways a shading reaches a page — the sh
operator and a PatternType 2 fill — go through the same decoder.

This is what an Illustrator gradient mesh is made of, and it is what the
prepress conformance suite pdfce measures itself against tests in its
shading patch.

How well

That patch pairs every live shading with a bitmap of what a correct render
produces, and prints its own criterion on its face: "The shadings should look
like the reference image." So it can be scored with no external reference at
all. Correlation of each shading against its own reference image:

cell	before	after	Acrobat, same file
type 7 mesh	−0.044	0.949	0.981
type 3 (already worked)	0.9985	0.9985	0.9979
type 2 (already worked)	0.9997	0.9997	0.9998
type 7 mesh	−0.044	0.997	0.997

The second mesh cell now matches its reference more closely than Acrobat's own
render of the same file does.

The small remaining gap on the first cell is not the mesh. pdfce's mesh
differs from Acrobat's mesh by the same amount pdfce's plain photograph on
that page differs from Acrobat's plain photograph — 26.5 versus 29.6. The
reference image contains no mesh at all, so what is left is the CMYK-to-screen
colour table, which belongs to a different part of the pipeline and is already
being worked on elsewhere.

The parts that are pdfce's choice rather than the standard's

The standard leaves two things open here, and they are handled differently on
purpose.

How finely a curved patch is approximated is unspecified, and the
smoothness tolerance the standard does define bounds colour error rather
than geometric deviation. pdfce picks the density from the patch's size on
screen, so it refines as you zoom in. That is deliberately not a setting: the
right value is a function of zoom, and a knob nobody can set correctly is worse
than no knob.

Where one patch record ends and the next begins, when the packed fields do
not land on a byte boundary, genuinely has two defensible readings — the
standard states the rule for a vertex and a patch has no vertices, and
ISO 32000-2 repeats the sentence unchanged, so it will not be settled by a
later edition. That one is a setting: mesh_patch_padding, defaulting to
the reading under which the standard's own cross-reference has any content.
Every mesh measured so far reads identically either way.

Also in this release

• Three new machine-readable counters on pdfce-cli render-page —
  mesh_records, mesh_truncated, mesh_unusable — and a named reason for
  every mesh pdfce declines. A shading that cannot be drawn says why.
• A truncated mesh stream paints the records that were complete and reports
  the discard, rather than refusing the whole shading.
• A fuzzing target for the mesh stream decoder: 1,107,957 runs, no crash.
• The tooling that keeps this project honest got two repairs of its own — the
  fuzz harness had not linked on Windows since the OCR engine landed, and a
  repository hygiene check could both leak the term it was meant to suppress
  and miss files written moments earlier.

Getting it

pdfce-v0.9.0-windows-x64-portable.zip — unzip anywhere and run
pdfce-gui.exe. No installer, no registry writes, nothing outside the folder;
your settings land in userdata/ beside the binaries. pdfce-cli.exe is a
first-class scriptable CLI, not a debug tool — start with --help.

MIT licensed. Third-party attribution ships in the folder and is generated,
never hand-written.