Re: (re)display problems after font backend merge

[Stephen Berman <Stephen.Berman@gmx.net>]

On Fri, 23 May 2008 18:37:00 +0100 David De La Harpe Golden <david@harpegolden.net> wrote:

> Stephen Berman wrote:
>
>>> So.... just to cross-check - what does
>>>
>>> fc-list : family scalable  | grep -i helvetica
>>>
>>> now return for you?
>> 
>> Adobe Helvetica:scalable=False
>> 
>
> scalable=False, eh?  Well, I _thought_ that effectively meant
> no antialiasing in fontconfig/xft land*.  The puzzle would
> be where the helvetica-like font that is antialiased is coming from,
> then :-).

I guess you mean the font that realizes mode-line-inactive face (in my
penultimate reply to you, I was confused and mistakenly said that this
face was *not* anti-aliased; it *is*, as you seem to realize)?  It is
this:

-unknown-DejaVu Sans-extra-light-normal-normal-*-12-*-*-*-*-0-iso8859-1

Moreover, the face in the tabbar header line, which also inherits
variable-pitch but like mode-line-inactive overrides some attributes, is
also anti-aliased, and it is realized by this font:

-b&h-Lucida Sans-normal-normal-normal-*-10-*-*-*-*-0-iso8859-1

My reply may have confused you as well, so to be clear, the font
realizing mode-line face is indeed *not* anti-aliased, and it is indeed
Helvetica:

-Adobe-Adobe Helvetica-normal-normal-normal-*-12-*-*-*-*-*-iso8859-1

> [Not sure, but may need to run fc-cache -fv  both as root and as
> yourself, there may be a global /var/cache/fontconfig dir]

I only ran it as root.

> fc-list :scalable=False file family scalable
>
> should return all non-scalable fonts fontconfig is seeing on your system.

The output includes Adobe Helvetica but not the other two fonts above
(though B&H Lucida, B&H LucidaBright, and B&H LucidaTypewriter are
listed).

I also tried fc-match as per James Cloos's suggestion, but I don't know
if I did it right:

% fc-match :family=Helvetica
n019003l.pfb: "Nimbus Sans L" "Regular"
% fc-match :family="Adobe Helvetica"
helvR12.pcf.gz: "Adobe Helvetica" "Regular"

If either of these is right, it doesn't shed any light on why Emacs uses
DejaVu Sans and b&h-Lucida Sans for faces derived from variable-pitch in
my cases.

Steve Berman