On 10/28/2010 04:59 PM, Hans Hagen wrote:
if the font is okay, accessing by glyph name will work ok
The font is an 8-bit encoding-indexed Macintosh Roman font presenting itself as TrueType, and that is why it is so confusing. Because the font says it is in MacRoman encoding, and the glyph names are pointless affairs like /c140 (which is the king symbol) instead of sane names, fontforge takes that the '140' part of the name is a decimal code point in MacRoman encoding. This is correct behavior on fontforge's part, but it means that the Unicode remap becomes slightly messy, as /c140 maps to 'LATIN SMALL LETTER A WITH RING ABOVE'., and the glyph named /c229 (which is in fact the aring symbol) maps to 'LATIN CAPITAL A WITH CIRCUMFLEX', and /194 (which is the Acirc) maps to 'NOT SIGN', etc. etc. In short: the font's glyph naming is anemic. Now, it appears that luaotfload produces a rubbish .lua file, probably because it dumps both the MacRoman and the Unicode assignment at the same time as a merged table. That is a bug, but that is an issue for the luaotfload maintainers, not something for the context mailing list. In context itself, \char140 actually and correctly produces the king symbol. Incidentally, in context, you can get a dump of the actually used unicode slots by running: \starttext \showfont[PIRAT.TTF][all] % grid table \stoptext or \usemodule[fnt-10] \starttext \ShowCompleteFont{PIRAT.TTF}{12pt}{1} % number&names table \stoptext Now, about fixing it: I don't think there is much you can do with a feature file in this case. If you want to make glyph (name) changes, it is better to do so in the actual font file, because the fea file will get hopelessly confusing. (and it will be specific to this particular font file anyway), and more importantly: if you use a fea file, you will keep hitting that luaotfload bug. So either clean up the font yourself, or report a luaotfload bug and wait for it to be fixed ... Best wishes, Taco