[MPEG-OTSPEC] AHG hybrid (F2F / Zoom) meeting agenda

Thu Aug 24 06:16:24 CEST 2023

Dear all,
Please see below the summary report of the AHG meeting that was held last
week on Aug. 17, 2023. We had a great event and I would like to express my
gratitude to many people who contributed to the discussion, and to Google
as our host, who provided excellent meeting facilities and accommodations!

*AHG hybrid (F2F / Zoom) meeting report summary.*
Meeting participants (sincere apologies if I missed anyone - please respond
with any additional names):
*In-person participants: *Liam Quin, Skef Iterum, Dave Crossland, Felipe
Sanches, Dominik Röttsches, Kamile Demir, Kalapi Gajjar, Eli Heuer, John
Hudson, Behdad Esfahbod, Sam Berlow, Thomas Phinney, Rod Sheeter, Ned
Holbrook, Greg Hitchcock, Eben Sorkin, Vladimir Levantovsky
*Zoom participants: *Cosimo Lupo, Mew Ophaswongse, Mike LaGattuta, Bianca
Berning, Guido Ferreyra, Georg Seifert, Laurence Penney, Makoto
Murata, Hin-Tak Leung, Suzuki Toshiya, Yasuo Kida, Josh Hadley, Nat
McCully, Marianna Paszkowska,

Discussion / Topics Summary:
0. Meeting opening / introductions
Administrivia: Review of the relevant ISO policies and procedures
- Declaration for participants in ISO activities
<https://www.google.com/url?q=https://www.iso.org/declaration-for-participants-in-iso-activities.html&sa=D&source=calendar&usd=2&usg=AOvVaw2n2ZhkFMkQBjPrst6wyAbi>
- ISO Code of Ethics and Conduct
<https://www.google.com/url?q=https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100011.pdf&sa=D&source=calendar&usd=2&usg=AOvVaw3R7JNkexzilX-qCtg_vrzR>
- Guideline for Implementation of the Common Patent Policy for
ITU‑T/ITU‑R/ISO/IEC
<https://www.google.com/url?q=https://www.iso.org/files/live/sites/isoorg/files/developing_standards/resources/docs/20221216_Guidelines_for_Implementation_of_the_Common_Patent_Policy.pdf&sa=D&source=calendar&usd=2&usg=AOvVaw3236BoeE5tQKR46VIx_R2a>
- Adoption of the agenda
- Introductions of meeting participants
Additional topic: Discussion of the proposed conflict resolution principle:
In case of conflict, consider users over font developers over implementers
over specifiers over theoretical purity. (Borrowed from the HTML Design
Principles, Priority of Constituencies
<https://www.w3.org/TR/html-design-principles/#priority-of-constituencies>)
1. Topic: Overcoming 64K glyph limit discussion summary
Attempts to reuse existing 'head' table format fields (glyphDataFormat /
indexToLocFormat) are error prone - many existing implementations are used
to ignore these values. As a result, an approach involving modifying
existing fields and 'glyf' / other tables would very likely break existing
implementations. An alternative approach that was discussed at length and
agreed upon is to introduce new table tags/versions, and give font
developers full control and final authority over backward compatible
behavior of a font that will be designed to support more than 64K glyphs.
E.g. font developers would decide what subset of the larger number of
glyphs would be supported by a new font that is fully compatible with
existing implementations [which would simply ignore new tables] and also
designed to support more than 64K glyphs for use in updated implementations.
Additional experiments (+ test fonts) would be needed to validate certain
assumptions made as part of the discussion.
(Sideline discussions included questions regarding consideration of 24- vs.
32-bit indices, and whether font sizes should still be considered as
a limiting factor that we need to optimize for.)
Action Item: Prepare, validate and submit an updated proposal to reflect
the new approach.
2. Topic: 'avar' version 2 discussion summary
Updated Working Draft text splits the discussion of coordinate scale and
normalization into two separate parts of the spec, which was previously
flagged as a spec concern and is less than ideal.
Fonts with avar2 [as currently specified] do not really offer a fallback
and may not be truly backward compatible / might behave differently on
older implementations. However, the use of avar2 is very appealing for cost
/ benefits, does solve some actual
problems and cost to implement is very low. Commitments from implementers
to introduce support for avar2 in a timely manner (e.g. 12-18 months) would
be needed to make this a success.
Follow up discussions touched on current implementations, including
HarfBuzz support, Chrome currently supports avar2 behind a compile-time
flag, Apple supports avar2 based on HB spec. Future updates to "avar.next"
might introduce per glyph axes, different adjustments for different
scripts, etc. - need more discussions / use cases regarding the kind of
things we need / want to be expressed.
3. Topic: Composite glyphs / variable components discussion summary
There are significant benefits of enabling new types of composite glyphs
allowing variability of components' weights and widths, variable translate
/ scale for better transformations, etc. Implementing it would require a
relatively small amount of code, while benefits could be significant -
hangul fonts see up to 80% size reduction, Kanji - 65% reduction, etc.
Other scripts might benefit as well - e.g. North Indic calligraphic scripts
can be deconstructed into straight / curved strokes. One can create a
single font supporting multiple scripts (Bengali, Devanagari, and more)
that would require smaller development time.
Part of the discussions were focused on current hinting approaches, and the
value of hinting for various scripts / geographic regions where low cost
devices with relatively lower res screens are still widely in use. The
discussion also focused on possible hinting approaches
for variable components and the role autohinting might play. Introducing
all these new functions as part of the new glyf table would make sense [as
far as introducing braking changes is concerned], and making the new table
format future-proof.
4. Topic: Combining cubic and quadratic Bézier curves in glyphs
Focused discussions on advantages / disadvantages of various approaches,
followed by the discussion of benefits of doing so. We established the fact
that supporting both cubic and quadratic outlines would benefit both users
and type designers / font developers (who currently almost exclusively work
in cubics), and that the conversion of cubic to quadratic outline is lossy
- it makes for a compelling story to support both. It also seems to be a
natural fit into a new glyph format supported by a new table tag. (During
the discussion of benefits / drawbacks of supporting both outline formats,
we also noted that while forcing new glyph outlines to only use cubics is a
possibility, and mixing different types of outlines might complicate
glyf table flags - mixed versions showed better file sizes in the initial
experiments.)
5a. Topic: Font interface default settings
<https://github.com/MPEGGroup/OpenFontFormat/issues/52>
Variable fonts used in environments that don't support variability offer
named instances as defaults; however, there are no requirement for a font
to have an instance named "Regular", and not all formats (e.g. CFF2) are
backward compatible in that way (and fonts aren't always built with
intermediate masters). While some environments like the Web (CSS Fonts
Module) offer mechanisms for setting default values for common axes, some
font selector UI would typically present a format default (e.g. zero for
all axes), which in some cases would be an extreme. In order to be able to
build fonts with extreme masters we need to be able to define a default
instance [via an InstanceRecord in 'fvar' table, see proposal
<https://github.com/MPEGGroup/OpenFontFormat/issues/52> for details].
5b. Topic: Variable substitutions (also see GitHub issues #53
<https://github.com/MPEGGroup/OpenFontFormat/issues/53> & #54
<https://github.com/MPEGGroup/OpenFontFormat/issues/54>)
Discussions were centered on the examples described in both GitHub issues
and in more details in the conditions.pdf
<https://github.com/MPEGGroup/OpenFontFormat/files/12198534/conditions.pdf>
document.
The overall responses to the proposed were very positive, the consensus
decision was that a more formal proposal outlining the necessary spec
changes would be prepared for review on GitHub and also be available for
discussion at the next AHG meeting.

The next AHG meeting is scheduled to be held as a Zoom meeting on Sep.
27th, two weeks prior to input submission upload deadline for the next WG3
meeting on October 16-20.

Near-term next steps / goals:
- prepare the updated proposal for new 'glyf2' table combining changes for
extending 64K glyph limit + variable components and mixed quadratic / cubic
outlines;
- prepare new proposals (variable substitutions, UI defaults);
- have the proposals ready for GitHub discussions by the end of August /
early September and for detailed review at the AHG meeting on Sep. 27.

NB: this meeting report is prepared based on my own notes with significant
help from Liam Quin who made detailed live notes during the meeting. If
anything is missing in the compiled summary, it is totally my fault -
please feel free to send your comments.

Thank you all for your active participation, this was by far the most well
attended and productive discussion we had to date.
Vladimir

On Wed, Aug 9, 2023 at 10:15 PM Vladimir Levantovsky <
vladimir.levantovsky at gmail.com> wrote:

> Dear all,
>
> The meeting details have been finalized, and the agenda for our meeting
> (scheduled on Aug. 17, 2023) is as follows (all time slots are tentative
> and indicated in local US Pacific time zone):
>
> The major part of the discussions will be centered on various proposed
> changes summarized in the Technologies under consideration for ISO/IEC
> 14496-22 5th edition Open Font Format
> <https://www.google.com/url?q=https://www.mpeg.org/wp-content/uploads/mpeg_meetings/142_Antalya/w22631.zip&sa=D&source=calendar&usd=2&usg=AOvVaw2S_Kr2e3cMgCFFOf-QiNKa>
>  document.
>
> 0. Meeting opening / introductions (9:00 - 9:30 am)
> 1. Overcoming 64K glyph limit, see chapter 4 of the TUC (9:30 - 12:00 pm):
> - table changes and inter-dependencies
> - backward compatibility concerns
> - implementation (deployment) challenges for various platforms
> - resource and timeline planning
> 2. Updated AVAR table changes, see updated Working Draft (12:00 - 12:30 pm)
> Lunch break: 12:30 - 1:30 PM
> 3. Variable glyph components, see chapter 3 of the TUC (1:30 - 2:30)
> - challenges / major hurdles / backward compatibility / timeline planing
> 4. Proposed 'glyf' V2 updates, see chapter 2 of the TUC (2:30 - 3:30 pm)
> Coffee break: 3:30 - 4:00 pm
> 5. New proposals / open issues, see
> https://github.com/MPEGGroup/OpenFontFormat/issues
> <https://www.google.com/url?q=https://github.com/MPEGGroup/OpenFontFormat/issues&sa=D&source=calendar&usd=2&usg=AOvVaw3OajI9EJatZEuGer7pomoz> (4:00
> - 5:00 pm)
>
> All registered participants, who either submitted a form entry for
> in-person participation or sent an RSVP for remote participation, should
> have received a meeting invitation that includes additional details.
> IMPORTANT - If you plan to attend in person, or RSVP'ed via email and have
> NOT received a meeting invite - please contact me directly and I will add
> you to the invite list.
>
> Thank you,
> Vladimir
>
> P.S. Stay tuned for public availability of the updated Working Draft text.
> I will send another email with the link, as soon as the document is made
> available for download.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20230824/1a65fe56/attachment-0001.html>