bug#19993: 25.0.50; Unicode fonts defective on Windows

[Ilya Zakharevich]

On Sun, Mar 08, 2015 at 12:46:07AM -0800, I wrote:
> Interesting tidbit:
> 
>   57  D800 - DFFF     Non-Plane 0. Note that setting this bit implies that
>                       there is at least one supplementary code point
>                       beyond the Basic Multilingual Plane (BMP) that
>                       is supported by this font. See Surrogates and
>                       Supplementary Characters.
> 
> Extrapolating (since there is no other way to treat this), having a
> Subset “identified” may mean just that there is at least 1 character
> in this range supported by the font.  ;-)  :-(

To check this conjecture:
   • I assume that for most fonts, the OS/2 table is created
     automatically by the font editor;
   • I did experiments with the only font editor I know: FontForge.

What I did:
   • created a new font (File/New);
   • changed Encoding to Unicode (Encoding/Reencode/10646-1);
   • made some scribles in ã (U+00e3) and щ (U+0449);
   • Looked into Element⫽Font␣Info⫽OS/2⫽Charsets.

As predicted above, (in Automatic mode)
  Latin Supplement
  Cyrillic & Supplement
are highlighted.  So, I presume, the conjecture above is justified:

  The fact that a Subset is “identified” means just that AT LEAST 1
  character is present.

=======================================================

Which means that the current algorithm used by Emacs (on
Windows?) — at least in the conjectural form outlined in another
message in this thread — is completely bogus.

Choosing the first font which has a subset of a character “identified”
is not a reasonable thing to do.  One must check whether the character
is ACTUALLY present, and scan other “identified” fonts if not.

Ilya