You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on the all-day discussion around the beyond-64k and glyf2 proposals, here's the list of technical suggestions for how to proceed:
New table GLYF / LOCA that have the same format as existing glyf / loca, but can support 24-bit glyph indices. All the beyond-64k and glyf2 proposed changes will go into the new GLYF / LOCA. That is:
The number of glyphs in the font will be deduces from either LOCA table, or from the num-CharStrings from the CFF2 table,
GLYF table regular composites have to use numContours=-1 exactly, and will be extended as already proposed to support 24bit GIDs.
GLYF table simple glyphs can use a mix of quadratic and cubic curves and already proposed.
GLYF table VariableComposites will use `numContours=-2 and work as proposed.
gvar table will be used for GLYF table variations, as already proposed. This means that if there's both glyf table and GLYF table present, then need to match on the legacy part. Alternatively a new GVAR table can be used.
New HMTX / VMTX tables that have the exact same format as existing hmtx / vmtx, except that numberOfHMetrics will be deduces from the length of the table and number of glyphs in the font. So there won't be any new hhea / vhea parallel tables.
GSUB / GPOS / GDEF table proposed changes stay as is.
The text was updated successfully, but these errors were encountered:
It would be nice to state that implementations must support avar2 if they support the new glyph tables to ensure it's safe to assume if GLYF/LOCA work so does avar2, make it a clear implementation error to use the identity avar with the new glyph tables when avar2 is present.
(I realize implementations can do whatever they like, but a nudge that way can't hurt)
@rsheeter you can't really say, implementations must (shall) support technically-unrelated feature X if they support Y, in a spec - to do so weakens the spec. However, it's possible to have a conformance requirement “Font processors claiming to conform to OFF 2024 must implement the GLYF table, support 24-bit glyph IDs, AVAR version 2, and also the DSIG table.” In practice, some test cases (sample fonts) may be a better approach though, because i don’t think many users care about conformance at this level of the stack. In particular it doesn’t really make sense to talk about support or conformance without tests.
Based on the all-day discussion around the beyond-64k and glyf2 proposals, here's the list of technical suggestions for how to proceed:
New table
GLYF
/LOCA
that have the same format as existingglyf
/loca
, but can support 24-bit glyph indices. All the beyond-64k and glyf2 proposed changes will go into the newGLYF
/LOCA
. That is:LOCA
table, or from the num-CharStrings from theCFF2
table,GLYF
table regular composites have to usenumContours=-1
exactly, and will be extended as already proposed to support 24bit GIDs.GLYF
table simple glyphs can use a mix of quadratic and cubic curves and already proposed.GLYF
table VariableComposites will use `numContours=-2 and work as proposed.gvar
table will be used forGLYF
table variations, as already proposed. This means that if there's bothglyf
table andGLYF
table present, then need to match on the legacy part. Alternatively a newGVAR
table can be used.New
HMTX
/VMTX
tables that have the exact same format as existinghmtx
/vmtx
, except thatnumberOfHMetrics
will be deduces from the length of the table and number of glyphs in the font. So there won't be any newhhea
/vhea
parallel tables.GSUB
/GPOS
/GDEF
table proposed changes stay as is.The text was updated successfully, but these errors were encountered: