diff options
author | Chris Liddell <chris.liddell@artifex.com> | 2021-11-04 08:35:08 +0000 |
---|---|---|
committer | Chris Liddell <chris.liddell@artifex.com> | 2021-11-04 08:35:08 +0000 |
commit | 6dd05a013f66a9322f92f62fd2d46be9bfa82097 (patch) | |
tree | 07d3d9d6aefbb102170065899d077ab081527ecb /configure.ac | |
parent | c1e51c99bbbc1c92b24019c5720ed15c1955dfb2 (diff) | |
download | ghostpdl-6dd05a013f66a9322f92f62fd2d46be9bfa82097.tar.gz |
Handle non-Encoded glyphs in TTF properly (pdfi/pdfwrite)
For TrueType fonts, pdfwrite "scans" the font twice, once to pick up
glyphs with glyph names, and a second time to find *all* the glyphs,
whether they have names associated with them or not.
pdfi was handling the former case correctly, but in the second pass
it wasn't correctly spotting that we weren't even interested in
glyph names (even if they exist) - i.e. the index we were given was
a gid and not a name index.
With gpdf, and an almost empty name table, this was (relatively) benign,
almost always meaning we'd just fail to find an associated name, and
give up on that glyph. But with pdfi called from gs, using the much
more populous Ghostscript name table, we'd almost always find a name
at the requested index, but that name would almost certainly have no
connection to this, or any, font.
It would then drop into the slowest, "fall back" case of simply linear
searching the TTF post table to match the name to a gid - searching a
fully populated post table for a non-existent name for every glyph in
a font would end up being extremely slow.
Plus, although the resulting output PDF would render correctly, it would
likely not be correct if pdfwrite were configured *not* to subset fonts, since
we'd end up ignoring any glyphs lacking names.
Diffstat (limited to 'configure.ac')
0 files changed, 0 insertions, 0 deletions