GNU bug report logs -
#20727
24.5; Font fallback doesn't work for the Emoji range
Previous Next
Full log
View this message in rfc822 format
> Date: Sat, 13 Jun 2015 14:19:42 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: v.schneidermann <at> gmail.com, andrewjmoreton <at> gmail.com,
> 20727 <at> debbugs.gnu.org
>
> > Anyway, does the idea of selectively removing codepoints from where we
> > currently specify Symbola sound good, given these trials?
>
> After trying it a bit I'm worried that this will be flaky. Often the Symbola
> fonts are better (much better, if the default fonts lack the symbols), often
> worse (if both fonts have the symbols), and it all depends on a lot of settings.
What settings are those? The only ones I think are relevant are the
default fontset and the default font. Are there any others?
> Instead of using Symbola for all symbols, perhaps we should just use it for
> emoticons and other symbols known to be commonly bad.
That's what I intend to do next: leave Symbola only for symbols that
are not well covered by other fonts. Similar to the patch I've shown
earlier.
> It's too bad that we can't fall back on Symbola only when the font is missing
> the character. I still don't understand things well enough to propose an
> implementation along those lines, though.
It'd be great if you or someone else did. My impression from reading
the (quite convoluted) code was that building font selection on
actually trying to see if each candidate font has a glyph for a
character will require a complete rewrite of the font-selection
logic. And even then, we have no way of knowing if the glyph we get
looks good.
This bug report was last modified 9 years and 346 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.