Peter Kirk responded: > >Third, the proposal to "transfer ... some or all of the Variation > >Selectors on the SSP to Private Use" is unclear on the concept of > >Private Use. The UTC will make *no* semantic encoding commitment > >regarding what a private use character is to be used for. That would > >include *not* specifying that some range of Private Use characters > >be dedicated to use as variation selectors (privately defined). ... > > > > > > The problem here is that, despite what you say, the UTC has already > specified the character properties of all of the existing PUA > characters,
No. The UTC has specified default values for the properties for all code points, including the PUA, to prevent implementers of property API's from having them blow up or return random values for such code points. > in a way which rules out their use as variation selectors, > or as combining marks, or as right-to-left characters. They do not. A user of PUA characters is free to define the whole range of PUA characters as consisting of strong R-to-L characters and implementing accordingly. I have, for example, for my own internal use for developing collation tables, defined U+F8F0..U+F8F4 as being non-spacing combining marks (with no display), for use in providing variant weights. These are, in fact, very, very similar to what you are advocating for here as specialized variant selectors. But I do so by my own *PRIVATE* use of those characters, with code that assigns my own *PRIVATE* semantics and operates accordingly. I don't expect, in this case, to even require interoperability with anyone else, because the usage is internal and what matters are the weighted outputs in the tables. But in principle I could interchange this usage with someone else who chose to also treat U+F8F0..U+F8F4 as non-spacing combining marks with no display, indicating variant forms. The problem you are having is that you (and most implementers) are dependent on how the underlying *platform* treats the PUA, and have not been given an API which makes it easy to specific specific character properties along with your PUA character assignments. > > As an alternative to adjusting the definitions of the existing variation > selectors, might it be possible for the UTC to adjust the character > properties of parts of the Supplementary Private Use Areas? If you are asking me, I'd say the answer is no. > For example, > a range of characters could be defined as default ignorable, default > collation weight [.0000.0000.0000.0000] etc., and so these could be used > as private variation selectors, or as private diacritical marks (which > would simply disappear if viewed with a regular font; they would be in > combining class 0 and so there would be no normalisation issues); and > another range could be defined as RTL; and whatever other ranges might > be required. 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. > Alternatively, an additional PUA could be defined to avoid > changing the properties of existing characters. This also won't happen. In my assessment the UTC is just dead set against trying to create this kind of mechanism through proliferating types of PUA spaces. > This cannot be in > conflict with the principle that "The UTC will make *no* semantic > encoding commitment regarding what a private use character is to be used > for" because these kinds of properties have already been specified by > the UTC for the existing PUA. Nope. You're wrong. A default value for a property is not a requirement by the UTC regarding what a PUA character can or may or must be used for. --Ken
