Am 22.10.2010 22:37, schrieb Tor-Einar Jarnbjo:
The problem is when using a font with combined diacritic marks (e.g. Junicode, http://junicode.sourceforge.net/). When rendering a simple PDF containing just the character 'ü', the embedded font will contain the glyphs for space, '-', 'ü', '¨' and 'u'. I'm not sure where the space and the hyphen come from, but the mismatch is caused by the additional glyphs '¨' and 'u', because these are not counted when generating the CIDSet field.
I'll answer myself on this one, as I've found the exact reason for this behaviour. When writing the actual font file ("FontFile2"), the TTFSubSetFile#readFont method is invoked with the "usedGlyphs" map from the font's CIDSubset instance. Within the readFont method, a copy of this map is made and later passed to the scanGlyphs method, in which additional glyphs may be added. In my example, the original map contained the glyph for 'ü' and the scanGlyphs method extended the map with the glyphs for '¨' and 'u'. Since we're working on a copy of the original map here, the font's CIDSubset instance is not aware of these additional glyphs.
Later, when the "CIDSubset" entry is created, the original map from the font's CIDSubset is used to check which glyphs are included in the subset, causing the additional composite glyphs to be ignored.
I've implemented an ugly hack to pass around the additional glyphs in a Set, so that the glyphs are known to the font's CIDSubset later. It fixes the validation problems, but I don't think it's a very pretty solution. Why is it necessary to operate on a copy of the "usedGlyphs" map, when the new glyphs are determined?
Do you perhaps want me to write an issue on this in Bugzilla? I am pretty sure that the font file generation is correct (the separate composites are indeed required in the font file) and that their indexes simply have to be included in the CIDSubset entry.
Regards, Tor --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
