From: Eli Zaretskii <eliz@gnu.org>
To: Werner LEMBERG <wl@gnu.org>
Cc: 31315@debbugs.gnu.org
Subject: bug#31315: wrong font encoding for fallback font
Date: Thu, 03 May 2018 20:48:44 +0300 [thread overview]
Message-ID: <83a7tgpr43.fsf@gnu.org> (raw)
In-Reply-To: <20180503.075227.154521786744892904.wl@gnu.org> (message from Werner LEMBERG on Thu, 03 May 2018 07:52:27 +0200 (CEST))
> Date: Thu, 03 May 2018 07:52:27 +0200 (CEST)
> Cc: handa@gnu.org, 31315@debbugs.gnu.org
> From: Werner LEMBERG <wl@gnu.org>
>
> > Emacs employs that logic for every charset it has defined, including
> > Latin-2, for example: if text was decoded from an encoding which
> > supports a particular charset, Emacs puts the corresponding
> > 'charset' text property on the decoded text, and the machinery which
> > selects the appropriate font tries first to find a font which
> > supports that charset. The idea is that users in a particular
> > culture have certain distinct preferences wrt fonts, and that an
> > encoding that supports a certain charset or culture provides a hint
> > about those preferences. This idea is very central in how Emacs
> > selects fonts.
>
> Being the FreeType maintainer, and having co-developed Emacs's
> internal buffer encoding scheme many, many years ago, I all know this.
Sorry, I couldn't know that.
> I can only repeat that Emacs might tag a certain text with GB18030 so
> that the user can deduce a Chinese origin. However, there is *no*
> guarantee that the user gets a Chinese-flavoured font – at least not
> from the xft interface.[**]
IME, there's no guarantee about anything in the Emacs font look up
heuristics, except that empirically it does TRT in about 85% of uses.
May I invite you to work on revisiting the design and implementation
of the Emacs font-look up facilities, and on modernizing them? I'm
afraid we didn't have an active developer in this area for several
years, and I fear that we will stagnate (or already are stagnating).
TIA
next prev parent reply other threads:[~2018-05-03 17:48 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-30 7:21 bug#31315: wrong font encoding for fallback font Werner LEMBERG
2018-04-30 15:13 ` Eli Zaretskii
2018-04-30 15:42 ` Andreas Schwab
2018-04-30 19:26 ` Eli Zaretskii
2018-04-30 20:03 ` Andreas Schwab
2018-05-01 2:37 ` Eli Zaretskii
2018-05-01 6:47 ` Werner LEMBERG
2018-05-01 8:13 ` Andreas Schwab
2018-05-01 9:11 ` Werner LEMBERG
2018-05-01 15:00 ` Eli Zaretskii
2018-05-01 17:42 ` Andreas Schwab
2018-05-05 8:57 ` Eli Zaretskii
2018-05-01 6:36 ` Werner LEMBERG
2018-05-01 15:22 ` Eli Zaretskii
2018-05-01 19:30 ` Werner LEMBERG
2018-05-02 7:27 ` Werner LEMBERG
2018-05-02 15:22 ` Eli Zaretskii
2018-05-03 5:52 ` Werner LEMBERG
2018-05-03 17:48 ` Eli Zaretskii [this message]
2018-05-03 19:05 ` Werner LEMBERG
2018-05-03 19:59 ` Eli Zaretskii
2018-05-04 5:11 ` Werner LEMBERG
2018-05-04 13:05 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83a7tgpr43.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=31315@debbugs.gnu.org \
--cc=wl@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.