unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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





  reply	other threads:[~2022-01-01  0:30 UTC|newest]

Thread overview: 32+ 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
     [not found]           ` <87pmpbm8j2.fsf@melete.silentflame.com>
     [not found]             ` <83v8z2eizk.fsf@gnu.org>
     [not found]               ` <87pmp9wyo3.fsf@melete.silentflame.com>
     [not found]                 ` <83r19pc8ax.fsf@gnu.org>
     [not found]                   ` <87v8yzb1v7.fsf@melete.silentflame.com>
     [not found]                     ` <83v8yy9ybv.fsf@gnu.org>
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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).