unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Cecilio Pardo <cpardo@imayhem.com>
Cc: 73730@debbugs.gnu.org, kbrown@cornell.edu
Subject: bug#73730: 31.0.50; Support for color fonts on MS-Windows
Date: Sun, 20 Oct 2024 19:17:10 +0300	[thread overview]
Message-ID: <86cyjuiwah.fsf@gnu.org> (raw)
In-Reply-To: <80dc50bd-b2d4-4d21-ad38-322412588b3b@imayhem.com> (message from Cecilio Pardo on Sun, 20 Oct 2024 15:35:10 +0200)

> Date: Sun, 20 Oct 2024 15:35:10 +0200
> From: Cecilio Pardo <cpardo@imayhem.com>
> Cc: 73730@debbugs.gnu.org, kbrown@cornell.edu
> 
> The error is caused indeed by fonts with size == 0.
> 
>   - w32-find-non-USB-fonts calls open-font with size == nil.
>   - open-font gets the size from font-entity, that is also empty.
>   - It ends up calling CreateFontIndirect with a LOGFONT
>     with lfHeight == 0
>   - Then, w32-find-non-USB-fonts calls font-get-glyphs, which call
>     text_extents.
>   - text_extents on DirectWrite fails with a font of size 0, but
>     w32font_text_extents does return values that are not 0.
> 
> If the case of size <= 0, we are now falling back to
> w32font_text_extents.

Maybe it's better to use some default size in text_extents instead?
The pixel size of the default font is known (see FRAME_LINE_HEIGHT),
so maybe just use it if you get a font of size zero?  That could be a
more future-proof fix, since we could get such fonts in other
situations as well.

Regardless, we should keep the strategy of falling back to the old
code if DirectWrite fails.

Thanks.





  parent reply	other threads:[~2024-10-20 16:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-10 11:16 bug#73730: 31.0.50; Support for color fonts on MS-Windows Cecilio Pardo
2024-10-10 13:08 ` Eli Zaretskii
2024-10-10 15:14   ` Cecilio Pardo
2024-10-10 16:33     ` Eli Zaretskii
2024-10-10 16:46       ` Cecilio Pardo
2024-10-15 22:18   ` Cecilio Pardo
2024-10-16 11:01     ` Eli Zaretskii
2024-10-16 11:32       ` Eli Zaretskii
2024-10-16 21:35       ` Cecilio Pardo
2024-10-17  6:21         ` Eli Zaretskii
2024-10-17 10:38           ` Cecilio Pardo
2024-10-20 13:35             ` Cecilio Pardo
2024-10-20 13:55               ` Eli Zaretskii
2024-10-20 16:17               ` Eli Zaretskii [this message]
2024-10-20 18:20                 ` Cecilio Pardo
2024-10-20 18:33                   ` Eli Zaretskii
2024-10-20 18:37                     ` Cecilio Pardo
2024-10-10 21:50 ` Cecilio Pardo
2024-10-11  3:36   ` Eli Zaretskii
2024-10-11  6:28     ` Eli Zaretskii
2024-10-11  7:19       ` Cecilio Pardo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86cyjuiwah.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=73730@debbugs.gnu.org \
    --cc=cpardo@imayhem.com \
    --cc=kbrown@cornell.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).