For a few days, David Lamkins and I have been kicking around a problem
in the ]keyb output. Turns out the least tractable of these seems to be
the result of two different utf8 sequences used for the epsilon-underbar
character:
]keyb uses utf8 e2 8b b8, unicode 22f8, "ELEMENT OF WITH UNDERBAR"
]keyb 1 uses utf8 e2 8d b7, unicode 2377, "APL FUNCTIONAL SYMBOL EPSILON
UNDERBAR"
The first of these, U+22f8, doesn't exist in either the FreeMono or
SimPL fonts; I'm guessing that GTK's text engine, pango, is just
grabbing the closest glyph it can find from some other font, which turns
out to be of a different width. U+22f8 isn't in Avec.def.
U+2377 exists in both fonts and corresponds to EPSILON_UNDERBAR in Avec.def.
I'm more or less guessing that the data for ]keyb comes from either
keyboard.dyalog.txt or keyboard1.dyalog.txt, both of which contain the
broken U+22f8 character while ]keyb 1 comes from either keyboard.txt or
keyboard1.txt, both of which contain the working U+2377. No idea, of
course, if these differences are deliberate.
Anyway, the latest push of aplwrap is stable with respect everything
except dealing with these differences in ]keyb output.
Chris Moller
