[MPEG-OTSPEC] Registries and frameworks [Was: Issues from CSS: Will they be covered by the text shaping WG?]

[John Hudson]

On 14082020 10:50 am, Nathan Willis wrote:
> 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 registry, 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.

Some background:

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.

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


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

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

In discussions regarding process for variation axis registration in 
2018, there seemed general acknowledgement that the process defined at
https://github.com/microsoft/OpenTypeDesignVariationAxisTags
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.

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.

So...

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.

And...

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.

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.

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.

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?

JH


-- 

John Hudson
Tiro Typeworks Ltd    www.tiro.com
Salish Sea, BC        tiro at tiro.com

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.

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