bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19117: 25.0.50; emacs on x11 chooses different fonts for the same fa


From: Dima Kogan
Subject: bug#19117: 25.0.50; emacs on x11 chooses different fonts for the same face sometimes
Date: Fri, 19 Dec 2014 14:46:31 -0800

Dmitry Antipov <address@hidden> writes:

> Hm. On my system (Fedora 21), there are no -adobe-courier-medium-i-normal-*
> fonts but:
>
> $ xlsfonts | grep -- -adobe-utopia-bold-i-normal-
> -adobe-utopia-bold-i-normal--0-0-0-0-p-0-iso10646-1
> -adobe-utopia-bold-i-normal--0-0-0-0-p-0-iso10646-1
> -adobe-utopia-bold-i-normal--0-0-0-0-p-0-iso8859-1
> -adobe-utopia-bold-i-normal--0-0-0-0-p-0-iso8859-1
> -adobe-utopia-bold-i-normal--10-100-75-75-p-58-iso10646-1
> -adobe-utopia-bold-i-normal--12-120-75-75-p-70-iso10646-1
> -adobe-utopia-bold-i-normal--14-100-100-100-p-78-iso10646-1
> -adobe-utopia-bold-i-normal--14-100-100-100-p-78-iso8859-1
> -adobe-utopia-bold-i-normal--15-140-75-75-p-82-iso10646-1
> -adobe-utopia-bold-i-normal--17-120-100-100-p-93-iso10646-1
> -adobe-utopia-bold-i-normal--17-120-100-100-p-93-iso8859-1
> -adobe-utopia-bold-i-normal--19-140-100-100-p-109-iso10646-1
> -adobe-utopia-bold-i-normal--19-140-100-100-p-109-iso8859-1
> -adobe-utopia-bold-i-normal--19-180-75-75-p-105-iso10646-1
> -adobe-utopia-bold-i-normal--25-180-100-100-p-139-iso10646-1
> -adobe-utopia-bold-i-normal--25-180-100-100-p-139-iso8859-1
> -adobe-utopia-bold-i-normal--25-240-75-75-p-140-iso10646-1
> -adobe-utopia-bold-i-normal--33-240-100-100-p-186-iso10646-1
> -adobe-utopia-bold-i-normal--33-240-100-100-p-186-iso8859-1
>
> And running your program with 
> -adobe-utopia-bold-i-normal--0-0-0-0-p-0-iso8859-1
> produces:
>
> font '-adobe-utopia-bold-i-normal--0-0-0-0-p-0-iso8859-1' loaded as 
> '-adobe-utopia-bold-i-normal--17-120-100-100-p-94-iso8859-1'
>
> Your X behaves pretty strange; I can't explain this just now.
>
> Also, what happens if you specify default font via ~/.Xdefaults
> and run with emacs -q (small 'q', not 'Q')?

Hi. Thank you for looking.

First off, setting the font in the .Xresources has the same effect as
doing it with the lisp snippet on the commandline.

My font configuration is stock from Debian; I didn't mess with it. The
adobe->urw conversion probably comes from
/usr/share/fonts/X11/Type1/fonts.alias which on my machine contains many
lines such as

 -adobe-courier-medium-o-normal--0-0-0-0-p-0-iso8859-2 "-urw-nimbus mono 
l-regular-o-normal--0-0-0-0-p-0-iso8859-2"

That file contains only aliases from scalable fonts to other scalable
fonts, but it's probably the cause in any case.

I do suspect that the adobe->urw conversion is not important here. What
IS important is that we ask Emacs for a particular size 11 font, it
gives back a size 0 (scalable) font, and when you ask X for that size 0
font, you get back a size 17 font. You are seeing this too, apparently.
You asked X for a scalable font

 -adobe-utopia-bold-i-normal--0-0-0-0-p-0-iso8859-1

and X gave you a size-17 font

 -adobe-utopia-bold-i-normal--17-120-100-100-p-94-iso8859-1

So in your case, if you ask Emacs for a size-11 -adobe-utopia-... font
then does Emacs pick a scalable font for you? If so, I would expect
things to not look very good, since you'll get a 17->11 scaling.

The questions for Emacs are:

- Should the candidate font list stay consistent as Emacs runs?
- Should the candidate font list contain any scalable fonts?

The answer to the 1st question is probably "yes". Do you know the answer
to the 2nd? I can keep probing if you tell me which observed behavior is
wrong.

My suspicion is that there's some race condition here that is tickled by
my window manager. I'm using notion, which is a niche WM, so this
wouldn't be widely reported. But even so, it has been working fine for
many years, only regressing 6 months ago or so.

Thanks again





reply via email to

[Prev in Thread] Current Thread [Next in Thread]