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

[Roderick Sheeter]

It would be helpful to start by understanding what changes people want to
make and why. One possible approach would be to simply ask people to post
their thoughts and share links back to the group (perhaps CG mailing
list?), inspired by the Rust call for blogs (
https://blog.rust-lang.org/2019/10/29/A-call-for-blogs-2020.html).

On Sun, Sep 13, 2020 at 10:02 AM Peter Constable <pgcon6 at msn.com> wrote:

> > I really hope we’re not going to try to define some entirely new font
> format by email.
>
>
>
> Someone mentioned offline that my brief message, saying what I don’t want
> but not what I would want to see happen, might come across as trying to
> shut down discussion and block progress. I think that’s valid feedback, and
> so want to correct that with a brief elaboration.
>
>
>
> Clearly, my statement indicates a desire to shut down discussion—_*in
> this current mode and context*_.
>
>
>
> For one thing, I thought there had been general consensus that a topic
> like creating an entirely new format would be pending a discussion
> elsewhere (the TFCG) on what new areas of activity should be discussed and
> what the appropriate context(s) for those should be.
>
>
>
> Secondly, discussion was bringing up specific design details (dropping
> CFF, what OS/2 metrics are needed, how formats for graphic elements should
> be architected), which is putting the cart waaaaayyyy ahead of the horse:
> As Adam and Vlad suggested, this topic needs to start with a cost-benefit
> analysis. I’d expand that a bit: any work to start in this direction would
> need a carefully thought-out business case _*and*_ strategic roadmap that
> can convince a broad range of vendors, including most or all the majors,
> that there will be beneficial ROI and a feasible path to success that takes
> current realities into consideration. (Do I sound like a PM?) Engineering
> is first of all a matter of addressing real public or business problems or
> opportunities. Without that, technical design is nothing more than a
> science project.
>
>
>
> And until vendors have bought into a business case and strategic roadmap,
> talk of a _*hugely*_ disruptive change (which is what is being discussed)
> is counter-productive: at best, a noisy distraction; and at worst,
> perceived as intended to create discord and new font wars.
>
>
>
> I’m all for designing a new and better mousetrap, and I’d be in favour of
> discussions that explore business case and possible paths to success. But I
> don’t think this email thread is net helping move toward that. Let’s
> progress one step at a time, as generally agreed, in the TFCG.
>
>
>
>
>
> Peter
>
>
>
> *From:* Peter Constable
> *Sent:* Friday, September 11, 2020 3:57 PM
> *To:* 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)
>
>
>
> I really hope we’re not going to try to define some entirely new font
> format by email.
>
>
>
>
>
> Peter
> _______________________________________________
> 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/20200913/4e999e3d/attachment-0001.html>