From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Wed Mar 22 2006 - 21:26:35 CST
From: "Richard Wordingham" <richard.wordingham@ntlworld.com>
> For example, to 'swap' characters K and E with glyphs gK and gE you could
> try a sequence of rules such as:
>
> gK > E_for_K / _ gE
> gE > gK / E_for_K _
> E_for_K > gE
>
> which converts 'gK gE' to 'gE gK'. However, a process that would normally
> delete gK would delete E from the backing store, with the result that
> apparently deleting gK would convert the display 'gE gK' to 'gK'!
I would not doit this way. "Swapping" doesnot mean that the same glyph ids must be used.
In fact I would probably use simply such rule: gK gE > gE_before gK
Mouse selection of the rendered text can effectively be tricky if the twoletters are not treated as a unit, but this could be done also as if it were a BiDi text. A user that just uses the caret currently after the sequence and that presses Backspace will delete the last encoded character from the backing store, and I don't see why it would delete the last displayed glyph instead of the first (unless the editor attempts to "optimize" the display to render again only the end of line after the caret, and not the whole cluster or the current line.
Advanced edition of text (with subselections, selection of grapheme clusters, ...) is another issue,and is less important than correct rendering of text only for display or print. Editors can still be written without any knowledge of the font support, but still can recognize where cluster boundaries occur in its backingstore (this is needed anyway to allow smart line breaks, and this process does not require any specific font support)
This archive was generated by hypermail 2.1.5 : Wed Mar 22 2006 - 21:38:12 CST