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

["yaglo@me.com" via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 3301 bytes --]

I’m in the process of sorting the paperwork with my employer as well. I will send an update to this thread when it’s confirmed and the copyright papers have been signed.

Kind regards,
Stanislav Yaglo
________________________________
From: bug-gnu-emacs-bounces+yaglo=me.com@gnu.org <bug-gnu-emacs-bounces+yaglo=me.com@gnu.org> on behalf of Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs@gnu.org>
Sent: Monday, June 12, 2023 2:31:11 PM
To: Stanislav Yaglo <yaglo@me.com>
Cc: 64013@debbugs.gnu.org <64013@debbugs.gnu.org>; YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
Subject: bug#64013: [PATCH] macfont.m: Fix values for font widths and weights on macOS

Stanislav Yaglo <yaglo@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@math.s.chiba-u.ac.jp>,
who might have additional comments on this code.




[-- Attachment #2: Type: text/html, Size: 4499 bytes --]