[MPEG-OTSPEC] Introducing breaking changes into the spec (was: RE: [EXTERNAL] Proposal to deprecate derived search values)

[Dave Crossland]

Thanks for clarifying Rod! :) Posting anywhere is good for me, as I or
anyone can track via https://github.com/MPEGGroup/OpenFontFormat/issues and
make an index :)

On Mon, Sep 14, 2020 at 4:10 PM Roderick Sheeter <rsheeter at google.com>
wrote:

> My intent was that people would just post personal blogs (which I
> translate to "post anywhere you like that people can access") and then
> email somewhere appropriate (the CG list, this list, w/e we think is best).
> From review of those posts we can start to identify specific projects we
> want to take up, who is interested in which projects, etc.
>
> On Mon, Sep 14, 2020 at 11:32 AM Dave Crossland <dcrossland at google.com>
> wrote:
>
>>
>> Hmm. I've heard from some that TFCG *isn't* expected to charter font
>> format spec work, but rather only the shaping spec work, which is adjacent
>> and interrelated. I've heard from others that the TFCG *is* expected to
>> spin off several CGs/WGs, at least one on font format specs.
>>
>> That work is already happening on 3 levels: (1) authoring docs on the
>> already implemented tech, (2) authoring incremental improvements to that
>> tech, and (3) authoring a step-change improved format.
>>
>> Peter, suggesting a serial approach ("one step at a time"), seems to me
>> counter to what I see as generally agreed and already widely enacted, which
>> is a parallel approach: These 3 tracks have been happening, in parallel,
>> for years and will continue to happen _somewhere_.
>>
>> It's only question of where.
>>
>> Rod and Peter, while I didn't see your suggestions to use the FTCG
>> mailing list or other fora instead of the AHG repo as attempts to start a
>> font war, lol, I don't think _any_ FTCG venue is yet chartered for _any_
>> technical discussion, and as I said above, its not clear that FTCG fora
>> will have font formats in scope.
>>
>> Peter and Vlad, you have special positions as the editors of the MSOT and
>> OFF specs. You've both posted responses in the last few days that I myself
>> did interpret as trying to shut down discussion and progress that is newly
>> happening in the AHG space around the 3rd track. So I'm glad to hear from
>> Vlad that this was a misunderstanding, and this 3rd track is welcome within
>> the AHG. However, what seems to still be missing is that collaborative
>> authoring environment; the https://github.com/MPEGGroup/OpenFontFormat/
>> repo is "issue only" and no collaborative authoring of files is expected
>> there, at present.
>>
>> But perhaps if we follow Rod's suggestion to start posting all desirable
>> change ideas as issues on the repo, and tag (or put into milestones) each
>> issue to clearly mark which track it is on, then another tag can be added
>> to indicate the idea is ready to move to authoring, and Pull Requests with
>> drafts can be linked to the issues and commented on line by line before
>> merged into meaningful "trunk" branches. (Perhaps Peter this is more what
>> you mean by "one step at a time"? :)
>>
>> What happened so far this year, to my eyes, is that ISO/MPEG had a window
>> of opportunity to lead in providing a space for the font format spec
>> discussions _and_ collaborative authoring, and it seems that window is now
>> closing (but not fully closed) and they have ceded that opportunity to W3C,
>> as there is no collaborative authoring space allowed here.
>>
>> If it does turn out to be the case, that collaborative authoring isn't
>> possible in the AHG repo, and the window closes, then what I expect
>> will happen is that the "real work" on all 3 tracks will happen at W3C, and
>> what will happen in the MPEG space is that "finished" change proposals will
>> be posted here, and this will become (remain?) a 'mere' forum to voice
>> objections that weren't heard upstream, and with the formal ISO WG as a
>> final backstop forum for objections.
>>
>> ...This would be surprising to me, because I had heard earlier this year
>> that this was the best forum available today for font format work, which
>> I'd understood to mean all 3 tracks. But if that's how it is, that's how it
>> is :)  And I don't see how this should be controversial, since that is
>> pretty much what has been happening for many years, where the "real work"
>> happens elsewhere (like private Unicode lists) and then goes into the
>> MSOT spec, and finally then change proposals are posted here.
>>
>> Really, my interest is to clarify and clearly document the whole thing; I
>> don't mind too much where the "real work" happens, as long as it is
>> effective, and everyone knows where to go.
>>
>> It seems worth being explicit here that I as Google have already
>> commissioned work on (3) from Black Foundry and Just van Rossum as part of
>> the RoboCJK project, which is happening on that GitHub repo. Just like the
>> COLR work, I don't think this location is ideal, not at all. Similarly,
>> Simon is working on all 3 tracks at an impressive pace of his own
>> initiative, not funded by Google, on commontype.org and its associated
>> Github repos. I can imagine that Simon's project may move to an MPEG repo,
>> or a FTCG repo - but that's up to him.
>>
>> While there are separate adjacent areas of interest and different costs
>> and benefits to different organizational homes, there is value in common
>> procedures. A set of repos scattered in org-less or single-vendor spaces, a
>> set of repos within GitHub.com/font-text, and issues-only repos for
>> Microsoft OpenType & Related Specs ("MSOT"?) and ISO/MPEG OFF ("MOFF"?) is
>> the current state of affairs.
>>
>> I'd like to see them converge a bit more, and de-duplicate as much as
>> possible.
>>
>> But in no scenario do I see any font wars emerging. The font wars were of
>> a time when font formats were encumbered by proprietary licensing regimes,
>> and I've heard nothing in 2020 that indicates any one expects any
>> contributions to any upcoming formats to not be intended for extremely wide
>> implementation. I think the business case for that is clear to everyone
>> here... If any vendor chooses to delay implementation of a format that they
>> are completely free to implement, that's not a war :) And its also the
>> current state of affairs for OFF: large parts of OFF are not widely
>> implemented by major vendors today.
>>
>> Cheers
>> Dave
>>
>>> _______________________________________________
>> mpeg-otspec mailing list
>> mpeg-otspec at lists.aau.at
>> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200914/2321730a/attachment.html>