In a message dated 2001-10-21 18:27:30 Pacific Daylight Time,
jseng@pobox.org.sg writes:
> > Is this scheme of reordering for the sake of compression really UTC's
> concern?
>
> Actually, they might. See UTS#6 A Standard Compression.
I know a little about SCSU, having written the SCSU encoder and decoder used
in the SC UniPad text editor, distributed by Sharmahd Computing (visit <
http://www.unipad.org> for more information).
SCSU works by defining 128-byte "windows" into the Unicode code space and
using two slightly different mechanisms ("locking" and "non-locking") to
refer to code points in those windows. SCSU is intentionally a very
lightweight solution, and does not depend on large tables of the sort
required by the normalization forms or the proposed reordering scheme. In
particular, no reordering takes place in SCSU; code point order within each
128-byte window is strictly adhered to.
Other forms of compression are unlikely to be of much interest to the UTC,
which acknowledges that heavier-weight or application-specific compression
schemes belong to the expertise of compression specialists or application
vendors.
> But of course, this discussion is not for IDN WG.
This is true, so I will not pursue it further on the IDN list.
Apologies to the Unicode list if this thread was inappropriate for
cross-posting.
-Doug Ewell
Fullerton, California
This archive was generated by hypermail 2.1.2 : Mon Oct 22 2001 - 00:41:54 EDT