GNU bug report logs - #73730
31.0.50; Support for color fonts on MS-Windows

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: cpardo <at> imayhem.com
Cc: 73730 <at> debbugs.gnu.org
Subject: bug#73730: 31.0.50; Support for color fonts on MS-Windows
Date: Fri, 11 Oct 2024 09:28:08 +0300

> Cc: 73730 <at> debbugs.gnu.org
> Date: Fri, 11 Oct 2024 06:36:55 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Date: Thu, 10 Oct 2024 23:50:00 +0200
> > From: Cecilio Pardo <cpardo <at> imayhem.com>
> > 
> > It looks like DirectWrite can't handle .FON files. When I build emacs, 
> > the fixed-pitch face, which uses the Monospace family, gets the 
> > "Courier" font which we can't use.
> > 
> > I'd say that this wasn't failing before today's windows update, but who 
> > knows...
> > 
> > Any pointers?
> 
> What happens if you revert commit 7eba90c12227 ?
> 
> If this fixes the problem, please look at the rationale described in
> the commit log message and see if you get back the problem described
> there, and in particular what happens with the faces requested by
> info.el.  It is possible that the problem described there only happens
> on XP, where there's no DirectWrite, in which case we could condition
> Qascii_0 so that it doesn't get in the way.
> 
> But it is somewhat bothersome that .fon fonts are not supported.  Are
> you sure this is true?  What does Internet search bring?  There are
> example programs on MSDN which use DirectWrite, can you try them with
> Courier and see if they also fail?

After some more thinking: I think something is amiss in your code,
because AFAICT the existing code draws .fon fonts using the 'gdi' font
driver.  Here's how to see that:

  emacs -Q
  M-x font-lock-mode
  M-x load-library RET facemenu RET

Now mark some text in *scratch* and type:

  M-x facemenu-set-face RET fixed-pitch RET

Then go to some character displayed with fixed-pitch face and type
"C-u C-x =".  When I do that in the current Emacs, I see:

             position: 78 of 147 (52%), column: 6
            character: c (displayed as c) (codepoint 99, #o143, #x63)
              charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x63
               script: latin
               syntax: w 	which means: word
             category: .:Base, L:Strong L2R, a:ASCII, l:Latin, r:Roman
             to input: type "C-x 8 RET 63" or "C-x 8 RET LATIN SMALL LETTER C"
          buffer code: #x63
            file code: #x63 (encoded by coding system iso-latin-1-dos)
              display: by this font (glyph code):
    gdi:-raster-Courier-regular-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x63)

Note the last line: we already detect that this font should use the
'gdi' font backend.  So either your new code somehow bypassed this
detection, or the fallback on old glyph-drawing APIs which are used on
the current master branch by the 'gdi' font driver is missing
something.  AFAIR (and my memory is not reliable in this matter, so
please check with the code), we decide that this font needs to be
drawn by the 'gdi' font driver when we look for fonts for the
"Monospace" family: I think the 'harfbuzz' font backend rejects it for
some reason (I don't remember which), whereas 'gdi' accepts it.

Bottom line: we should use the 'gdi' font backend for these fonts,
like we do with the current code.  The 'harfbuzz' font driver, with or
without the new DirectWrite methods, should not be used for them,
presumably for reasons similar to those which determined how the
current code works.

If the above doesn't help, please tell more details about how
DirectWrite "cannot handle .FON fonts", and let's take it from there.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.