unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: emacs-devel@gnu.org
Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
Subject: When and how to register various font backends
Date: Fri, 07 Jun 2019 22:40:45 +0300	[thread overview]
Message-ID: <83tvd1p4jm.fsf@gnu.org> (raw)

With HarfBuzz now available on master, we basically have 3 font
backends on almost every supported platform: the basic backend (Xfont
on Posix systems, GDI on Windows), a backend capable of shaping
complex scripts (ftfont/xftfont with FLT on X, Uniscribe on Windows),
and HarfBuzz.

Having too many active font backends is not a good idea, because when
there's no fonts on your system that can display some character, Emacs
tries to find a font with each of the active backends, so having 3
backends instead of 2 will make such failed searches significantly
longer (approximately by 50%).

Since HarfBuzz can do everything FLT can do, and more, I think it
makes sense to register HarfBuzz in preference to FLT backends when
both are available.  That is, by default each frame will only register
the basic backend and HarfBuzz; the FLT/Uniscribe backends will only
be registered if HarfBuzz is not available or if the user or the code
that creates the frame explicitly requested the other backends.

The question is how to implement this preference.  In the code that is
currently on master, you will see one way of implementing it in
w32fns.c, where the Windows code creates GUI frames (look in
x-create-frame).  Basically, after determining whether Uniscribe was
explicitly requested, this implementation registers or doesn't
register Uniscribe for each new frame.  This means the backends to be
available to a frame must be specified at frame creation time, or be
known by that time.

Yamamoto-san suggested a slightly different way of implementing the
same idea; I will let him explain his proposal in more detail.

Each implementation produces a slightly different behavior.  Since I
believe we should have the same behavior on all platforms, I would
like people to express their opinions on the two implementation, so
that we could eventually decide with which one to go, and implement it
for all platforms.

Thanks.



             reply	other threads:[~2019-06-07 19:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-07 19:40 Eli Zaretskii [this message]
2019-06-14  9:14 ` When and how to register various font backends Robert Pluim
2019-06-14 12:19   ` Eli Zaretskii
2019-06-14 13:16     ` Robert Pluim
2019-06-14 14:47       ` Eli Zaretskii
2019-06-15  9:50         ` Eli Zaretskii
2019-06-17  3:03           ` Michael Welsh Duggan
2019-06-17  9:41           ` Robert Pluim
2019-06-17 16:01             ` Eli Zaretskii
2019-06-18  1:29               ` YAMAMOTO Mitsuharu
2019-06-18 17:26                 ` Eli Zaretskii
2019-06-18 23:21                   ` YAMAMOTO Mitsuharu
2019-06-19 16:42                     ` Eli Zaretskii
2019-06-14 16:54     ` Andy Moreton
2019-06-14 10:52 ` YAMAMOTO Mitsuharu
2019-06-14 11:52   ` Robert Pluim
2019-06-14 12:26     ` Eli Zaretskii
2019-06-14 13:24       ` Robert Pluim

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=83tvd1p4jm.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=mituharu@math.s.chiba-u.ac.jp \
    /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).