Re: [idn] REORDERING: stability issues and UTC solutions

[DougEwell2@cs.com]

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