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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
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 09:27:40 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  Tomohisa Kuranari
>  <tomohisa.kuranari <at> gmail.com>,  73363 <at> debbugs.gnu.org
> Date: Fri, 20 Sep 2024 07:51:13 +0800
> 
> Robert Pluim <rpluim <at> gmail.com> writes:
> 
> >>>>>> On Thu, 19 Sep 2024 19:33:01 +0300, Eli Zaretskii <eliz <at> gnu.org>
> > said:
> >
> >     Eli> I cannot reproduce this, but I'm not on macOS.  Can someone
> >     Eli> reproduce
> >     Eli> this on GNU/Linux and/or on macOS?
> >
> > On GNU/Linux I get the same result from
> > emacs-29 and emacs-30 ("-GOOG-Noto Sans CJK
> > KR-regular-normal-normal-*-16-*-*-*-*-0-iso10646-1""
> >
> > On macOs it changes from "PingFang SC" to "Arial Unicode MS" when I go
> > from emacs-29 to emacs-30
> >
> >     Eli> The only changes I see in fontset.el due to Android which
> >     Eli> could
> >     Eli> explain this are supposed to be in effect only when Emacs is
> >     Eli> built for
> >     Eli> Android.  I see quite some changes in macfont.m, but they
> >     Eli> seem to
> >     Eli> affect font's weight and slant, so I'm not sure how that
> >     Eli> could be
> >     Eli> relevant.
> >
> > It doesnʼt appear to be either of those. Iʼd bisect, but right now I
> > donʼt have time for that.
> >
> > Robert
> 
> Could it be 1727777a (a Git revision)?  Would the OP try reverting it?

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?

Previous Next

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