GNU bug report logs - #73363
30.0.91; CJK Font Rendering Behavior Changed

Previous Next

Full log

View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, tomohisa.kuranari <at> gmail.com, 73363 <at> debbugs.gnu.org
Subject: bug#73363: 30.0.91; CJK Font Rendering Behavior Changed
Date: Fri, 20 Sep 2024 19:59:47 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> That's the only font-related change I found there, yes.
>
> Regardless of the effect of reverting it, I'd appreciate if Po Lu
> could explain its rationale (and improve the comments with that),
> since the log message and the comments don't say enough for me to
> figure that out.  In particular, this part of the comment:
>
>   TrueType fonts have contrived character map selection
>   semantics which makes determining the repertory at font
>   spec matching time unduly expensive.
>
> What does this allude to (details and examples of such contrived
> character map selection semantics, please), and where's the code where
> spec matching becomes expensive without this change?

Some of our font backends (sfntfont, at least, and perhaps macfont in
this case) will return different registries from that which was
specified in the font spec when enumerating font entities, in order to
enable font specs requesting an ASCII charset also to match fonts with
Unicode as the charset.  If cached, these font entities will be
repeatedly rejected in font_find_for_lface after being opened, with
obvious consequences for performance.

Previous Next

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