From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dima Kogan Newsgroups: gmane.emacs.bugs Subject: bug#19117: 25.0.50; emacs on x11 chooses different fonts for the same face sometimes Date: Tue, 16 Dec 2014 21:36:14 -0800 Message-ID: <87r3vykdse.fsf@secretsauce.net> References: <878uj674zh.fsf@secretsauce.net> <831tox7t03.fsf@gnu.org> <87a92zrj4b.fsf@secretsauce.net> <83egsbzbfu.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418796625 28240 80.91.229.3 (17 Dec 2014 06:10:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Dec 2014 06:10:25 +0000 (UTC) Cc: 19117@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 17 07:10:19 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y17oP-0006O3-Ui for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 Dec 2014 07:10:18 +0100 Original-Received: from localhost ([::1]:48039 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y17oP-00083y-FV for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 Dec 2014 01:10:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y17oH-00083O-Cg for bug-gnu-emacs@gnu.org; Wed, 17 Dec 2014 01:10:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y17oC-0001QN-3p for bug-gnu-emacs@gnu.org; Wed, 17 Dec 2014 01:10:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y17oB-0001Pt-TO for bug-gnu-emacs@gnu.org; Wed, 17 Dec 2014 01:10:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y17oB-00063R-1v for bug-gnu-emacs@gnu.org; Wed, 17 Dec 2014 01:10:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dima Kogan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Dec 2014 06:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19117-submit@debbugs.gnu.org id=B19117.141879660123265 (code B ref 19117); Wed, 17 Dec 2014 06:10:02 +0000 Original-Received: (at 19117) by debbugs.gnu.org; 17 Dec 2014 06:10:01 +0000 Original-Received: from localhost ([127.0.0.1]:48353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y17o7-00062w-M4 for submit@debbugs.gnu.org; Wed, 17 Dec 2014 01:10:01 -0500 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]:56193) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y17o4-00062m-Fr for 19117@debbugs.gnu.org; Wed, 17 Dec 2014 01:09:58 -0500 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DB4F620861 for <19117@debbugs.gnu.org>; Wed, 17 Dec 2014 01:09:55 -0500 (EST) Original-Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 17 Dec 2014 01:09:55 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=secretsauce.net; h=x-sasl-enc:references:from:to:cc:subject:date:in-reply-to :message-id:mime-version:content-type; s=mesmtp; bh=iIk/CWutDoqR HYamWzvVXLrscko=; b=YreXT2B2if9l2zcY4EUq2BgJIh5P73u7R2BFMWUmP4lq OHz08p/057nHiHSJWFvvRnV4Zq80/+UweZ8Sg6PsVxZ+WFGnL1yHESNRemfxsby+ VseLxxNGfbp8SxdgmK0tOvdFnaV3mLmBGbgLtf05R5NUTcgznR9FhYJf3gCPzDk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:references:from:to:cc:subject :date:in-reply-to:message-id:mime-version:content-type; s= smtpout; bh=iIk/CWutDoqRHYamWzvVXLrscko=; b=OCqUi4hsprRh+wOE8vtj pc1DD9mfyiITT5YCUPa9BnTWpTD/v1WC4Je/yBxWmqNSTbvdG5eaMZqR+QzeIzyF 16jEP3cHA+FU0fHeP0F0lWK9GwQ0TEzNF9zIRYV+C19qiDdxFEAiJ35MSpUK/EQY 2NzZRFvDtT+U2NQ969Xqmvs= X-Sasl-enc: an05dqKH7f0LxkctdBZpVUW3roOpQRB9LbJKllhzIRmp 1418796595 Original-Received: from shorty.local (unknown [76.91.145.213]) by mail.messagingengine.com (Postfix) with ESMTPA id 6C05068009D; Wed, 17 Dec 2014 01:09:55 -0500 (EST) Original-Received: from dima by shorty.local with local (Exim 4.84) (envelope-from ) id 1Y17o1-0002gP-W9; Tue, 16 Dec 2014 22:09:54 -0800 In-reply-to: <83egsbzbfu.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:97433 Archived-At: Eli Zaretskii writes: >> From: Dima Kogan >> Date: Sat, 06 Dec 2014 23:28:34 -0800 >> >> > Put a breakpoint where Emacs loads new fonts, and see who calls that >> > code. >> >> I'm digging through the code. It's slow going so far, but I'm getting >> more familiar with it. In my init.el I have in my default-frame-alist >> >> (font . "-adobe-courier-medium-r-*-*-*-80-*-*-m-*-iso8859-1") I just dumped more time into this, and have more information, some of it (hopefully) actionable. I just built a optimization-free copy of emacs from the latest git: e2815bf. This uses the lucid UI. I'm on a recent Debian/sid box. This allows me to use gdb effectively. I also have a mostly reproducible way to both break it and to fix it with emacs -Q. I suspect this recipe is dependent on my window manager and font setup, so it probably wouldn't trigger failures on other boxes, but it's useful to illustrate what I'm doing. Recipe: 1. emacs -Q --eval "(progn (custom-set-variables '(default-frame-alist '( (font . \"-adobe-courier-medium-r-*-*-*-80-*-*-m-*-iso8859-1\")))) (kill-new \"(face-font \\\"italic\\\")\"))" 2. M-: (face-font "italic") The commandline eval places this string into the kill-ring so you can simply M-: C-y, but this is a detail. I expect it to give me an -adobe-courier font, but at this point it gives me an (ugly) -urw-.... font. Happens about 80% of the time 3. C-x 5 2 New frame 4. Kill that new frame with my window manager 5. M-: (face-font "italic") Same font lookup as before. This time it gives me the correct font. I traced various parts of the data flow. Internally emacs generates a list of candidate fonts, scores each one against the requested font spec, and picks the font with the best score. The issue is two-fold: - The list of candidate fonts changes over time. This is why the issue self-corrects - In the above recipe, the "right" font is in the list both times, however the first (wrong) time there's another candidate in the list that scores highly, and produces an ugly result The top-level code flow is font_find_for_lface() calls font_list_entities() to get the candidate font list and font_select_entity() to pick the best candidate; this calls font_sort_entities() which calls font_score() to evaluate a specific candidate The "reference" font that font_score() is asked to match appears to always be # In font_list_entities(), need_filtering = 0 is always true. When the incorrect font is chosen at the start I see that font_list_entities() gets a list of fonts from the cache (not from the driver; driver_list->driver->list() is not invoked here). font_list_entities() returns this candidate list (a vector): # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # font_score() is given a subset of these. Candidates and returned scores: | font | score | |--------------------------------------------------------------------------------+---------| | # | 393616 | | # | | | # | | | # | | | # | 1180048 | | # | 917904 | | # | 786832 | | # | 393616 | | # | 393616 | | # | 131472 | | # | 400 | | # | 131472 | | # | 400 | | # | 393256 | | # | | | # | | | # | | | # | 1179688 | | # | 917544 | | # | 786472 | | # | 393256 | | # | 393256 | | # | 131112 | | # | 40 | | # | 131112 | | # | 40 | | # | 0 | Fonts with blank scores are disqualified. Lower scores are better, so the last font with a score of 0 is chosen. This, unfortunately produces poor results. When the correct font is chosen further down in the recipe, I see that font_list_entities() again gets a list of fonts from the cache: # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # and the corresponding scores: | font | score | |--------------------------------------------------------------------------------+---------| | # | 393616 | | # | | | # | | | # | | | # | 1180048 | | # | 917904 | | # | 786832 | | # | 393616 | | # | 393616 | | # | 131472 | | # | 400 | | # | 131472 | | # | 393256 | | # | | | # | | | # | | | # | 1179688 | | # | 917544 | | # | 786472 | | # | 393256 | | # | 393256 | | # | 131112 | | # | 40 | | # | 131112 | | # | 444816 | | # | | | # | | | # | | | # | 1231248 | | # | 969104 | | # | 838032 | | # | 444816 | | # | 444816 | | # | 182672 | | # | 51600 | | # | 182672 | | # | 444456 | | # | | | # | | | # | | | # | 1230888 | | # | 968744 | | # | 837672 | | # | 444456 | | # | 444456 | | # | 182312 | | # | 51240 | | # | 182312 | The best font has a score of 40, and it is the "right" answer. I'm not an expert, but it seems wrong to me that the candidate list does not stay constant. Furthermore, it's odd that the bold fonts are not passed to font_score() during the "bad" pass, but ARE passed to it during the "good" pass. Furthermore, the fonts that have "0 0 0 0" all score relatively well in the "bad" pass, and the best match is one of those. In the "good" pass those "0 0 0 0" fonts aren't there at all. I'm going to stop investigating for today. If this is enough for somebody knowledgeable to investigate, then that's great. Otherwise I'll keep digging myself later. What's the "right" behavior? I suspect that blocking out the "0 0 0 0" fonts would be sufficient to solve my issue, but wouldn't address the other things that look wrong and possibly are an issue for others.