[MPEG-OTSPEC] SHORT vs int16 vs ???

[Behdad Esfahbod]

On Fri, Aug 14, 2020 at 2:57 PM Peter Constable <pgcon6 at msn.com> wrote:

> Those changes were not made unilaterally. Behdad and others reviewed these
> changes before OT1.8.1 was published; Behdad suggested the type names could
> make big-endian explicit, but considered it “bikeshedding”. Without any
> further input, it was left as we see now.
>

That is what I'm talking about. Just because it was discussed doesn't mean
it wasn't unilateral. You keep to form this pet-peeve bikeshedding opinions
and no amount of talking with technical reasons seems to phase you. Here's
a short list of the times I conceded to such demands from you that I regret
now. All made the spec worst:

- When I designed the ItemVariationStore, I wanted 32bit "variation
index"es. You forced separate "major+minor" instead. This resulted in
misunderstanding and faulty design in CFF2 (which Adobe also demanded not
be reviewed by others formally). This also means everywhere in the spec now
we need two fields instead of one, for no benefit whatsoever. It also leaks
internal details of the ItemVarStore.

- Also in ItemVariationStore, I initially had it each region list its
active axes. You forced your opinion of regions listing every axis in fvar
even if inactive. I believe in "pay for what you use" design. With mine,
adding a hundred axes wouldn't have made every ItemVariationStore consume
more bytes. With yours it does. With mine, it would have magically enabled
Higher-Order Interpolation.  With yours it doesn't. Mine wasn't accidental,
even though I had not thought about the HOI possibility. A good product
will enable use-cases the original authors didn't think of. A bad product
tries to enforce the limited worldview of the builder on the users for no
good technical reason.

- You on behalf of MS demanded the `rvrn` feature be added, even though it
was not needed. *Every* feature can get variations in what the committee
designed. But MS / Office wanted a "fast path" because is stuck in
mentality that "simple shaping" is a legitimate design and should be
supported by the font format. Because of that decision, and because of
another bad decision unilaterally forced by MS: that lookups are NOT
applied solely by lookup-number like the spec says, now `rvrn` is useless
and confusing because some designs are made easier if variation
substitutions are applied first, other designs are made easier if variation
substitutions are applied last.

- You on behalf of MS demanded that LSB/RSB variations (and by extension
TSB/BSB variations) be encoded in the HVAR/VVAR tables because the obsolete
GDI "ABC" API "needs them" and can't be bothered to get them from the
outlines. Everyone else didn't want that. It was later pointed out by Dave
Lemon that the side-bearing variations of OT1.8 varfonts CANNOT be
represented in OT1.8 variation model. So the spec is faulty now. I fought
and got MS/you to agree to make those variations at least optional.

- MS, including you, blocked from progression any of the OTlayout proposals
that me and Martin Hosken prepared, that were a path to truly advancing
OTlayout towards being able to handle Nastaliq.

- As a sub-example of the above, Martin and I wrote the "glyph filtering"
proposal:


https://github.com/OpenType/opentype-layout/blob/master/proposals/glyph_filtering.md

to address a very real need from designers. You/MS blocked that with the
faulty "security issue" of allowing jumping over arbitrary number of
glyphs. It didn't convince you that it was already possible to jump over
arbitrary number of glyphs if the font declares all glyphs (or any!) as
GDEF class mark. Indeed, Andrew Glass & John Hudson's Soyombo font
*depends* on that.

That's just a few I could type right now. There's probably another dozen I
will type next week.

It is the fact that you don't see any of these as problematic that I
question your fairness and objectivity.

To everyone who tells me to drop the past and focus on the future, I won't
as long as Peter and/or MS don't change their stance. That would be
continuing with the status quo and I will refuse to do that. Albert
Einstein : “Insanity is doing the same thing over and over again and
expecting different results.”

Want me to drop all my grudges? You and/or MS admit past faults (no
"but"s), offer a sincere apology, and commit to not repeat them moving
forward.

behdad


>
>
>
>
> Peter
>
>
>
> *From:* mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> * On Behalf Of *Dave
> Crossland
> *Sent:* Friday, August 14, 2020 1:19 PM
> *To:* Behdad Esfahbod <behdad at behdad.org>
> *Cc:* mpeg-otspec <mpeg-otspec at lists.aau.at>
> *Subject:* [MPEG-OTSPEC] SHORT vs int16 vs ???
>
>
>
>
>
>
>
> On Fri, Aug 14, 2020 at 1:36 PM Behdad Esfahbod <behdad at behdad.org> wrote:
>
> On Fri, Aug 14, 2020 at 7:40 AM Eric Muller <eric.muller at efele.net> wrote:
>
> At the same time, the names of structures in OpenType tables end up in
> code, documentation, tools' UI, discussions on this list, our heads, etc..
> Changing them every two months is not going to help. I would prefer such
> changes to occur infrequently, may be accumulating them in a backlog in the
> mean time.
>
>
>
> Not just that: Peter's unilateral renaming was a disservice to the
> specification: he replaced the obscure-looking "SHORT", "USHORT", "LONG",
> "ULONG", with common words "int16", "uint16", "int32", "uint32", even
> though those do not match the similarly-named types in computers and
> languages, because the OpenType ones are always big-endian.  If he had
> consulted others, we could have reached a universally-unambiguous and clear
> names.
>
>
>
> What alternatives do you propose, Behdad, Peter, Eric, anyone? :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200814/c464dedd/attachment-0001.html>