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 ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
