[MPEG-OTSPEC] near-term OT spec work

[Behdad Esfahbod]

On Sun, Oct 4, 2020 at 8:06 PM Levantovsky, Vladimir <
Vladimir.Levantovsky at monotype.com> wrote:

> On Saturday, October 3, 2020 4:55 AM Caleb Maclennan wrote:
>
> On Sat, Oct 3, 2020 at 1:23 AM MURATA Makoto <eb2m-mrt at asahi-net.or.jp>
> wrote:
> > I think that synchronization with OT should not be mentioned in
> > this AHG.
>
> Why not? It seems quite relevant to me. Even if I don't *like* the
> current process and the black-box stages it involves, the current
> defacto way the MOFF (MPEG Open Font Format) spec actually gets
> updated is through tracking changes to MSOT (Microsoft OpenType).
> They are still (rightfully) in a position to do whatever they want
> with their own spec for internal use and pragmatically speaking the
> most effective way we have to get things fixed in OFF is by appealing
> to M$ as a benevolant dictator that can actually change their own
> spec and pretty significant weight to get their changes rubber
> stamped into OFF (since keeping them in sync is kind of the deal).
>
> I think it’s universally true that anyone who is a major implementer of
> the OFF/OpenType spec is also in a position to innovate and “do whatever
> they want”, which includes doing something new as a proof of concept,
> before one is in position to make a proposal for spec amendment to be
> considered.
>

Right. That's how we got four color font formats in OFF.



> However, saying that the de-facto way the OFF spec actually gets updated
> is through tracking changes to MSOT is inaccurate – for many years this has
> been a two-way street. Many times, a proposal was brought to the AHG list
> that ended up being incorporated in both specs, or made its way into OFF
> and then to OT. I don’t need to dig deep to find examples – these recent
> issues filed in the MSOT GitHub repo speak about changes being part of the
> last OFF amendment published in January 2020:
>
> https://github.com/MicrosoftDocs/typography-issues/issues/533
>
> https://github.com/MicrosoftDocs/typography-issues/issues/535
>
> https://github.com/MicrosoftDocs/typography-issues/issues/536
>
> https://github.com/MicrosoftDocs/typography-issues/issues/538
>

I just want to point out to others that these four examples simply
constitute adding one language tag, and two feature tags, to the tag
registries of OpenType. Tags are four-byte data. The feature tags get added
to the registry for reference and do not involve any implementation for
most clients. The language tag, in implementations that require language
tags to be spelled out explicitly, requires adding one line of code in a
bsearch table.

These are not representative or even comparable examples of the kind of
innovation and changes that have happened in this space in the past ten
years. Color fonts, variable fonts, even the ongoing COLRv1 work are
thousands of times more involved than these examples show.

So I find using those as examples of OFF/MSOT relationship being a "two-way
street" is at best misleading.



>
> However bad this state of affairs is and however silly it is for M$
> to try to keep their cake and eat it too — as long as this is the
> state of things I'd much rather hear about work they are doing
> internally on their MSOT spec through this AHG than have the topic
> be made off limits. The inevitable result of that would be for the
> entire end-to-end process to happen in closed groups that many in
> the industry don't have access to even audit!
>
> I believe that the spec progress is inconceivable without work first being
> done internally – this is where new proposals come from (COLRv1 is a good
> example, and the most recent). Folks don’t come here simply because they
> woke up one day with a great idea, they internalize it first. And yes,
> anyone who comes here with a proposal that is rooted in the work done
> internally makes a valuable contribution to this joint effort and
> potentially benefits from having their ideas reviewed in discussed by this
> community of experts.
>
>
>
> Now, I do agree that having two different specs describing the same
> technology isn’t ideal and may be confusing, especially because they use
> two different names due to trademark. However, there is also a pragmatic
> convenience to it – having one spec publicly available online is a
> convenience that ISO OFF simply doesn’t offer – it’s publicly available,
> but only as a massive PDF file. For as long as we have a clear
> understanding that our goal is to keep these two in sync [which has been
> the case until now, even if this sync mechanism is rather elastic] – I
> agree that we should continue this effort and that this discussion should
> not be off limits in this AHG.
>
>
>
> Vlad
>
>
>
> In short it seems very relevant to me for the sync process from
> MSOT→OFF to be mentioned in this AHG list. Even if some of the
> steps are still off limits to plebians, the fact that some of the
> steps are closed doesn't seem like a good reason to close off all
> of the process.
>
> Why do you think the OT→OFF synchronization that is both currently
> and historically a significant part of what the OFF is should be
> off limits for disccussion in this AHG?
>
> Caleb
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
> <https://protect-us.mimecast.com/s/fLo7CPN9lzh45MMOf0yRx2>
> _______________________________________________
> 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/20201007/321dcb1a/attachment.html>