bug#19993: 25.0.50; Unicode fonts defective on Windows

[Ilya Zakharevich]

On Thu, Mar 12, 2015 at 08:16:39PM +0200, Eli Zaretskii wrote:
> support these characters.  This is now fixed in commit fc10058 on
> master.  You should now be able to type "C-x 8 RET 1d400 RET" and see
> the character displayed.
> 
> While at that, I also added the missing subranges that for some reason
> unknown to me were commented out; for many of them, I could verify
> that adding them makes the corresponding characters displayable by
> default, where they previously weren't.  (I couldn't verify that for
> some of the scripts for which I have no fonts.)  A few subranges were
> left out, and I added comments explaining why.

A lot of thanks!

> With that out of our way, part of the problem is solved.  Part, but
> not all of it.  Because it is true: Emacs searches the fonts installed
> on the system mostly by requiring only that the font supports the
> script to which the character belongs, but without opening the font
> and checking whether the specific character we are about to display
> has a glyph in the font.  Here's the crucial piece of code (from
> fontset.c):
> 
>         /* Find a font best-matching with the spec without checking
>            the support of the character C.  That checking is costly,
>            and even without the checking, the found font supports C
>            in high possibility.  */

So, this explains why U+2099, U+27e8, U+27e9 are not shown here (while
supported by a lot of fonts).  Thanks for investigating this!

> Assuming that we want to become smarter about this, we could do one or
> both of the following:
> 
>   . have a database of fonts which are _not_ to be used for certain
>     scripts, because it is known that their coverage is poor
> 
>   . have a more elaborate default fontset that favors specific fonts
>     for scripts which these fonts are known to support well
> 

Did you look into the link I provided (about how Firefox does it)?

  
http://search.cpan.org/~ilyaz/UI-KeyboardLayout/lib/UI/KeyboardLayout.pm#There_is_no_way_to_show_Unicode_contents_on_Windows

As my experiments show (I did not try to read the source code) the
logic of falling back goes this way:

  • If document’s fonts can show a char, stop;
  • If (user-configurable) fallback fonts for a Subset can show a
    char, stop; 
  • If (user-configurable) universal fallback fonts can show a
    char, stop;
  • Otherwise, scan all fonts to find one supporting a char.

(The third case is the “x-unicode” pseudo-subset mentioned in the link
above.)

Emacs:
  • Supports different fallbacks for different subsets;
  • But it supports only one fallback font per character.
    (Well, it allows specifying more than one font, but as you saw,
    only one of them will be actually used — at least in the case
    when the fonts would claim having chars in all the ranges — as
    most of “good universal fonts” would do.)

The second one is a significant show-stopper, since it is very hard to
boil down things to one font.

Myself, I only use scripts with “simple shaping”, so all of my needs
are covered by 4 fonts:
   DejaVu *
   Symbola
   Junicode
   Unifont Smooth

(with Unifont Smooth last, since though I’m still working on
un-uglifying Unifont, there is a limit to algorithmic beautification,
and it is always going to be MUCH worse than all the
alternatives — when alternatives exist).

BTW, is font-family search caseless?  Since last year, the family was
changed from
  unifont
to
  Unifont
(in the unifondry’s TTF distribution).

> One problem with both of these is that it's hard to recommend fonts
> because many good fonts are non-free.

For simple rendering (no shaping), there is a lot of possibilities.

Ilya