[MPEG-OTSPEC] B64K for JSTF?

[suzuki toshiya]

Dear experts working with B64K issue...

The JSTF table would have one or more ExtenderGlyph
table(s) per script, including 16-bit GIDs. It cannot
hold the 24-bit GID; a 24-bit extension is expected.
At least, JSTF with GID is found in arial.ttf, times.ttf
(of Windows), Harmattan, Lateef, and ScheherazadeNew
(of Google fonts). Current proposal for B64K at
https://github.com/harfbuzz/boring-expansion-spec/tree/main/iso_docs
does not mention about JSTF.

Unfortunately, during the payload from the JSTF header
to the ExtenderGlyph table, there are no version or
format numbers to switch the parsing behavior, except
for the version number in the JSTF header (1.0).
The straight way would be bumping the version at the
header from 1.0 to 1.1 (or 2.0).

However, some existing implementations may ignore
the JSTF version in the header. Can we ignore such
implementations because they would be unable to handle
new cmap and GLYF tables? If we have to care for them,
there is an idea to insert an empty header to a 24-bit
version of ExtenderGlyph to invalidate the content
in the eyes of the legacy implementation, like:

Old ExtenderGlyph format for JSTF 1.0:

(1) uint16	glyphCount
(2) uint16	extenderGlyphs[glyphCount]

24-bit GID savvy ExtenderGlyph format for JSTF 1.1 or 2.0:

(1) uint16	majorVersion (= 0)
(2) uint16	minorVersion (= 2)
(3) uint24(*)	glyphCount24
(4) uint24	extenderGlyphs[glyphCount24]

(*) It is hard to think one script has so many extender
glyphs over 64K. uint16 might be acceptable too.

If JSTF is no longer recommended technology and no need
to update, it is expected to add some notes to clarify
why JSTF stays in 64K glyph space.

Please let me hear your view before file an issue on github,
about 3 options:
a) no update for JSTF, but add a note to stay 64K glyph
b) update JSTF without special care in JSTF table for legacy implementations
c) update JSTF with special care in JSTF table for legacy implementations

Thanks in advance,
suzuki toshiya