Re: Combined Yorùbá characters with dot below and tonal diacritics

Philippe Verdy verdy_p at
Thu Apr 16 11:21:23 CDT 2015

2015-04-15 17:59 GMT+02:00 Doug Ewell <doug at>:

> Luis de la Orden <webalorixa at gmail dot com> wrote:
> > But with regards to the ALt-Gr, there it goes my innocence and feeling
> > of accomplishment :)), I had everything linked to the Alt-Gr key and
> > did exactly as Ilya said... MS Word is fine, but very specialised
> > software such as Photoshop are a pain as their power-user shortcuts
> > all use ALT-Gr indeed.
> It's true that some very popular software packages define their own
> Alt+key or Ctrl+Alt+key combinations, and keyboard layouts that use the
> same combinations (as AltGr+key) will conflict with them. I just annoyed
> a colleague the other day because my keyboard layout (John Cowan's
> delightful Moby Latin [1]) co-opts one of his favorite Visual Studio
> shortcuts; he tried to build a project and got U+2022 BULLET instead.
> But there are also a lot of keyboard layouts worldwide that do use AltGr
> keys. There are only so many keys on a standard keyboard, and if you're
> designing a layout and you've made all the tough choices and you still
> need to find room for more characters, you pretty much have to go to
> AltGr.
> It helps to educate users of such a keyboard layout, especially
> Americans, that the left and right Alt keys aren't the same. Americans
> tend not to expect this, because the standard U.S. keyboard doesn't use
> AltGr at all and the key isn't marked as such.

Another candidate key for modifiers that you can use on PC keyboards is the
useless "NumLock" key on 101/102-keys keyboards (there's actually no need
to switch the working mode of the numeric keypad, given you have also a
separate set of keys for cursor movements, which remain active
independantly of the NumLock setting).

So this NumLock can be reused as another modifier (e.g. to support input in
Japanese without a physical Japanese keyboard). Of course this will not
work if your connected keyboard does not have a separate numpad but you
need to share it with cursor keys.

Some keyboard layouts also use ScrollLock for similar purpose (but this
function key is frequently not easy to access on notebooks where you
activate it by using the "Fn" key plus another function key. NumLock in
that case remains more accessible as it will remain under a single
keystroke. Several keyboard drivers (e.g. Logitech) have settings that
disable ScrollLock by default (or that recommend disabling it...), a good
sign that this function is useless in standard layouts, but more useful for
extended layouts (in that case don't disable it in the device control

Outside physical keyboards, for virtual touch keyboards there's no such
limitation, and these layouts can have much more freedom in how they will
switch their visible panels in various input modes. Many more facilities
can be integrated, including faciltiies specific to the application having
the input focus (they don't necessarily have to modify the virtual driver
of the OS, they can provide these faciltiies directly in their own
application UI, but the OS-provided virtual keyboard facility can provide a
space for such application-specific customizations of the touch panel). For
these virtual panels, even common modifiers like CapsLock, Shift, Control,
or Numlock are not productive, as the proposed lists of characters may be
arranged in very different groups or input modes and with more choice in
terms of geometry. However these applications providing custom UI should
propose clear mappings to other common input devices, including physical
keyboards and mouse or other pointing devices. These interfaces should also
not assume that alternate devices will be able to emulate a multitouch
capability (with multiple pointing positions on screen)

On touch interfaces, the "AltGr" modifier itself does not have any meaning.
It is more important for the layout to offer the best selections of
characters for the current language, and offer extended subsets with some
logical groupings that make sense for that language, but we are not limited
to just 2 or 3 "modifier" keys (for example long presses or clicks on a
basic virtual key can open a popup panel that contains dozens characters to
choose from, and contextual input can also predispose the most common or
most recent choice in some easy position without having to look for other
panels). Virtual onscreen keyboards (not necessarily on touch screens
because you may also point and click in them) are in fact acting more like
an IME than a traditional keyboard

These virtual keyboards are in fact true applications with a visual UI,
accessible with several other input devices: a tactile area, possibly
multitouch, pointing devices, physical keyboards, or other sensors. These
applications process all these inputs, present some selections, present the
result to be sent to other applications, and they will send these results
either by emulating standard keyboard events, or mouse events, or even
image captures, or clipboard contents to be pasted in other applications.
These IME can also be desigend to manage completely the content of an
external input control widget, becoming their standard text editor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Unicode mailing list