[Poppler-bugs] [Bug 63963] pdftops - some fonts are encoded incorrectly in level2 postscript

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63963

--- Comment #7 from William Bader <williambader at hotmail.com> ---
I had a similar problem in https://bugs.freedesktop.org/show_bug.cgi?id=96644 ,
and I am close to a patch to fix it.
I think that FoFiTrueType.cc should remember how many glyphs it writes.
When PSOutputDev builds the resources, it can build a hash with the font name
and the number of glyphs.
Then when PSOutputDev drawString builds the output string, if it can find the
number of glyphs in the hash and if a code exceeds the last valid glyph, it can
increment the last pair of values in the dxdy array by dx and dy but otherwise
ignore the code.

The problem is that in PS Level 1 or 2, FoFiTrueType makes a composite font,
but some fonts have a lot of empty positions, so it writes only to the last
used glyph. For example, a font in test.pdf has nGlyphs 1674 but maxUsedGlyph
88. Writing all of the empty glyphs in FoFiTrueType would fix the problem, but
the resulting ps file would be much larger. Then when the ps uses code 2797
(hex AED), it considers 0xA as the index of the composite font, and there will
be enough fonts in the FDepVector. I suppose that unused glyphs have a 0 size
and leave no marks, so the alternative is to remember that the font has only 88
glyphs (actually FoFiTrueType rounds it up to 255) and then ignoring the
attempt to show code 2797 (except for adding in the dx dy). It looks like these
codes are used for alignment. Maybe some applications have poor subsetting
logic that doesn't compact empty glyphs. The PDF in my bug report was made by
'Adobe InDesign CC 2015 (Windows)'.

William

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/poppler-bugs/attachments/20160703/c8975634/attachment.html>