From: Sean Whitton <spwhitton@spwhitton.name>
To: Eli Zaretskii <eliz@gnu.org>, 52888@debbugs.gnu.org
Subject: bug#52888: 29.0.50; font_{delete_unmatched,score} do not handle nil FONT_WEIGHT_INDEX
Date: Fri, 31 Dec 2021 17:30:35 -0700 [thread overview]
Message-ID: <87v8z4mh5g.fsf@melete.silentflame.com> (raw)
In-Reply-To: <8335mahr8f.fsf@gnu.org>
Hello,
On Thu 30 Dec 2021 at 08:39PM +02, Eli Zaretskii wrote:
> Does it really make sense to accept these fonts in some situations,
> but not in others? AFAIU, what you suggest would cause Emacs to
> accept these fonts when :weight is not mentioned (and so defaults to
> 'normal'), but to reject them if the 'normal' weight is specified
> explicitly, is that right? If so, it's confusing, and users will
> complain. Rejecting such fonts outright is at least consistent, and
> thus better than semi-support.
Ah, yes, that would indeed be confusing.
> I installed on the release branch a temporary fix, similar to what you
> suggested, to avoid undefined behavior with those fonts, but I don't
> think we should install something like that on master. On master, I
> think ftfont.c and its ilk should be fixed to handle these fonts
> correctly, or reject them if we cannot DTRT with them for some reason.
> I think the fact that we create invalid font entities from such fonts
> is a clear sign that the font backend mishandles them, and if so,
> that's where this problem should be corrected: we should create valid
> font entities to begin with, with ;weight and other similar attributes
> having numerical values, as expected.
I spent some more time in gdb and learned the following.
The ftcrhb backend returns a FcPattern for each of the weights contained
in Inconsolata-VariableFont_wdth,wght.ttf. So Emacs does not need to
learn anything special about these variable weight files in order to
support them, I think. However, this code in ftfont_pattern_entity can
sometimes set FONT_WEIGHT_INDEX to nil:
if (FcPatternGetInteger (p, FC_WEIGHT, 0, &numeric) == FcResultMatch)
{
FONT_SET_STYLE (entity, FONT_WEIGHT_INDEX, make_fixnum (numeric));
}
I haven't yet determined exactly when this can happen, but it suggests
the problem is within FONT_SET_STYLE, as all the backend-specific code
is doing is upplying 'numeric'.
If I might ask a gdb question: to try to determine when this code can
set FONT_WEIGHT_INDEX to nil, I set a breakpoint right after it and then
tried
condition NN NILP (AREF (entity, FONT_WEIGHT_INDEX))
but this didn't work -- is it possible to do something like that?
Thanks.
--
Sean Whitton
next prev parent reply other threads:[~2022-01-01 0:30 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-30 5:28 bug#52888: 29.0.50; font_{delete_unmatched,score} do not handle nil FONT_WEIGHT_INDEX Sean Whitton
2021-12-30 7:33 ` Eli Zaretskii
2021-12-30 17:13 ` Sean Whitton
2021-12-30 18:39 ` Eli Zaretskii
2022-01-01 0:30 ` Sean Whitton [this message]
2022-01-01 2:35 ` Sean Whitton
2022-01-01 7:15 ` Eli Zaretskii
2022-01-01 22:31 ` Sean Whitton
2022-01-03 2:04 ` Sean Whitton
2022-01-05 2:10 ` Sean Whitton
2022-01-05 12:37 ` Eli Zaretskii
2022-01-05 13:55 ` Robert Pluim
2022-01-05 14:08 ` Eli Zaretskii
2022-01-06 5:41 ` Sean Whitton
2022-01-06 12:29 ` Eli Zaretskii
2022-01-06 18:10 ` Sean Whitton
2022-01-12 14:56 ` Eli Zaretskii
2022-01-12 21:41 ` Sean Whitton
2022-01-13 6:52 ` Eli Zaretskii
2022-01-01 6:56 ` Eli Zaretskii
2022-01-01 21:49 ` Can't set conditional break point using AREF/NILP Sean Whitton
2022-01-02 6:42 ` Eli Zaretskii
2022-01-02 22:38 ` Sean Whitton
2022-01-03 12:28 ` Eli Zaretskii
2022-01-04 21:57 ` Sean Whitton
2022-01-05 12:11 ` Eli Zaretskii
2022-01-06 18:20 ` bug#53058: etc/DEBUG could say more about --enable-check-lisp-object-type Sean Whitton
2022-01-06 20:11 ` Eli Zaretskii
2022-01-06 23:46 ` Sean Whitton
2022-01-07 6:58 ` Eli Zaretskii
2022-01-07 20:41 ` Sean Whitton
2022-01-08 6:55 ` Eli Zaretskii
2022-02-03 0:19 ` Sean Whitton
2022-02-03 7:28 ` Eli Zaretskii
2022-01-13 11:54 ` bug#52888: André Silva
2022-01-13 16:40 ` bug#52888: Eli Zaretskii
[not found] ` <CANfyKeBjec0z2c33Fph1=ESr-4ACH0BNKXq_wW-Vtr6sEfJ_VA@mail.gmail.com>
2022-01-13 18:13 ` bug#52888: Eli Zaretskii
[not found] ` <CANfyKeD2-sP4tO0dH0rbjbyD+rR+ahiDgBn+Pnx89EG1iKqiYg@mail.gmail.com>
2022-01-13 19:49 ` bug#52888: Eli Zaretskii
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=87v8z4mh5g.fsf@melete.silentflame.com \
--to=spwhitton@spwhitton.name \
--cc=52888@debbugs.gnu.org \
--cc=eliz@gnu.org \
/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.