<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 14082020 10:50 am, Nathan Willis
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAL6+1Kqp2OmpHCY_NxKO1=3R7gSz65tLUJ7So8DLypWq9qhzg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">I for one am still really unclear on exactly what
the nature of tag registries is — people talk about them as
being distinct from the specifications (in fact it was John's
comment along those lines "after all, changes only to a <span
class="gmail-il">registry</span>, not to part of the core OT
specification" that made me ask), but ... as a practical matter,
they don't seem to exist in distinct location separate from the
spec, nor have separate processes defined. So, if they are
distinct, then I guess I don't understand how they work.</div>
</blockquote>
<p>Some background:</p>
<p>Eliyezer Kohen’s conception of TrueType Open laout (what became
OTL) was that Microsoft would act as registrar for features and
language system tags (and script tags, although these are defined
in reference to Unicode). So that’s the origin of the registry
idea.</p>
<p>To understand the difference between the OT format spec and the
registries, it is helpful to consider the handling of OT
variations axes. The five registered axes were initially described
in the fvar table spec, but then were removed to an external
registry (with its own broken process, abiut which more below) on
the grounds that a registry can be expanded and updated without
needing to rev a table number. So I would say that it is the
functional distinction between the format spec and the registries:
ease of editing (presuming an editorial process of any kind!)<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAAL6+1Kqp2OmpHCY_NxKO1=3R7gSz65tLUJ7So8DLypWq9qhzg@mail.gmail.com">
<div dir="ltr">
<div>Maybe that's in scope, maybe not. But I would float the
idea that if the registry idea has a broader intent, like
"people can declare their own tags for the purpose of testing
new ideas" or even just "people can avoid stepping on each
others' toes", then that sounds like a valuable concept, but
it might not be as well-publicized as it could be. <br>
</div>
</div>
</blockquote>
<p>Eliyezer’s concept was that private or custom tags wouldn't be
supported anywhere, and that if people wanted new tags they would
have to register them with Microsoft. I'm not sure that even made
sense in the mid-1990s. So again this comes down to a question of
ownership (in both the legal sense and the sense of
responsibility, which may be at odds, e.g. Microsoft claiming
ownership of OpenType while being derelict in their responsibility
for the spec).</p>
<p>In discussions regarding process for variation axis registration
in 2018, there seemed general acknowledgement that the process
defined at<br>
<a
href="https://github.com/microsoft/OpenTypeDesignVariationAxisTags">https://github.com/microsoft/OpenTypeDesignVariationAxisTags</a><br>
is broken. That process assumed a proposal-forward model, in which
people would submit proposals for new axes, then these would be
reviewed, refined, and then registered. Following discussions at
the TYPO Labs event in Berlin in Spring 2018, there was talk of
changing that process to be implementation-forward, including
restructuring the repo as a sand box to encourage experimentation
with custom axes, some of which could then be formalised and
registered if it looked like they would benefit, in terms of
interoperability, from having a standardised axis scale. That
didn’t happen, though; I think for the same internal MS reasons
that they don't have an OT spec editor.</p>
<p>The repeating problem is that Microsoft set up processes by which
they control the OT spec and associated registries, but have
stopped providing resources to those processes. So when the
processes are broken, they remain broken, and even when they're
not structurally broken they only work periodically, when MS
decide that they need something—like very basic variable fonts—and
stop working again as soon as they deem their needs met.</p>
<p>So...</p>
<p>A couple of years ago, I started thinking about a different
approach to registries: that because they're independent of the
format spec, they could be spun off from it, put into a different,
collective ownership model, and hence benefit from shared
resources instead of being dependent on Microsoft management.
There is, of course, an argument — as this group manifests — for
doing that for the whole OT spec, as such or via OFF, but the
nature of the registries perhaps makes them an easier ask, i.e.
Microsoft might be more willing to hand them over, and even to
see benefit in doing so.</p>
<p>And...</p>
<p>I've also been thinking about ways to simplify the implementation
aspect of new OTL features and OTvar axes. We have an intertia
problem in the current implementation models, because new features
and axes need to be implemented at the app level, which means
things like UI real estate. That makes companies like Adobe, for
instance, reluctant to support registering new OTL features (I
proposed one for honorific forms a few months ago, and Sairus
advised against it on the grounds that it would be unlikely to be
supported: the refrain is ‘Isn’t there an existing feature you
could used for that?’ — and I’m not saying he was wrong under the
current implementation model). The fact that app-based UI
implementation issues still have such an impact, when web-based
use of fonts via CSS do not have the same issues, is particularly
problematic: I feel we're being help up by one subset of font
client software.</p>
<p>One of the things that Microsoft really did right in the past
decade was developing the Universal Shaping Engine, which Andrew
Glass invented specifically to get past the kind of broken process
bottleneck I think we're looking at here. In that case, it was the
development lag between proposing and approving a script encoding
in Unicode and getting it supported with an MS shaping engine and
fonts.</p>
<p>What is USE? It is a framework that sits between Unicode and
fonts, and uses common concepts to minimise the amount of work
that needs to be done to push a newly encoded script into the
framework.</p>
<p>So recently I have been wondering if some of the implementation
inertia for OTL and OTvar could also be addressed in terms of
frameworks of common concepts, even e.g. a common axis scale at
the font level rather than a unique scale for each registered
axis? Instead of requiring each application to implement support
for discrete subsets of OTL features, which then get stuck that
way for decades, could we create an open framework for OTL
implementation, with hooks for UI on one side and a consistent
implementation of GSUB and GPOS on the other side?<br>
</p>
<p>JH</p>
<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>