<div dir="auto"><div dir="auto"><br></div>Dear Vlad, <div dir="auto"><br></div><div dir="auto">Another long one from me I'm afraid. Adam, don't get jealous 😂<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Sep 15, 2020, 1:15 PM Levantovsky, Vladimir <<a href="mailto:Vladimir.Levantovsky@monotype.com">Vladimir.Levantovsky@monotype.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_4624575274242950524WordSection1">
<p class="MsoNormal" style="margin-left:.5in">We just have to remember if we want other people to implement we need to do our due diligence at some point and get the spec updated.<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">We also need to be realistic of the potential challenges with new technology adoption _<i>from the end-user point of view</i>_. Today’s reality is that the current
implementations are widespread, </span></p></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">Err, I'm not sure about that, it's not the reality I am living in :) </div><div dir="auto"><br></div><div dir="auto">In my reality, support for CFF2 or SVG in OT is not widespread, nor CBDT. COLR is getting there. I don't mean to pick on Adobe or Google, but the fact is that in recent years we've all seen these new tables added to the spec, without them being held to the same bar that is currently being proffered on the mostly new and energetic folks in the AHG. </div><div dir="auto"><br></div><div dir="auto">Mostly those folks are not employees of a large implementor, but they do have the same commit access to harfbuzz as everyone else in the world, and today that gives them a steak which they did not hold in the past. Dad joke intended. </div><div dir="auto"><br></div><div dir="auto">Even focusing on the most widely implemented parts of MOFF, uneven implementation reigns in my reality:</div><div dir="auto"><br></div><div dir="auto">Currently a lot of my attention is arrested by what CSS refers to as font-optical-sizing:auto not being widespread, and even correct support for ital or slnt axes (<a href="https://arrowtype.github.io/vf-slnt-test/slnt-ital-tests/index.html">https://arrowtype.github.io/vf-slnt-test/slnt-ital-tests/index.html</a>). </div><div dir="auto"><br></div><div dir="auto">Many applications still do not have suitable access to discretionary OpenType Features, or correctly shape all OpenType scripts. Again, I don't mean to pick on Adobe, the petition to Adobe subsequent to the final session of ATYPI 2014 may be well known, but I am thinking of Google Docs/Slides and Microsoft Word/Powerpoint. Figma put everyone to shame in their very first try at an OpenType UI. </div><div dir="auto"><br></div><div dir="auto">Now look, I don't mean to diminish the achievements of the last 5, 10, 25 years. But I also think it's equally important to be clear about the current shortcomings, and to metabolise the energy in the AHG for multi-track improvements through clearly written down protocols of change management. </div><div dir="auto"><br></div><div dir="auto">The change is here and it needs to be managed. </div><div dir="auto"><br></div><div dir="auto">:)</div><div dir="auto"><br></div><div dir="auto">As for ubiquity and adoption....</div><div dir="auto"><br></div><div dir="auto">As we've seen with color fonts and variable fonts, introducing new tables and updates to existing tables does not detract from the ubiquitous support for ancient sfnt tables. Those users will stick with ancient technologies, and that's totally fine. </div><div dir="auto"><br></div><div dir="auto">I expect that new specs actually simplify things for authors and users, so there is less to care about. </div><div dir="auto"><br></div><div dir="auto">For example, the vast majority of fonts will never have more than 64k glyphs, and 16 bit GIDs will continue to be an efficient representation of the list of glyphs in such fonts. </div><div dir="auto"><br></div><div dir="auto">No one authoring fonts with glyphs will need to care that now their "Generate" menu item "just works" instead of telling them "nope!". The compiler behind the menu item will decide to use 16 or 32 bit GIDs, as needed. </div><div dir="auto"><br></div><div dir="auto">Similarly, users will have a choice of just 1 family that supports the entire East Asian region and "just works", or a set of families which forces them to deal with the complexity of choosing the locale specific family, and fallback stack settings, and so on.</div><div dir="auto"><br></div><div dir="auto">With VF, users also have to deal with 1,000s of static fonts corresponding to named instances, or just 3 axes (like Weight Width OpSz) with 10 instances each, roman and italic. The full VF situation is much more simple.</div><div dir="auto"><br></div><div dir="auto">So I just don't see the relevance of comparing the adoption curve of a 20+ year technology with either an incremental improvement to it, or a step change improvement to it. </div><div dir="auto"><br></div><div dir="auto">Obviously it will be better to "piggy back" on the adoption of the ancient stuff, but if the incrementation process is stuck, the step change is inevitable - and likely to be a taller step. </div><div dir="auto"><br></div><div dir="auto">Inevitable because the old stuff doesn't do all of what all users need, only the majority of needs for the majority of existing users. Members of the AHG are here and now creating new stuff that does what a minority of existing users need, and what users of non-OFF formats need - and today they meet those needs with those other formats.</div><div dir="auto"><br></div><div dir="auto">If users are completely satisfied with the current font format, they are welcome to continue using such fonts. </div><div dir="auto"><br></div><div dir="auto">There is a lot of stuff in the current format that had a business need at the time it was made, but if we were designing a new format, we wouldn't include it - eg all the duplicate values for the same attributes. </div><div dir="auto"><br></div><div dir="auto">If an incremental update can offer a smooth transition path, such as specifying that when a font engine's client is seeking an old value, it can compute that value from the deduplicated new format and return it, that's desirable. Terence Dowling posted last week some kind of koans for this kind of thing. </div><div dir="auto"><br></div><div dir="auto">Suggestions to the AHG to consider that kind of thing will, I expect, be very fruitful. </div><div dir="auto"><br></div><div dir="auto">But saying stuff that rhymes with "slow down kids, be REALISTIC, stop stop stop, no no no," is, I think, going to rub people the wrong way, and risks the opposite of what is intended.</div><div dir="auto"><br></div><div dir="auto">:)</div><div dir="auto"><br></div><div dir="auto">So, yes, there are challenges and yes we there AHG need to collaborate on the business cases from the most general to vendor specific ones. Rather than endlessly long emails to this mailing list, I propose you set up a milestone for each track of development on the mpeggroup GitHub issue repo, set up tags for "business case" discussions, and we can start cataloging them. When you start closing issues as "duplicate of #previousIssue" we'll know we have started to get near a comprehensive set. </div><div dir="auto"><br></div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>