bug#54685: 28.0.92; incorrect font on new frame after menu-set-font (Win32)

bug#54685: 28.0.92; incorrect font on new frame after menu-set-font (Win32)

[Corwin Brust]

Steps to reproduce:
1. emacs -Q
2. From the Menu, select Options | Set Default Font
3. Pick a distinct looking font (I'm using Robot Light at 17pts)
4. C-x 5 2 (open a new frame)

What I expected:
The new frame should use the font just selected as the default

What Happened:
The new frame selects another font.  Using M-- C-x = in the scratch
buffer suggests it's choosing:
  harfbuzz:-outline-Adobe
Devanagari-normal-normal-normal-serif-13-*-*-*-p-*-iso8859-1

Here are some screenshots (as links).

The original frame after menu-sent font:
  https://bru.st/i/emacs_eVUJ7FAScU.png

And from the new frame where menu-set-font doesn't appear to DTRT:
  https://bru.st/i/emacs_vmq9PKp6q0.png

In GNU Emacs 28.0.92 (build 2, x86_64-w64-mingw32)
 of 2022-03-23 built on AVALON
Repository revision: 8e7a3f21e00649bacc01be627edd45ff01b51a33
Repository branch: emacs-28
Windowing system distributor 'Microsoft Corp.', version 10.0.19043
System Description: Microsoft Windows 10 Home (v10.0.2009.19043.1620)

Configured using:
 'configure --without-dbus --with-native-compilation
 --without-compress-install CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr pp wid-edit descr-text emacsbug message rmc puny
dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068
epg-config gnus-util rmail rmail-loaddefs auth-source eieio eieio-core
eieio-loaddefs password-cache json map text-property-search mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail comp comp-cstr warnings rx cl-seq cl-macs cl-extra help-mode
seq byte-opt gv bytecomp byte-compile cconv rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date subr-x cl-loaddefs cl-lib
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 108040 16222)
 (symbols 48 22422 1)
 (strings 32 85980 2308)
 (string-bytes 1 2074425)
 (vectors 16 19681)
 (vector-slots 8 778062 43900)
 (floats 8 42 209)
 (intervals 56 335 1)
 (buffers 992 13))

bug#54685: 28.0.92; incorrect font on new frame after menu-set-font (Win32)

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Sat, 2 Apr 2022 18:48:59 -0500
> 
> Steps to reproduce:
> 1. emacs -Q
> 2. From the Menu, select Options | Set Default Font
> 3. Pick a distinct looking font (I'm using Robot Light at 17pts)
> 4. C-x 5 2 (open a new frame)
> 
> What I expected:
> The new frame should use the font just selected as the default
> 
> What Happened:
> The new frame selects another font.  Using M-- C-x = in the scratch
> buffer suggests it's choosing:
>   harfbuzz:-outline-Adobe
> Devanagari-normal-normal-normal-serif-13-*-*-*-p-*-iso8859-1

I cannot reproduce this here.  It works as expected for me: the same
font is used on a new frame.

Does this happen for any font on your system, or just for that one?

bug#54685: 28.0.92; incorrect font on new frame after menu-set-font (Win32)

[Corwin Brust]

On Sun, Apr 3, 2022 at 12:20 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Does this happen for any font on your system, or just for that one?

It appears (this same) incorrect font is used for the new frame when
the default is set to any font's "Light" variant.  Font without a
light variant has no issue, nor is there an issue when I don't choose
the Light variant.

I didn't try every font on my system, if there is any particular font
you'd like me to try LMK.

bug#54685: 28.0.92; incorrect font on new frame after menu-set-font (Win32)

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Sun, 3 Apr 2022 09:49:30 -0500
> Cc: 54685@debbugs.gnu.org
> 
> On Sun, Apr 3, 2022 at 12:20 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > Does this happen for any font on your system, or just for that one?
> 
> It appears (this same) incorrect font is used for the new frame when
> the default is set to any font's "Light" variant.  Font without a
> light variant has no issue, nor is there an issue when I don't choose
> the Light variant.

What other variants of this font do you have there?

bug#54685: 28.0.92; incorrect font on new frame after menu-set-font (Win32)

[Corwin Brust]

On Sun, Apr 3, 2022 at 10:03 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> What other variants of this font do you have there?

Here are all of the variants I have for the "Fira Sans" font.

Thin**
Thin Italic**
UltraLight**
UltraLight Italic**
ExtraLight Italic**
ExtraLight**
Light**
Light Italic**
Semi Light**
Semi Light Italic**
Regular
Italic
Medium
Medium Italic
SemiBold**
SemiBold Italic**
Bold
Bold Italic
ExtraBold**
ExtraBold Italic**
Heavy**
Heavy Italic**

All variants appear correctly after I select them as default in the
initial frame.  Those followed by ** exhibit the problem: they aren't
used in the new frame after the variant was selected as default in the
initial frame.  It's a bit time-consuming to iterate over all variants
so I started with a font that has lots of variants.  Let me know if
you'd like me to try with some of the other fonts where I've been able
to reproduce the problem.

bug#54685: 28.0.92; incorrect font on new frame after menu-set-font (Win32)

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Sun, 3 Apr 2022 10:53:05 -0500
> Cc: 54685@debbugs.gnu.org
> 
> On Sun, Apr 3, 2022 at 10:03 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > What other variants of this font do you have there?
> 
> Here are all of the variants I have for the "Fira Sans" font.

(Why are we suddenly talking about Fira Sans, when your original
report was about Robot?)

> Thin**
> Thin Italic**
> UltraLight**
> UltraLight Italic**
> ExtraLight Italic**
> ExtraLight**
> Light**
> Light Italic**
> Semi Light**
> Semi Light Italic**
> Regular
> Italic
> Medium
> Medium Italic
> SemiBold**
> SemiBold Italic**
> Bold
> Bold Italic
> ExtraBold**
> ExtraBold Italic**
> Heavy**
> Heavy Italic**
> 
> All variants appear correctly after I select them as default in the
> initial frame.  Those followed by ** exhibit the problem: they aren't
> used in the new frame after the variant was selected as default in the
> initial frame.

If so, then this is expected.  The APIs we use on MS-Windows to
enumerate fonts in a font family consider only 4 font varieties to
belong to the same family: Regular, Italic, Bold, and Bold-Italic.
All the other varieties aren't returned by those APIs when we request
to list all the fonts in a family.  (I don't know if this is just the
deficiency of the APIs we use, or a general issue with how fonts are
managed on Windows.)  So any font variety that is not one of those 4
will cause trouble sooner or later.  (Medium is special, because we
have an extra-special kludge to allow Medium when Regular is being
sought.)

So I think what you see is expected: on Windows one cannot select a
Light (or Thin, or UltraLight, or SemiBold, or ...) font for the
default face and hope that it will work as expected.

bug#54685: 28.0.92; incorrect font on new frame after menu-set-font (Win32)

[Corwin Brust]

On Sun, Apr 3, 2022 at 11:12 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Corwin Brust <corwin@bru.st>
> > Date: Sun, 3 Apr 2022 10:53:05 -0500
> > Cc: 54685@debbugs.gnu.org
> >
> > On Sun, Apr 3, 2022 at 10:03 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > What other variants of this font do you have there?
> >
> > Here are all of the variants I have for the "Fira Sans" font.
>
> (Why are we suddenly talking about Fira Sans, when your original
> report was about Robot?)

As I said in my prior, I selected the "problematic" font having the
most variants.  I can repeat the experiment with Robot if that's
useful, but I think it isn't per your comments, quoted below:

>
> If so, then this is expected.  The APIs we use on MS-Windows to
> enumerate fonts in a font family consider only 4 font varieties to
> belong to the same family: Regular, Italic, Bold, and Bold-Italic.
> All the other varieties aren't returned by those APIs when we request
> to list all the fonts in a family.  (I don't know if this is just the
> deficiency of the APIs we use, or a general issue with how fonts are
> managed on Windows.)  So any font variety that is not one of those 4
> will cause trouble sooner or later.  (Medium is special, because we
> have an extra-special kludge to allow Medium when Regular is being
> sought.)
>
> So I think what you see is expected: on Windows one cannot select a
> Light (or Thin, or UltraLight, or SemiBold, or ...) font for the
> default face and hope that it will work as expected.

In which case I think this bug report can be closed.  Thank you.

bug#54685: 28.0.92; incorrect font on new frame after menu-set-font (Win32)

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Sun, 3 Apr 2022 11:23:25 -0500
> Cc: 54685@debbugs.gnu.org
> 
> > If so, then this is expected.  The APIs we use on MS-Windows to
> > enumerate fonts in a font family consider only 4 font varieties to
> > belong to the same family: Regular, Italic, Bold, and Bold-Italic.
> > All the other varieties aren't returned by those APIs when we request
> > to list all the fonts in a family.  (I don't know if this is just the
> > deficiency of the APIs we use, or a general issue with how fonts are
> > managed on Windows.)  So any font variety that is not one of those 4
> > will cause trouble sooner or later.  (Medium is special, because we
> > have an extra-special kludge to allow Medium when Regular is being
> > sought.)
> >
> > So I think what you see is expected: on Windows one cannot select a
> > Light (or Thin, or UltraLight, or SemiBold, or ...) font for the
> > default face and hope that it will work as expected.
> 
> In which case I think this bug report can be closed.  Thank you.

Done.  I will at some time add a PROBLEMS entry about this.

bug#54685: 28.0.92; incorrect font on new frame after menu-set-font (Win32)

[Eli Zaretskii]

> Date: Sun, 03 Apr 2022 19:34:15 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 54685-done@debbugs.gnu.org
> 
> > From: Corwin Brust <corwin@bru.st>
> > Date: Sun, 3 Apr 2022 11:23:25 -0500
> > Cc: 54685@debbugs.gnu.org
> > 
> > > If so, then this is expected.  The APIs we use on MS-Windows to
> > > enumerate fonts in a font family consider only 4 font varieties to
> > > belong to the same family: Regular, Italic, Bold, and Bold-Italic.
> > > All the other varieties aren't returned by those APIs when we request
> > > to list all the fonts in a family.  (I don't know if this is just the
> > > deficiency of the APIs we use, or a general issue with how fonts are
> > > managed on Windows.)  So any font variety that is not one of those 4
> > > will cause trouble sooner or later.  (Medium is special, because we
> > > have an extra-special kludge to allow Medium when Regular is being
> > > sought.)
> > >
> > > So I think what you see is expected: on Windows one cannot select a
> > > Light (or Thin, or UltraLight, or SemiBold, or ...) font for the
> > > default face and hope that it will work as expected.
> > 
> > In which case I think this bug report can be closed.  Thank you.
> 
> Done.  I will at some time add a PROBLEMS entry about this.

Now done.