[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Monospace font bug?
From: |
David De La Harpe Golden |
Subject: |
Re: Monospace font bug? |
Date: |
Sat, 25 Oct 2008 06:55:27 +0100 |
User-agent: |
Mozilla-Thunderbird 2.0.0.17 (X11/20081018) |
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?