incorrect/absent PostScript names for some greek characters
Dear Hans and All, in char-def.lua there are no "adobename" for "greekDelta" AKA "GREEK CAPITAL LETTER DELTA" "greekOmega" AKA "GREEK CAPITAL LETTER OMEGA" "greekmu" AKA "GREEK SMALL LETTER MU" because adobenames Delta, Omega and mu are used for "INCREMENT", "OHM SIGN", "textmu" AKA "MICRO SIGN". While the issue is of infinitesimal and only potential significance, may be it is worth a fix. The problem likely comes from Adobe Glyph List http://www.adobe.com/devnet/opentype/archives/glyphlist.txt The sub-optimal mapping was fixed in the latest version of Adobe Glyph List For New Fonts http://www.adobe.com/devnet/opentype/archives/aglfn.txt but not in the main Adobe Glyph List. Both lists are referenced from http://www.adobe.com/devnet/opentype/archives/glyph.html BTW, the Adobe Glyph List also has "increment", "Ohm" and "mu1" that look like better candidates for "INCREMENT", "OHM SIGN", "textmu" AKA "MICRO SIGN". Sincerely, Michail
Michail Vidiassov wrote:
Dear Hans and All,
in char-def.lua there are no "adobename" for "greekDelta" AKA "GREEK CAPITAL LETTER DELTA" "greekOmega" AKA "GREEK CAPITAL LETTER OMEGA" "greekmu" AKA "GREEK SMALL LETTER MU"
because adobenames Delta, Omega and mu are used for "INCREMENT", "OHM SIGN", "textmu" AKA "MICRO SIGN".
While the issue is of infinitesimal and only potential significance, may be it is worth a fix.
I am not so sure a fix is needed. At the moment, the only for "adobename" is inconjunction with Type1 fonts. Fonts using the new Agl you referenced below will likely be OTFs. For those the name is irrelevant, while on the other hand 'fixing' the names may break usage with older fonts. Best wishes, Taco
Dear Taco, On Mon, 12 May 2008, Taco Hoekwater wrote:
in char-def.lua there are no "adobename" for "greekDelta" AKA "GREEK CAPITAL LETTER DELTA" "greekOmega" AKA "GREEK CAPITAL LETTER OMEGA" "greekmu" AKA "GREEK SMALL LETTER MU"
because adobenames Delta, Omega and mu are used for "INCREMENT", "OHM SIGN", "textmu" AKA "MICRO SIGN".
While the issue is of infinitesimal and only potential significance, may be it is worth a fix.
I am not so sure a fix is needed. At the moment, the only for "adobename" is inconjunction with Type1 fonts. Fonts using the new Agl you referenced below will likely be OTFs. For those the name is irrelevant, while on the other hand 'fixing' the names may break usage with older fonts.
The bug bit me some time ago (not in context context, but with pdftex) when the glyph-to-unicode map embedded into PDF document was flawed in this way and thus export to plain UTF text and searching were broken. When AGL is used to map from adobe glyph names to Unicode I do not see how things can potentially be broken by the proposed fix, but if the Type1 fonts support is considered frosen, then there is a point in not touching it unless it is something really severe, what my issue definetely is not. Sincerely, Michail
The list is mostly used when LuaTeX tries to assign unicode slot from glyph name. It would indeed make sense to have even more than a single name for every unicode slot, for example both dbar & dcroat (the first one that comes to my mind) poiting to the same unicode slot, with drcoat having priority in case that both names are present in font. No, the names are not frozen I guess. I have generated some list years ago, and I guess that Hans simply took that list to generate char-def.lua. Fixes are probably still welcome. Adding an unexisting name to an empty slot cannot break break anything, I guess. Mojca
participants (3)
-
Michail Vidiassov -
Mojca Miklavec -
Taco Hoekwater