bug#32210: Support medium weighted fonts

bug#32210: Support medium weighted fonts

[Carlos Pita]

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

(I'm unable to access my emacs now so sorry for reporting this from my
phone. Ask for any additional details and I will provide them ASAP.)

Many programming fonts are designed for hidpi devices and look pretty bad
(too thin and "diffused") in their default weight in antialiased settings
with standard resolution screen.

Nevertheless a number of fontsets provide medium and/or demibold variants
in between the regular one and the bold one. For example, the medium
SauceCodePro (based on SourceCodePro) looks much solid than the regular
variant.

Now, the problem is that, no matter how emacs font is configured
(xresources with xft or gtk descriptor, customize-face, the standard gtk
dialog launched from the menu) medium is taken as an alias for
normal/regular and you have to jump from regular to demibold.

One good example is the aforementioned font. In xfce4-terminal I get all
regular, medium and demibold variants. Medium is a nice default weight,
demibold being too close to bold for regular usage. In emacs I get only the
too thin regular weight (using regular or medium weights) or the too fat
demibold (using demi/semibold).

I think this is a relevant issue since emacs is mostly a programmer's tool
and being unable to use the best font in a set designed for programming is
not just a minor annoyance.

One general solution would be to allow numerical values for weight, but
nevertheless the medium symbol should be assigned the right meaning.

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

bug#32210: Support medium weighted fonts

[Lars Ingebrigtsen]

Carlos Pita <carlosjosepita@gmail.com> writes:

> Many programming fonts are designed for hidpi devices and look pretty
> bad (too thin and "diffused") in their default weight in antialiased
> settings with standard resolution screen.
>
> Nevertheless a number of fontsets provide medium and/or demibold variants in
> between the regular one and the bold one. For example, the medium
> SauceCodePro (based on SourceCodePro) looks much solid than the regular
> variant.
>
> Now, the problem is that, no matter how emacs font is configured
> (xresources with xft or gtk descriptor, customize-face, the standard
> gtk dialog launched from the menu) medium is taken as an alias for
> normal/regular and you have to jump from regular to demibold.

I think this is the culprit:

static const struct table_entry weight_table[] =
{
  { 0, { "thin" }},
  { 20, { "ultra-light", "ultralight" }},
  { 40, { "extra-light", "extralight" }},
  { 50, { "light" }},
  { 75, { "semi-light", "semilight", "demilight", "book" }},
  { 100, { "normal", "medium", "regular", "unspecified" }},
  { 180, { "semi-bold", "semibold", "demibold", "demi" }},
  { 200, { "bold" }},
  { 205, { "extra-bold", "extrabold" }},
  { 210, { "ultra-bold", "ultrabold", "black" }}
};

We define "medium" the same as "regular", but there are many fonts that
have both "regular" and "medium" variants, if I understand things
correctly.  Googling around a bit, it seems that most pages that
describe these things put "medium" at the halfway point between
"regular" and "demibold", which would mean a value of 140 for Emacs.

For instance:

https://www.quora.com/What-is-the-difference-between-Medium-Demi-and-Semibold-fonts
https://cssreference.io/property/font-weight/

Those are from a web/TrueType perspective, though.

Anybody have any thoughts on this issue?  The medium/regular
non-distinction in Emacs seems to crop up here and there, so it's a
problem in practice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32210: Support medium weighted fonts

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 17 Nov 2019 09:37:45 +0100
> Cc: 32210@debbugs.gnu.org
> 
> > Now, the problem is that, no matter how emacs font is configured
> > (xresources with xft or gtk descriptor, customize-face, the standard
> > gtk dialog launched from the menu) medium is taken as an alias for
> > normal/regular and you have to jump from regular to demibold.
> 
> I think this is the culprit:
> 
> static const struct table_entry weight_table[] =
> {
>   { 0, { "thin" }},
>   { 20, { "ultra-light", "ultralight" }},
>   { 40, { "extra-light", "extralight" }},
>   { 50, { "light" }},
>   { 75, { "semi-light", "semilight", "demilight", "book" }},
>   { 100, { "normal", "medium", "regular", "unspecified" }},
>   { 180, { "semi-bold", "semibold", "demibold", "demi" }},
>   { 200, { "bold" }},
>   { 205, { "extra-bold", "extrabold" }},
>   { 210, { "ultra-bold", "ultrabold", "black" }}
> };

I don't think this is the only place.  For example,
XG_WEIGHT_TO_SYMBOL looks also relevant.  And there are other places
in the sources that only support subsets of all the weights.  If we
want to make them more fine-grained, we should make them all
consistent, as much as possible, modulo the limitations of the
toolkit.  For example, Someone™ should verify that the problem
described above is not some inherent GTK limitation.

bug#32210: Support medium weighted fonts

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think this is the only place.  For example,
> XG_WEIGHT_TO_SYMBOL looks also relevant.

Interesting...

#define XG_WEIGHT_TO_SYMBOL(w)			\
  (w <= PANGO_WEIGHT_THIN ? Qextra_light	\
   : w <= PANGO_WEIGHT_ULTRALIGHT ? Qlight	\
   : w <= PANGO_WEIGHT_LIGHT ? Qsemi_light	\
   : w < PANGO_WEIGHT_MEDIUM ? Qnormal		\
   : w <= PANGO_WEIGHT_SEMIBOLD ? Qsemi_bold	\
   : w <= PANGO_WEIGHT_BOLD ? Qbold		\
   : w <= PANGO_WEIGHT_HEAVY ? Qextra_bold	\
   : Qultra_bold)

If we look at

https://abi-laboratory.pro/?view=headers_diff&l=pango&v1=1.36.5&v2=1.36.6

we find

* @PANGO_WEIGHT_NORMAL: the default weight (= 400)
* @PANGO_WEIGHT_MEDIUM: the normal weight (= 500; Since: 1.24)

so Pando has also grown a MEDIUM in addition to NORMAL...  and we don't
have PANGO_WEIGHT_NORMAL.

> And there are other places in the sources that only support subsets of
> all the weights.  If we want to make them more fine-grained, we should
> make them all consistent, as much as possible, modulo the limitations
> of the toolkit.

Yup.  

> For example, Someone™ should verify that the problem described above
> is not some inherent GTK limitation.

If we look at

https://emacs.stackexchange.com/questions/32377/selecting-correct-font-weight-variant-linux

people seem to be instructing Emacs to use the sizes adjacent to Emacs
normal/medium to actually get the weights they want, and then it works.
Also see bug#28351 (which I've merged with this one).

But is this something we want to tweak before Emacs 27, or should it
wait for Emacs 28?  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32210: Support medium weighted fonts

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: carlosjosepita@gmail.com,  32210@debbugs.gnu.org
> Date: Sun, 17 Nov 2019 18:06:51 +0100
> 
> #define XG_WEIGHT_TO_SYMBOL(w)			\
>   (w <= PANGO_WEIGHT_THIN ? Qextra_light	\
>    : w <= PANGO_WEIGHT_ULTRALIGHT ? Qlight	\
>    : w <= PANGO_WEIGHT_LIGHT ? Qsemi_light	\
>    : w < PANGO_WEIGHT_MEDIUM ? Qnormal		\
>    : w <= PANGO_WEIGHT_SEMIBOLD ? Qsemi_bold	\
>    : w <= PANGO_WEIGHT_BOLD ? Qbold		\
>    : w <= PANGO_WEIGHT_HEAVY ? Qextra_bold	\
>    : Qultra_bold)
> 
> If we look at
> 
> https://abi-laboratory.pro/?view=headers_diff&l=pango&v1=1.36.5&v2=1.36.6
> 
> we find
> 
> * @PANGO_WEIGHT_NORMAL: the default weight (= 400)
> * @PANGO_WEIGHT_MEDIUM: the normal weight (= 500; Since: 1.24)

For more amusement, see

  https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createfonta

Who copycats whom?

> so Pando has also grown a MEDIUM in addition to NORMAL...  and we don't
> have PANGO_WEIGHT_NORMAL.

A related question is: can the GTK font selection dialog return
PANGO_WEIGHT_MEDIUM (when you choose a font with that weight)?

> > And there are other places in the sources that only support subsets of
> > all the weights.  If we want to make them more fine-grained, we should
> > make them all consistent, as much as possible, modulo the limitations
> > of the toolkit.
> 
> Yup.  
> 
> > For example, Someone™ should verify that the problem described above
> > is not some inherent GTK limitation.
> 
> If we look at
> 
> https://emacs.stackexchange.com/questions/32377/selecting-correct-font-weight-variant-linux
> 
> people seem to be instructing Emacs to use the sizes adjacent to Emacs
> normal/medium to actually get the weights they want, and then it works.
> Also see bug#28351 (which I've merged with this one).

I think there's still more to this.  From reading various parts of
font.c I get the impression that Fontconfig supports only a subset of
the above values.  Or maybe it did in the past, when font.c was coded,
and nowadays supports more?

Also see the node "Fonts" n the user manual, where it describes no
less than 4 different methods of specifying a font, each one with a
different repertoire of "weight" values.  

So not only the toolkit matters here, but also the font configuration
back-end (Fontconfig and FreeType on Posix platforms) etc., and we use
different font specifications in different commands, which sometimes
exposes the differences.  We need to bring them all to the common
denominator, and it has to be not the lowest one.

> But is this something we want to tweak before Emacs 27, or should it
> wait for Emacs 28?  

It depends what kind of tweaking will be needed.  If we just need to
change a bunch of constants and augment several switch statements that
convert between representations, it might be safe enough for Emacs 27.
E.g., see the change I just installed in w32font.c for bug#24226.

bug#32210: Support medium weighted fonts

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> so Pando has also grown a MEDIUM in addition to NORMAL...  and we don't
>> have PANGO_WEIGHT_NORMAL.
>
> A related question is: can the GTK font selection dialog return
> PANGO_WEIGHT_MEDIUM (when you choose a font with that weight)?

I installed the following debugging

diff --git a/src/gtkutil.c b/src/gtkutil.c
index c4d2ef9d80..b1b3e4c397 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -2300,6 +2300,10 @@ xg_get_font (struct frame *f, const char *default_name)
 	  PangoWeight weight = pango_font_description_get_weight (desc);
 	  PangoStyle  style  = pango_font_description_get_style (desc);
 
+	  CALLN (Fmessage, build_string ("Weight: %s, symbol %s"),
+		 make_int (weight),
+		 XG_WEIGHT_TO_SYMBOL (weight));
+ 
 	  font = CALLN (Ffont_spec,
 			QCfamily, build_string (family),
 			QCsize, make_float (pango_units_to_double (size)),

and tried using the gtk selector (via M-x menu-set-font).  I only have
one font installed that has both normal and medium variations "Nimbus
no9", so I tried that.  And I got:

Weight: 400, symbol normal
Weight: 700, symbol bold

And, yes, the thing that's called Nimbus No9 Medium does look like a
bold in both the gtk selector and in Emacs.  So I don't think I have a
proper font to experiment with...  does anybody know of a font in Debian
Stable that has both varieties?  SauceCodePro was the example in the
bug report, but that does not seem to be available here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32210: Support medium weighted fonts

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So I don't think I have a proper font to experiment with...  does
> anybody know of a font in Debian Stable that has both varieties?
> SauceCodePro was the example in the bug report, but that does not seem
> to be available here.

Found one -- "apt install ubuntu-font".

I chose "Ubuntu Regular" and "Ubuntu Medium":

Weight: 400, symbol normal
Weight: 500, symbol semi-bold

And: Added wrinkle: In Emacs, the "Regular" font is heavier than the
"Medium" font (but they're not in the Gtk selector).

This is all very confusing.

If I say

emacs -Q -fn "Ubuntu:weight=regular" 
emacs -Q -fn "Ubuntu:weight=medium" 

I get the more expected result (i.e., identical display in Emacs since
we map both of these to the same thing in other parts of Emacs).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32210: Support medium weighted fonts

[Robert Pluim]

>>>>> On Mon, 18 Nov 2019 11:28:49 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:
    Lars> and tried using the gtk selector (via M-x menu-set-font).  I only have
    Lars> one font installed that has both normal and medium variations "Nimbus
    Lars> no9", so I tried that.  And I got:

    Lars> Weight: 400, symbol normal
    Lars> Weight: 700, symbol bold

    Lars> And, yes, the thing that's called Nimbus No9 Medium does look like a
    Lars> bold in both the gtk selector and in Emacs.  So I don't think I have a
    Lars> proper font to experiment with...  does anybody know of a font in Debian
    Lars> Stable that has both varieties?  SauceCodePro was the example in the
    Lars> bug report, but that does not seem to be available here.

I tried here with 'Noto Sans CJK HK', which seems to have every
variant under the sun, and got:

Weight: 400, symbol normal
Weight: 500, symbol semi-bold

I donʼt know if Debian Stable has that font.

Robert

bug#32210: Support medium weighted fonts

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: carlosjosepita@gmail.com,  32210@debbugs.gnu.org
> Date: Mon, 18 Nov 2019 11:41:42 +0100
> 
> I chose "Ubuntu Regular" and "Ubuntu Medium":
> 
> Weight: 400, symbol normal
> Weight: 500, symbol semi-bold
> 
> And: Added wrinkle: In Emacs, the "Regular" font is heavier than the
> "Medium" font (but they're not in the Gtk selector).

Sorry, I don't understand: is this "wrinkle" due to the font, or is
this something Emacs does?  If the latter, can you point out where we
treat "regular" heavier than "medium"?

bug#32210: Support medium weighted fonts

[Lars Ingebrigtsen]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> I chose "Ubuntu Regular" and "Ubuntu Medium":
>> 
>> Weight: 400, symbol normal
>> Weight: 500, symbol semi-bold
>> 
>> And: Added wrinkle: In Emacs, the "Regular" font is heavier than the
>> "Medium" font (but they're not in the Gtk selector).
>
> Sorry, I don't understand: is this "wrinkle" due to the font, or is
> this something Emacs does?  If the latter, can you point out where we
> treat "regular" heavier than "medium"?

When choosing the font via the Gtk selector, the font named "Ubuntu
Regular" in the selector is less heavy than the font named "Ubuntu
Medium" in the selector, but in Emacs it's the other way around.

Here's after selecting "Ubuntu Regular":


[-- Attachment #2: screenNv8rm6.jpg --]
[-- Type: image/jpeg, Size: 3636 bytes --]

[-- Attachment #3: Type: text/plain, Size: 46 bytes --]


And here's after selecting "Ubuntu Medium":


[-- Attachment #4: screenEOYozM.jpg --]
[-- Type: image/jpeg, Size: 4776 bytes --]

[-- Attachment #5: Type: text/plain, Size: 207 bytes --]


(The texts are from the debugging patch.)

So we have a whole a whole bunch of bugs here, apparently.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32210: Support medium weighted fonts

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: carlosjosepita@gmail.com,  32210@debbugs.gnu.org
> Date: Mon, 18 Nov 2019 18:17:27 +0100
> 
> So we have a whole a whole bunch of bugs here, apparently.

I'm not surprised.  Just look at the different conversions of weight
symbols into numbers, and you will see the mess.  For example,
font_parse_fcname obviously supports only a subset of weight values,
so it's enough to convert a value back and forth to get a mismatch, at
least in principle.

bug#32210: Support medium weighted fonts

[Lars Ingebrigtsen]

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

Robert Pluim <rpluim@gmail.com> writes:

> I tried here with 'Noto Sans CJK HK', which seems to have every
> variant under the sun, and got:
>
> Weight: 400, symbol normal
> Weight: 500, symbol semi-bold
>
> I donʼt know if Debian Stable has that font.

I didn't have the HK variant, but I used CJP JP, and got the same as
you.

However, I don't see any difference between those two in Emacs.

Regular:


[-- Attachment #2: screenC5TGnt.jpg --]
[-- Type: image/jpeg, Size: 4808 bytes --]

[-- Attachment #3: Type: text/plain, Size: 10 bytes --]


Medium:


[-- Attachment #4: screenGfX4MP.jpg --]
[-- Type: image/jpeg, Size: 4033 bytes --]

[-- Attachment #5: Type: text/plain, Size: 202 bytes --]


But the frame did shrink when I chose Medium...  and doesn't unshrink if
I choose Regular again.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32210: Support medium weighted fonts

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not surprised.  Just look at the different conversions of weight
> symbols into numbers, and you will see the mess.  For example,
> font_parse_fcname obviously supports only a subset of weight values,
> so it's enough to convert a value back and forth to get a mismatch, at
> least in principle.

Yup.

I think somebody (ahem) will have to carve out some serious time and go
through all the back-and-forth font parsing functions and ensure that
they all agree with each other to avoid these mismatches.

I don't have the stamina to do that right now, so if somebody else wants
to look into it, it's fine by me.  :-)  But if not, I'll try to have a
whack at it sometime later.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32210: Support medium weighted fonts

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I don't have the stamina to do that right now, so if somebody else wants
> to look into it, it's fine by me.  :-)  But if not, I'll try to have a
> whack at it sometime later.

Man, this font stuff is convoluted.  I mean, the programming -- it's all
via indirect methods for no particular reason.

Anyway, I've added all the new weights, and things...  mostly work.  But
I'm having problems actually understanding this table:

/* Table of weight numeric values and their names.  This table must be
   sorted by numeric values in ascending order.  */

 static const struct table_entry weight_table[] =
 {
   { 0, { "thin" }},
-  { 20, { "ultra-light", "ultralight" }},
-  { 40, { "extra-light", "extralight" }},
-  { 50, { "light" }},
-  { 75, { "semi-light", "semilight", "demilight", "book" }},
-  { 100, { "normal", "medium", "regular", "unspecified" }},
-  { 180, { "semi-bold", "semibold", "demibold", "demi" }},
-  { 200, { "bold" }},
-  { 205, { "extra-bold", "extrabold" }},
-  { 210, { "ultra-bold", "ultrabold", "black" }}

What are those numbers?  Is it just an ordering, and it doesn't matter
what the numbers are?  Or are they used when instantiating fonts
somewhere?  I'm just having puzzling issues with some of the new names
but not others, and I just don't understand where certain font weights
are coming from.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32210: Support medium weighted fonts

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: carlosjosepita@gmail.com,  32210@debbugs.gnu.org
> Date: Wed, 20 Oct 2021 14:58:12 +0200
> 
> /* Table of weight numeric values and their names.  This table must be
>    sorted by numeric values in ascending order.  */
> 
>  static const struct table_entry weight_table[] =
>  {
>    { 0, { "thin" }},
> -  { 20, { "ultra-light", "ultralight" }},
> -  { 40, { "extra-light", "extralight" }},
> -  { 50, { "light" }},
> -  { 75, { "semi-light", "semilight", "demilight", "book" }},
> -  { 100, { "normal", "medium", "regular", "unspecified" }},
> -  { 180, { "semi-bold", "semibold", "demibold", "demi" }},
> -  { 200, { "bold" }},
> -  { 205, { "extra-bold", "extrabold" }},
> -  { 210, { "ultra-bold", "ultrabold", "black" }}
> 
> What are those numbers?  Is it just an ordering, and it doesn't matter
> what the numbers are?  Or are they used when instantiating fonts
> somewhere?

It's used in faces.el.

bug#32210: Support medium weighted fonts

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> -  { 205, { "extra-bold", "extrabold" }},
>> -  { 210, { "ultra-bold", "ultrabold", "black" }}
>> 
>> What are those numbers?  Is it just an ordering, and it doesn't matter
>> what the numbers are?  Or are they used when instantiating fonts
>> somewhere?
>
> It's used in faces.el.

The numbers are?  The data ends up in font-weight-table, but this is the
only place I can find in faces.el that uses that variable:

(defun face-valid-attribute-values (attribute &optional frame)

[...]

           (:weight
	    (mapcar #'(lambda (x) (cons (symbol-name (aref x 1)) (aref x 1)))
		    font-weight-table))


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32210: Support medium weighted fonts

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: carlosjosepita@gmail.com,  32210@debbugs.gnu.org
> Date: Wed, 20 Oct 2021 15:20:25 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> -  { 205, { "extra-bold", "extrabold" }},
> >> -  { 210, { "ultra-bold", "ultrabold", "black" }}
> >> 
> >> What are those numbers?  Is it just an ordering, and it doesn't matter
> >> what the numbers are?  Or are they used when instantiating fonts
> >> somewhere?
> >
> > It's used in faces.el.
> 
> The numbers are?  The data ends up in font-weight-table, but this is the
> only place I can find in faces.el that uses that variable:
> 
> (defun face-valid-attribute-values (attribute &optional frame)
> 
> [...]
> 
>            (:weight
> 	    (mapcar #'(lambda (x) (cons (symbol-name (aref x 1)) (aref x 1)))
> 		    font-weight-table))
> 

Not sure what exactly you are asking, but does font_style_to_value
answer that?

bug#32210: Support medium weighted fonts

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Not sure what exactly you are asking, but does font_style_to_value
> answer that?

No, that function is fine.

I'm asking: What are the semantics of the integers in weight_table?  Do
they have to match up with numbers somewhere else?  The comment just
says that they have to be monotonically increasing, but not what their
meaning is.

If I change

  { 210, { "black", "heavy" }},

to

  { 212, { "black", "heavy" }},

changing to the "black" weight still works.  If I change it to

  { 215, { "black", "heavy" }},

it no longer works, and the font machinery chooses the "normal" font
instead...  which is at 100.  

So I'm guessing the numbers are used in font_score somehow, but the
logic is oblique.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32210: Support medium weighted fonts

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> If I change
>
>   { 210, { "black", "heavy" }},

fc-query /usr/share/fonts/opentype/noto/NotoSansCJK-Black.ttc

has

        weight: 210(f)(s)

So these are actually the weights in the font files?  Which is a
separate system from the Pango weights...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32210: Support medium weighted fonts

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> fc-query /usr/share/fonts/opentype/noto/NotoSansCJK-Black.ttc
>
> has
>
>         weight: 210(f)(s)

So now I've got all the test cases working with one font, and I think
I'm going to take a long holiday to rest up after that ordeal.

That is, until tomorrow.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32210: Support medium weighted fonts

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: carlosjosepita@gmail.com,  32210@debbugs.gnu.org
> Date: Wed, 20 Oct 2021 16:42:17 +0200
> 
> > If I change
> >
> >   { 210, { "black", "heavy" }},
> 
> fc-query /usr/share/fonts/opentype/noto/NotoSansCJK-Black.ttc
> 
> has
> 
>         weight: 210(f)(s)
> 
> So these are actually the weights in the font files?  Which is a
> separate system from the Pango weights...

Yes, and see, e.g., ftfont.c, where we query fontconfig for these
values.

bug#32210: Support medium weighted fonts

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, and see, e.g., ftfont.c, where we query fontconfig for these
> values.

Right.

I've now gone through all the fonts I have here that have different
weights for medium and regular, and with the adjustments in the weights
and Pango weights, I can now select both of them.  (And the other
weights for Noto and DejaVu, which are the main fonts that I've tested
with, also work.)

So I've pushed the changes now to the trunk.  If these changes don't
work with other fonts, please let me know.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32210: Support medium weighted fonts

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: carlosjosepita@gmail.com,  32210@debbugs.gnu.org
> Date: Thu, 21 Oct 2021 04:33:49 +0200
> 
> I've now gone through all the fonts I have here that have different
> weights for medium and regular, and with the adjustments in the weights
> and Pango weights, I can now select both of them.  (And the other
> weights for Noto and DejaVu, which are the main fonts that I've tested
> with, also work.)
> 
> So I've pushed the changes now to the trunk.  If these changes don't
> work with other fonts, please let me know.

Hmm... bother:

>  static const struct table_entry weight_table[] =
>  {
>    { 0, { "thin" }},
> -  { 20, { "ultra-light", "ultralight" }},
> -  { 40, { "extra-light", "extralight" }},
> +  { 40, { "ultra-light", "ultralight", "extra-light", "extralight" }},

This loses the distinction between ultra-light and extra-light.  Are
these two really indistinguishable in all supported font backends?

>  static Lisp_Object
>  w32_to_fc_weight (int n)
>  {
> -  if (n >= FW_HEAVY)     return intern ("black");
> +  if (n >= FW_HEAVY)     return Qbold;
>    if (n >= FW_EXTRABOLD) return Qextra_bold;

This doesn't look right.  Should that Qbold be Qblack?

bug#32210: Support medium weighted fonts

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>>  static const struct table_entry weight_table[] =
>>  {
>>    { 0, { "thin" }},
>> -  { 20, { "ultra-light", "ultralight" }},
>> -  { 40, { "extra-light", "extralight" }},
>> +  { 40, { "ultra-light", "ultralight", "extra-light", "extralight" }},
>
> This loses the distinction between ultra-light and extra-light.  Are
> these two really indistinguishable in all supported font backends?

I added them together because the Gtk documentation (and the Windows
one, I think? I've been working on this for a while, and some of the
details are vague) said that there's only one weight between "light" and
"thin", so people specifying "ultra-light" wouldn't actually get it,
because 20 is too far from being correct.

I fc-queried all the 1K fonts on this system, and indeed -- none of them
had a weight of 20.  There were weights at 0 and 40, though (and none
inbetween).

So I'm as confident about that change as...  er...  well, it's font
stuff, so I'm not confident at all, but I think it's worth a try.  I'll
test this stuff on FreeBSD and see what it says there, once I get the
VMs up again on my new VM machine.

>>  static Lisp_Object
>>  w32_to_fc_weight (int n)
>>  {
>> -  if (n >= FW_HEAVY)     return intern ("black");
>> +  if (n >= FW_HEAVY)     return Qbold;
>>    if (n >= FW_EXTRABOLD) return Qextra_bold;
>
> This doesn't look right.  Should that Qbold be Qblack?

Good catch.  Now fixed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no