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

[Dave Crossland]

On Tue, Sep 15, 2020, 12:23 PM Peter Constable <pgcon6 at msn.com> wrote:

> Not trying to shut anything down…
>
>
>
> > Font compiler and rendering stack are open source
>
>
>
> There are open source font compiler and rendering stack implementations,
> and that can definitely help facilitate hacking on new ideas.
>
>
>
> Just don’t confuse that with eventual adoption of new ideas: the
> implementation landscape is far more complex than current OSS
> compiler/rendering implementations.
>

And sil graphite is a case study.

Also recently is aat layout, as harfbuzz has full support for it now, so
it's a cross platform format, de facto.


>
>
>
> Peter
>
>
>
> *From:* mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> * On Behalf Of *Roderick
> Sheeter
> *Sent:* Tuesday, September 15, 2020 8:30 AM
> *To:* Simon Cozens <simon at simon-cozens.org>
> *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)
>
>
>
> I see the hackers path as wide open! Font compiler and rendering stack are
> open source, we can (and IMHO should) play with implementation as early as
> we like without regard for business cases and spec changes. Q
>
>
>
> 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.
>
>
>
> On Tue, Sep 15, 2020, 12:22 AM Simon Cozens <simon at simon-cozens.org>
> wrote:
>
> On 15/09/2020 04:50, David Lemon wrote:
> > But I'd seriously emphasize Peter's points about building the business
> > case. I kinda get the sense Dave thinks it will all be self evident, but
> > that's not how business cases work. As someone who struggled to get
> > required buy-in for some of the main developments we use today, I can
> > assure you there's no such thing as a no-brainer.
>
> As much as it pains me (as a gung-ho developer) to admit this, I think
> you're right. Unless there are clear and compelling reasons to move to
> something else, it won't happen. Building both the business case and the
> coalition is really important.
>
> That said, I would strongly *recommend* putting the cart before the
> horse! Or at least allowing the cart and the horse to be in whatever
> order people like. For some of the people you want to have involved, a
> period of frenzied, anything-goes creativity about what a new font
> format might look like (whether here or elsewhere) will expose where the
> energy is and where the current pain points are much better than forcing
> them to articulate a business-focused justification. So long as all
> concerned are aware that this is just brainstorming and not every wild
> idea is likely to be taken up, then I think it's important not to quench
> that creativity too prematurely. We can attack the issue from both ends
> simultaneously: gather ideas and building the business case. Indeed,
> each will need to inform the other.
>
> To put it another way, thinking about implementation is precisely how
> developers express what's important to them.
>
> S
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=02%7C01%7C%7C5830dade35b84bba8f6208d8598c3fb6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637357806183500235&sdata=Fx48Bma2SSGyLiwNriMHNo25r7nXdgScQytddPT3TbY%3D&reserved=0>
>
> _______________________________________________
> 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/20200915/fe89365a/attachment.html>