Problem with mapping a key to multiple characters (Unicode + diacritic symbol)

[Ken Moffat]

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