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

[Corwin Brust <corwin@bru.st>]

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.