[MPEG-OTSPEC] near-term OT spec work

Dave Crossland dcrossland at google.com
Sat Sep 12 12:14:26 CEST 2020


Excellent progress! Thank you Peter

On Sat, Sep 12, 2020, 12:12 AM Peter Constable <pgcon6 at msn.com> wrote:

> I thought I’d mention a bit on status of this work: When I started on
> August 10, the MicrosoftDocs/typography-issues repo had 99 open issues
> pertaining to the OT spec. Since then, 117 additional OT spec issues were
> opened—the count I’m tracking is now 216. Of those, I’ve marked 11 for
> future (post OT 1.8.4) consideration, and resolved 158 with 154 “fixed”
> (i.e. proposed revisions), leaving 47 still open.
>
>
>
> I’m still waiting on some logistics to prepare a way to have drafts of
> pages available for review.
>
>
>
>
>
> Peter
>
>
>
> *From:* mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> * On Behalf Of *Peter
> Constable
> *Sent:* Tuesday, August 18, 2020 3:59 PM
> *To:* MPEG OT Spec list (mpeg-otspec at lists.aau.at) <
> mpeg-otspec at lists.aau.at>
> *Subject:* [MPEG-OTSPEC] near-term OT spec work
>
>
>
> OpenType / OFF stakeholders:
>
>
>
> I want to let you all know that I have been in discussion with the Google
> Fonts team and Microsoft about getting work on the OpenType spec unblocked
> for the near term. Google approached me about working on an extension to
> the COLR table (more below). That was something Microsoft also wanted to
> see move forward, along with a backlog of reported issues. I’ve been able
> to work out compatible agreements with each of them which are making it
> possible for me to resume working as editor on the OpenType spec for a
> period of time.
>
>
>
> Let me be clear that this is not a long-term arrangement. There has been
> recent community discussion about better structures for working together on
> the OpenType spec and, perhaps, other specs related to text layout and
> shaping. That is a parallel discussion, and this doesn’t presume any
> particular outcomes of those discussions.
>
>
>
> There are a couple of specific spec projects that Google and Microsoft
> agreed I should work on:
>
>
>
> The first is to address the backlog of issues on the OT spec that have
> been reported* to Microsoft since OT 1.8.3 was published (two years ago
> this month). This will include incorporating anything that was in Amendment
> 1 of OFF that’s not yet reflected in OT. But it would not include extending
> the OT format with any new capabilities. It also won’t include anything
> regarding shaping-engine / script-implementation specs; it’s just the OT
> spec proper.
>
>
>
> * OT spec issues can be reported using the feedback link at the bottom of
> the page for each page of the OT spec
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2F&data=02%7C01%7C%7C4356b0de60584856c69408d843ca51b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637333883515870496&sdata=fmFPZCFpqtAchK2yGhVUgDVwNXCmwb%2FrW7zHtIm8664%3D&reserved=0>;
> these get filed as issues in a public GitHub repo,
> MicrosoftDocs/typography-issues
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Ftypography-issues&data=02%7C01%7C%7C4356b0de60584856c69408d843ca51b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637333883515880492&sdata=sxFNlt0BQRZ90l2wNvCu1hTcgR%2FAz8vAJ4v%2FRnNquj4%3D&reserved=0>.
> (I’ve tagged OT spec issues with the “OpenType spec” label.) For the time
> being, this remains the preferred way to report issues on the OT spec. I’ll
> say a bit more below about reviewing drafts of changes.
>
>
>
> The only technical changes to the OT spec would be corrections to errors
> or clarifications—some of which might have larger impact, but all of the
> changes will be proposals offered for broad review. Note that this will not
> be an attempt to re-write major portions of the spec or rid it of legacy,
> technical cruft. The main objective is to keep work alive and make
> incremental but worthwhile improvements.
>
>
>
> The second project will be to add some significant new capabilities for
> color fonts, extending the COLR table to support gradient fills and to
> integrate variations. This is a proposal that’s been floated for a little
> while. In particular, it was discussed between several companies over a
> year ago (or maybe earlier?), and a preliminary proposal was drafted by
> Behdad Esfahbod and Dominik Röttsches. That proposal (with some subsequent
> revisions) is in the googlefonts/colr-gradients-spec
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgooglefonts%2Fcolr-gradients-spec&data=02%7C01%7C%7C4356b0de60584856c69408d843ca51b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637333883515890486&sdata=VExDewWHwPzTi%2B3eIaV%2B2T8Bw%2FiQsYufM1DomuiW6Do%3D&reserved=0>
> repo. I’ve also prepared a separate doc
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPeterConstable%2FOT_Drafts%2Fblob%2Fmaster%2FCOLR_V1%2FCOLRv1formats_rev4.md&data=02%7C01%7C%7C4356b0de60584856c69408d843ca51b8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637333883515900480&sdata=qoYtjbemU%2F5GzShp1H08jJDBxHcOko1fqmPmdmne7dU%3D&reserved=0>
> showing the new structure formats as they’d appear in the OT spec (for
> those not familiar with C++ template syntax). For now, input should be
> filed as issues in the googlefonts repo.
>
>
>
> In terms of timelines for these two projects, I hope both will progress
> quickly. The only thing to slow down the first is the volume of feedback to
> be considered, and possible need for in-depth investigation on some issues
> to get the right information. The second project still requires some design
> work, and that might take longer. If both can progress fairly quickly, then
> I would combine the two into a proposed OpenType 1.9 release. But if the
> second requires somewhat more time, then I could split these into a 1.8.4
> release for the maintenance update, followed before long with 1.9.
>
>
>
> For both of these, I’ll be working with MS, Google and Vlad Levantovsky to
> come up with as good a way I can find to make drafts (with changes
> highlighted) available for public review and input. I’m open to suggestions
> on how to do this, but for quick progress I’ll opt for what’s feasible
> quickly over better long-term options. I know some would like MS’s private
> repo that has the OT sources to be made public; that might not be so easy
> since that repo has a lot more content than just the OT spec. Something
> like that might eventually be possible, but we want to make sure that
> what’s best for the long term doesn’t get in the way of making some
> valuable progress in the near term, provided the latter is done in a manner
> that reasonably transparent and that allows anybody who has useful input to
> offer can do so.
>
>
>
> I should mention how I anticipate this will fold into ISO process for OFF.
> After there’s been some public review (by whatever means), proposed changes
> for OFF will be circulated on the MPEG-OTSpec list, which is how the formal
> process for ISO would be initiated. ISO has certain policies around
> amendments and timelines that somewhat limit flexibility. For that reason,
> if there were to be an OT 1.8.4 update, there probably would _*not*_ be a
> corresponding amendment to the OFF standard. Rather, any OFF amendment
> would be held to take the additional changes that would go into OT 1.9,
> notably COLR enhancements. Vlad can provide more info on ISO process if
> needed.
>
>
>
> In the big scheme, this is a small step, but I hope it’s generally seen as
> a positive step nonetheless.
>
>
>
>
>
> Peter Constable
> _______________________________________________
> 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/20200912/a74f4e78/attachment-0001.html>


More information about the mpeg-otspec mailing list