[MPEG-OTSPEC] AHG Font Format Kick-off: 5th ed. Working Draft and future milestones

[Laurence Penney]

Given the substantial changes to the "glyf" table that Dave has outlined for the future, it may be helpful to make some clarifications in the spec at this time. I would like to suggest the following relatively minor changes relating to section 5.1.3 (head — Font header):

First, rename:

head.indexToLocFormat -> head.locaTableVersion
head.glyphDataFormat -> head.glyfTableVersion

The reasoning is that:
- "Version" is the language used elsewhere in the spec, not "Format";
- it helps to reference "glyf" and "loca" by their table names;
- it helps to state "Table" explicitly since these are references to data outside of "head" (in other cases, table version is recorded within the table itself).

Second, change the data types for both of these from "int16" to "uint16" (matching OS/2, COLR etc.).

Third, update the descriptions:
- replace "0 for short offsets (Offset16), 1 for long (Offset32)." with "Version of the loca table data. For short offsets (Offset16), set to 0. For long offsets (Offset32), set to 1."
- replace "0 for current format" with "Version of the glyf table data." or "Version of the glyf table data. Currently only Version 0 is defined." (I recommend the first suggestion of the two, since it places responsibility for listing valid glyf formats entirely in the glyf table description)

By making these changes now, we not only clarify the spec but we also potentially give implementers a heads-up to ensure their code checks these fields (which has never been necessary in the case of glyfTableVersion).

There are some related texts in other sections to fix. Both fields are referenced in the CFF2 description.

Finally, we may want to clarify the relevance of these two fields within the descriptions of the tables they refer to. In section "5.2.4.1", the introduction to the glyf table structure, it would help to insert "The format of the glyf table is determined by glyfTableVersion in the head table. The following description defines Version 0 of the glyf table, currently the only format specified. Therefore glyfTableVersion in the head table must be set to 0." Similarly, the introduction to the loca table format, section 5.2.5, may benefit from a reminder that its format depends on head.locaTableVersion.

- Laurence

> On 5 Apr 2023, at 22:36, Vladimir Levantovsky <vladimir.levantovsky at gmail.com> wrote:
> 
> Dear AHG members,
>  Thank you for contributing to AHG discussions and sharing your proposals for OFF spec improvements and updates.
> I’d like to remind you that we are rapidly approaching the deadlines for new input submissions to the WG3 “MPEG Systems” meeting, which will take place on April 24-28, 2023: - input contributions registration deadline is the end of day Central EU time on Monday, April 17;
> - any registered input contributions will need to be uploaded by the end of day Central EU time on Wednesday, April 19.
>  For future proposed technical contributions (if any), I would like to consider highlighting any possible backward compatibility issues as part of the future submissions, similar to how it’s being currently discussed as part of Harfbuzz community discussion (https://github.com/harfbuzz/boring-expansion-spec/issues/86).
>  I’d also really appreciate if all stakeholders / implementers of current standard would voice their opinion on the detailed goals outlined below for possible future enhancements of the OFF spec.
>  Thank you,
> Vladimir
>   From: Dave Crossland [mailto:dcrossland at google.com] 
> Sent: Monday, March 6, 2023 5:41 PM
> To: Vladimir Levantovsky <vladimir.levantovsky at gmail.com>
> Cc: MPEG OT Spec list <mpeg-otspec at lists.aau.at>
> Subject: Re: [MPEG-OTSPEC] AHG Font Format Kick-off: 5th ed. Working Draft and future milestones
>   Hi
> 
> On Wed, Feb 8, 2023 at 5:14 PM Vladimir Levantovsky <vladimir.levantovsky at gmail.com> wrote:
> >
> > The deadline for submission of the input contributions for the next meeting is April 17, 2023 – please make all reasonable efforts to finalize your submissions early rather than late, and please do not hesitate to raise new topics for discussion in this AHG – we still have plenty of time to do so.
> 
> The Noto project offers a large collection of fonts for 100s of writing systems - each covered by the Unicode standard :) 
>  Google Fonts would like to take Noto Sans and Noto Serif to the next level by creating a single compact pan-Unicode font for each design. 
>  Within these fonts, we would like to see the glyphs be composed from reusable parts that are built using new variation capabilities, separate how the parts are crafted and assembled from how they are presented to the user.
> 
> Behdad and the Harfbuzz community have been working on github.com/harfbuzz/boring-expansion-spec - a set of changes to the tech spec, implemented in harfbuzz to overcome limitations of the existing spec tech, with 3  top level goals, the first of which has 4 subgoals to achieve the above, as detailed on that page:
>  1a. Break the 65k glyph limit on glyphs in a single font file
> 1b. Enable cubic curves in glyf outlines
> 1c. Enable components to take advantage of variations
> 1d. Enhance core variation capability with "avar2" (support for user-facing vs internal axis distinction and the mapping between them); explicitly support HOI as Underware have demo'd it; and make more efficient storage of sparse variation data.
>  The other top level goals are, I would say:
>  2. Provide a de-duplicated, "clean cut" subset version of the spec; currently the closest thing to this is the "internal representation" that font compilers use when converting source formats into binaries.
>  3. Provide an 'escape hatch' from the inherent limitations of GSUB/GPOS shaping, using WebAssembly as a hardened runtime, that already ships on all major platforms.
>  This "master plan" was initially presented by Behdad in April 2021, and Simon Cozens made an excellent summary deck @ https://docs.google.com/presentation/d/1dVfuU7YhUBXg9MtU6kYBXVs9082PiHpwhGPYa--yA7c
>  There are beefy new topics, but the four listed as 1a-d are the most important, I think.
>  Cheers
> Dave
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec