From: Eli Zaretskii <eliz@gnu.org>
To: Robert Pluim <rpluim@gmail.com>
Cc: luangruo@yahoo.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 16:50:22 +0300 [thread overview]
Message-ID: <865xqq77tt.fsf@gnu.org> (raw)
In-Reply-To: <87cykyh5sk.fsf@gmail.com> (message from Robert Pluim on Fri, 20 Sep 2024 14:24:11 +0200)
> From: Robert Pluim <rpluim@gmail.com>
> Cc: Po Lu <luangruo@yahoo.com>, tomohisa.kuranari@gmail.com,
> 73363@debbugs.gnu.org
> Date: Fri, 20 Sep 2024 14:24:11 +0200
>
> >>>>> On Fri, 20 Sep 2024 20:08:10 +0800, Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> said:
> >> 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.
>
> Po Lu> I forgot to mention that sometimes no charset can be derived before the
> Po Lu> font object is opened, and in these situations it is best not to cache
> Po Lu> these font objects at all, if a registry should be specified in the
> Po Lu> spec, for similar reasons.
>
> These are the fonts which are being rejected on macOS for me. And yet
> PingFang SC seems to work ok.
>
> strangeness detected: spec:’#<font-spec nil nil nil nil gb2312.1980-0 nil nil nil nil nil nil nil nil>’ font:’#<font-object -*-PingFang SC-regular-normal-normal-*-12-*-*-*-p-0-iso10646-1>’
Po Lu, why does it make sense to reject iso10646-1 in these cases? I
could perhaps understand why reject gb2312.1980-0 when we request
something like jisx0208*-*, but iso10646-1 is supposed to support all
the characters, so I don't understand the rationale for rejecting
that. And the same for unicode-bmp and unicode-sip, I think (although
those are rarely used).
And what if the requested registry is ascii-0? That one should match
any registry, IMO. If not, why not?
More generally, what were the examples where you saw problems in
accepting registries different from the requested one? Also, if those
problems are specific to certain platforms, how about making this test
only on those platforms? Font selection machinery in Emacs is
delicate enough to try to "do no harm" first and foremost.
next prev parent reply other threads:[~2024-09-20 13:50 UTC|newest]
Thread overview: 25+ 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
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 [this message]
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
2024-09-21 1:09 ` Tomohisa Kuranari
2024-09-21 2:31 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-21 8:27 ` 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=865xqq77tt.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).