<div dir="auto"><div>Personal opinion below...<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 26, 2020, 11:26 AM John Hudson <<a href="mailto:john@tiro.ca" rel="noreferrer noreferrer noreferrer" target="_blank">john@tiro.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>This goes back to my point some weeks
ago that Microsoft's OT spec is the <i>de facto</i> standard. </div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">So I think it's more accurate to say, today:</div><div dir="auto"></div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif">Microsoft's OT ___implementation___ ***was*** the de facto standard. </span><br></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">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</span><font face="sans-serif"> new de facto standard implementation.</font></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">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. </span></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">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)</span><font face="sans-serif"> 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.</font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">(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). </font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">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. </font><span style="font-family:sans-serif">(Of course, as they saying goes, in the long term we are all dead. 😂)</span></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">But, part of why I have this somewhat millenarianist idea, is that this is what I seehas been going on alread</font><span style="font-family:sans-serif">y, 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.</span></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">It's also too expensive to have text fonts not be interoperable, especially within one's own product line. </span></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">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. </font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">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.</font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">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. </font></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>