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

Thu Aug 24 20:11:03 CEST 2023

> they are probably all counter and contrary to users having an interesting
visual experience, and font designers experimenting with unsual/interesting
designs.

I disagree entirely; avar2 in particular will allow variable fonts to work
with more dynamic range and/or smaller file sizes. It is a more interesting
visual experience and allows for more unusual/interesting variable font
designs than avar1.

Personally, I am currently producing some variable icon fonts for Google.
We need more control of the corners of the designspace than is possible
without having either corner masters, or a warped (avar2) designspace. So I
work around the lack of avar2 by instantiating additional “synthetic”
corner masters at build time. They are created by picking spots from other
parts of the initial design space, instantiating them as masters and
sticking them in the corners, effectively simulating an avar2 font... at
the cost of additional masters and increased file size. There are 14 real
masters… and 12 more synthetic ones untouched by human hands.

If you take file size as a limit, the effective variation range is thus
larger than it would have otherwise been.

> How many type faces are the government going to need, beyond the three
styles, sung/ming, kai, hei?

I sincerely doubt there will be a large number of >64K-glyph fonts in my
lifetime. But I am quite sure that some of the ones to be made will be
workhorses, used by vast numbers of people. Created by/for governments or
system vendors, and distributed with operating systems or libre. There may
be few of them, but at least some will be extremely widely used.

> and for CJK font designers, might even set the "entry bar" and discourage
font designers from making new type faces

I have been doing fonts long enough to have heard this argument repeatedly
with new font technologies. First with western fonts that went beyond 256
encoded glyphs with language support. Then with OpenType features and
alternate glyphs (ligatures, small caps, ordinals, etc.). Now you are
suggesting that breaking the 64K limit in the format will be bad for the
same reason.

None of those previous changes broke the industry. A few folks were
discouraged by these trends, but overall, the trend has continued to be:
more and more people creating fonts, despite these increased level of font
functionality and glyph count. I am not worried by further such increases
in things that are possible, but not required of all fonts.

On Thu, Aug 24, 2023 at 8:07 AM Hin-Tak Leung <htl10 at users.sourceforge.net>
wrote:

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