GNU bug report logs -
#19993
25.0.50; Unicode fonts defective on Windows
Previous Next
Full log
View this message in rfc822 format
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
This bug report was last modified 10 years and 156 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.