[MPEG-OTSPEC] B64K for JSTF?

[Behdad Esfahbod]

Thank you for bringing this up. I wrote a proposal:

https://github.com/harfbuzz/boring-expansion-spec/issues/130

Please comment there if you think it should be done differently.


behdad
http://behdad.org/


On Fri, Jan 26, 2024 at 12:23 AM suzuki toshiya via mpeg-otspec <
mpeg-otspec at lists.aau.at> wrote:

> 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
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240126/334041ae/attachment.html>