[MPEG-OTSPEC] To add some more perspective

[Dave Crossland]

Personal opinion below...

On Sat, Sep 26, 2020, 11:26 AM John Hudson <john at tiro.ca> wrote:

> This goes back to my point some weeks ago that Microsoft's OT spec is the *de
> facto* standard.
>

But as we've also been discussing for weeks, standards are shadows cast by
implementations, and their purpose is that each independent implementation
cast the same shadow.

So I think it's more accurate to say, today:

Microsoft's OT ___implementation___ ***was*** the de facto standard.

Past tense because there's an implementation called the Persian words Open
and Type transliterated in Latin script, Harf Buzz, which I argue is now
established as the new de facto standard implementation.

That's what changed since 2015: hb is now at the core of Adobe and
Microsoft flagship products, joining Google and Facebook and Amazon. I
suspect only Apple's product line is harfbuzzless.

So, in the best future, as the community of hb developers led by Behdad put
changes into harfbuzz, and their standards documentation is submitted to
OFF, these corporate downstream redistributors have to decide if they are
(a1) going to object to the off submissions and (a2) going to commit to
forking harfbuzz and paying the costs associated with maintaining each of
their forks (or coordinating their efforts in a single fork) in perpetuity;
or (b1) commit to continuing to integrate harfbuzz without forking it to
avoid those costs, and (b2) support and engage in the advancement of the
OFF standard, but then either (c1) pay the costs of maintaining their first
party (legacy) implementations to keep up - and in sync, such as through
the OFF standardization process; or (c2) if they will deprecate, and
abandon development of, their legacy implementations and upgrade in status
harfbuzz from a de facto standard implementation to the de jure standard
implementation.

(A) would be an escalation into the next world font war. I doubt it will
happen. It looks to me personally that the default path of Adobe is (B+C2)
and MS is (B+C1).

In all cases there are costs associated, and since these costs have to be
paid out in perpetuity, it's my personal software user freedom movement
political opinion that the latter is inevitably likely to succeed over all
former options in the long term. (Of course, as they saying goes, in the
long term we are all dead. 😂)

But, part of why I have this somewhat millenarianist idea, is that this is
what I seehas been going on already, in the broad software industry, and
specifically in our little area of interest - because it's too expensive to
maintain software that isn't at the surplus edge of value (~profitable): 25
years ago there was competitive value in supporting more languages with
proprietary (vendor-specific) text shaping engines, and in web rendering
engines - but no more. It's just too expensive for everyone to reinvent
their own wheel.

It's also too expensive to have text fonts not be interoperable, especially
within one's own product line.

Even for their high margin, small but top of marketplace segment, strategy,
which depends on integrated hardware and software, Apple started with khtml
to fork into webkit, rather than paying the full costs of starting a web
engine from scratch. Since their shaping implementation is already state
machine based, I doubt I'll see harfbuzz winding up in there soon, because
it will be incremental steps to keep fonts interoperable between harfbuzz
and CoreText.

At the same time, there are inherent problems with c/c++ code, so once a
libre implementation in a problematic language comes to the fore, it
usually sees alternative implementations arise in potentially better
languages. In our case we see AllSorts in Rust is nipping at harfbuzz's
heels.

So I'm looking forward to learning more about Behdad's proposed Ruzz
approach to bringing the safety of Rust to a c++ API on harfbuzz.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200926/5debd6d9/attachment-0001.html>