[NTG-context] [***SPAM***] Incorrect internal font processing

Khaled Hosny khaledhosny at eglug.org
Sun Dec 1 10:21:30 CET 2013


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


More information about the ntg-context mailing list