From mpsuzuki at hiroshima-u.ac.jp Wed Apr 2 15:45:34 2025 From: mpsuzuki at hiroshima-u.ac.jp (mpsuzuki) Date: Wed, 2 Apr 2025 22:45:34 +0900 Subject: [MPEG-OTSPEC] Minor ballot comment - change a field from 16 to 24 bits In-Reply-To: <06c90c88c50f4336a3e280a78ef3b7b2@TYWPR01MB9542.jpnprd01.prod.outlook.com> References: <06c90c88c50f4336a3e280a78ef3b7b2@TYWPR01MB9542.jpnprd01.prod.outlook.com> Message-ID: Dear Liam, I apologize to ask a few questions to your post in 2 months ago... As far as I could check the current specifications, the field DataOffset has been 16-bit for a long time, in Microsoft OpenType spec, Apple TrueType spec, and current 14496-22. https://learn.microsoft.com/ja-jp/typography/opentype/spec/otvarcommonformats https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6gvar.html (in Apple's spec, offsetToData in glyphVariationData structure might be the field we discuss) It is reasonable attitude to care about the overflow of this field in 24-bit GID world, but simple change of this field to 24-bit could be incompatible with existing implementations. At least, the proposed change in the draft ballot comment does not mention about a technique to keep the compatibility with existing fonts & font drivers. Maybe I'm missing something, please let me ask a few questions. 1) Adding a new version of "gvar" table whose DataOffset is 24-bit is bad option? Also, reservation of a bit in "flags" field of "gvar" header might be another option. 2) Some fonts with 24-bit DataOffset are already shipped to the market? 3) Some existing implementations are already capable to handle 24-bit DataOffset? HarfBuzz was already mentioned, but Behdad commented that it is not enabled by default. Regards, mpsuzuki On 2025/02/06 12:02, Liam R. E. Quin via mpeg-otspec wrote: > In 7.2.2.2 GlyphVariationDataHeader, there is a field called > DataOffset; this is defined to be 16-bit. In testing, people building > actual fonts found this overflowed and needed to be 24 bits, > so we have a proposed change, Change dataOffset from Offset16 to > Offset24. > > My understanding is that this has already been implemented in harfbuzz, > since its an ISO draft and since it was necessary... > > No other problems were found so far. > > The PDF file enclosed says the same thing, using the ISO template for > comments (numbered as if made sa a US comment; the Canadian mirror > committee meeting is tomorrow) > > liam > From behdad at behdad.org Wed Apr 2 20:02:29 2025 From: behdad at behdad.org (Behdad Esfahbod) Date: Wed, 2 Apr 2025 12:02:29 -0600 Subject: [MPEG-OTSPEC] Minor ballot comment - change a field from 16 to 24 bits In-Reply-To: References: <06c90c88c50f4336a3e280a78ef3b7b2@TYWPR01MB9542.jpnprd01.prod.outlook.com> Message-ID: On Wed, Apr 2, 2025 at 7:46?AM mpsuzuki via mpeg-otspec < mpeg-otspec at lists.aau.at> wrote: > Dear Liam, > > I apologize to ask a few questions to your post in 2 months ago... > > As far as I could check the current specifications, the field DataOffset > has been 16-bit for a long time, in Microsoft OpenType spec, Apple TrueType > spec, and current 14496-22. > > > https://learn.microsoft.com/ja-jp/typography/opentype/spec/otvarcommonformats > > https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6gvar.html > (in Apple's spec, offsetToData in glyphVariationData structure might be the > field we discuss) > > It is reasonable attitude to care about the overflow of this field in > 24-bit > GID world, but simple change of this field to 24-bit could be incompatible > with existing implementations. At least, the proposed change in the draft > ballot comment does not mention about a technique to keep the compatibility > with existing fonts & font drivers. Maybe I'm missing something, please > let me ask a few questions. > > 1) Adding a new version of "gvar" table whose DataOffset is 24-bit is bad > option? > Also, reservation of a bit in "flags" field of "gvar" header might be > another > option. > The proposal is to change the DataOffset to 24bit only in the newly proposed `GVAR` table. We are not touching the existing `gvar`. behdad > 2) Some fonts with 24-bit DataOffset are already shipped to the market? > > 3) Some existing implementations are already capable to handle 24-bit > DataOffset? > HarfBuzz was already mentioned, but Behdad commented that it is not enabled > by default. > > Regards, > mpsuzuki > > On 2025/02/06 12:02, Liam R. E. Quin via mpeg-otspec wrote: > > In 7.2.2.2 GlyphVariationDataHeader, there is a field called > > DataOffset; this is defined to be 16-bit. In testing, people building > > actual fonts found this overflowed and needed to be 24 bits, > > so we have a proposed change, Change dataOffset from Offset16 to > > Offset24. > > > > My understanding is that this has already been implemented in harfbuzz, > > since its an ISO draft and since it was necessary... > > > > No other problems were found so far. > > > > The PDF file enclosed says the same thing, using the ISO template for > > comments (numbered as if made sa a US comment; the Canadian mirror > > committee meeting is tomorrow) > > > > liam > > > > _______________________________________________ > 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: From mpsuzuki at hiroshima-u.ac.jp Thu Apr 3 03:12:14 2025 From: mpsuzuki at hiroshima-u.ac.jp (mpsuzuki) Date: Thu, 3 Apr 2025 10:12:14 +0900 Subject: [MPEG-OTSPEC] Minor ballot comment - change a field from 16 to 24 bits In-Reply-To: <7945bbf3f5944a0e997357720d3371a4@TYWPR01MB9542.jpnprd01.prod.outlook.com> References: <06c90c88c50f4336a3e280a78ef3b7b2@TYWPR01MB9542.jpnprd01.prod.outlook.com> <7945bbf3f5944a0e997357720d3371a4@TYWPR01MB9542.jpnprd01.prod.outlook.com> Message-ID: <9d00bf03-2673-4495-b187-0f15c99ffc38@hiroshima-u.ac.jp> Dear Behdad, > The proposal is to change the DataOffset to 24bit only in the newly proposed `GVAR` table. We are not touching the existing `gvar`. Oh! I slipped to check the section which 7.2.2.2 belongs to... Many thanks to your clarification! Regards, mpsuzuki On 2025/04/03 3:02, Behdad Esfahbod wrote: > On Wed, Apr 2, 2025 at 7:46?AM mpsuzuki via mpeg-otspec > wrote: > Dear Liam, > > I apologize to ask a few questions to your post in 2 months ago... > > As far as I could check the current specifications, the field DataOffset > has been 16-bit for a long time, in Microsoft OpenType spec, Apple TrueType > spec, and current 14496-22. > > https://learn.microsoft.com/ja-jp/typography/opentype/spec/otvarcommonformats > https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6gvar.html > (in Apple's spec, offsetToData in glyphVariationData structure might be the > field we discuss) > > It is reasonable attitude to care about the overflow of this field in 24-bit > GID world, but simple change of this field to 24-bit could be incompatible > with existing implementations. At least, the proposed change in the draft > ballot comment does not mention about a technique to keep the compatibility > with existing fonts & font drivers. Maybe I'm missing something, please > let me ask a few questions. > > 1) Adding a new version of "gvar" table whose DataOffset is 24-bit is bad option? > Also, reservation of a bit in "flags" field of "gvar" header might be another > option. > > The proposal is to change the DataOffset to 24bit only in the newly proposed `GVAR` table. We are not touching the existing `gvar`. > > behdad > > 2) Some fonts with 24-bit DataOffset are already shipped to the market? > > 3) Some existing implementations are already capable to handle 24-bit DataOffset? > HarfBuzz was already mentioned, but Behdad commented that it is not enabled > by default. > > Regards, > mpsuzuki > > On 2025/02/06 12:02, Liam R. E. Quin via mpeg-otspec wrote: >> In 7.2.2.2 GlyphVariationDataHeader, there is a field called >> DataOffset; this is defined to be 16-bit. In testing, people building >> actual fonts found this overflowed and needed to be 24 bits, >> so we have a proposed change, Change dataOffset from Offset16 to >> Offset24. >> >> My understanding is that this has already been implemented in harfbuzz, >> since its an ISO draft and since it was necessary... >> >> No other problems were found so far. >> >> The PDF file enclosed says the same thing, using the ISO template for >> comments (numbered as if made sa a US comment; the Canadian mirror >> committee meeting is tomorrow) >> >> liam >> > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec