Re: RTL PUA?

From: Philippe Verdy <verdy_p_at_wanadoo.fr>
Date: Tue, 23 Aug 2011 14:12:00 +0200

2011/8/23 Richard Wordingham <richard.wordingham_at_ntlworld.com>:
>> The BiDi algorithm absolutely does not have to be changed.
>
> But you have to remember that preposed combining marks (and
> fragments) must inherit the BiDi class of the base letter.  I'm glad
> you know what a circumposed Indic vowel looks like when subject to a
> right-to-left override.

Yes I know the case of preposed Indic vowels, e.g. vowel I in
Devanagari, as well of vowels that are splitted in two parts (one
before the consonnant cluster and one after it). However, this applies
here to an LTR script, for which we don't have BiDi issues. PUA Indic
characters can safely be represented using existing PUA characters
without needing any directionality property override from their
default strong LTR value.

The case of RTL PUA will be in fact much more rare now than other PUAs
(except if someone creates a RTL conscript). Typically, it will be
used for rare or special characters that are not encoded (or won't be
encoded, such as specific glyph variants of letters in an existing RTL
script, including Arabic, for which a text author wants a PUA to
maintain a distinction that he cannot manage by other means just in
the encoded text, or because the character has not demonstrated for
now a sufficient proof of usage, due to extremely rare usage, found
for example in a single old book or manuscript, or to characters that
were invented specifically by some author, for esoteric reasons).

It could also apply to the need for encoding things that we don't
consider as characters (for example if someone wants to encode some
custom decorating swash to Arabic text, that have no logical or
phonetical reading and no other semantic by itself). Note that in this
case, the PUA will act as a custom variation sequence (variation
sequences must be assigned if we want to use something else than a
PUA) or as a custom diacritic...
Received on Tue Aug 23 2011 - 07:17:00 CDT

This archive was generated by hypermail 2.2.0 : Tue Aug 23 2011 - 07:17:01 CDT