Problem running mapl in xterm on Ubuntu

[David Lamkins]

Just to try to get some closure on the question of appropriate FreeType (TrueType) fonts, I did a bit more experimenting tonight.

I found the virtual fonts to be quite variable in their coverage, depending upon the chosen font size.

FreeMono seems to be a good choice, as does APL385. Both of these seem to cover all of the Dyalog APL characters over a variety of sizes.

[Geoff|Dyalog]

OK I will try to do this. There is something strange going on. If this was just at the xkb level then that character should not work anywhere. It does work in Konsole, gnome-terminal, Firefox, ... . There have been changes in the libraries that are used to access xkb's facilities. I suspect that some programs are using an old library. Nevertheless, that still implies that different programs are invoking different compilers for xkb. I would have expected one compile and a cache of the output. In addition the keyboard should be X server side and the programs are X client side.

[Geoff|Dyalog]

I changed overbar to macron on my machine (Kubuntu 12.04). Pushed it through a reboot - which is excessive, but certain. I still have the same problem in opera and xterm. Still works in Konsole etc. The "overbar" comes from keysymdef.h. "macron" is there as well. This is the right place to look according to Doug Palmer: "An Unreliable Guide to Xkb Configuration" which, admittedly dates from 2004. Could I ask for the experiment to be repeated please. I don't want to submit an unnecessary change to the xkb support. I will do some experiments on Fedora and OpenSuSe but not until tomorrow.

[David Lamkins]

I installed the x11proto-core-dev package to get /usr/lib/X11/keysymdef.h .

This is interesting...

In the Latin 1 section, I see:

Code: Select all

#define XK_macron                        0x00af  /* U+00AF MACRON */

In the APL secion, I see:

Code: Select all

#define XK_overbar                       0x0bc0  /*(U+00AF MACRON)*/

Unless I misunderstand what I'm reading (which is entirely possible), macron and overbar generate different codes. I believe that the actual difference in the codes is a non-issue, since none of the #defined codes match the U+... in the associated comment. I assume that the keymap compiler is supposed to do something with the #defined code; maybe that "something" is broken for overbar...

Also, overbar as a code point doesn't seem to have any existence in Unicode; its present in keysymdef.h seems to be a special case just for APL. Search for overbar at http://unicode-search.net/ ; you'll see that overbar doesn't appear alone in Unicode 6. (Note, however, that there is an overline character, which is - according to http://en.wikipedia.org/wiki/Overline - distinct from macron.)

Maybe the keysymdef.h file is wrong, or maybe the keymap compiler isn't doing the right thing with the 0x0bc0 code for XK_overbar... I don't know. As I've noted before: I'm out of my depth here; I'm just pointing at stuff that doesn't seem consistent.




One more thing, Geoff. When you tested with the modified /usr/share/X11/xkb/symbols/apl file, did you also remove the /usr/share/X11/xkb/symbols/dyalog_vndr directory?

I installed Opera on my Ubuntu 12.04 system; I can type the macron (<APL><2>) just fine. Also in xterm... There must be something that differs between our installations.

[Geoff|Dyalog]

The only aspect of xkbsymdef.h that is relevant is the XK_somename.

An update: I have now tried out the change from "overbar" to "macron" on Fedora 17 and openSUSE 12.1. Both enabled the use of the key in Xterm. I also checked out my Kubunu 12.04 where it is not working. As far as I can tell I have no remnants of previous xkb work but this is my development box.

I think I now have enough evidence that this is a fix worth having and will make a submission to Xorg. Perhaps they will also have some input on why this affects client side programs differently.

In the meantime - if this issue is troubling you - there is a temporary fix. Edit /usr/share/X11/xkb/symbols/apl and replace "overbar" with "macron" - it will probably work. It also sorts out the trouble I was having with the compose sequences so ¯⊤ now gives ⍑ so I ought to submit a patch to remove the comments from the compose sequences.

[David Lamkins]

Thank you, Geoff.

[jibanes]

I'm having the same exact issue, no glyph appears with <APL>2; the workaround: "Edit /usr/share/X11/xkb/symbols/apl and replace "overbar" with "macron" - it will probably work" Doesn't seem to help; or maybe I missed something.

I'm running debian wheezy.