bug#64013: closed ([PATCH] macfont.m: Fix values for font widths and weights on macOS)

[GNU bug Tracking System]

Your message dated Thu, 01 Feb 2024 12:21:40 +0200
with message-id <86y1c4zdqj.fsf@gnu.org>
and subject line Re: [PATCH] macfont.m: Fix values for font widths and weights 
on macOS
has caused the debbugs.gnu.org bug report #64013,
regarding [PATCH] macfont.m: Fix values for font widths and weights on macOS
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
64013: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64013
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: [PATCH] macfont.m: Fix values for font widths and weights on macOS Date: Mon, 12 Jun 2023 11:42:53 -0000

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

0001-Fix-values-for-font-widths-and-weights-on-macOS.patch
Description: Binary data

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: [PATCH] macfont.m: Fix values for font widths and weights on macOS
>
>
>
>
> Date: 
>
> Thu, 01 Feb 2024 12:21:40 +0200
>
>
>
>
> > From: Stanislav Yaglo <yaglo@me.com>
> > 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.
>
>
> --- End Message ---