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

[Behdad Esfahbod]

Here's a few more instances of MS unilaterally acting or refusing to act in
a timely manner to consensus by experts:

- Ned / Apple repeatedly asked for “Indic 3” tags to be added to the spec
such that Indic scripts can be routed to the USE shaper. This first was
presented in an OpenType Layout meeting I called for and chaired in Google
Seattle in 2014 [0]. Was a recurring topic in multiple OpenType Layout
meetings. Never happened.

- name table format 1 was added to spec with no input from anyone outside
Microsoft as far as I know. No one I have talked to even is sure that even
Microsoft implements that.

- OS/2 table version 5 optical-size items were added by Microsoft solely
when it was not even necessary. Same could already be expressed in GPOS
table feature size parameters as originally put in by Adobe. It was purely
laziness on Microsoft’s side to use the existing facilities.

- STAT table Axis value table, format 4 was added hastily by Peter
subsequently to the original #varfonts release. Axis value table
format2 acknowledges the need for ranges of values instead of just point
values (format 1). Yet when Peter wanted to add format 4 (I disagree with
the need / solution more generally, but that's a different issue), I
suggested that he make format 4 encode (possibly degenerate) ranges only.
But he ignored my reasonable and technical point and went with point values
instead, which makes this another defect in OpenType that didn't have to be.
behdad
http://behdad.org/

[0] Read the agenda (first) document. Most items are still as relevant and
overdue and unaddressed today.
http://goo.gl/ub684i
https://docs.google.com/document/d/1ge62dgj9KzFpN0ifGvKEs2s-y31S31qSYBWeqdd03H8/edit

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

> 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/20200821/f0b52fc1/attachment.html>