From: Ernest Cline (ernestcline@mindspring.com)
Date: Wed Mar 31 2004 - 15:28:08 EST
> [Original Message]
> From: Kenneth Whistler <kenw@sybase.com>
> To: <peterkirk@qaya.org>
>
> Peter Kirk continued:
>
> > >You can do it privately. See above. But attempting to do such things
> > >in terms of formally specified usages of the PUA is an invitation
> > >to failure of interoperability.
>
> > I don't understand this last comment.
>
> Scenario: The UTC listens to you and defines some section of the PUA
> as strong right-to-left by default for use in PUA-defined bidirectional
> scripts. Somebody else is *already* using that section of the PUA
> for something else. Now they have an interoperability problem,
> because the default behavior they were depending on changes over
> in some future version of some software, not under their control,
> and they data gets munged by bidi.
>
> This is the kind of stuff the UTC refuses to start up by trying
> to provide some subdivision of semantics in the PUA. *That* is
> the principle, by the way, which guides the UTC position on
> the PUA: Use at your own risk, by private agreement.
Which is why if any private use characters with default characteristics
other than those of the existing Private Use blocks are ever to be part of
Unicode they will need to be added as additional Private Use blocks,
not by redefining existing PUA's
There are currently some 10 totally unused planes, with not even any
tentative plans for them, Allocating one or two those into additional
Private Use Areas with a variety of default characteristics instead of
the monotonous default characteristics of the existing Private Use
Areas should not prove too difficult. For example, 26 blocks of 128
Private Use Combining Marks each, each block corresponding to
one of the existing canonical combining classes (with perhaps a
larger block for class 0) would amply satisfy the needs of most
private use scripts for combining marks. Similarly, blocks for
additional characters that would have other properties should
be simple to define and for most combinations of property values,
128 characters should also prove to be exceedingly ample
I'd have to take the time to list them, but a quick glance convinces
me that there are at most several hundred combinations that would
need to be supported if we limit things to just those combinations
already in use. (it might take more, if for example all 256 potential
combining classes were supported instead of the 26 listed in
UCD.html), At 128 characters per combination plus more for a
few that might need them, it should prove possible to handle this
in 1 or 2 planes.
This archive was generated by hypermail 2.1.5 : Wed Mar 31 2004 - 16:14:10 EST