[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21028: Slow font rendering in emacs
bug#21028: Slow font rendering in emacs
Wed, 15 Mar 2017 17:36:57 +0200
> Cc: address@hidden
> From: Ralf Jung <address@hidden>
> Date: Tue, 14 Mar 2017 20:39:56 +0100
> > IOW, the way to fix this is to augment the existing default fonts or
> > maybe create an additional ready-to-be-used fontset that users could
> > simply tell Emacs to use, without any tinkering.
> I think we can agree that ideally, the default should DTRT.
I was indeed talking what the default should do. If it doesn't do TRT
in your case (without any customizations of the fontsets), I suggest
to describe the problems in a bug report, so that the defaults could
be augmented to cater to your use cases.
> Unfortunately, I noticed no change when upgrading to Emacs 25; that may
> be because of which exact fonts I have installed.
Could be, I don't know. Once again, if the defaults, without any font
customizations, are somehow not good for you, please report the
details in a bug report.
> > The more sensible way is to specify explicit ranges of codepoints
> > where you want certain fonts, and leave the rest to the defaults.
> Well, IMHO it is not very sensible to do this manually. For example,
> the supported codepoint ranges of the fonts won't change during the
> runtime of Emacs, so Emacs could perfectly well build a more refined
> per-block fallback cascade from the coarse-grained information I provide
> (essentially caching the information whether a font supports no, some,
> or all characters of any given block).
If you are asking for an Emacs feature that could map the installed
fonts and find out which characters they support, this should be
doable, if someone writes the code. But the assumption that the
installed fonts rarely change is not a universally valid one: I know
people who install new fonts every day.
> On a high level, what I want to achieve is for things to look like they
> do in Kate/gedit. ;) Now that's probably not very instructive, so here
> is what I think these editors pick for various characters, just to give
> you some examples (deduced by checking that the characters look the same
> in emacs and Kate, and then asking emacs which font it used):
> all basic ASCII, Latin, Greek characters: Fira Sans Mono
> → Fira Sans Mono
> ∃ DejaVu Mono (not supported by Fira, it seems)
> ∀ DejaVu Mono (not supported by Fira, it seems)
> ∗ DejaVu Mono (not supported by Fira, it seems)
> ⋅ DejaVu Mono (not supported by Fira, it seems)
I would begin by specifying Fira Sans Mono as your default font, via
default-frame-alist. Then see if some of the above are not displayed
as you like, and fix that via fontset-default. It sounds like all the
characters for which you need DejaVu Mono are punctuation and symbols,
so setting up DejaVu Mono for the range '(#x2200 . #x22FF) should do.
If you want more symbols, try '(#x2200 . #x232F), it looks like DejaVu
Mono has good coverage in this larger range.
> Of course this is just an excerpt of the characters we use. From all I
> can tell, the general rule is "if the character is supported by Fira,
> use that font; else of it is supported by DejaVu, use that font; else do
> <no idea what it does>"
As you have seen, this does work as you want, but it's slow. We are
talking about getting you the same functionality, but faster. That
comes for a price of more accurate fontset setup.
> >> You say these fonts support only Latin, Cyrillic and Greek -- but for
> >> example Fira Sans Mono supports → and … and ↑, and DejaVu Mono supports
> >> ∃ and ↦ and ▷. Are these all in one of these ranges?
> > No. But the rest of the blocks are covered only very partially,
> Wait -- if Fira already covers the entire Latic, Greek and Cyrillic
> range, how can it make any sense to even have a fallback to DejaVu here?
You tell me, I don't know your exact needs. Maybe I guessed them
above, and all you need is more punctuation and symbols, because Fira
has very incomplete coverage of those. Emacs 25 will use the default
face's font for any symbol and punctuation characters supported by
that font, so you only need fallbacks where those characters are not
available in Fira. That's what the above blocks should achieve by
configuring DejaVu Sans for them.
> I thought the entire purpose of these fallback chains was to deal with
> fonts supporting random characters in some blocks, so that one cannot
> tell in advance exactly which font to use for which block.
It can be used like that, but then it could be slow.
> So, maybe I could figure out which 2 or 3 unicode blocks all the special
> characters are in, and then I could set up Fira followed by DejaVu just
> for these blocks. Then I could have emacs pick the fonts I want without
> being slow.
My suggestions for that are above. Maybe that's what you need.
> I don't think the font is to blame here. After all, other applications
> manage to deal with exactly the same fonts just fine.
> Unfortunately, I don't know *how* everybody else is selecting fonts, I
> only know they do a better job at it than emacs, and they have no
> problem dealing with fonts that only partially support some blocks.
> Probably fontconfig is doing most of the work here, but I am really just
Most other applications don't deal with multi-lingual text, so their
job is easier. Emacs attempts to solve a harder problem here.
bug#21028: Slow font rendering in emacs, Eli Zaretskii, 2017/03/14