an X11 keyboard layout for scholars of old germanic

Diss,how-to,Linguistik,Linux,Uni,VGS — 21. Nov 2009

as an historical linguist dealing with old germanic languages, i need a convenient way to input special characters on my computer. since I want to be able to use these characters across all my applications (text editor, office suite, email-client, browser), a per-application solution is not a good idea. a better approach is to change the keyboard layout system wide. luckily, this can be achieved easily on a linux system by customizing one of the predefined X11 keyboard layouts. in my case, i came to the conclusion that it was best to modify the existing keyboard layout definition for us-english (called “us”) by adding a new “layout variant“, which i decided to call “altgr-gmc”. as you can see, every key is bound to four different characters. the characters on the right side of every key can be accessed by using AltGr (bottom right) and AltGr+SHIFT (top right) as modifiers.

here’s what i came up with (click for a larger image):
altgr-gmc keyboard layout

the distribution of characters across the keyboard is somewhat arbitrary, though i tried to keep compatibility to “altgr-intl” if possible, and i strived to make the rest as intuitive as possible (r-sounds on the r-button, combining diacritical mark for a stroke below on the hyphen-button, since it sort of looks like a little rotated hyphen etc.).

if you want to give it a try, follow these instructions (root permissions required for all steps):

  1. adding the new layout variant
    open the file /usr/share/X11/xkb/symbols/us and append these lines at the end of it.
  2. enabling it in X11
    edit /usr/share/X11/xkb/rules/evdev.xml and add the following lines at a suitable position (e.g. after the entry for “altgr-intl”):

            <variant>
              <configItem>
                <name>altgr-gmc</name>
                <description>for Old Germanic</description>
                <languageList><iso639Id>eng</iso639Id>
                              <iso639Id>fra</iso639Id>
                              <iso639Id>ger</iso639Id></languageList>
              </configItem>
            </variant>

    you may also want to make a corresponding change in /usr/share/X11/xkb/rules/evdev.lst for consistency’s sake (it doesn’t seem to be required).

  3. setting it as system default
    open /etc/default/console-setup update: /etc/default/keyboard and set XKBVARIANT to “altgr-gmc”. make sure that the variable XKBLAYOUT points to the file that you modified in step 1 (“us”)
  4. restart your computer

(this was all done on a xubuntu 9.10 system. should also work on any other recent ubuntu installation.)

if you want this to take effect immediately, load it up like this: setxkbmap us -variant altgr-gmc.

a few problems remain, mostly related to the handling of combining diacritical marks. contrary to my initial plans, i ended up refraining from the use of “dead keys” in favour of using combining diacritical marks throughout. this happened for consistency’s sake. in general, i prefer to use precomposed characters (which is what the “dead keys” give you), but since precomposed characters are not available for all the desired combinations, it’s unavoidable to use combining diacritical marks in some cases, and because of that it seemed better to me to use the latter throughout. of course it would be best to have a “fall back strategy”, so that precomposed characters will be used whenever possible, and combining diacritical marks elsewhere. such a solution doesn’t seem possible currently, however, since you can only use a key either as a “dead key” (which will give you no character at all in the case that you choose an unavailable combination) or to have it produce a combining diacritical mark.

a second thing that’s been irritating me is that the handling of combining diacritical marks seems to be very inconsistent across applications and fonts. strangely, changing the font of my text editor does not only change the way the marks are displayed in the editor window (sometimes combined, sometimes simply next to each other), but it can also (in some cases) change the order in which i need to input the base letter and the modifier: depending on the current font, i sometimes have to type the diacritical mark before and sometimes after the letter i want to modify… isn’t that odd?

another issue is that stacking diacritical marks is messy. often, the marks will end up being superimposed on each other instead of being stacked. it’s basically a matter of trial and error to see what will work and what won’t :(

so here’s a sample of what you can do with “altgr-gmc”, including some fancy (but not always neatly typeset) stacked diacritical marks:

altgr-gmc-sample

links:
http://people.uleth.ca/~daniel.odonnell/Blog/custom-keyboard-in-linuxx11
http://www.mufi.info/ Medieval Unicode Font Initiative
http://unicode.org/charts/
http://unicode-search.net
http://en.wikipedia.org/wiki/Unicode

how to remove black borders from a PDF

how-to,Linux,Uni — 21. Jul 2009

our copy machines at the university can scan documents and send them to an email address. how convenient! however, when you scan pages from a book, the page-size will most likely not match the exact size of an A4 paper, resulting in a PDF document that has black borders on the side and/or the bottom. this is bad, because printing these pages later will waste a lot of ink. that’s why i’ve been looking for an easy way to crop PDF documents on linux, and i’ve finally found out how to do this:

pdfcrop –margins ‘0 0 0 -50’ –clip report.pdf

this will remove 50 bp from the bottom of every page of the PDF.

on my distro, pdfcrop is provided by the package ‘texlive-extra-utils’, so you’ll need to install this if you don’t have it already.

texworks and the synctex feature

LaTeX,Linux — 13. May 2009

i have recently learned about texworks, a project started by jonathan kew to come up with an easy-to-use pdf-centric cross-platform latex editor. a praisworthy effort, imho. the feature that i am most excited about is the synchronisation of source file and pdf with the help of a technology called synctex. what this does is that it allows you to jump from some point in the source file to the corresponding point in the pdf, and vice versa. in my opinion, this is a real killer-feature! navigating through (large) documents is a problem in traditional latex editors, because it is so easy to get lost in the source file. if it is possible to navigate through the PDF instead, and then simply click somwhere to make an edit at that position, it makes life much easier.

unfortunately, it does not look like i will be able to use this feature any time soon. while texworks itself is already in a usable state, and someone has kindly prepared packages for ubuntu, the “synctex” feature does depend on texlive 2008, and it does not look like we will get this in ubuntu any time soon. in fact, the debian tex maintainers are still in a very early phase of integrating texlive 2008, and it does not look likely that it will be in “debian unstable” early enough to get included in the karmic release of ubuntu (9.10). and what’s more, i’ve just seen that texlive 2008 might never make it into debian at all, because the debian tex maintainers are considering to jump to texlive 2009 directly. in that case, we could hope for it at the earliest in karmic+1, i.e. the spring 2010 release of ubuntu.

i could of course install texlive 2008 from upstream, but frankly, i don’t think it’s a good idea. tex is very, very complex, and it makes much more sense to wait for the “official” packages instead of tinkering with it myself and risking major breakage. my experience with installing non-trivial applications from outside the package repository have been less than optimal. just the thought that i’d have to manually update it afterwards is enough to discard the idea.

so for the moment i’m stuck with texlive 2007. no choice but to wait, it seems… :(