Bug#216161: xserver-xfree86: font resolution not following the rules

[Andrew Pimlott <andrew@pimlott.net>]

On Sun, Jan 14, 2007 at 02:59:38AM +0100, Brice Goglin wrote:
> About 3 years ago, you reported a bug to the Debian BTS regarding font
> resolution not following the rules. Did you reproduce this problem
> recently? If not, I will close this bug in the next weeks.

Well, I can confirm the same behavior as I reported on a current
unstable system.  However, in the process of testing I noticed something
I probably missed before.  When I remove the gsfonts-x11 aliases, the
font chosen when I run

    xfd -fn '-adobe-times-bold-r-normal--17-120-100-100-p-86-iso8859-1'

is

    -adobe-times-bold-r-normal--17-120-100-100-p-87-iso8859-1

Note the 86 becomes 87.  (This is the "average width field, measured in
tenths of pixels" according to X(7).)  This caused me to suspect that
the bitmap font was being skipped according to the rule in
/usr/share/X11/doc/fonts.txt:

    When matching fonts, the server makes two passes over the font path:
    during the first pass, it searches for an exact match; during the
    second, it searches for fonts suitable for scaling.

But here's the wicked thing:  If you look at
/usr/share/fonts/X11/100dpi/fonts.dir, you find

    timB12-ISO8859-1.pcf.gz -adobe-times-bold-r-normal--17-120-100-100-p-88-iso8859-1

Note the width is 88!  So where did the 87 come from?  That I have no
idea.  Anyhow, if I restore the gsfonts-x11 aliases and ask for

    -adobe-times-bold-r-normal--17-120-100-100-p-88-iso8859-1

then I get the expected bitmap font.

I have no idea anymore where the example font string came from; probably
I changed it in some config file long ago.  At this point, the issue
doesn't matter to me, and based on the above investigation, the behavior
in fact looks pretty sane.  The only reason to keep this bug open, IMO,
would be to understand the 86/87 quirk.  But you can close it for all I
care.

Sorry for the long mail, and thanks again for following up.

Andrew