[MPEG-OTSPEC] Introducing breaking changes into the spec (was: RE: [EXTERNAL] Proposal to deprecate derived search values)

[John Hudson]

Notes in diary for Wednesday 16 September 2020: agreed 100% with Dave 
Crossland for the first time.:-)

JH
>
> Dear Vlad,
>
> Another long one from me I'm afraid. Adam, don't get jealous 😂
>
> On Tue, Sep 15, 2020, 1:15 PM Levantovsky, Vladimir 
> <Vladimir.Levantovsky at monotype.com 
> <mailto:Vladimir.Levantovsky at monotype.com>> wrote:
>
>     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.
>
>     We also need to be realistic of the potential challenges with new
>     technology adoption _/from the end-user point of view/_. Today’s
>     reality is that the current implementations are widespread,
>
>
> Err, I'm not sure about that, it's not the reality I am living in :)
>
> 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.
>
> 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.
>
> Even focusing on the most widely implemented parts of MOFF, uneven 
> implementation reigns in my reality:
>
> 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 
> (https://arrowtype.github.io/vf-slnt-test/slnt-ital-tests/index.html).
>
> 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.
>
> 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.
>
> The change is here and it needs to be managed.
>
> :)
>
> As for ubiquity and adoption....
>
> 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.
>
> I expect that new specs actually simplify things for authors and 
> users, so there is less to care about.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> If users are completely satisfied with the current font format, they 
> are welcome to continue using such fonts.
>
> 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.
>
> 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.
>
> Suggestions to the AHG to consider that kind of thing will, I expect, 
> be very fruitful.
>
> 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.
>
> :)
>
> 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.
>
>
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec


-- 

John Hudson
Tiro Typeworks Ltd    www.tiro.com
Salish Sea, BC        tiro at tiro.com

NOTE: In the interests of productivity, I am currently
dealing with email on only two days per week, usually
Monday and Thursday unless this schedule is disrupted
by travel. If you need to contact me urgently, please
use some other method of communication. Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200916/2b8ad1fd/attachment.html>