From: Mark E. Shoulson (mark@kli.org)
Date: Thu Apr 29 2004 - 21:36:09 EDT
Language Analysis Systems, Inc. Unicode list reader wrote:
> Seems like it might have made more political sense if Unicode really
> had left the semantics of PUA code points completely open and not
> assigned default properties. Or if it had assigned default properties
> that made the PUA universally unusable, such as making them all
> default ignorable. Then an application would have to explicitly know
> and care about some set of PUA code points in order for them to be
> usable at all. Either that, or most application vendors would have
> done essentially what they're doing now, and the defaults we have
> would have been the de facto defaults anyway.
Making the PUAs default ignorable would probably have been the smartest
plan all 'round. Then everybody has to fix the properties to use it.
After all, the default properties are mostly for apps that don't want to
handle the PUA. So those apps should just ignore it! That's what should
have been done; can it still be done?
> Seems to me that the choice of defaults was designed to irritate the
> smallest number of people possible and cover the widest range of use
> cases possible, and that we're now hearing from people in that
> "smallest possible" group.
>
> Those people have legitimate needs. How should they be accommodated,
> and how does Unicode participate in that process? Seems there are a
> number of options:
>
> 1) Change the default properties for some range of the PUA.
The only really workable version of this option is to change all of PUA
to default ignorable.
> 4) Lobby for operating-system vendors to extend their text engines to
> allow properties of PUA code points to be configured. With some text
> engines, a lot of the work is delegated to the font, and you can get
> most of the effects you need by designing appropriate fonts. The big
> case where this doesn't seem to be possible is OpenType. Maybe the
> user communities who aren't being accommodated now should be lobbying
> for things like pluggable OpenType renderers. This seems like a good
> idea, but it's completely outside the scope of Unicode. This also
> doesn't solve all the problems. Searching and sorting can be covered
> with tailored collation weights on systems that let you specify
> collation weights directly, but direct character property queries are
> tougher-- this stuff generally isn't configurable and making it
> configurable would slow lots of things WAY down. But if you're mostly
> concerned with rendering, these might be properties you can live
> without configuring.
>
> 5) Write specialized applications that are designed to deal with
> certain scripts and address the needs of user communities whose needs
> aren't being met right now. Of course it's better to use
> industry-standard applications, but when they don't do the job, you
> write your own and make do. This seems like something that could be
> done by the open-source community.
I'm not sure why you see 4 as less marketable than 5. Something like 4
is really the Right Thing. If people are expected to make "agreements"
in order to use the PUA, then the most useful way to do that is to
provide them some standardized way to make those agreements. Some sort
of way to specify the requisite attributes, and a nice *general-purpose*
engine that can interpret that standard, which thus only has to be done
once, and not a lot of little specialized apps for each individual case.
Putting the attributes in the font makes sense to me, though it isn't
the only way. An XML file distributed separately might be less
convenient in some ways, but more useful in others... whatever. *Some*
kind of standard for specifying these things is really what the PUA
needs. It's not actually Unicode's responsibility to come up with this
putative standard, and technically it could just be some astute
programmers with the foresight to place the standard in the public
domain... though it might be nice to have the might of some recognized
standards organization behind it.
~mark
This archive was generated by hypermail 2.1.5 : Thu Apr 29 2004 - 22:26:40 EDT