From: Dima Kogan <dima@secretsauce.net>
To: "Jan Djärv" <jan.h.d@swipnet.se>
Cc: 19117@debbugs.gnu.org
Subject: bug#19117: 25.0.50; emacs on x11 chooses different fonts for the same face sometimes
Date: Fri, 26 Dec 2014 11:43:36 -0800 [thread overview]
Message-ID: <87bnmqi1ps.fsf@secretsauce.net> (raw)
In-Reply-To: <5497D623.7040406@swipnet.se>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 3305 bytes --]
Jan Djärv <jan.h.d@swipnet.se> writes:
> Den 2014-12-19 23:46, Dima Kogan skrev:
>
>> 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.
>
> The answer to the first one is no. Or rather, it is out of Emacs control.
> Since you are using non-client fonts, the list is determined by the X- or
> font-server. The fact that you can get two matches suggests that your font
> spec is underspecified, if your goal is to get just one specific font.
>
> I see no bug here.
Hi. The observed behavior (same face getting different fonts of varying
ugliness over time) cannot be considered correct, but I cannot yet say
where the bad behavior lies. It could be in Emacs or X or the Debian
font configuration.
Looking at this some more, I'm now more confused than when I started.
Any enlightenment is welcome.
To summarize the earlier findings:
- Emacs is asked for a font that matches the spec
#<font-spec nil nil nil nil nil medium italic normal 11 nil nil nil nil>
- The font chosen by emacs can vary here. When it chooses the "ugly"
path, it picks
#<font-entity x adobe courier ## iso8859-1 medium i normal 0 0 0 0 nil>
- When X is asked for a corresponding font
-adobe-courier-medium-i-normal-*-0-0-0-0-p-0-iso8859-1
it actually loads
-urw-nimbus mono l-regular-o-normal--17-120-100-100-p-100-iso8859-1
Note that we originally sought an 11-px font, but got a 17-px one
instead.
OK. So the hypothesis is that the 11-px version of that 17-px urw font
does not exist, hence it's down-scaling the 17-px version. However,
apparently I can do
xfontsel -pattern "-urw-nimbus mono l-regular-o-normal--11-*-*-*-p-70-iso8859-1"
and it works. I.e. xfontsel doesn't complain that the font doesn't
exist, it simply shows me the ugly 11-px font I'm complaining about.
I don't think this font actually exists (it's ugly; a human would not
draw it). However if I ask the font system whether it exists or not, it
unambiguously says yes:
$ xlsfonts -fn "-urw-nimbus mono l-regular-o-normal--11-*-*-*-p-70-iso8859-1"
-urw-nimbus mono l-regular-o-normal--11-79-100-100-p-70-iso8859-1
However, when I use a wildcard for the font size, (so * instead of 11),
it reports that the 11-px font does NOT exist, but a 17-px one does:
$ xlsfonts -fn "-urw-nimbus mono l-regular-o-normal--*-*-*-*-p-70-iso8859-1"
-urw-nimbus mono l-regular-o-normal--17-120-100-100-p-70-iso8859-1
This 17-px font looks good in xfontsel, but it's obviously bigger than
the 11-px one.
It looks like the font specs have a pixel-size and a point-size, (11-79)
and (17-120), with the ratio staying roughly constant in either case, so
the 11-79 is almost certainly a scaled version of 17-120. Problem is
that the rendering is based on the px-size only, so it looks like crap.
Is this how X fonts are supposed to work? What if Emacs treated scalable
fonts by looking at the actual px-sizes that were available (17 in this
case) and only evaluating those? Would that be a reasonable thing to do?
I can work on an implementation if it is.
Thanks
next prev parent reply other threads:[~2014-12-26 19:43 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-20 6:13 bug#19117: 25.0.50; emacs on x11 chooses different fonts for the same face sometimes Dima Kogan
2014-11-20 16:10 ` Eli Zaretskii
2014-12-07 7:28 ` Dima Kogan
2014-12-07 16:12 ` Eli Zaretskii
2014-12-17 5:36 ` Dima Kogan
2014-12-17 6:57 ` Dima Kogan
2014-12-18 16:24 ` Eli Zaretskii
2014-12-20 8:08 ` Jan Djärv
2014-12-19 15:28 ` Dmitry Antipov
2014-12-19 22:46 ` Dima Kogan
2014-12-22 8:01 ` Dmitry Antipov
2014-12-22 8:28 ` Jan Djärv
2014-12-26 19:43 ` Dima Kogan [this message]
2014-12-27 2:17 ` Stefan Monnier
2014-12-27 9:17 ` Dima Kogan
2014-12-30 9:44 ` Dima Kogan
2014-12-30 16:57 ` Stefan Monnier
2014-12-30 18:33 ` Dima Kogan
2014-12-30 20:05 ` Eli Zaretskii
2014-12-31 4:06 ` Dima Kogan
2015-01-02 9:43 ` Eli Zaretskii
2015-01-02 21:07 ` Dima Kogan
2015-02-02 8:10 ` Dima Kogan
2015-02-03 17:53 ` Stefan Monnier
2015-02-05 2:41 ` handa
2015-02-15 13:47 ` K. Handa
2015-02-05 15:08 ` Jan D.
2015-02-05 20:41 ` Dima Kogan
2015-02-07 7:24 ` Jan D.
2015-02-07 7:59 ` Jan D.
2015-02-07 8:28 ` Dima Kogan
2015-02-09 14:58 ` Jan D.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bnmqi1ps.fsf@secretsauce.net \
--to=dima@secretsauce.net \
--cc=19117@debbugs.gnu.org \
--cc=jan.h.d@swipnet.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.