Continuing Font Problems: Some XFT fonts not using XFT engine?

Continuing Font Problems: Some XFT fonts not using XFT engine?

[Taylor Venable]

Continuing with the font weirdness I've been seeing:

I can set XFT fonts like "DejaVu Sans Mono" for the 'default' face and
it looks great.  However, when I set 'variable-pitch' to use "DejaVu
Sans" or "DejaVu Serif" the XFT engine is not used.  To summarise:

    (set-face-attribute 'variable-pitch nil :font "DejaVu Sans")
       >> hover over something to get a tooltip, see that it's all
          blocky and not anti-aliased

What's weird is that sometimes after trying to use different fonts for
the variable-pitch face, it will start using anti-aliasing again and
then everything works.  I cannot reproduce when this occurs, and it
doesn't seem correlated with the font choice.

My Emacs version is: GNU Emacs 23.0.92.1 (i386-unknown-openbsd4.5,
GTK+ Version 2.14.7) of 2009-04-13 on lionel.metasyntax.net

Fontconfig version is 2.4.2 with XFT 2.1.12 (version numbers taken
from pkg-config output).

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/

foldr = lambda f, i, l: (len(l) == 1 and [f(l[0], i)] or
                         [f(l[0], foldr(f, i, l[1:]))])[0]

Re: Continuing Font Problems: Some XFT fonts not using XFT engine?

[Miles Bader]

Taylor Venable <taylor@metasyntax.net> writes:
> I can set XFT fonts like "DejaVu Sans Mono" for the 'default' face and
> it looks great.  However, when I set 'variable-pitch' to use "DejaVu
> Sans" or "DejaVu Serif" the XFT engine is not used.  To summarise:
>
>     (set-face-attribute 'variable-pitch nil :font "DejaVu Sans")
>        >> hover over something to get a tooltip, see that it's all
>           blocky and not anti-aliased

You're using openbsd, but on debian there's annoying package (which I
think gets installed by default) that makes all truetype fonts also
available as (usually pretty ugly ugly) X bitmap fonts, using the _same
font name_.  I think the debian package is called "xfstt".

This isn't such a problem for most apps, which only understand one of
the two types of fonts, but it may terribly confuse Emacs, which can
handle both simultaneously.

The easiest way to avoid the problem is to (1) un-install that package
[on debian, ... dunno on openbsd], or (2) tell emacs to only use either
"xft" or "x" fonts, and not both (the default is to support both).

You can do the latter by doing putting something like:

   Emacs.FontBackend: xft

in your .Xdefaults file, or by doing
(set-frame-parameter nil 'font-backend '(xft))
[this only affects the current frame though.]

> My Emacs version is: GNU Emacs 23.0.92.1 (i386-unknown-openbsd4.5,
> GTK+ Version 2.14.7) of 2009-04-13 on lionel.metasyntax.net

-Miles

-- 
"... The revolution will be no re-run brothers; The revolution will be live."

Re: Continuing Font Problems: Some XFT fonts not using XFT engine?

[Jason Rumney]

Miles Bader wrote:
> This isn't such a problem for most apps, which only understand one of
> the two types of fonts, but it may terribly confuse Emacs, which can
> handle both simultaneously.
>   

There should be an order imposed on font backends. So one backend should 
always take precedence over the other, and duplicate font names should 
not matter. It used to work that way, but it seems from reports of this 
type that something has changed recently.

Re: Continuing Font Problems: Some XFT fonts not using XFT engine?

[Taylor Venable]

On Thu, Apr 16, 2009 at 08:40:42AM +0800, Jason Rumney wrote:
> Miles Bader wrote:
>> This isn't such a problem for most apps, which only understand one of
>> the two types of fonts, but it may terribly confuse Emacs, which can
>> handle both simultaneously.
>>   
>
> There should be an order imposed on font backends. So one backend should  
> always take precedence over the other, and duplicate font names should  
> not matter. It used to work that way, but it seems from reports of this  
> type that something has changed recently.

In my default-frame-alist I had set (font-backend . "xft, x") --
removing the "x" backend has prevented the use of the bitmap font.
This is fine for me since I only use one or the other, but it seems
that there could be a problem in stable precedence since I could
"randomly" get either a bitmapped or XFT font.

I should also note (if I haven't already) that I didn't see this
behaviour on my Ubuntu box at work, so I wonder (what with the several
problems I've had with fonts on OpenBSD) if it could have something to
do with some underlying font libraries.  I just checked and the bitmap
versions of those fonts are available on that machine as well.

Best regards,

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/

Re: Continuing Font Problems: Some XFT fonts not using XFT engine?

[Miles Bader]

Jason Rumney <jasonr@gnu.org> writes:
>> This isn't such a problem for most apps, which only understand one of
>> the two types of fonts, but it may terribly confuse Emacs, which can
>> handle both simultaneously.
>
> There should be an order imposed on font backends. So one backend should
> always take precedence over the other, and duplicate font names should
> not matter. It used to work that way, but it seems from reports of this
> type that something has changed recently.

There is an order, but, given that the backends are quite different, the
(visible-to-emacs) details are probably often slightly different.  It
seems like there are certain situations where the font exported by the
non-preferred backend somehow looks like a better match for some set of
font attributes specified by emacs...

-Miles

-- 
Alliance, n. In international politics, the union of two thieves who have
their hands so deeply inserted in each other's pockets that they cannot
separately plunder a third.