Sorry for the belated response to this. I hope it is still relevant.
Patrick T. Rourke <ptrourke@methymna.com> wrote:
>> I would think you could simply use the version number of the Unicode
>> Standard. For example, the use of Tagalog would have been conformant
to
>> this proposed PUA registry until Unicode version 3.2, at which time
it
>> would have to be removed from the registry because of its
introduction
>> into Unicode.
>
> This had not occurred to me! The only thing that would militate
against
> this would be if additional characters were identified which had not
yet
> been proposed and were proposed at a later date; that would require a
> new version number which would not be a Unicode point number, and so
> might be distinguished using a letter, etc. (I don't foresee this
> happening, but it's better to be safe than sorry, no?).
Patrick is right. I neglected to consider that the proprietors of this
private registry would want to add characters between releases of
Unicode. Of course they would; the Unicode release cycle is completely
irrelevant to their process. In any event, the exact technique used for
version control of such a registry is a minor detail.
> The target
> users for the registry would be a small number of electronic scholarly
> publishers in the community.
Originally I thought Patrick was talking about a relatively large group.
In the situation he describes, it should not be difficult to enforce
adherence to the registry, and make sure everyone's on the most current
version.
> The point is that the registry would not be "rushing characters into
> use," but that they would be characters which were already in use with
a
> variety of non-standardized methods and which are widely used in print
> in the community.
Absolutely, it is much better to use Unicode, even if that means the
PUA, than to putter along with a private 8-bit encoding.
> Another serious issue. The characters are such that I doubt they
would
> be approved for the BMP. Most of the tools being used by the users in
> the community in question (mostly Windows 98 and Mac OS 9 word
> processors and web browsers - yes, Mac OS 9 will be a problem anyway)
> are not yet able to handle secondary plane characters, at least not
> without serious intervention. The PUA code points which would be used
> would be in the BMP because use of the secondary plane PUA (I don't
> remember the code points, so forgive me for not knowing what plane(s)
> they're in)
Planes 15 and 16. (U+Fxxxx and U+10xxxx)
> would be obstacles to adoption. The problem will be getting
> the targeted content providers to agree beforehand to convert their
> content to the approved codepoints when they become available, as the
> BMP code points are easier to support. Does anyone have any advice /
> prior experience for dealing with this issue?
Sorry, I can't offer much moral support here. The supplementary planes
have existed since 1993, and the designation of private-use code points
in Planes 15 and 16 has existed since the release of Unicode 2.0 in
1996. That's six years ago. Vendors of "Unicode-compliant" software
that can't handle supplementary characters -- and there's a lot of it
out there, make no mistake -- really need to get in touch with the
times.
> Finally, are there any existing resources describing / testing support
> for PUA characters in existing applications, besides Alan Wood's test
> page? Perhaps at ConScript?
This is going to be a bit tricky, almost by definition, because
characters in the PUA are intended for privately-defined exchange only.
You are not going to find many fonts on the Web that contain PUA
characters. Personally, I'd like to see a font that covers all or most
of the ConScript characters, but that seems impossible since so many of
the ConScript glyphs have become unavailable, possibly forever.
-Doug Ewell
Fullerton, California
This archive was generated by hypermail 2.1.2 : Tue Mar 19 2002 - 00:46:04 EST