Re: Updating gtkimcontextsimple.c (bug #321896)

And an article to get things going,


Simos Xenitellis wrote:
Hi Samuel,

I had some discussions on this and I think the problem can be resolved
in the following way.

To add combining diacritics there is no need for extra support in
GTK+; this is something that is handled by the keyboard layouts (which
are not handled by GTK+).
What that means is that you need a keyboard layout that produces all
those combining diacritics.

The project for the keyboard layouts is xkeyboard-config,

For your case of Tagbanwa, you would create a new keyboard layout.
For the generic case to add combining diacritics to different
characters, a catch-all keyboard layout could be used.

Currently, there is no GUI tool to create such keyboard layouts.
In your Linux system, keyboard layouts live in /etc/X11/xkb/symbols/
You can have an idea how to modify an existing layout by looking into the files.

If you would like to pursue this further, I would be happy to give you


On Feb 7, 2008 11:19 AM, Samuel Thibault <samuel thibault ens-lyon org> wrote:

Simos wrote:
In bug #341341, Danilo talks about support for compose sequences that
produce more than one Unicode characters, as in
COMBINING ACUTE + CYRILLIC LATIN A where no precomposed form exists.
At the moment, the Xorg Compose file does not have such compose
sequences. If we were to implement in GTK+, I would suggest to build up
a new table of the form

dead_acute, A, E, H, I, O, U, ...  (assume all these cyrillic)
dead_diaeresis, A, E, H, I, O, U, ...  (assume all these cyrillic)
The problem is that this is very tedious for people who already have a
hard time making Linux suit to their language (fonts, messages, locales,
...) and can potentially be very big. For instance in vietnamese you may
need to put two accents on a voyel, and so you'd need to enumerate all
such possible combinations.

In check_algorithmic, we currently check if the compose sequence can be
normalised to a single Unicode character.
Which is necessary for proper string unicity/comparison etc, yes.

So, here we can also check if the compose sequence matches the "valid"
compose sequence (a cyrillic small 'a' with a combining acute is ok)
There is no such thing as a "valid" compose sequence. As Unicode says,

"All combining characters can be applied to any base character and can,
in principle, be used with any script. As with other characters, the
allocation of a combining character to one block or another identifies
only its primary usage; it is not intended to define or limit the range
of characters to which it may be applied.  In the Unicode Standard, all
sequences of character codes are permitted.

This does not create an obligation on implementations to support all
possible combinations equally well. Thus, while application of an
Arabic annotation mark to a Han character or a Devanagari consonant is
permitted, it is unlikely to be supported well in rendering or to make
much sense."

So there are indeed combinations that don't make so much sense, but
enumerating those that make looks to me unnecessary work:

- It may be potentially very big, just see all the possible vietnamese
- It will mostly never be complete, there will always be a language
  (say, for instance, tagbanwa) which nobody takes care of.
- Why limiting ourselves like this? It has been objected that a generic
  support potentially leads to "odd" things like n̈̈̈, which is an n
  with three diaeresis on it.  I don't think this is odd: if the user
  pressed the dead_diaeresis key several times, I guess he indeed wanted
  to have three diaeresis, and if they don't show up, then the text
  rendering engine is probably broken and may not for instance properly
  show ẫ, which is needed for vietnamese (actually, on my system,
  pango shows both fine).  Actually I think some mathematicians may even
  have a use for n with several diaeresis :)

How would we know which compose sequences are "valid"? We can parse
parts of
It is _not_ a table of "valid" characters, it is only a partial test
to check that the algorithm which transforms character + combining
character into normalized precomposed form works correctly. Actually,
a table that would hold _all_ the valid combinations would be very
big. Just for the vietnamese language, there would be 10*6 entries.

Instead, it could be solved once for all by systematically turning
<dead_foo> <bar>, <combining_foo> <bar> and <Multi_key> <foo> <bar> into
"Ubar Ucombining_foo". The only limitation is the font rendering engine,
which seems to already do a pretty good job in all the cases: if I try
to put a tagbanwa accent on a latin accent, it just works. If I try to
put a combining kannara vocalic on a kannara character to which it isn't
supposed to apply, it just shows the character and then the combining
vocalic with a dotted circle.

If the implementation can be generic enough that it works ASAN for every
languages in the world without more work, then why not do it?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]