Julian Bradfield writes:
Urgh. Typesetting is a hard task.
I know that. I just don't think we should rule out improvements in
XEmacs's capabilities there.
The kind of thing Unicode does that is really annoying is
by one of the characters I use most often, namely U+5C06 将.
The difference between the reference glyph for U+5C06 and its
rendition in CNS and Japanese is a clear example of a difference that
should prevent unification: a different radical in a component.
For what it's worth, I would have no trouble reading Japanese words
such as 将来 (future) or 将軍 (shogun == generalissimo) if written
with the reference glyph (in the context of other simplified Han).
>Unicode advocates have a set of rules that are easy to apply in
>thousands of common cases and ambiguous in very few cases, even for
>rare glyphs (except for the case of "lost" glyphs whose meaning is
I wouldn't mind, if they actually applied their own criteria
I don't see convincing evidence that they don't. It seems you just
got burned by a rather arbitrary choice of some GB bureaucrat in a
character you happen to refer to a lot, and the geopolitical weight of
"China" that makes its standards the reference, rather than the
earlier and probably more useful (to foreigners) ROC and Japanese
I don't criticize you or your application, and obviously this kind of
thing makes your work more difficult. I just don't see how it makes
sense to reject the Unicode standard on this basis. If XEmacs
slavishly kowtows to Unicode and fails to provide ways for you to work
around these difficulties, that is a bug in XEmacs, not in Unicode, as
far as I'm concerned. (Of course I don't plan to do the work! :-)
XEmacs-Beta mailing list