Invalid substitute glyph indices?

[winjii]

Regarding single-substitution information in the font data, the first of SourceHanSerifOTC_EL-M\SourceHanSerif-Regular.ttc collection, the following output glyph indices look to be out of the range of glyph index. Perhaps, some else font data be the same.

• At LookupList[31] (0-indexed), Coverage->GlyphIDs[0] + DeltaGlyphID >= 65535
• At LookupList[53], Coverage->GlyphIDs[0] + DeltaGlyphID < 0

I don't understand what these values mean.

[kenlunde]

What tool spit out that information? While the Source Han fonts push various various implementation limits, such as the maximum number of glyphs, they do not exceed them. I therefore suspect that you're dealing with a tool issue, not a font issue. If you were to provide details about the tool that you used, I could potentially be more helpful, especially if I am familiar with the tool that you used.

[winjii]

I observed the problem with the two tools.

• T2FAnalyzer http://vanillasky-room.cocolog-nifty.com/blog/t2fanalyzer-truetypeopent.html
• FreeType2.8.1 https://www.freetype.org/
  • I use Visual Studio 2017, v141 toolset, and freetype-2.8/build/windows/vc2010/freetype.vcxproj to build.
  • I contained otvalid.c in the project, and added "FT_USE_MODULE( FT_Module_Class, otv_module_class )" to ftmodule.h, in order to use FT_OpenType_Validate() method.
  • Calling FT_OpenType_Validate(), the invalid indices appeared on otvgsub.c, line 73.

#include <ft2build.h>
#include FT_FREETYPE_H
#include FT_OPENTYPE_VALIDATE_H

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~omission~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    FT_Library library;
    FT_Face face;

    FT_Init_FreeType(&library);
    FT_New_Face(library, "[suitable path]/SourceHanSerifOTC_EL-M/SourceHanSerif-Regular.ttc", 0, &face);

    FT_Bytes baseTable, gdefTable, gposTable, gsubTable, jstfTable;
    int error = FT_OpenType_Validate(face, FT_VALIDATE_GSUB, &baseTable, &gdefTable, &gposTable, &gsubTable, &jstfTable); //returns 8

[kenlunde]

My best guess is that T2FAnalyzer doesn't support font collections, and also that the FreeType module that you tried also doesn't support collections. I suggest that you repeat these tests with the non-collection font resources whose filename extension is otf, not ttc. Everything about how the fonts were built and being used suggests that the problem is not with the fonts.

[winjii]

The two tools indicated exactly the same problem in OTF/Japanese/SourceHanSerif-Regular.otf. I'll check it in different ways. (If you are available, please give me some advice about reliable tools or something.)

[kenlunde]

The two lookup indexes, 31 and 53, seem to correspond to the 'hist' and 'calt' GSUB features, respectively, and they are unique in that they include a single substitution. The GIDs that are referenced are well within range, so I suspect that it is a bug someone in the tools that you are using. I recall a bug that was exposed by the 'hist' GSUB feature that involved it having a single substitution, and perhaps @behdad remembers the details.

[winjii]

I made DTL OTMaster Light scan the otf file. Then, I saw that the two output GIDs was 1683 and 62249. 1683 equals "Coverage->GlyphIDs[0](=64605) + DeltaGlyphID(=2614) - 65536" at LookupList[31], and 62249 equals "Coverage->GlyphIDs[0](=1) + DeltaGlyphID(=-3288) + 65536" at LookupList[53].

In the page related to cmap table, Microsoft Typography, I also found the description such as the following.

https://www.microsoft.com/typography/otspec/cmap.htm#format2

Finally, if the value obtained from the subarray is not 0 (which indicates the missing glyph), you should add idDelta to it in order to get the glyphIndex. The value idDelta permits the same subarray to be used for several different subheaders. The idDelta arithmetic is modulo 65536.

However, In the page related to Single Substitution Subtable, I didn't find such description. https://www.microsoft.com/typography/otspec/gsub.htm#SSF1 However, still, I have conjectured that GID in this case implicitly is treated as the residue class ring of integers modulo 2^16.

I'm afraid that It became a topic uninvolved with Source Han Serif. It wouldn't be a problem if you should close this, because It was solved to me. Thank you!

[kenlunde]

Your wish is my command.

[behdad]

GSUB SingleSubst math is also modulo 65536, but undocumented indeed.

[behdad]

cc @PeterCon