🚀 go-pugleaf

In article <27618@life.ai.mit.edu>, glenn@wheat-chex.ai.mit.edu (Glenn A. Adams) writes:
> 32-bits are *not* needed, 16-bits suffices for representing the primary
> content of *all* languages, both modern and archaic.  Of course, 32-bits
> might be useful for glyph encodings; but Unicode doesn't encode glyphs.
 
> [Note: 16-bits only suffices when a compositional approach is allowed, such
> as is the case with Unicode and ISO10646; i.e., to represent the textual
> information displayed as LATIN CAPITAL G WITH CIRCUMFLEX, the two Unicode
> characters LATIN CAPITAL LETTER G and NON-SPACING CIRCUMFLEX are employed.
> There is no need to encode all combinations of formal elements as single
> encoding units.]

The problem is that text-sorting algorithims are greatly
complicated by having multiple characters representing a single
sorting unit. This is a general problem of course (for example,
in Spanish, ch, ll and rr are each treated as single letters so,
e.g., lo comes before llegar in an alphabetized list of Spanish
words, on the other hand, in an American English dictionary, i
and i-with-diaresis would be treated as the same letter for
sorting purposes). The approach of coding diacriticals separately
has both advantages and disadvantages and I don't think that
it's quite the closed book represented here.

-dh

Don Hosek                  
dhosek@ymir.claremont.edu  
Quixote Digital Typography 
714-621-1291