bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#51277: 27.1; menu-set-font not loading correct font


From: Robert Pluim
Subject: bug#51277: 27.1; menu-set-font not loading correct font
Date: Thu, 21 Oct 2021 09:40:19 +0200

>>>>> On Thu, 21 Oct 2021 04:11:56 +0200, Lars Ingebrigtsen <larsi@gnus.org> 
>>>>> said:

    Lars> Selecting Operator Mono Light reports back a weight of 300 (which is
    Lars> according to spec).

    Lars> Book reports 330 (but should be 380).

    Lars> Medium reports 350 (but should be 500).

    Lars> Bold reports 400 (but should be 700).

    Lars> So for this font, the PangoWeights returned by the Gtk selector are
    Lars> totally out of whack with the spec in pango-font.h.  So I'm wondering
    Lars> whether this font is just buggy.

I think this kind of mismatch is not uncommon. All the 'book' fonts
that I have report a weight of 400, which is 'normal', although all
the 'light' fonts that I have report '300'.

    Lars> I'm trying to compare with what other programs are displaying.  It 
would
    Lars> be convenient to test with a program that understands fonts on the
    Lars> command line, but if I say

    Lars> xfce4-terminal --font "Operator Mono SSm:weight=book"

    Lars> then I get something that looks very wrong indeed.  Anybody know a
    Lars> program that understands these things?

    FC_DEBUG=1 xfce4-terminal --font "Operator Mono SSm:weight=book"

will get you fontconfig debug telling you which actual font is
used.

   Lars> Well,

    Lars>   PANGO_WEIGHT_THIN = 100,

    Lars> and

    Lars>   PANGO_WEIGHT_ULTRAHEAVY = 1000

    Lars> so it kinda sounds like <=, not >= is the intended semantic (which is
    Lars> what Emacs does).

gedit rounds down to the nearest multiple of 100, which equates to >=

I guess the root cause of all of this is that weʼre mapping
PangoWeights to symbolic constants, which we then pass to
fontconfig. Perhaps we could arrange to pass the weights directly?

    >> [2]  Iʼll note that 'w32_to_fc_weight' uses the various FW_* constants
    >> as the start of the respective range, not the end

    Lars> Hm...

Didnʼt I say itʼs a mess? ;-)

Robert
-- 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]