<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>