bug#19993: 25.0.50; Unicode fonts defective on Windows

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 8 Mar 2015 00:38:05 -0800
> From: Ilya Zakharevich <ilya@math.berkeley.edu>
> Cc: 19993@debbugs.gnu.org
> 
> But the major hurdle is that the semantic of fontsets is completely
> undocumented.  After your suggestions, I think I arrived at some
> description which does not contradict anything I have seen:
> 
> =======================================================
> When Emacs wants to show a character using a fontset:
>   • Emacs looks in the fontset and finds the font specifications associated
>     to this character.
>   • Emacs checks which Unicode Subset contains the given character.
>                 (What if not unique???)
>   • From fonts matching the font specifications, Emacs picks up those
>     which have this Unicode Subset “identified” within the font.
>   • From these, Emacs choses one (which?).
> 
> Emacs uses this procedure for two fontsets: the currently enabled one, and
> the default fontset.  If none of two obtained fonts supports the given
> character, a HEX representation is shown.
> =======================================================
> 
> Is it similar to what actually happens?  (I’m not asking about the
> implementation, just whether there is a functional equivalence.)

Sounds reasonable; but then my "reason" in this matter means very
little.  And I'm not aware of any documentation that could be used to
confirm or refute the above.

I can add 2 bits to this:

  . the match between the font spec and the Unicode subranges is
    checked as part of the Windows implementation of the font driver's
    'list' method, which (the method) is called only from
    font_list_entities, which see.

  . at least some of the "wisdom" (or lack thereof) of font selection
    using the defaults seems to come from the database created by
    setup-default-fontset, which see.