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

Fri Apr 14 20:16:15 CEST 2023

 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> 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> 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
>
>
> _______________________________________________
> 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: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20230414/fd6b314b/attachment.html>