unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Po Lu <luangruo@yahoo.com>
Cc: rpluim@gmail.com, tomohisa.kuranari@gmail.com, 73363@debbugs.gnu.org
Subject: bug#73363: 30.0.91; CJK Font Rendering Behavior Changed
Date: Fri, 20 Sep 2024 09:27:40 +0300	[thread overview]
Message-ID: <86setu7sbn.fsf@gnu.org> (raw)
In-Reply-To: <s1rttebw6by.fsf@yahoo.com> (message from Po Lu on Fri, 20 Sep 2024 07:51:13 +0800)

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Tomohisa Kuranari
>  <tomohisa.kuranari@gmail.com>,  73363@debbugs.gnu.org
> Date: Fri, 20 Sep 2024 07:51:13 +0800
> 
> Robert Pluim <rpluim@gmail.com> writes:
> 
> >>>>>> On Thu, 19 Sep 2024 19:33:01 +0300, Eli Zaretskii <eliz@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?





  reply	other threads:[~2024-09-20  6:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-19 14:50 bug#73363: 30.0.91; CJK Font Rendering Behavior Changed Tomohisa Kuranari
2024-09-19 16:33 ` Eli Zaretskii
2024-09-19 17:02   ` Robert Pluim
2024-09-19 17:59     ` Eli Zaretskii
2024-09-19 20:10     ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-20  6:12       ` Eli Zaretskii
2024-09-20  8:21         ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-19 23:51     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-20  6:27       ` Eli Zaretskii [this message]
2024-09-20  8:44         ` Robert Pluim
2024-09-20 10:29           ` Eli Zaretskii
2024-09-20 11:07             ` Robert Pluim
2024-09-20 13:24               ` Eli Zaretskii
2024-09-20 13:42                 ` Robert Pluim
2024-09-20 13:53                   ` Eli Zaretskii
2024-09-20 14:03                     ` Robert Pluim
2024-09-20 11:59         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-20 12:08           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-20 12:24             ` Robert Pluim
2024-09-20 13:50               ` Eli Zaretskii
2024-09-20 14:24                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-20 15:41                   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86setu7sbn.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=73363@debbugs.gnu.org \
    --cc=luangruo@yahoo.com \
    --cc=rpluim@gmail.com \
    --cc=tomohisa.kuranari@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).