GNU bug report logs - #64013
[PATCH] macfont.m: Fix values for font widths and weights on macOS

Previous Next

Package: emacs;

Reported by: Stanislav Yaglo <yaglo <at> me.com>

Date: Mon, 12 Jun 2023 12:34:02 UTC

Severity: normal

Tags: patch

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #16 received at 64013 <at> debbugs.gnu.org (full text, mbox):

From: Stanislav Yaglo <yaglo <at> me.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 64013 <at> debbugs.gnu.org, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#64013: [PATCH] macfont.m: Fix values for font widths and
 weights on macOS
Date: Fri, 8 Sep 2023 10:34:08 +0100
Hi,

Update - I’ve sorted the copyright assignment docs, so everything should be good to move forward.

Kind regards,
Stanislav Yaglo

> On 12 Jun 2023, at 14:31, Po Lu <luangruo <at> yahoo.com> wrote:
> 
> Stanislav Yaglo <yaglo <at> me.com> writes:
> 
>> Hi everyone,
>> 
>> Currently, on macOS, font weights are not handled correctly, which causes Emacs to choose different font weights and widths than what you
>> request. As one example, if you want to choose "Cascadia Code:weight=semi-light", you will get Cascadia Code Light instead. Same for font
>> widths, what you specify is not always what you get.
>> 
>> There's some interpolation going on which I didn't remove as it's potentially handy for in-between values, but the problem itself is that the
>> corresponding values are not correct for the majority of fonts, for example, kCTFontWeightTrait is specified as -0.24 corresponding to 87.5 , but
>> in reality, it is usually 50 (light), and the same for the other values. As you can see here, it won't work as we have 50 followed by 87.5 and then
>> (a lower) 80, and then 140:
>> 
>> {-0.4, 50},      /* light */
>> {-0.24, 87.5},   /* (semi-light + normal) / 2 */
>> {0, 80},         /* normal */
>> {0.24, 140},     /* (semi-bold + normal) / 2 */
>> 
>> It probably is a typo, as in the second (duplicate) table of values in the code, 100 is treated as normal instead of 80, which also isn't correct, as
>> 100 is medium, not normal:
>> 
>> {-0.4, 50},      /* light */
>> {-0.24, 87.5},   /* (semi-light + normal) / 2 */
>> {0, 100},        /* normal */
>> {0.24, 140},     /* (semi-bold + normal) / 2 */
>> 
>> For font widths, there's only two kCTFontWidthTrait values in the range that are handled currently — from 0 to 1, and they are handled as
>> linear font values from 100 to 200, which isn't correct either. For condensed fonts, kCTFontWidthTrait is negative, which is not accounted for,
>> and the slope is linear only from -0.4 (50, ultra-condensed) until 0.2 (125, expanded), and from there until ultra-expanded is much steeper.
>> 
>> I've included all values that are listed in font.c for explicitness even if some values can be calculated with the code that interpolates the values.
>> Also, I haven't refactored the duplication of the structs and code as I think this is a different issue and should be done separately to keep this
>> patch on point of the issue being fixed, and I will probably submit a patch for this later to avoid code duplication and potential issues in the
>> future as with the current 80/100 problem mentioned above.
>> 
>> Kind regards,
>> Stanislav Yaglo
> 
> Thanks.  Have you signed copyright papers for this change?
> I've also copied in YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
> who might have additional comments on this code.




This bug report was last modified 1 year and 116 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.