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

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

[Stanislav Yaglo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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

[-- Attachment #2.1.1: Type: text/html, Size: 3822 bytes --]

[-- Attachment #2.2: 0001-Fix-values-for-font-widths-and-weights-on-macOS.patch --]
[-- Type: application/octet-stream, Size: 5613 bytes --]

From daa36b4ac1f3450168564932299db80c974236be Mon Sep 17 00:00:00 2001
From: Stanislav Yaglo <yaglo@me.com>
Date: Mon, 12 Jun 2023 11:56:37 +0100
Subject: [PATCH] macfont.m: Fix values for font widths and weights on macOS

---
 src/macfont.m | 96 ++++++++++++++++++++++++++++++++++++---------------
 1 file changed, 68 insertions(+), 28 deletions(-)

diff --git a/src/macfont.m b/src/macfont.m
index 9f9f6f4efaf..cb7f937fa0d 100644
--- a/src/macfont.m
+++ b/src/macfont.m
@@ -855,21 +855,42 @@ static void mac_font_get_glyphs_for_variants (CFDataRef, UTF32Char,
       struct {
         enum font_property_index index;
         CFStringRef trait;
-        CGPoint points[6];
-	CGFloat (*adjust_func) (CTFontDescriptorRef, CGFloat);
-      } numeric_traits[] =
-          {{FONT_WEIGHT_INDEX, kCTFontWeightTrait,
-            {{-0.4, 50},	/* light */
-             {-0.24, 87.5},	/* (semi-light + normal) / 2 */
-             {0, 80},		/* normal */
-             {0.24, 140},	/* (semi-bold + normal) / 2 */
-             {0.4, 200},	/* bold */
-             {CGFLOAT_MAX, CGFLOAT_MAX}},
-	    mac_font_descriptor_get_adjusted_weight},
-           {FONT_SLANT_INDEX, kCTFontSlantTrait,
-            {{0, 100}, {0.1, 200}, {CGFLOAT_MAX, CGFLOAT_MAX}}, NULL},
-           {FONT_WIDTH_INDEX, kCTFontWidthTrait,
-            {{0, 100}, {1, 200}, {CGFLOAT_MAX, CGFLOAT_MAX}}, NULL}};
+        CGPoint points[12];
+        CGFloat (*adjust_func) (CTFontDescriptorRef, CGFloat);
+      } numeric_traits[] = {
+        { FONT_WEIGHT_INDEX,
+          kCTFontWeightTrait,
+          { { -0.6, 0 },    /* thin */
+            { -0.4, 40 },   /* ultra-light, ultralight, extra-light, extralight  */
+            { -0.23, 50 },  /* light */
+            { -0.115, 55 }, /* semi-light, semilight, demilight */
+            { 0, 80 },      /* regular, normal, unspecified, book */
+            { 0.2, 100 },   /* medium */
+            { 0.3, 180 },   /* semi-bold, semibold, demibold, demi-bold, demi */
+            { 0.4, 200 },   /* bold */
+            { 0.6, 205 },   /* extra-bold, extrabold, ultra-bold, ultrabold */
+            { 0.8, 210 },   /* black, heavy */
+            { 1, 250 },     /* ultra-heavy, ultraheavy */
+            { CGFLOAT_MAX, CGFLOAT_MAX } },
+          mac_font_descriptor_get_adjusted_weight },
+        { FONT_SLANT_INDEX,
+          kCTFontSlantTrait,
+          { { 0, 100 }, { 0.1, 200 }, { CGFLOAT_MAX, CGFLOAT_MAX } },
+          NULL },
+        { FONT_WIDTH_INDEX,
+          kCTFontWidthTrait,
+          { { -0.4, 50 }, /* ultra-condensed, ultracondensed */
+            { -0.3, 63 }, /* extra-condensed, extracondensed */
+            { -0.2, 75 }, /* condensed, compressed, narrow */
+            { -0.1, 87 }, /* semi-condensed, semicondensed, demicondensed */
+            { 0, 100 },   /* normal, medium, regular, unspecified */
+            { 0.1, 113 }, /* semi-expanded, semiexpanded, demiexpanded */
+            { 0.2, 125 }, /* expanded */
+            { 0.3, 150 }, /* extra-expanded, extraexpanded */
+            { 0.4, 200 }, /* ultra-expanded, ultraexpanded, wide */
+            { CGFLOAT_MAX, CGFLOAT_MAX } },
+          NULL }
+      };
       int i;
 
       for (i = 0; i < ARRAYELTS (numeric_traits); i++)
@@ -1940,19 +1961,38 @@ static int macfont_variation_glyphs (struct font *, int c,
   struct {
     enum font_property_index index;
     CFStringRef trait;
-    CGPoint points[6];
-  } numeric_traits[] =
-      {{FONT_WEIGHT_INDEX, kCTFontWeightTrait,
-        {{-0.4, 50},		/* light */
-         {-0.24, 87.5},		/* (semi-light + normal) / 2 */
-         {0, 100},		/* normal */
-         {0.24, 140},		/* (semi-bold + normal) / 2 */
-         {0.4, 200},		/* bold */
-         {CGFLOAT_MAX, CGFLOAT_MAX}}},
-       {FONT_SLANT_INDEX, kCTFontSlantTrait,
-        {{0, 100}, {0.1, 200}, {CGFLOAT_MAX, CGFLOAT_MAX}}},
-       {FONT_WIDTH_INDEX, kCTFontWidthTrait,
-        {{0, 100}, {1, 200}, {CGFLOAT_MAX, CGFLOAT_MAX}}}};
+    CGPoint points[12];
+  } numeric_traits[] = {
+    { FONT_WEIGHT_INDEX,
+      kCTFontWeightTrait,
+      { { -0.6, 0 },    /* thin */
+        { -0.4, 40 },   /* ultra-light, ultralight, extra-light, extralight  */
+        { -0.23, 50 },  /* light */
+        { -0.115, 55 }, /* semi-light, semilight, demilight */
+        { 0, 80 },      /* regular, normal, unspecified, book */
+        { 0.2, 100 },   /* medium */
+        { 0.3, 180 },   /* semi-bold, semibold, demibold, demi-bold, demi */
+        { 0.4, 200 },   /* bold */
+        { 0.6, 205 },   /* extra-bold, extrabold, ultra-bold, ultrabold */
+        { 0.8, 210 },   /* black, heavy */
+        { 1, 250 },     /* ultra-heavy, ultraheavy */
+        { CGFLOAT_MAX, CGFLOAT_MAX } } },
+    { FONT_SLANT_INDEX,
+      kCTFontSlantTrait,
+      { { 0, 100 }, { 0.1, 200 }, { CGFLOAT_MAX, CGFLOAT_MAX } } },
+    { FONT_WIDTH_INDEX,
+      kCTFontWidthTrait,
+      { { -0.4, 50 }, /* ultra-condensed, ultracondensed */
+        { -0.3, 63 }, /* extra-condensed, extracondensed */
+        { -0.2, 75 }, /* condensed, compressed, narrow */
+        { -0.1, 87 }, /* semi-condensed, semicondensed, demicondensed */
+        { 0, 100 },   /* normal, medium, regular, unspecified */
+        { 0.1, 113 }, /* semi-expanded, semiexpanded, demiexpanded */
+        { 0.2, 125 }, /* expanded */
+        { 0.3, 150 }, /* extra-expanded, extraexpanded */
+        { 0.4, 200 }, /* ultra-expanded, ultraexpanded, wide */
+        { CGFLOAT_MAX, CGFLOAT_MAX } } }
+  };
 
   registry = AREF (spec, FONT_REGISTRY_INDEX);
   if (NILP (registry)
-- 
2.39.2 (Apple Git-143)

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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.

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]

[-- 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 --]

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

[Stanislav Yaglo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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@yahoo.com> wrote:
> 
> 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.

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

[Eli Zaretskii]

> 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.