In a message dated 2001-10-21 18:27:30 Pacific Daylight Time, [EMAIL PROTECTED] 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
