<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Notes in diary for Wednesday 16
September 2020: agreed 100% with Dave Crossland for the first
time.<span class="moz-smiley-s1"><span>:-)</span></span></div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">JH<br>
</div>
<blockquote type="cite"
cite="mid:CAOgqPYcLiZpsDw09erpMrC5haaDQEzJ=ybyiAUL-vKm3BaK+qw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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 link="blue" vlink="purple" lang="EN-US">
<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.</p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </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"
moz-do-not-send="true">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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
mpeg-otspec mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mpeg-otspec@lists.aau.at">mpeg-otspec@lists.aau.at</a>
<a class="moz-txt-link-freetext" href="https://lists.aau.at/mailman/listinfo/mpeg-otspec">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a>
</pre>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
John Hudson
Tiro Typeworks Ltd <a class="moz-txt-link-abbreviated" href="http://www.tiro.com">www.tiro.com</a>
Salish Sea, BC <a class="moz-txt-link-abbreviated" href="mailto:tiro@tiro.com">tiro@tiro.com</a>
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.</pre>
</body>
</html>