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

[Hin-Tak Leung]

 Thanks Vlad and Liam for the excellent summary.
Seeing it in this short form, it is somewhat interesting to note that the majority of the proposals have the idea of "one font (file) to rule it all" baked into it: 64k limit is about having a large font that covers more than 64k glyphs; avar2 is about "one" font file that have variable styles/weights/attributes, "composite glyphs" is about "one" collection of reusable components for building glyph shapes. While they each have their own justifications and usages/applications, they are probably all counter and contrary to users having an interesting visual experience, and font designers experimenting with unsual/interesting designs.
The Japanese government wanting "a" font that works on the names of all living individuals is a valid need. How many type faces are the government going to need, beyond the three styles, sung/ming, kai, hei? Do we expect people to say, commission and license an "interesting looking" 64k+ font for printing their business cards, say? Or compiling a cjk dictionary?
Not saying we shouldn't go beyond 64k, but just saying that the typical street person in Tokyo may not see it as such a big thing; and for CJK font designers, might even set the "entry bar" and discourage font designers from making new type faces. Ditto for the other "one font to rule it all" suggestions.
Last I heard CFF(CFF2) is cubic - what was the argument against improving CFF/CFF2, on the quadratic vs cubic question? Is it the size question again? To beat a dead horse, OT-SVG is probably capable of cubic splines. If it is just size, would say, introducing compression to OT-SVG do the same job? To be honest, "poorly written SVG" (*cough* generated by some auto-conversion program *cough*) is big in size, but that's the same problem about any "poorly written" outlines.
    On Thursday, 24 August 2023 at 05:16:53 BST, Vladimir Levantovsky <vladimir.levantovsky at gmail.com> wrote:  
 
 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 LevantovskyZoom 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 / introductionsAdministrivia: Review of the relevant ISO policies and procedures- Declaration for participants in ISO activities
- ISO Code of Ethics and Conduct
- Guideline for Implementation of the Common Patent Policy for ITU‑T/ITU‑R/ISO/IEC
- Adoption of the agenda
- Introductions of meeting participantsAdditional 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)1. Topic: Overcoming 64K glyph limit discussion summaryAttempts 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 summaryUpdated 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 actualproblems 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 summaryThere 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 glyphsFocused 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 settingsVariable 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 for details].5b. Topic: Variable substitutions (also see GitHub issues #53 & #54)Discussions were centered on the examples described in both GitHub issues and in more details in the 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 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 (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.

_______________________________________________
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/pipermail/mpeg-otspec/attachments/20230824/e5c3fc84/attachment-0001.html>