Problem running mapl in xterm on Ubuntu
17 posts
• Page 1 of 2 • 1, 2
Problem running mapl in xterm on Ubuntu
When I run in xterm under Ubuntu, the <APL><2> key seems to get swallowed by xterm. IOW, no glyph (high-minus expected) is echoed to the screen. So far as I can tell, the keystroke has absolutely no effect on xterm. <SHIFT><APL><2>, and indeed all other key combinations, seems to be OK.
The <APL><2> keystroke works fine in all other applications, producing the expected high-minus glyph.
I'm able to run mapl in gnome-terminal, so the problem with xterm is not a show-stopper. On the other hand, I'd like to be able to use the Apl385 font but have been unable to do so in gnome-terminal.
To the best of my knowledge, the OS does not grab <APL><2> as a hot key. (And besides, only xterm is affected...)
I've been wrestling with this on and off for several weeks and am no closer to a solution than I was when I began. Clues will be graciously accepted.
Edited to add:
The use of gnome-terminal is a passable workaround. However, it'd be much preferred to use xterm since gnome-terminal provides no way to select a font (or indeed, to configure most of the terminal's options) from the command-line.
The <APL><2> keystroke works fine in all other applications, producing the expected high-minus glyph.
I'm able to run mapl in gnome-terminal, so the problem with xterm is not a show-stopper. On the other hand, I'd like to be able to use the Apl385 font but have been unable to do so in gnome-terminal.
To the best of my knowledge, the OS does not grab <APL><2> as a hot key. (And besides, only xterm is affected...)
I've been wrestling with this on and off for several weeks and am no closer to a solution than I was when I began. Clues will be graciously accepted.
Edited to add:
The use of gnome-terminal is a passable workaround. However, it'd be much preferred to use xterm since gnome-terminal provides no way to select a font (or indeed, to configure most of the terminal's options) from the command-line.
- David Lamkins
- Posts: 21
- Joined: Sun Aug 26, 2012 7:08 am
Re: Problem running mapl in xterm on Ubuntu
One more bit of information:
It just occurred to me to try xterm without mapl. Same result: the <APL><2> key doesn't produce a glyph or any other detectable effect. For example, the keystrokes <l> <APL><2> <s> gives me a directory listing; the <APL><2> key has absolutely no effect.
So it seems the problem is either within xterm or some interaction between the APL keyboard setup and xterm (but not gnome-terminal)...
It just occurred to me to try xterm without mapl. Same result: the <APL><2> key doesn't produce a glyph or any other detectable effect. For example, the keystrokes <l> <APL><2> <s> gives me a directory listing; the <APL><2> key has absolutely no effect.
So it seems the problem is either within xterm or some interaction between the APL keyboard setup and xterm (but not gnome-terminal)...
- David Lamkins
- Posts: 21
- Joined: Sun Aug 26, 2012 7:08 am
Re: Problem running mapl in xterm on Ubuntu
I'm continuing to dig into this...
If I run xev and observe what happens when I press various keys, I see that pressing <APL><2> does not return an XLookupString or XmbLookupString value. This suggests to me that the translation tables (or even the underlying code) may be in error.
I found this post from Geoff Streeter regarding FreeDesktop support for composed APL characters:
https://bugs.freedesktop.org/show_bug.cgi?id=44059
The above post is in regard to the /usr/share/X11/locale/en_US.UTF-8/Compose file.
Although the current issue seems unrelated to composition, there may be a connection as suggested by Geoff's comment:
Geoff, BTW, is identified as a contributor to the /usr/share/X11/xkb/symbols/apl file.
Going back to my first post, I'm now wondering whether gnome-terminal may be using a different means to translate keycodes...
I wish I understood this stuff better. I'm going to keep logging my observations here in hopes that someone who groks the underlying mechanisms will take a quick look and say "Aha! Here's how to meke this work..." ;-)
If I run xev and observe what happens when I press various keys, I see that pressing <APL><2> does not return an XLookupString or XmbLookupString value. This suggests to me that the translation tables (or even the underlying code) may be in error.
I found this post from Geoff Streeter regarding FreeDesktop support for composed APL characters:
https://bugs.freedesktop.org/show_bug.cgi?id=44059
The above post is in regard to the /usr/share/X11/locale/en_US.UTF-8/Compose file.
Although the current issue seems unrelated to composition, there may be a connection as suggested by Geoff's comment:
There seems to be a problem with <macron>. I could not get ¯⊤ or ⊤¯ to work.
Also the existing ¯A doesn't seem to work. I tried a Compose files with just
the two lines and that did not work. I tried using <U00af> and that didn't work
either.
Geoff, BTW, is identified as a contributor to the /usr/share/X11/xkb/symbols/apl file.
Going back to my first post, I'm now wondering whether gnome-terminal may be using a different means to translate keycodes...
I wish I understood this stuff better. I'm going to keep logging my observations here in hopes that someone who groks the underlying mechanisms will take a quick look and say "Aha! Here's how to meke this work..." ;-)
- David Lamkins
- Posts: 21
- Joined: Sun Aug 26, 2012 7:08 am
Re: Problem running mapl in xterm on Ubuntu
There is something strange about Macron (U00af). In Opera I can't type it into a text box - I logged a bug a long time ago for that. I wind up pasting it rather than typing it. I also ran into the issue you noticed with regard to compose sequences. I can't get it in Xterm either. I usually use konsole where everything seems to work. If you are wedded to gnome then installing Konsole may be a bit heavy in terms of the amount of KDE on which it depends.
Why the desire to use APL385? It is a solution on Windows where the normal installed fonts have poor support for APL characters. On Linux I just make sure that "freemono" is installed (some distributions have it as standard, some don't). There is a virtual font called "monospace" and "freemono" is one of the fonts to which it maps. Not perfect but the only character that seems to give issues is ⊥ which is rendered at an incorrect width. I think the default font for gnome-terminal is "Monospace" so you should have APL characters without modifying it. Which ones are you missing?
Why the desire to use APL385? It is a solution on Windows where the normal installed fonts have poor support for APL characters. On Linux I just make sure that "freemono" is installed (some distributions have it as standard, some don't). There is a virtual font called "monospace" and "freemono" is one of the fonts to which it maps. Not perfect but the only character that seems to give issues is ⊥ which is rendered at an incorrect width. I think the default font for gnome-terminal is "Monospace" so you should have APL characters without modifying it. Which ones are you missing?
- Geoff|Dyalog
- Posts: 43
- Joined: Wed May 13, 2009 12:36 pm
Re: Problem running mapl in xterm on Ubuntu
I have encountered this problem as well, but I fixed it by editing the key mappings in the vndr file to use the actual unicode value for the high minus rather than the symbolic name.
- arcfide
- Posts: 19
- Joined: Fri Dec 09, 2011 3:53 am
Re: Problem running mapl in xterm on Ubuntu
The key mappings in /usr/share/X11/xkb/symbols/apl, which is the file used on bang up to date Linux distributions, use U00AF and not the name. Still fails in xterm and opera. Interesting that it made a difference for you though.
Linux APL users should know that current distributions - OpenSuse 12.1, Fedora 17, Ubuntu 12.04 ... have apl as a supplied keyboard. What is more of an issue is that the rules for being able to select that keyboard are in /usr/share/X11/xkb/rules/evdev.extras.xml. The keyboard configuration tools for the various desktops take different approaches as to whether they use this file. KDE does, Unity and Gnome 3 don't. If you try to add the apl keyboard and it is not listed this is probably why. To work around it without going the whole hog and changing desktop edit /usr/share/X11/xkb/rules/evdev.xml and include the apl stanza from evdev.extras.xml. Jason is pursuing this as a bug in those desktops that don't support the extras file.
Feedback on whether other desktops support this or not would be interesting - Enlightenment, XFCE, ... anybody?
What has happened to modern Linux distributions is that APL is available both for keyboarding and for font use at the distribution level. You do not need to add anything from Dyalog. It does help if your distribution provides freemono as a font on a default install - Fedora 17 doesn't. This is still not perfect but progress is definitely being made.
APL compose sequences have been accepted by Xorg. I have not yet seen a distribution that issues them.
The apl keyboard has a number of variants. Tim Nelson did the original work to get an apl keyboard into the distributions. I have extended it. The default if you do not change the variant (you get a drop down to do this) is a bare Dyalog keyboard - it has the APL characters but not the commands (Edit, Trace ...) or the line drawing characters. There are variants for STSC, SAX and a few others. Dyalog users should choose "dyalog" which gives the additional keystrokes.
Linux APL users should know that current distributions - OpenSuse 12.1, Fedora 17, Ubuntu 12.04 ... have apl as a supplied keyboard. What is more of an issue is that the rules for being able to select that keyboard are in /usr/share/X11/xkb/rules/evdev.extras.xml. The keyboard configuration tools for the various desktops take different approaches as to whether they use this file. KDE does, Unity and Gnome 3 don't. If you try to add the apl keyboard and it is not listed this is probably why. To work around it without going the whole hog and changing desktop edit /usr/share/X11/xkb/rules/evdev.xml and include the apl stanza from evdev.extras.xml. Jason is pursuing this as a bug in those desktops that don't support the extras file.
Feedback on whether other desktops support this or not would be interesting - Enlightenment, XFCE, ... anybody?
What has happened to modern Linux distributions is that APL is available both for keyboarding and for font use at the distribution level. You do not need to add anything from Dyalog. It does help if your distribution provides freemono as a font on a default install - Fedora 17 doesn't. This is still not perfect but progress is definitely being made.
APL compose sequences have been accepted by Xorg. I have not yet seen a distribution that issues them.
The apl keyboard has a number of variants. Tim Nelson did the original work to get an apl keyboard into the distributions. I have extended it. The default if you do not change the variant (you get a drop down to do this) is a bare Dyalog keyboard - it has the APL characters but not the commands (Edit, Trace ...) or the line drawing characters. There are variants for STSC, SAX and a few others. Dyalog users should choose "dyalog" which gives the additional keystrokes.
- Geoff|Dyalog
- Posts: 43
- Joined: Wed May 13, 2009 12:36 pm
Re: Problem running mapl in xterm on Ubuntu
With regards to setting the keyboard up, There is a feature in Unity/Gnome3 that doesn't show the APL language in the configuration window. I have updated our keyboards post here: http://www.dyalog.com/forum/viewtopic.php?f=20&t=210 with information on how to set this up for newer distributions.
You don't need to edit any files, and shouldn't as updating your system will overwrite changes you've made to them.
Jason
You don't need to edit any files, and shouldn't as updating your system will overwrite changes you've made to them.
Jason
- Jason|Dyalog
- Posts: 22
- Joined: Tue Sep 09, 2008 2:42 pm
Re: Problem running mapl in xterm on Ubuntu
Geoff|Dyalog wrote:Why the desire to use APL385? It is a solution on Windows where the normal installed fonts have poor support for APL characters. On Linux I just make sure that "freemono" is installed (some distributions have it as standard, some don't). There is a virtual font called "monospace" and "freemono" is one of the fonts to which it maps. Not perfect but the only character that seems to give issues is ⊥ which is rendered at an incorrect width. I think the default font for gnome-terminal is "Monospace" so you should have APL characters without modifying it. Which ones are you missing?
Two reasons, actually:
1) I prefer the appearance of that font.
2) On my systems, the virtual font Monospace doesn't seem to have a complete set of glyphs. In particular, I've observed that right-arrow and left-arrow display as "missing character" glyphs.
It's certainly possible, I'd guess, that something in particular about my systems causes the observed problem. My lack of knowledge about how virtual fonts work prevents me from speculating further.
- David Lamkins
- Posts: 21
- Joined: Sun Aug 26, 2012 7:08 am
Re: Problem running mapl in xterm on Ubuntu
Geoff|Dyalog wrote:The key mappings in /usr/share/X11/xkb/symbols/apl, which is the file used on bang up to date Linux distributions, use U00AF and not the name. Still fails in xterm and opera. Interesting that it made a difference for you though.
That's what I see in Ubuntu 12.04 with all current updates.
However, arcfide has provided a pointer to the solution.
As installed on my system, /usr/share/X11/xkb/symbols/dyalog_vndr/apl_group2 maps key <AE02> to overbar. arcfide observed that changing overbar to U00AF resolves the problem. I've confirmed this, and have found that changing overbar to macron also resolves the problem.
Linux APL users should know that current distributions - OpenSuse 12.1, Fedora 17, Ubuntu 12.04 ... have apl as a supplied keyboard. What is more of an issue is that the rules for being able to select that keyboard are in /usr/share/X11/xkb/rules/evdev.extras.xml. The keyboard configuration tools for the various desktops take different approaches as to whether they use this file. KDE does, Unity and Gnome 3 don't. If you try to add the apl keyboard and it is not listed this is probably why. To work around it without going the whole hog and changing desktop edit /usr/share/X11/xkb/rules/evdev.xml and include the apl stanza from evdev.extras.xml. Jason is pursuing this as a bug in those desktops that don't support the extras file.
I was unaware of this. I'll give it a try.
Am I correct in assuming that, if I apply the above edit, I can uninstall dyalog-keyboards.deb ?
- David Lamkins
- Posts: 21
- Joined: Sun Aug 26, 2012 7:08 am
Re: Problem running mapl in xterm on Ubuntu
To answer my most recent question: yes, you can uninstall dyalog-keyboards.deb and use the built-in APL keyboard support on Ubuntu 12.04. The commands I used are:
However, the inability to use <APL><2> to type the high-minus in xterm returns upon uninstalling dyalog-keyboards.deb, which removes the edited /usr/share/X11/xkb/symbols/dyalog_vndr/apl_group2 file that I described above.
Fortunately, the same fix can be applied to the /usr/share/X11/xkb/symbols/apl file. Here's a diff:
The first change (A00AF → macron) is probably not necessary, but I like it for purposes of self-documentation and consistency. The second change (overbar → macron) is certainly necessary.
It seems that the underlying problem all along has been that xkb does not understand overbar. When I look up the unicode names for U+00AF, I see 'apl overbar' and a number of other alternate names, but no overbar.
Is there a chance that someone from Dyalog would vet and submit the patch for the /usr/share/X11/xkb/symbols/apl file?
- Code: Select all
$ sudo apt-get remove dyalog-keyboards
$ gsettings set org.gnome.libgnomekbd.desktop load-extra-items true
However, the inability to use <APL><2> to type the high-minus in xterm returns upon uninstalling dyalog-keyboards.deb, which removes the edited /usr/share/X11/xkb/symbols/dyalog_vndr/apl_group2 file that I described above.
Fortunately, the same fix can be applied to the /usr/share/X11/xkb/symbols/apl file. Here's a diff:
- Code: Select all
$ diff -c apl.old apl
*** apl.old 2012-07-02 23:21:33.000000000 -0700
--- apl 2012-09-25 12:41:17.845229684 -0700
***************
*** 95,101 ****
key <AD11> { [ U2190 ] }; // [: ← -- Leftwards Arrow
key <AE01> { [ diaeresis ] };
! key <AE02> { [ U00AF ] }; // ¯ -- Macron
key <AE03> { [ less ] };
key <AE04> { [ U2264 ] }; // ≤ -- Less-than Or Equal To
key <AE05> { [ equal ] };
--- 95,101 ----
key <AD11> { [ U2190 ] }; // [: ← -- Leftwards Arrow
key <AE01> { [ diaeresis ] };
! key <AE02> { [ macron ] }; // ¯ -- Macron
key <AE03> { [ less ] };
key <AE04> { [ U2264 ] }; // ≤ -- Less-than Or Equal To
key <AE05> { [ equal ] };
***************
*** 418,424 ****
key <AD11> { [ U2190, U235e ] }; // left arrow, quote quad
key <AD12> { [ U2192, U236c ] }; // right arrow, zilde
key <AE01> { [ diaeresis, U2336 ] }; // i-beam
! key <AE02> { [ overbar, U236B ] }; // deltilde
key <AE03> { [ less, U2352 ] }; // downgrade
key <AE04> { [ U2264, U234b ] }; // lesseq upgrade
key <AE05> { [ equal, U233d ] }; // circlestile
--- 418,424 ----
key <AD11> { [ U2190, U235e ] }; // left arrow, quote quad
key <AD12> { [ U2192, U236c ] }; // right arrow, zilde
key <AE01> { [ diaeresis, U2336 ] }; // i-beam
! key <AE02> { [ macron, U236B ] }; // deltilde
key <AE03> { [ less, U2352 ] }; // downgrade
key <AE04> { [ U2264, U234b ] }; // lesseq upgrade
key <AE05> { [ equal, U233d ] }; // circlestile
The first change (A00AF → macron) is probably not necessary, but I like it for purposes of self-documentation and consistency. The second change (overbar → macron) is certainly necessary.
It seems that the underlying problem all along has been that xkb does not understand overbar. When I look up the unicode names for U+00AF, I see 'apl overbar' and a number of other alternate names, but no overbar.
Is there a chance that someone from Dyalog would vet and submit the patch for the /usr/share/X11/xkb/symbols/apl file?
- David Lamkins
- Posts: 21
- Joined: Sun Aug 26, 2012 7:08 am
17 posts
• Page 1 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 1 guest
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group