Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposed changes based on August Portland f2f #105

Open
behdad opened this issue Aug 22, 2023 · 3 comments
Open

Proposed changes based on August Portland f2f #105

behdad opened this issue Aug 22, 2023 · 3 comments

Comments

@behdad
Copy link
Member

behdad commented Aug 22, 2023

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.

@behdad
Copy link
Member Author

behdad commented Aug 22, 2023

Humm. Need to modify VarComposite glyf format to accommodate hinting.

@rsheeter
Copy link
Contributor

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)

@liamquin
Copy link
Collaborator

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants