GNU bug report logs - #20727
24.5; Font fallback doesn't work for the Emoji range

Previous Next

Package: emacs;

Reported by: Vasilij Schneidermann <v.schneidermann <at> gmail.com>

Date: Wed, 3 Jun 2015 17:23:01 UTC

Severity: normal

Tags: confirmed

Found in version 24.5

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
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 10:07:09 -0700
Eli Zaretskii wrote:

> I don't really see why it's "way worth".

Sorry, I mistyped (and used my Sylvester voice 
<https://en.wikipedia.org/wiki/Sylvester_%28Looney_Tunes%29>).  I meant that 
Symbola looks "way worse".  I assume that you can see that in the screenshots, 
it's just that you can't reproduce the problem on your machine.

> The Symbola font looks much more crisp on my system, FWIW.  Which font
> back-end did you configure Emacs to use?

Sorry, I don't know what "font back-end" means.  I'm running on Ubuntu 15.04 and 
configured Emacs with --enable-gcc-warnings.  'configure' outputs:

Configured for 'x86_64-unknown-linux-gnu'.

  Where should the build process find the source code?    .
  What compiler should emacs be built with?               gcc -std=gnu99 -g3 -O2
  Should Emacs use the GNU version of malloc?             yes
      (Using Doug Lea's new malloc from the GNU C Library.)
  Should Emacs use a relocating allocator for buffers?    no
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    x11
  What toolkit should Emacs use?                          GTK3
  Where do we find X Windows header files?                Standard dirs
  Where do we find X Windows libraries?                   Standard dirs
  Does Emacs use -lXaw3d?                                 no
  Does Emacs use -lXpm?                                   yes
  Does Emacs use -ljpeg?                                  yes
  Does Emacs use -ltiff?                                  yes
  Does Emacs use a gif library?                           yes -lgif
  Does Emacs use a png library?                           yes -lpng12
  Does Emacs use -lrsvg-2?                                yes
  Does Emacs use cairo?                                   no
  Does Emacs use imagemagick?                             yes
  Does Emacs support sound?                               yes
  Does Emacs use -lgpm?                                   yes
  Does Emacs use -ldbus?                                  yes
  Does Emacs use -lgconf?                                 yes
  Does Emacs use GSettings?                               yes
  Does Emacs use a file notification library?             yes -lgio (gfile)
  Does Emacs use access control lists?                    no
  Does Emacs use -lselinux?                               no
  Does Emacs use -lgnutls?                                yes
  Does Emacs use -lxml2?                                  yes
  Does Emacs use -lfreetype?                              yes
  Does Emacs use -lm17n-flt?                              yes
  Does Emacs use -lotf?                                   yes
  Does Emacs use -lxft?                                   yes
  Does Emacs directly use zlib?                           yes
  Does Emacs use toolkit scroll bars?                     yes

> Also, if you use the iso10646-1 variant instead of the iso8859-1 as
> the default font, doesn't that fix the problem

Yes.  The problem, I imagine, is that users will have put a fixed-width font of 
their own preference into their .Xdefaults or .Xresources file (e.g., 
"Emacs.font fixed").  This is reasonably common, and the recent change makes 
symbols look much worse, at least in my environment.

By the way, I can reproduce a similar problem with "emacs -Q -font fixed".  It's 
not as unreadable there, but it's still pretty bad: Symbola characters have a 
different width than the fixed-width characters that Emacs previously used, so 
source code listings no longer line up.

> existing
> fonts are frequently inadequate, in that they claim support for
> Unicode ranges where they actually support only a handful of glyphs.
> Users then complain that they have decent fonts (like Symbola)
> installed, but Emacs still shows some characters as boxes with hex
> code, instead of using Symbola.

This doesn't seem to be a problem in Ubuntu and/or Fedora (the systems I 
typically use), and on these environments the cure seems to be worse than the 
disease.  Is there some way we can heuristically tell whether we're in an 
environment where glyphs are often not supported?  For example, can we convert a 
sample glyph or two to a bitmap and see whether it looks like a boxed hex code? 
 (Just thinking out loud.)

> I don't think it's a good idea to
> go back to the previous arrangement where any font that claimed
> iso10646-1 support would be considered as covering symbols and
> punctuation well, because that means restoring the problems I tried to
> fix in the first place.

In that case I don't understand why emacs -Q -font 
-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 works now.  If 
Emacs is supposed to prefer Symbola to other fonts when displaying symbols, why 
isn't it using Symbola in this case?





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.