bug#73363: 30.0.91; CJK Font Rendering Behavior Changed

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@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.

I forgot to mention that sometimes no charset can be derived before the
font object is opened, and in these situations it is best not to cache
these font objects at all, if a registry should be specified in the
spec, for similar reasons.