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

[Renzhi Li]

I think we should divide "breaking changes" into two kinds:

  *   The difference could be hidden under a font library.
  *   The difference could not be hidden under a font library.

CFF2 lies in the first category: unless a client application explicitly reads font tables, this format difference is well encapsulated under font libraries (i.e., DWrite), so most applications could simply update their dependencies and do not need to do any substantial change.

GID32 is the second kind: At least one well-known font library must update their interfaces to properly support such features, and applications need update themself too, since the interfaces are changed. This kind also include tangled shaping (i.e., position-dependent substitution). For these features, putting them together and create an OFF2 should be the easiest method to get them realized, and OFF2 should provide a "LGCY" table to allow fonts to provide additional information for graceful downgrading. (for GID32, it should be a subset of glyphs?)

Yours,
Renzhi
________________________________
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> on behalf of Peter Constable <pgcon6 at msn.com>
Sent: Wednesday, September 16, 2020 18:18
To: Dave Crossland <dcrossland at google.com>
Cc: mpeg-otspec <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)


In that vein, I’ve opened an issue to seed discussion on one particular topic: “32-big glyph IDs: what and why”



https://github.com/MPEGGroup/OpenFontFormat/issues/10<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMPEGGroup%2FOpenFontFormat%2Fissues%2F10&data=02%7C01%7Crenzhi.li%40microsoft.com%7C52896f52316949b05d8208d85aa7aa49%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637359023472799484&sdata=0G87oWI2zdhdvmvEcevTxtLfQugFConEFuRsDD1rMHA%3D&reserved=0>





From: Dave Crossland <dcrossland at google.com>
Sent: Wednesday, September 16, 2020 4:47 PM
To: Peter Constable <pgcon6 at msn.com>
Cc: Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com>; mpeg-otspec <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)





On Wed, Sep 16, 2020, 1:30 PM Peter Constable <pgcon6 at msn.com<mailto:pgcon6 at msn.com>> wrote:

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.

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.

100%, and this isn't a hypothetical as Peter has very politely posed it!



Liang already stated he is tired of this list, as any email list would be tiring.



I think email lists are incapable of managing the clear open/closed status of any thread of discussion, and lack tags, and the special kind of tag called a milestone, which comes with a few associated properties - like completion date, stack rank, and that an issue can only have one milestone tag.



So, if someone is only interested in discussing 1.8.x updates, they can just look at the 1.8.x milestones' lists of issues  (discussion threads.)



I'd like to start directing all meaningful discussion away from this list to the mpeggroup GitHub repo. Does anyone object to this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200917/e852a8fa/attachment-0001.html>