On Fri, Nov 07, 2003 at 05:31:12PM +0800, Cameron Patrick wrote:
> Package: xterm
> Version: 4.3.0-0pre1v4
>
> Many TrueType fonts don't have both a hyphen (0x2010) and a minus sign
> (0x2212); however, groff (and thus man pages) differentiates between the
> two in UTF-8 locales. This results in lots of man pages displaying ugly
> boxes where hyphens should be in a uxterm, but displaying fine on a
> 'normal' xterm where there is no distinction between the two characters.
>
> uxterm should display hyphens and minus signs as a simple ASCII "-"
> (0x002D, "hyphen-minus") if the font does not contain the requested
> character.
>
> In fact, it would probably be useful if xterm had some kind of more
> general character substitution mechanism for this kind of problem.
[ Disclaimer: I'm part of the XSF, but I don't generally deal with ]
[ [u]xterm So this is merely my opinion. ]
It seems to me like this is an emminently *bad* slope to start down; the
entire point of Unicode's distinguishing between the two is that they
are, in fact, different. True, if one transliterates them back to ASCII,
then they both end up being 0x002D, but it seems to me that the sanest
assumption, if someone is running UTF-8, is that they actually want UTF-8.
If the default Unicode fonts are incomplete enough that they lack this
character, then that is probably worthy of a bug (and this one could just
be reassigned), but I fail to see why the application should be expected to
do something fundamentally antithetical to the user's stated request for
UTF-8, simply because some fonts claiming to be intended for Unicode fail
to provide a useful set of Unicode entries.
--
Joel Baker <fenton@debian.org> ,''`.
Debian GNU NetBSD/i386 porter : :' :
`. `'
`-
Attachment:
pgpF849EWFRgy.pgp
Description: PGP signature