[MPEG-OTSPEC] Co-existence of glyph rendering source types

[Dave Crossland]

On Fri, Sep 11, 2020, 8:02 PM Adam Twardoch (Lists) <list.adam at twardoch.com>
wrote:

> On Sat, 12 Sep 2020 at 01:34, Dave Crossland <dcrossland at google.com>
> wrote:
> > I'm not sure "political reasons" is a good principle. The political
> reasons have a technical basis, right?
>
> Well, I'm not qualified enough to speak about whether CFF2 is technically
> a “good thing” or not. ... it’s likely that it has some advantages. ... I
> don’t feel I’m equipped to list arguments why it shouldn’t be part of OFF2.
> I’m leaving it up to others to come up with pros and cons.
>

I'm with Li Renzhi, I'm not sure we should start with anything in OFF other
than goals - ideas about what is needed and useful:

I think a 64k glyph limit is a problem, and the idea that there should be
no limit to the number of glyphs seems appealing to me; going from 16 bit
GIDs to 32 to 64 to ...

I think shape reuse is such an idea, and while CFF has one implementation
of that, Li Renzhi has just proposed a more powerful kind which is familiar
to editors like fontlab 6+ and GlyphsApp and robocjk. However, in some
situations the "unpacking" of such "routinization" isn't ideal, as it
requires loading a superset of data into memory and processing it.

I think w3c incremental transfer is coming, so a relevant idea is that a
new format should work well with such technologies.

I think postscript/ttfautohint zone based style hinting is such an idea,
and the "full" hinting instructions of TrueType have gone away in all
modern renderers, but there is still a need for "overrides" as can be done
to ttfautohint and VTT autohinter output.

I think the "versioned table container" superstructure idea of sfnt is a
good idea.

And so on. I like the idea of having principles and goals, and citing prior
art in so far as it prevents "reinventing the wheel" unnecessarily.

But where OFF has duplicate data, or archaic constraints, we can avoid that
by developing a new format from first b principles.

Cheers
Dave

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200911/c86aad13/attachment.html>