On 08/19/2011 07:43 PM, Doug Ewell wrote:
My question would be why the PUA is designated as 'L' by default at all,
instead of, say, 'ON'.
...
do present the impression that these code points are somehow reserved
for strong-LTR characters, and also for non-reordrant characters (i.e.
no combining marks), neither of which is true.
I entirely agree! There then should be an effort to officially change
the BC of these characters to ON, would you say? I mean, what kind of
implementations could such a change affect adversely?
There's a lot of misinformation and FUD about the PUA, and unfortunately
I expect at least one response of the form "The PUA is evil, don't use
it," which accomplishes very little.
Um -- I wonder whether my previous comment about one not being able to
expect proper rendering to be done for PUA character, whether in terms
of bidi or in terms of glyph reordering etc, qualifies as saying "don't
use it"? That is certainly not my intention.
Conceivably certain closed user-groups could be using
closed-distribution rendering engines which would support bidi and glyph
reordering or such for PUA codepoints.
In which case, the only change that needs to be done to affirm that the
PUA can be used for both LTR and RTL scripts is to change the BC of all
those characters to ON. (No change needs to be done for glyph reordering
etc behaviour of these characters in closed-group software, of course.)
But really, do any implementations actually parse those lines which read
"PUA First" and "PUA Last" and store it in some database or something to
do something else meaningful? I mean, these particular entries are
certainly not on par with the other entries in the file.
Personally I wonder if these entries really need to be there! These are
just like other unallocated codepoints with the only difference being
that these are *permanently* unallocated, right?
--
Shriramana Sharma
