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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: v.schneidermann <at> gmail.com, andrewjmoreton <at> gmail.com, 20727 <at> debbugs.gnu.org
Subject: bug#20727: 24.5; Font fallback doesn't work for the Emoji range
Date: Sat, 13 Jun 2015 22:03:53 +0300

> Date: Sat, 13 Jun 2015 11:47:07 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: v.schneidermann <at> gmail.com, andrewjmoreton <at> gmail.com, 
>  20727 <at> debbugs.gnu.org

> I tried the 8 specific characters that you mentioned (the endpoints of the 
> ranges) with emacs -Q, and found that in my environment Symbola looked way 
> better with U+1F600, U+1F64F, U+1F100 (where older Emacs just displays hex codes 
> in boxes), that Symbola looks a bit worse with U+2E00 and U+20A0 (where older 
> Emacs uses FreeSerif which better matches the FreeSerif characters elsewhere in 
> the buffer)

How did you get FreeSerif characters elsewhere in the buffer?  Which
characters were those?

> both fonts look bad (hex boxes) with U+1F1FFF, U+2E7F, U+20CF (as
> they're unassigned).

Sorry, I mentioned the block limits without checking what parts are
assigned.  (Also, U+1F1FFF was a typo.)  What do you see for U+2E3F
and U+20BD?

Anyway, does the idea of selectively removing codepoints from where we
currently specify Symbola sound good, given these trials?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.