Re: Monospace font bug?

[David De La Harpe Golden <david@harpegolden.net>]

Chong Yidong wrote:

> 
> That's an unfortunate choice of name.
> 

Yes, yes it is.

> Any suggestion about how to avoid matching to that font?
> 
> 

No. but is it desirable to?  If emacs says "monospace"
to the OS, and the OS returns something usable (see below), should emacs 
second guess it?   The distros with ttf-georgewilliams packages seem to 
be aware of the issue and are fixing it by removing or renaming the font 
in favour of the de-facto standard "monospace" virtual font name
https://bugs.launchpad.net/ubuntu/+source/gw-fonts-ttf/+bug/95357/comments/6

Anwyay, while emacs on my display with george williams monospace doesn't 
look _wonderful_ - the font isn't hinted I guess, looks better at larger 
sizes - it is nowhere near as bad as  bug 1219's rendering. (I'll send a 
screenshot offlist).

If it were to be blacklisted very naively, I can even imagine someone 
who doesn't mind the non-dotted-zeros and with a hires display (so the 
hinting issues didn't matter) deciding they like it, and being perplexed 
when they tell emacs "monospace" and it doesn't work...

Of course, it's being rendered by xft not core x in my case.  But it 
certainly currently looks to me like bug 1219 could well be some aspect 
of core x's truetype font metric handling being buggy rather than the 
font or emacs for that matter being buggy.

So _maybe_ blacklisting it from the core x font backend might be 
worthwhile (I for one just don't use core x font rendering, it's 
terrible even when working right), but the font doesn't seem to me to
be a real problem when it's rendered by xft, and the problem
is being treated as a bug by the distros anyway?