Subject: Re: bug#73363: 30.0.91; CJK Font Rendering Behavior Changed

From: Po Lu <[email-masked]>
Date: Fri, 20 Sep 2024 19:59:47 +0800

Eli Zaretskii <[email-masked]> 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.