> > (2) Therefore, FINAL-KAF and LONG-S need to be encoded. Not, as has
> > been hinted, because they come from an ancient legacy encoding,
> > but because they are necessary, here and now.
> For both reasons.
> > (3) There still remains the question why LONG-S has a compatibility
> > decomposition to S, while FINAL-KAF doesn't.
> This involves a subtle point (meaning that I myself only figured it out
> a short while ago :-) ). To give a character a compatibility decomposition
> asserts more than that it is a variant form of one or more other
> characters. It further asserts that the character is itself a
> compatibility character: i.e. it was encoded solely for compatibility
> with something, typically another encoding.
Aren't your two answers contradicting here? If LONG-S, like
FINAL-KAF, is in Unicode because it is necessary, how can it be a
compatibility character and be encoded solely for compatibility with
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:54 EDT