bug#20727: 24.5; Font fallback doesn't work for the Emoji range

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 13 Jun 2015 14:19:42 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: v.schneidermann@gmail.com, andrewjmoreton@gmail.com, 
>  20727@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.