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 20:08:10 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> 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.

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.

Previous Next

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