<div dir="ltr">Thank you for bringing this up. I wrote a proposal:<div><br></div><div><a href="https://github.com/harfbuzz/boring-expansion-spec/issues/130">https://github.com/harfbuzz/boring-expansion-spec/issues/130</a></div><div><br></div><div>Please comment there if you think it should be done differently.</div><div><br></div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">behdad<br><a href="http://behdad.org/" target="_blank">http://behdad.org/</a></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 26, 2024 at 12:23 AM suzuki toshiya via mpeg-otspec <<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear experts working with B64K issue...<br>
<br>
The JSTF table would have one or more ExtenderGlyph<br>
table(s) per script, including 16-bit GIDs. It cannot<br>
hold the 24-bit GID; a 24-bit extension is expected.<br>
At least, JSTF with GID is found in arial.ttf, times.ttf<br>
(of Windows), Harmattan, Lateef, and ScheherazadeNew<br>
(of Google fonts). Current proposal for B64K at<br>
<a href="https://github.com/harfbuzz/boring-expansion-spec/tree/main/iso_docs" rel="noreferrer" target="_blank">https://github.com/harfbuzz/boring-expansion-spec/tree/main/iso_docs</a><br>
does not mention about JSTF.<br>
<br>
Unfortunately, during the payload from the JSTF header<br>
to the ExtenderGlyph table, there are no version or<br>
format numbers to switch the parsing behavior, except<br>
for the version number in the JSTF header (1.0).<br>
The straight way would be bumping the version at the<br>
header from 1.0 to 1.1 (or 2.0).<br>
<br>
However, some existing implementations may ignore<br>
the JSTF version in the header. Can we ignore such<br>
implementations because they would be unable to handle<br>
new cmap and GLYF tables? If we have to care for them,<br>
there is an idea to insert an empty header to a 24-bit<br>
version of ExtenderGlyph to invalidate the content<br>
in the eyes of the legacy implementation, like:<br>
<br>
Old ExtenderGlyph format for JSTF 1.0:<br>
<br>
(1) uint16 glyphCount<br>
(2) uint16 extenderGlyphs[glyphCount]<br>
<br>
24-bit GID savvy ExtenderGlyph format for JSTF 1.1 or 2.0:<br>
<br>
(1) uint16 majorVersion (= 0)<br>
(2) uint16 minorVersion (= 2)<br>
(3) uint24(*) glyphCount24<br>
(4) uint24 extenderGlyphs[glyphCount24]<br>
<br>
(*) It is hard to think one script has so many extender<br>
glyphs over 64K. uint16 might be acceptable too.<br>
<br>
If JSTF is no longer recommended technology and no need<br>
to update, it is expected to add some notes to clarify<br>
why JSTF stays in 64K glyph space.<br>
<br>
Please let me hear your view before file an issue on github,<br>
about 3 options:<br>
a) no update for JSTF, but add a note to stay 64K glyph<br>
b) update JSTF without special care in JSTF table for legacy implementations<br>
c) update JSTF with special care in JSTF table for legacy implementations<br>
<br>
Thanks in advance,<br>
suzuki toshiya<br>
_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
</blockquote></div>