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

[Behdad Esfahbod]

Correction: I meant Dave Arnold, not Dave Lemon.

behdad
http://behdad.org/


On Fri, Aug 14, 2020 at 4:16 PM Behdad Esfahbod <behdad at behdad.org> wrote:

> 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/5d55945a/attachment.html>