<div dir="ltr"><div dir="ltr"><div>On Wed, Apr 2, 2025 at 7:46 AM mpsuzuki via mpeg-otspec <<a href="mailto:mpeg-otspec@lists.aau.at">mpeg-otspec@lists.aau.at</a>> wrote:</div></div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Liam,<br>
<br>
I apologize to ask a few questions to your post in 2 months ago...<br>
<br>
As far as I could check the current specifications, the field DataOffset<br>
has been 16-bit for a long time, in Microsoft OpenType spec, Apple TrueType<br>
spec, and current 14496-22.<br>
<br>
<a href="https://learn.microsoft.com/ja-jp/typography/opentype/spec/otvarcommonformats" rel="noreferrer" target="_blank">https://learn.microsoft.com/ja-jp/typography/opentype/spec/otvarcommonformats</a><br>
<a href="https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6gvar.html" rel="noreferrer" target="_blank">https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6gvar.html</a><br>
(in Apple's spec, offsetToData in glyphVariationData structure might be the<br>
field we discuss)<br>
<br>
It is reasonable attitude to care about the overflow of this field in 24-bit<br>
GID world, but simple change of this field to 24-bit could be incompatible<br>
with existing implementations. At least, the proposed change in the draft<br>
ballot comment does not mention about a technique to keep the compatibility<br>
with existing fonts & font drivers. Maybe I'm missing something, please<br>
let me ask a few questions.<br>
<br>
1) Adding a new version of "gvar" table whose DataOffset is 24-bit is bad option?<br>
Also, reservation of a bit in "flags" field of "gvar" header might be another<br>
option.<br></blockquote><div><br></div><div>The proposal is to change the DataOffset to 24bit only in the newly proposed `GVAR` table. We are not touching the existing `gvar`.</div><div><br></div><div>behdad</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2) Some fonts with 24-bit DataOffset are already shipped to the market?<br>
<br>
3) Some existing implementations are already capable to handle 24-bit DataOffset?<br>
HarfBuzz was already mentioned, but Behdad commented that it is not enabled<br>
by default.<br>
<br>
Regards,<br>
mpsuzuki<br>
<br>
On 2025/02/06 12:02, Liam R. E. Quin via mpeg-otspec wrote:<br>
> In 7.2.2.2 GlyphVariationDataHeader, there is a field called<br>
> DataOffset; this is defined to be 16-bit. In testing, people building<br>
> actual fonts found this overflowed and needed to be 24 bits,<br>
> so we have a proposed change, Change dataOffset from Offset16 to<br>
> Offset24.<br>
> <br>
> My understanding is that this has already been implemented in harfbuzz,<br>
> since its an ISO draft and since it was necessary...<br>
> <br>
> No other problems were found so far.<br>
> <br>
> The PDF file enclosed says the same thing, using the ISO template for<br>
> comments (numbered as if made sa a US comment; the Canadian mirror<br>
> committee meeting is tomorrow)<br>
> <br>
> liam<br>
> <br>
<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></div>