[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: bug#20727: 24.5; Font fallback doesn't work for the Emoji range
Date: Sun, 14 Jun 2015 05:46:03 +0300

> Date: Sat, 13 Jun 2015 14:19:42 -0700
> From: Paul Eggert <address@hidden>
> CC: address@hidden, address@hidden, 
>  address@hidden
> > 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

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]