Open zeromake opened 10 months ago
See the line above: https://github.com/nothings/stb/blob/master/stb_truetype.h#L1584
The font doesn't contain a supported unicode-to-glyph mapping table. There are multiple types, and stb_truetype handles all the major types, but apparently this file has one we don't support.
@nothings
stbtt_uint16 format = ttUSHORT(data + index_map + 0);
// format = 14
Format 14: Unicode Variation Sequences
Subtable format 14 specifies the Unicode Variation Sequences (UVSes) supported by the font. A Variation Sequence, according to the Unicode Standard, comprises a base character followed by a variation selector; e.g. <U+82A6, U+E0101>.
The subtable partitions the UVSes supported by the font into two categories: “default” and “non-default” UVSes. Given a UVS, if the glyph obtained by looking up the base character of that sequence in the Unicode encoding subtable (i.e. the UCS-4 or the BMP encoding subtable) is the glyph to use for that sequence, then the sequence is a “default” UVS; otherwise it is a “non-default” UVS, and the glyph to use for that sequence is specified in the format 14 subtable itself.
The example below shows how a font vendor can use format 14 for a JIS-2004–aware font.
(Note the presence of 24-bit integers in the structures used. The type 14 'cmap' subtable does not keep data aligned to four-byte boundaries. This is also the only 'cmap' subtable which does not stand by itself and is not completely independent of all others; a 'cmap' may not consist of a type 14 subtable alone.)
Describe the bug use macosx 13 PingFang.ttc stbtt_FindGlyphIndex Assertion failed
To Reproduce demo.c
PingFang.ttc