Re: char-displayable-p returns t for undisplayable characters

[Jonathan Yavner]

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!