GNU bug report logs -
#64013
[PATCH] macfont.m: Fix values for font widths and weights on macOS
Previous Next
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.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64013 in the body.
You can then email your comments to 64013 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64013; Package
emacs.
(Mon, 12 Jun 2023 12:34:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stanislav Yaglo <yaglo <at> me.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 12 Jun 2023 12:34:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]
[0001-Fix-values-for-font-widths-and-weights-on-macOS.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64013; Package
emacs.
(Mon, 12 Jun 2023 13:32:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 64013 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64013; Package
emacs.
(Mon, 12 Jun 2023 16:10:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 64013 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> gnu.org <bug-gnu-emacs-bounces+yaglo=me.com <at> gnu.org> on behalf of Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org>
Sent: Monday, June 12, 2023 2:31:11 PM
To: Stanislav Yaglo <yaglo <at> me.com>
Cc: 64013 <at> debbugs.gnu.org <64013 <at> debbugs.gnu.org>; YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: bug#64013: [PATCH] macfont.m: Fix values for font widths and weights on macOS
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.
[Message part 2 (text/html, inline)]
Added tag(s) pending.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sun, 03 Sep 2023 11:52:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64013; Package
emacs.
(Fri, 08 Sep 2023 12:44:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 64013 <at> debbugs.gnu.org (full text, mbox):
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.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Thu, 01 Feb 2024 10:23:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Stanislav Yaglo <yaglo <at> me.com>:
bug acknowledged by developer.
(Thu, 01 Feb 2024 10:23:02 GMT)
Full text and
rfc822 format available.
Message #21 received at 64013-done <at> debbugs.gnu.org (full text, mbox):
> From: Stanislav Yaglo <yaglo <at> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 29 Feb 2024 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 69 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.