[MPEG-OTSPEC] Request for OFF Github Repo

[Dave Crossland]

On Wed, Sep 16, 2020, 2:39 PM Behdad Esfahbod via Otfontvar <
otfontvar at unicode.org> wrote in thread "Re: [OTFontVar] revising STAT
description":

It's a huge problem that *you* [Peter Constable] can do this but the rest
of us can't because we don't have access to the spec source code.


This reminded me to finish my reply to your message on this thread:

On Wed, Aug 26, 2020, 8:01 PM Behdad Esfahbod <behdad at behdad.org> wrote:

On Wed, Aug 26, 2020 at 11:03 AM Levantovsky, Vladimir <
Vladimir.Levantovsky at monotype.com> wrote:

What’s the magic word … (Ah, I remember now, “abracadabra”!)

https://github.com/MPEGGroup/OpenFontFormat

(You can click on it now!)

Vlad

P.S. You have two more requests remaining until midnight! :D


Populate it with the source to the OFF text.


I've suggested this to Vlad in another thread, and he has legitimately said
that is not a decision he can make himself, and he would enquire with ISO
folks and get back to us. But as far as I know Vlad hasn't yet communicated
a decision back from ISO to the AHG yet. Vlad, is there a firm answer? :)

Since I earlier asked for this, I want to explain why I think ISO has an
incentive to do so - and why MSOT does not. :)

There is this tremendous energy swirling around the MSOT/AHG/font-text
community, which I think is a single unit.

Primarily this is for "the missing volume" of the OFF spec, one that
comprehensively documents shaping behavior, and that energy is now directed
to a separate independent institutional home at w3c in the font-text
community group.

Secondarily it is for a more enjoyable OFF spec to read, from the
perspective of several different kinds of audiences. This will require a
very high volume of edits to OFF.

That energy has been accumulating, cooly dispersed for many years and in a
dozen nooks and crannies of the web, and the scale of the challenge has
been daunting and dampening that energy.

But now for various reasons, that energy has now become hot, and is
manifesting as a torrent of activity.

This is why I believe documenting the process and protocol for acceptance
of change proposals to OFF needs to be clarified in writing, and made
efficient using a modern collaborative authoring technology.

The most efficient way forward is for ISO to make a complete copy of the
OFF spec text available in source form to the AHG on GitHub.

If ISO won't do this, perhaps Microsoft will offer to make their
specification source available - as Peter and Simon recently discussed on
this list, it seems it is tantalizingly 'just' a "git filter branch" away,
and it is in sync with the OFF text.

But I repeat myself to say to you Behdad, that it is their format. I find
it hard to be invited into someone's house and then complain they aren't
sharing their best wine with me, so I'm grateful for all the community
engagement they wish to offer; I keep in mind they have a right not to
offer any. Since it seems okay for Apple to want to have a spec they
control to match the implementations they control, I don't really see why
Microsoft would not want to retain the OpenType ® spec that always matches
their implementation.

So, while I will respect both ISO and MS as organizations if they continue
to not make it easy to contribute changes to their texts as pull requests,
if neither ISO or Microsoft do this within a reasonable amount of time, I
expect what will happen is that one or more new specification text projects
will gather steam, vying to be the highest upstream.

I don't say this hypothetically, but as a simple extrapolation of the
trajectory I see that Google is on with COLR repo, and Simon Cozens and
Adam Twardoch are on with the CommonType.org project.

Note that CommonType is no longer starting with the AOTS text, but it's
starting from scratch.

I expect such new "from scratch" documentation projects will each send the
AHG proposals to update each and every section of the OFF standard with a
new draft, each submitted as "non-technical editorial change."

This will deliver you what you are asking for.

And there is going to be such a large volume of changes proposed that it
will become inevitably rather cruel to the editor, Vlad, to follow a
technically unsophisticated "copy and paste into a docx" workflow... that
was state of the art when I was a boy.

Now today at least at the ISO MPEG OFF AHG, we have a GitHub issue tracker,
so we can start to make it easier on the editor to track changes and call
for consensus as a 1:1 upgrade from doing that on this mpeg-otspec mailman
list, in terms of volume and mass of change proposals.

But it may still become burdensome as the volume or mass of change
proposals increases - and it remains far from the current state of the art,
as practiced at w3c and OASIS Open, and at Microsoft with OpenType® (albeit
internally to MS) and at Google with the COLRv1 proposal.

If ISO does make an editors draft available for direct change proposals
that can be commented on line by line, discussed as a whole, and when
consensus arrives, merged into the mainline... Then that will be less
cruel.

It is now how the w3c and OASIS Open operate their standards working group
activity, and I believe ISO has an opportunity to modernize it's processes.

But, it seems to me likey Vlad's firm answer will be no. David Singer has
posted his concerns about it at
https://github.com/MPEGGroup/OpenFontFormat/issues/1

And that will be fine. Having to redo the spec from scratch is actually
a good "exercise" *anyway* - throwing away the first draft and starting
again when you know what you're doing always gives a good result.

I say "exercise" as a plain metaphor: it's hard work, there's a feeling of
inertia the first time around the track, but it gets easier over time and
it's ultimately better than without doing it.

So, I encourage you again to let it go if it turns out MS and ISO don't
seize the moment and the opportunity to lead, and to benefit themselves.
There are benefits to all from not having their texts available!

But if it is available, we can propose the rewrite as incremental changes
in a more efficient way.

So, Vlad, what's the firm answer? :)

Cheers
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200916/e058fe80/attachment.html>