Skip to content
This repository was archived by the owner on Sep 3, 2026. It is now read-only.

pdfce v0.10.0 - text that was a blank page

Choose a tag to compare

@KenM76 KenM76 released this 25 Aug 21:11
· 415 commits to main since this release

Text that was a blank page

Some PDFs define their letters as little drawing programs rather than as a
font file — one content stream per glyph. The standard calls them Type 3
fonts, and they turn up in old TeX and dvips output, in prepress and CAD
exports, and in anything converted from a bitmap font.

pdfce recognised them, counted them, and drew nothing. If a page used one, the
text simply was not there.

They render now — both flavours the standard allows: glyphs drawn with path
operators, and glyphs drawn as a 1-bit stencil (ISO 32000-1 §9.6.5, Tables 112
and 113). Both routes a font can reach a page by — the Tj family and a
shading-pattern fill — go through the same code.

Measured, not asserted: all 49 files in the test corpus that carry a Type 3
font now render, with no glyph unaccounted for. One of them draws a heading
that was an entirely blank page before this release.

The rule that decides every glyph's colour

A Type 3 glyph declares, in its own first operator, whether it specifies its
shape and its colour or only its shape. In the second case the standard
says any colour the glyph sets for itself "shall be ignored" and the glyph
takes the colour of the surrounding text.

No public source established whether Acrobat actually obeys that — so a probe
was built and run in Acrobat before any of this was written. It obeys: the two
declarations produce opposite colours from identical instructions. pdfce
follows the clause knowing the clause and Acrobat agree.

Getting this backwards would paint every glyph of a colour-setting font the
wrong colour, on every page, in a way that looks deliberate.

Bitmap glyphs are stencils, and stay stencils

A bitmap Type 3 glyph is a region of the page to be painted, not a picture to
be resampled — so pdfce never smooths one, at any zoom. Acrobat does not
either; it is what drove the old practice of converting TeX Computer-Modern
fonts to Type 1. Verified across a 64× zoom range, on both sides of the point
where the image switches between being shrunk and being enlarged.

Three new things pdfce-cli render-page will tell you

  • type3_glyphs — how many glyphs were drawn by running a program rather than
    by looking up a shape.
  • type3_glyphs_missing — a character was shown whose glyph does not exist in
    the file. The spacing still happened, so this counts letters that are
    absent, never text that has moved.
  • type3_colors_ignored — how many colour instructions pdfce deliberately
    dropped, under the rule above. Not a shortfall: it is what the standard
    requires. It is reported because anyone debugging a glyph that came out the
    "wrong" colour deserves to be told the instruction they can see in the file
    was dropped on purpose rather than missed.

What is not in this release

Searching and copying text set in a Type 3 font. A Type 3 glyph name means
nothing on its own, so extraction depends on the file carrying a /ToUnicode
map — a separate capability from drawing, and one Acrobat is equally dependent
on. Named here rather than left to be discovered.

Getting it

pdfce-v0.10.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.