On Thu, Mar 14, 2019 at 10:44:29PM +0100, Pierre-Luc Angles wrote: > Dear ĸen, dear all, > > Thanks for your answer and your interest! > > I have mapped it for Frecnh-azerty but would like to make German qwertz and > English qwerty versions for other Egyptologists by putting it for example on > my Gitlab account. >
Part of my eason for asking that is that I think you might want to use compose sequences for some of those letters. For example, on a gb english keyboard I think I could *perhaps* map i with inverted breve below to multi_key i (for inverted) b (for breve) i (the letter) to i followed by the combining accent. Not tested. The practicalities of what makes sense to a user for adding a compose sequence may differ between languages. In us english there are dead hooks and horns for vietnamese, for gb english it is hard to find a suitable key to use for those (I mapped KP + for my own "prove it can be done" usage). I don't see a lot of available symbols on a (gb) keyboard which look like inverted breves, for example. Whatever, the solutions you come up with will have to be learned by your users. > The Yogh is used by some online databases instead of the more accurate aleph > used now. Since these databases are very usefull, it makes sense to keep > them on the keyboard layout for searching in them. > > My aim was to make like an up-to-date keyboard layout as the one we can for > example there: > http://www.ifao.egnet.net/uploads/polices/Translit_IFAO_fr.bundle.zip > index="3" ? Interesting, the keycode 11 appears as a nicely formatted h with breve below (sic - not inverted). But there are lots more sets of maps for different things. The detail is beyond me and I repeat that you cannot map everything in a manner which is practical to use. Still no idea which letters you need, other than yogh. And do you really need both cases of that ? But my gut feeling is that for glyphs which are not available pre-composed (so, what you showed in your first post) it will be impractical to define them in the keymap. And therefore, IFF mapping them to compose sequences works (as I have said, I have not tried that), it might be easiest for the users to do similar sequences for all the additions. On the other hand, I don't know what the users will actually need to type - if every other character needs a multiple-key compose sequence then that too might be impractical. But expecting everyone to recompile Xorg is "unfortunate", although if you eventually get something which is popular then I'm sure upstream xkeyboard-config might consider it. > Like this keyboard, it is quite useful to have the modern language key on > the two first levels (without modifier, and with shift) and all the modified > keys on the third and fourth levels (with ALtGr, and AltGr+Shift). > > Best, > > Pierre-Luc Yes, I understand the convenience of AltGr and AltGr+Shift - my own interest started after I found the "extensions" æÆ ¢© ðÐ łŁ ĸ& øØ þÞ ß§ ŧŦ »> «< and others hidden away on my gb keyboard and accessed in that way. And I think that some of the dead keys (e.g. AltGr + ; for acute accent) were also part of the standard layout. For English where non-ascii is uncommon, dead keys are fine once learned. For other languages they may be the cause of much annoyance. Ultimately, you have to go with something which works for your users. The more pieces of software you have to change to achieve the result, the less likely it will be that other people use your solution. An alternative might be to put all the special characters into a libreoffice writer file, and get people to use writer. I know you said it ignores your changes, so try preparing the sequences in some other way, like what you did for your first post, and paste that into a file. Ideally big text to read, but spaced out and on one line so the window can be reduced in height - and paste from that whenever a special character is required. Not at all ideal, but might be acceptable ? With that you would only need to argue with your users about which font looks best for this text ;-) You also mentioned polytonic greek - I assume that everything in that was already mapped to pre-composed characters before the consortium said "enough!". Whether or not there are enough key combinations available for the parts you want to use is a different question. ĸen -- It is said that there are two great unsolved problems in computer science: naming, cache invalidation, and off-by-one errors. -- Ben Bullock _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
