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.