ceska klavesnice vs XFree 3.3.1

[Pavel Kankovsky]

kdyz uz jsem tak nemel pres vanoce nic na praci, tak jsem si doma povysil
XFree86 na verzi 3.3.1 a trochu to potyral ve spojeni s pocestenim,
pricemz jsem odhalil nektere zajimave veci, o ktere se s vami ted podelim
(predpokladam, ze nekteri uz je odhalili, ale rozhodne o tom nikdo zatim
nenapsal takovy roman jako ja ;> )

situace je takova, ze (svete div se) jakasi ceska klavesnice je primo
"v krabici" a da se zapnout prikazem "setxkbmap cs" (navrat zpet na stromy
je pres "setxkbmap us"), ovsem je pravda, ze uvedeny zpusob prepinani je
ponekud nepohodlny a navic docela pomaly (na me 486 to zabere nekolik
sekund), takze "obojetna" klavesnice bude asi lepsi (coz lze za
spoluprace extenze XKB udelat celkem snadno--viz XKB-cz-X11R6.3)

po zapnuti ceske klavesnice to sice zacne nejake znaky s nabodenicky psat,
ale pouze ty, co jsou v iso-8859-1: programu je treba dat na vedomi, ze
ma pouzivat iso-8859-2, coz lze udelat nejmene dvema zpusoby
1) LANG=cs nebo LC_CTYPE=cs nebo neco podobneho
2) _XKB_CHARSET=iso8859-2

ovsem ani jeden ze zpusobu neni dokonaly:
metoda (1) funguje pouze u programu, ktere provedou volani setlocale
(neco, ""), metoda (2) zas pouze u programu, ktere si nevytvori vstupni
metodu (input method, dale jen IM) a obecne to stejne neni vhodny
pristup, takze se ji nebudu dale zabyvat

predpokladejme, ze program je spusten s LANG=cs nebo necim podobnym
a zavolal setlocale(), takze se Xlib dozvi o tom, ze ma fungovat cesky
(a v iso-8859-2)

pak nastava zajimavy rozpor: pokud si program nevytvori IM, pak funguji
vsechny "jednoklavesove" ceske znaky (napr. ty v horni rade klaves), ale
nefunguji mrtve klavesy, ovsem pokud si IM vytvori (napr. kdyz je k tomu
donucen pres Xlib-forcedIM), tak funguji mrtve klavesy, ale nefunguji
nektere "jednoklavesove" znaky--jmenovite ty, ktere jsou obsazeny jak
v iso-8859-1, tak v iso-8859-2 (cili jsou to aacute, eacute, iacute,
uacute, yacute, odpovidajici velka pismena a znak paragraf)...
zvlastni co?

zkoumal jsem proc to a prisel jsem na dosti sokujici zjisteni: kdyz
IM interpretuje "keysym" (Xmb/wcLookupString), tak ho (pokud je to
pismeno) prekonvertuje na "compound text" (coz znamena, ze iso-8859-1
znaky necha jak jsou a zbytek prefixuje patricnou escape sekvenci) a cele
se to pokusi prevest na mb/wc string; vtip je v tom, ze u znaku z horni
pulky iso-8859-1 se mu to nepovede, protoze je nedokaze (v kontextu
popsanem souborem /usr/lib/X11/locale/iso8859-2/XLC_LOCALE) nijak
interpretovat--vysledkem je, ze aplikace dostane prazdny string

ovsem kdyz byl znak vytvoren pomoci mrtve klavesy, tak vyse uvedeny
bestialni postup neni aplikovan, protoze je patricny string vzat primo ze
souboru /usr/lib/X11/locale/iso8859-2/Compose (ted ani nevim, jak vlastne
resi rozdil mb/wc...)

moznych reseni je nekolik:
1) asi nejcistsi by bylo naucit Xlib prekladat z iso-8859-1 do iso-8859-2
   (coz ale asi nijak jednoduse nepujde, pominu-li ponekud brutalni
   zpusob, kdyz se prohlasi i horni pulky zminenych kodovani za identicke)
2) v popisu klavesnice je mozno pouzit specialni "keysyms", napr.
   il2_aacute (pouzito v klavesnicich, co jsem videl)
3) doplnit spravnou implementaci problematickych "keysyms" do
   souboru Compose (coz jsem sam vymyslel a vyzkousel a funguje to--
   kupodivu je mozno provadet kompozici i nad jedinou klavesou)
   [toto reseni povazuji za ponekud cistsi nez (2), protoze se vlastne
   jedna o ponekud zvlastni a neuplnou implementaci (1)]

--Pavel Kankovsky aka Peak (troja.mff.cuni.cz network administration)
          [ Boycott Microsoft -- http://www.vcnet.com/bms ]