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

[Levantovsky, Vladimir]

Hi Peter,

On Wednesday, September 16, 2020 1:30 PM Peter Constable wrote:

Vlad [wrote]:

> wouldn’t you want to brainstorm…

I guess the question is where and how.
We know people have wanted to discuss a few distinct areas: file formats, shaping, vertical layout. The latter two haven’t been part of OFF, so I’ve assumed the primary locus for discussion would be elsewhere than here, starting in the FTCG. I was thinking that _preliminary_ discussion of possibilities for entirely new formats could also happen there, but you’ve indicated that would be in scope for the AHG. Which is reasonable to me since, if there is consensus to start any technical work on some new format, I wouldn’t suggest it happen somewhere other than here.

Whether preliminary discussions happen “here” or “elsewhere (in FTCG)” isn’t at all a concern – as a community, we _are_ one and the same. The venues only becomes important when it comes to doing technical work, and I am happy that you and I agree on the fact that this AHG is both able (as in scope) and capable to make it happen.

My main concern for this email list has been that discussion on technical issues in relation to potential new formats could quickly run into a hundred different areas and rabbit holes, and could quickly become very randomizing. And I don’t think that’s good because (i) some could be chased away by volume of traffic they’re not interested in, (ii) it would be harder someone to focus on any of those discussions if they _are_ interested, and (iii) in the meantime it would make it harder to focus on any work relevant to the _current_ OFF project.

I am not sure if any email list (whether AHG or FTCG) is immune from the concerns you raised. But for the sake of focusing on the work relevant to the current OFF project – I agree that we should prioritize it on _this_ list.

Dave has suggested a github issues repo; I haven’t closely followed discussion between him and you on that, but perhaps that’s an idea to consider.

This is now existing and readily available tool: https://github.com/MPEGGroup/OpenFontFormat

Vlad

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at<mailto:mpeg-otspec-bounces at lists.aau.at>> On Behalf Of Levantovsky, Vladimir
Sent: Wednesday, September 16, 2020 9:03 AM
To: Dave Crossland <dcrossland at google.com<mailto:dcrossland at google.com>>
Cc: mpeg-otspec <mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>>
Subject: Re: [MPEG-OTSPEC] Introducing breaking changes into the spec (was: RE: [EXTERNAL] Proposal to deprecate derived search values)

Dear Dave,
I will try to keep this one short. ☺

On Tuesday, September 15, 2020 11:31 PM Dave Crossland wrote:
Dear Vlad,

Another long one from me I'm afraid. Adam, don't get jealous 😂
On Tue, Sep 15, 2020, 1:15 PM Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com<mailto:Vladimir.Levantovsky at monotype.com>> wrote:
We just have to remember if we want other people to implement we need to do our due diligence at some point and get the spec updated.

We also need to be realistic of the potential challenges with new technology adoption _from the end-user point of view_. Today’s reality is that the current implementations are widespread,

Err, I'm not sure about that, it's not the reality I am living in :)

In my reality, support for CFF2 or SVG in OT is not widespread, nor CBDT. COLR is getting there.
<snip>
Even focusing on the most widely implemented parts of MOFF, uneven implementation reigns in my reality:
<snip>

I tried to make an emphasis on end-user point of view. Yes, the existing implementations are never perfect and not complete, there is always something to be desired … but that’s not the point. I see success when a user can simply select any font they want, declare it as one to be used to render text on their website, and then actually see the text rendered exactly as desired – on any device, in any browser. The running counter of font views on Google Fonts analytics page<https://protect-us.mimecast.com/s/hcUxCYEnxyt3LGLDf03WtQ> is a testament to this success, because the number is mind-boggling!

Now look, I don't mean to diminish the achievements of the last 5, 10, 25 years. But I also think it's equally important to be clear about the current shortcomings, and to metabolise the energy in the AHG for multi-track improvements through clearly written down protocols of change management.

The change is here and it needs to be managed.

I think we are both in violent agreement on the perception of the events of the last 20 years and on what is happening now. I am experiencing a pure joy thinking about how this group and the community at large was able to achieve something that literally changed the world of CE devices and the web.
<snip>

If an incremental update can offer a smooth transition path, such as specifying that when a font engine's client is seeking an old value, it can compute that value from the deduplicated new format and return it, that's desirable. Terence Dowling posted last week some kind of koans for this kind of thing.

Suggestions to the AHG to consider that kind of thing will, I expect, be very fruitful.

But saying stuff that rhymes with "slow down kids, be REALISTIC, stop stop stop, no no no," is, I think, going to rub people the wrong way, and risks the opposite of what is intended.

This is not what I said! If we were a team getting ready for a debate – wouldn’t you want to brainstorm all possible questions all get all the answers and arguments ready, before the debate starts? Would you want to _know_ the questions you may be asked (I do not imply cheating) and get our story so compelling that it tells everybody “trust us, we know what we are doing”?

This is what I was talking about – making our business case where all ‘i’s are dotted and ‘t’s are crossed, and an attempt to foresee any and all possible questions, and present our solutions making the arguments for our case so compelling! We don’t get there if we cut corners hoping that questions won’t be asked, or shortcomings won’t be noticed.

Vlad

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