On Mon, 2006-02-06 at 21:58 +0100, Jan Willem Stumpel wrote: > Imitating the difficult-to-learn Windows system for 'multiple > diacriticals' should IMHO be offered as an option, but not as the only
I am not sure what complexities the Windows keyboard layout has that make it difficult to re-implement as an extra layout in Xorg. My understanding is that sets too many dead keys, as there is a limitation of "stacking" dead keys together. > option. The ease with which diacriticals can be combined by means of > xkb/Compose could be a 'Linux selling point' in the academic world. > > BTW I am now terribly confused about he tonos/oxia issue. > > -- "Tonos and oxia are considered equivalent in Unicode" - but why, > then, are there different code points for them (U+1FFD, and all > the letters "with oxia", vs. U+0384 and all the letters "with > tonos")? Where does it actually say that they are equivalent? It at http://www.unicode.org/charts/PDF/U1F00.pdf For example, see 1F71, Greek Small Letter Alpha with Oxia. The three horizontal bars show equivalence between glyphs. It shows that 1F71 == 03AC. It is common to have these equivalences; compatible software should take care of these equivalences for the end-users and fold glyphs to their initial equivalences. > -- Many (maybe most) font creators made different glyphs for oxia > and tonos (although others did not, see the Gentium font), because > they were "looking at unicode". But, surely, that was the correct > place to look? Unicode does not dictate how fonts should look. See the Fonts section at http://www.unicode.org/charts/PDF/U1F00.pdf The selected font was merely a font donated for this purpose. > -- Kostas calls it "a bug of the fonts". If there is a bug, isn't it > in the Unicode standard ? I am not sure about the background of this; I think it has to do with different "schools of thought" on how original documents looked like. > I hope there is a way to put the genie back into the bottle. Just making > the keyboard entry for oxia "hard, forcing people not to use it" does > not seem to be the right way. The choice is between 1. do not provide an option for people to type 1F71 and other vowels with oxia. (current situation) 2. provide such a choice to type vowels with oxia. The preference is to move to Choice 2, so that if a user wants this option, he has the freedom of choice to do so. Giving equivalent exposure to both oxia and tonos can create a mess with documents. That's why oxia should be somewhere far away, not on a nearby dead key. Google does not normalise yet texts so that these equivalent glyphs are treated the same. Simos -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
