Uwe Brauer wrote:
the following symbol
is correctly decoded in GNU emasc 21.4 (but not displayed!, it is a
in Xemacs 21.4.17 it is decoded, incorrectly, as ?
is the situation better in 21.5
21.5 has vastly/completely rewritten unicode support. with my
unicode-internal workspace, it will certainly support this (whether or
not you compile --unicode-internal).
gnu emacs 21.x has charsets into which unconvertible unicode chars are
stuffed, so they can be undone upon output rather than lost. i've
recently suggested a similar approach for XEmacs 21.4.