Re: [NTG-context] [***SPAM***] Incorrect internal font processing
On Wed, Nov 27, 2013 at 11:35:01PM +0100, Jan Tosovsky wrote:
On 2013-11-27 Jan Tosovsky wrote:
On 2013-11-27 Hans Hagen wrote:
On 11/27/2013 10:20 PM, Jan Tosovsky wrote:
On 2013-11-27 Hans Hagen wrote:
On 11/27/2013 9:53 PM, Jan Tosovsky wrote:
On 2013-11-27 Hans Hagen wrote: > On 11/27/2013 8:44 PM, Jan Tosovsky wrote: >> >> during my attempts to patch the Palatino's dotless 'i' I found >> that this font is parsed incorrectly by ConTeXt. >> >> Comparing index/name info of individual glyphs in the font >> software and resulting pala.tma file there is the following >> difference: >> >> Index | Name - font | Name - tma >> 1110 | dotlessi.smcp | i.sc (1) >> 1170 | i.smcp | i.sc (2) >> >> The first one should have IMHO a different name. >> The same name for two glyphs might be dangerous. >
the fact that there are two i.sc in the font is suspicious ... best check the font in fontforge ... one never know what kind of things other programs do
Hmm, FontForge glyphs naming corresponds to what we can observe in the ConTeXt (doubled i.sc). My previous analysis was based on FontLab. I am confused now...
Actually, there are no names of these glyphs available in the font so they are calculated(!)
Right, the font (like many MS fonts) uses version 3 ‘post’ table which includes no glyph names at all, software that needs glyph names (e.g. LuaTeX, since you can’t embed a font is PDF without glyph names else printers would go nuts) have to generate it. Some software will use dump names; glyph1 etc. using glyph id, others will try to guess more sensible names from the OpenType layout tables.
Each of two programs uses a different method. FontLab method is based on layout tables - GPOS, GSUB, GDEF (it somehow detects that both glyps differs). The FontForge method is unclear and seems to be buggy.
FontForge uses the layout tables, too, but this font has a catch, it has two <i> → <some glyph> substitutions in the ‘smcp’ feature, one to a dotted small cap for Turkish (under TRK tag) and a regular one, and FontForge just names the resultant glyph ‘i.sc’ in both cases since it does not seem to check for duplicates, thinking that only one such a substitution can happen per feature. LuaTeX uses a (subset of) FontForge internally, so you get the same bug. It is not clear to me how FontLab arrived to the dotlessi name from the GSUB table, but I need to look into the font a bit more closer. Regards, Khaled
On Sun, Dec 01, 2013 at 11:21:30AM +0200, Khaled Hosny wrote:
It is not clear to me how FontLab arrived to the dotlessi name from the GSUB table, but I need to look into the font a bit more closer.
Interestingly, after I patched Sorts Mill (a FontForge fork) to avoid duplicates[1] I ended up with a ‘dotlessi.sc’ glyph, as it turns out the font has a <dotlessi> → <regular smallcap i> later on, so that is where FontLab gets the glyph name, too. I’ll try to port this patch to LuaTeX later. Regards, Khaled [1] https://bitbucket.org/sortsmill/sortsmill-tools/commits/a7fdc1cd13d94659fe90...
On 2013-12-01 Khaled Hosny wrote:
On Sun, Dec 01, 2013 at 11:21:30AM +0200, Khaled Hosny wrote:
Interestingly, after I patched Sorts Mill (a FontForge fork) to avoid duplicates[1] I ended up with a ‘dotlessi.sc’ glyph, as it turns out the font has a <dotlessi> → <regular smallcap i> later on, so that is where FontLab gets the glyph name, too.
I’ll try to port this patch to LuaTeX later.
Thanks for handling this! When can I expect this fix in luatex.dll updated on my local machine using the first-setup script? Will it be in any following minor 0.77 update or in 0.80 later this year? Jan Btw, FontForge could be patched as well ;-)
participants (2)
-
Jan Tosovsky -
Khaled Hosny