Subject: Re: [PATCH] macfont.m: Fix values for font widths and weights on macOS

From: Eli Zaretskii <[email-masked]>
Date: Thu, 01 Feb 2024 12:21:40 +0200

> From: Stanislav Yaglo <[email-masked]>
> Date: Mon, 12 Jun 2023 11:42:53 -0000
> 
> 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.

Thanks, installed on the master branch, and closing the bug.