In that case, there remains only one alternative: encoding new
characters with another (existing) Bidi class. The problem will
immediately come: you'd need to duplicate lots of characters (it could
be the case for all visible characters, including whitespaces, that
are neither letters or digits or combining characters, and that don't
have a strong RTL or LTR directionality: much more than just CS
characters).
For me the stability of Bidi classes should only concern existing
characters, it should not limit new characters (or new scripts) that
may need new Bidi classes, as it would not break existing texts
rendered in existing implementations.
2011/9/13 Asmus Freytag <asmusf_at_ix.netcom.com>:
> On 9/13/2011 6:01 AM, Philippe Verdy wrote:
>
> Unfortunately, adding controls would imply the creation of new Bidi
> classes for them (and forgetting the stability policy about them,
> which was published too soon before solving evident problems).
>
> The first part is correct, and giving up stability to that degree would be a
> serious issue.
>
> I disagree with the second part. True plaintext bidi will always be a
> compromise, because there's a lack of information on the intent of the
> writer. (In rich text, you can supply that with styles). There's a limited
> workaround with bidi controls, but that's beginning to be a form of minimal
> rich text in itself.
>
> Stability is paramount for predictability. You need to be able to predict
> what your reader will see, and you will only be able to do that, when you
> can rely on all implementations agreeing on the details of how to lay out
> bidi.
>
> Introducing any new feature now, will result in decades of implementations
> having different levels of support for it. This makes the use of such a new
> feature unpredictable - and is a problem whether there was a formal
> stability guarantee or not.
>
> A./
>
Received on Tue Sep 13 2011 - 10:51:38 CDT
This archive was generated by hypermail 2.2.0 : Tue Sep 13 2011 - 10:51:38 CDT