From: [email protected] [mailto:[email protected]] On Behalf Of Philippe Verdy
>> As I explained in an earlier message, the layout engine doesn't use >> the "default" property value but the resolved bidi level. > > Once again, you refuse to understand my arguments. I don't think I'm refusing to understand anything. I'm merely taking your assertions _as stated_ and evaluating whether I think they are accurate or not. Perhaps what you intend to convey assumes things not clear in what you've stated, since you think I'm not understanding you. > What I'm saying is that OpenType CANNOT resolve the bidi level of > PUAs (with the exception where we use additional BiDi controls, Of course _OpenType_ cannot, but any rendering engine that uses OpenType _must_ resolve the bidi level of _all_ characters in a sequence that it is given to render. Given our current situation, a default rendering implementation would resolve PUA characters to an even (LTR) level unless, of course, bidi control characters -- particularly RLO -- are used to override the directionality of the character, as you mention. > which remains a hack, because it adds unnecessary unvisible markup > around the encoded texts, and complexifies the use of strings and > substrings). We'll, depending on how you define "hack", some might reasonably suggest that any usage of PUA is "a hack". (Of course, some who may not use the term in the same way might argue that it is certainly not "a hack".) You can turn the problem as you want, but PUAs (as well as unknown characters) still have default properties that, in fine, will get used in absence of a more precise definition (i.e. an explicit override) of the actual BiDi property needed for the character. > And at least on this point, Michael Everson is also right when he says > that PUAs do not properly handle RTL scripts only because of their > default BiDi property value. That depends on what your expectation is of PUA code points in stock software implementations, without any further tailoring. Sharma has made the point that, even if there were PUA code points with default RTL bidi properties, a user who wanted PUA characters for an as-yet-unencoded Indic script would still not have PUA code points with the default properties they'd need to get their script to display correctly. We could start naming off any kind of text process and any number of unencoded characters or script; we can't possibly (literally) assign PUA code points with default values for every different combination of character property values. But that is what would be needed if one were to argue that there should be PUA code points available for an arbitrary user to get desired behaviour in their text process of concern using only available PUA code positions and stock software without further tailoring. I don't hold to that expectation (certainly not in the strong form as I've described). > I did not post any assertion about how OpenType could be used, just > wanted to > explain that with the current specifications, it cannot > *currently* resolve the problem OpenType cannot resolve the problem of the directionality of PUA characters for the particular reason that OpenType doesn't deal with bidi layout at all! It sits at a lower level in a text rendering stack. But, what it can do -- and this is _all_ that I said -- is that (once the layers above it have resolved bidi levels) the OpenType spec has details covering the mechanisms necessary to handling glyph mirroring. Peter
