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

Sat Apr 15 01:32:50 CEST 2023

Of course I don’t have concerns with issues being posted in the MSFT issue tracker.

I’m not sure I agree with Laurence’s proposed changes. In fact, for OT 1.9.1 alpha I drafted editorial changes in the ‘loca’ table description, including changing the headings for the two tables describing the formats from “Short version” / “Long version” to “Short format” / “Long format”. Those are editorial changes because those are clearly not different versions of the loca table but are different formats for the table.

> "Version" is the language used elsewhere in the spec, not "Format";

“Version” and “format” are distinct concepts, and both are used in many parts of the spec. In the case of ‘loca’, it is a format difference, not a version difference.

So, in that regard, I would say that it is the current field name “indexToLocFormat” in the head table description that gets that aspect right, not the references to “version” in the loca table description.

The “indexToLoc” portion of the field name is ancient. Since at least TrueType 1.66, the description for the ‘loca’ table had “loca - Index to location” in the title, and “indexToLoc table” in the first paragraph. (My interpretation is that the intent of the naming is that the table provides a mapping from glyph indices to locations for the corresponding glyph data. This thread has got me thinking that I should revisit some of the edits I drafted in the ‘loca’ description.)

The rest of Laurence’s suggestions hinge on the assumption that we can treat these fields as version fields. I definitely think more discussion is needed on how to handle future enhancements the data formats for glyph descriptions before we go making these kinds of spot changes.

Peter

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of Dave Crossland
Sent: Friday, April 14, 2023 11:16 AM
To: Laurence Penney <lorp at lorp.org>
Cc: MPEG OT Spec list <mpeg-otspec at lists.aau.at>; Peter Constable <petercon at microsoft.com>
Subject: [EXTERNAL] Re: [MPEG-OTSPEC] AHG Font Format Kick-off: 5th ed. Working Draft and future milestones

 Hi Laurence

I think this proposal is excellent - no data changes, merely label clarifications.

I suggest posting on the MSFT typography issue tracker too, as I believe Peter Constable is working to sync the 2 spec texts at the moment, so tracking in both specs trackers would be helpful.

Anyone have any concerns about this?

--
Cheers,
Dave

On Wed, Apr 5, 2023 at 5:07 PM Laurence Penney <lorp at lorp.org<mailto:lorp at lorp.org>> wrote:
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<mailto: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<mailto:dcrossland at google.com>]
> Sent: Monday, March 6, 2023 5:41 PM
> To: Vladimir Levantovsky <vladimir.levantovsky at gmail.com<mailto:vladimir.levantovsky at gmail.com>>
> Cc: MPEG OT Spec list <mpeg-otspec at lists.aau.at<mailto: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<mailto: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<http://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<mailto:mpeg-otspec at lists.aau.at>
> https://lists.aau.at/mailman/listinfo/mpeg-otspec

_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>
https://lists.aau.at/mailman/listinfo/mpeg-otspec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20230414/1f50804f/attachment-0001.html>