[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: char-displayable-p returns t for undisplayable characters
From: |
Jonathan Yavner |
Subject: |
Re: char-displayable-p returns t for undisplayable characters |
Date: |
Wed, 11 Feb 2004 23:25:59 -0500 |
User-agent: |
KMail/1.4.3 |
JY> So this is basically the same problem as with xterm? If the display
JY> system claims it supports iso10646-1, we have to take them at their word?
SM> It seems that the `...' char is supported by almost all unicode fonts:
SM> the only problem you've seen was when you had the encoding wrongly set
SM> (which was a local misonfiguration problem). I.e. the imperfect
SM> information returned by char-displayable-p is actually not a problem in
SM> this case.
Not exactly. The ellipsis character is fine. When xterm's locale is properly
set to utf-8, char-displayable-p says U+221A (the square root) is present,
because it's encodable but my fonts actually have no drawing for that char.
Not much Emacs can do about this, I guess.
When Emacs is running under X11, char-displayable-p says U+221A is present,
apparently because I have a font with an ISO-10646 registry, but that font
has no drawing for the square-root character. Arguably, char-displayable-p
could try harder to determine whether the char is actually present.
MilesBader> Perhaps XFree86 4.3 has better unicode fonts.
I tried upgrading to XFree86-4.3, but this has rippling effects on many other
packages (e.g., Qt), so I'll think I'll live with 4.2 for now, and do a
complete system upgrade to FC2 later this year.
The reason for my bug report to emacs-pretest is that kmail does something
reasonable for U+221A (substituting the JIS-equivalent character), but Emacs
doesn't. However, since I can't find any other program that does this trick,
it seems to be kmail that's the outlier, not Emacs.
In summary: NEVER MIND!