summaryrefslogtreecommitdiff
path: root/configure.ac
diff options
context:
space:
mode:
authorChris Liddell <chris.liddell@artifex.com>2021-11-04 08:35:08 +0000
committerChris Liddell <chris.liddell@artifex.com>2021-11-04 08:35:08 +0000
commit6dd05a013f66a9322f92f62fd2d46be9bfa82097 (patch)
tree07d3d9d6aefbb102170065899d077ab081527ecb /configure.ac
parentc1e51c99bbbc1c92b24019c5720ed15c1955dfb2 (diff)
downloadghostpdl-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