Re: RTL PUA?

From: Asmus Freytag <asmusf_at_ix.netcom.com>
Date: Sun, 21 Aug 2011 16:37:34 -0700

On 8/21/2011 3:31 PM, Richard Wordingham wrote:
> On Sun, 21 Aug 2011 11:00:26 -0600
> "Doug Ewell"<doug_at_ewellic.org> wrote:
>
>> I think as soon as we start talking about this many scenarios, we are
>> no longer talking about what the *default* bidi class of the PUA (or
>> some part of it) should be. Instead, we are talking about being able
>> to specify private customizations, so that one can have 'AL' runs and
>> 'ON' runs and so forth.
> I was exploring the consequences to see if there was a one size fits
> all solution. Someone (you?) suggested ON as a default, and I like
> it. I think it would also work fairly well for practical CJK
> applications as well - the only problems are that LRM and RLM would
> occasionally be needed, and the subtle differences between AL and R
> would be lost. I expect ARABIC LANGUAGE MARK would not go down well
> - has it already been proposed and rejected?.

If your implementation supported the directional overrides, it would be
possible to use these to lay out any RTL text in a portable manner. Just
enclose any RTL run with RLO and PDF (pop directional formatting).

No impact on any existing implementation, no impact on the standard.

Those who produce rendering engines that do not support these overrides
today could be leaned on to upgrade their implementations - that change
would benefit users of non-PUA RTL languages as well (because sometimes,
the bidi-algorithm can fail, such as for part numbers, and being able to
use RLO is a simple way to stabilize such problematic text).

Treating PUA characters as ON is very problematic - their display would
become context sensitive in unintended ways. No users of CJK characters
would think of using LRM characters, but if text is inserted or viewed
in RTL context, it could behave randomly.

In contrast, always supplying a RLO override for RTL text (containing
PUA characters) would be a simple thing to remember and to get right.

A./
Received on Sun Aug 21 2011 - 18:41:45 CDT

This archive was generated by hypermail 2.2.0 : Sun Aug 21 2011 - 18:41:46 CDT