On 4/21/14 12:44 PM, Peter Saint-Andre wrote:
On 4/21/14, 5:12 AM, "Martin J. Dürst" wrote:
On 2014/04/19 11:13, Peter Saint-Andre wrote:
I'm still worried about foot-guns.
Yeah, I think the foot-gun argument is always the trump card. So I will
relent on asking for any significant change.
Even strings without a mix of RTL and LTR characters can lead to
confusing display, e.g. if they contain digits at the start or at the
end. Don't remember to what extent they are excluded in IDNs.
IDN Labels can't begin with a number. LTR labels can't have any RTL
numbers. So the only strange case is RTL strings, which can end with
number, but the rest of the rules make bad behavior pretty hard.
As long as Precis strings are displayed only in isolation, the
restrictions may not be that important, but the moment any of these
strings is displayed with something else, maybe with an entervening
punctuation, these restrictions will be very helpful, although not
perfect (they aren't perfect for IDNs, either).
So I think the restrictions are a good thing.
I still agree.
I'm convinced on the restrictions. On the text:
NEW
The directionality rule of a profile specifies which strings are to
be considered left-to-right (LTR) and right-to-left (RTL), and the
allowable sequences of characters in LTR and RTL strings (see Unicode
Standard Annex #9 [UAX9]).
This is the part I'm still having trouble with. An "LTR string" and an
"RTL string" are not defined entities in Annex 9; AFAICT, are entirely
5893 inventions, and 5893 only talks in terms of "labels", not
"strings". How about this:
The directionality rule of a profile specifies how to treat strings
containing left-to-right (LTR) and right-to-left (RTL) characters
(see Unicode Standard Annex #9 [UAX9]). A profile usually specifies a
directionality rule that restricts strings to be entirely LTR strings
or entirely RTL strings and defines the allowable sequences of
characters in LTR and RTL strings.
The rest of this is fine:
Possible rules include, but are not
limited to, (a) considering any string that contains a right-to-left
code point to be a right-to-left string, or (b) applying the "Bidi
Rule" from [RFC5893].
Mixed-direction strings are not directly supported by the PRECIS
framework itself, since there is currently no widely accepted and
implemented solution for the processing and safe display of mixed-
direction strings. An application protocol that uses the PRECIS
framework (or an extension to the framework) could define methods for
handling mixed-direction strings; however, such methods are outside
the scope of the framework.
s/the framework/this framework ?
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
