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

[Dave Crossland]

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> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200915/94cad267/attachment-0001.html>