<div dir="ltr">Here's a few more instances of MS unilaterally acting or refusing to act in a timely manner to consensus by experts:<div><br></div><div>- 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.</div><div><br></div><div>- <code class="gmail-markup--code gmail-markup--p-code">name</code> 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.</div><div><p name="bbed" class="gmail-graf gmail-graf--p"><code class="gmail-markup--code gmail-markup--p-code">- OS/2</code> table version 5 optical-size items were added by Microsoft solely when it was not even necessary. Same could already be expressed in <code class="gmail-markup--code gmail-markup--p-code">GPOS</code> table feature <code class="gmail-markup--code gmail-markup--p-code">size</code> parameters as originally put in by Adobe. It was purely laziness on Microsoft’s side to use the existing facilities.</p><p name="91b9" class="gmail-graf gmail-graf--p">- 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.</p></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">behdad<br><a href="http://behdad.org/" target="_blank">http://behdad.org/</a></div></div><br></div><div>[0] Read the agenda (first) document. Most items are still as relevant and overdue and unaddressed today.</div><div><a href="http://goo.gl/ub684i">http://goo.gl/ub684i</a><br></div><div><a href="https://docs.google.com/document/d/1ge62dgj9KzFpN0ifGvKEs2s-y31S31qSYBWeqdd03H8/edit">https://docs.google.com/document/d/1ge62dgj9KzFpN0ifGvKEs2s-y31S31qSYBWeqdd03H8/edit</a><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 14, 2020 at 4:30 PM Behdad Esfahbod <<a href="mailto:behdad@behdad.org">behdad@behdad.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Correction: I meant Dave Arnold, not Dave Lemon.<div><br clear="all"><div><div dir="ltr">behdad<br><a href="http://behdad.org/" target="_blank">http://behdad.org/</a></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 14, 2020 at 4:16 PM Behdad Esfahbod <<a href="mailto:behdad@behdad.org" target="_blank">behdad@behdad.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Fri, Aug 14, 2020 at 2:57 PM Peter Constable <<a href="mailto:pgcon6@msn.com" target="_blank">pgcon6@msn.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div>
<p class="MsoNormal">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.</p></div></div></blockquote><div><br></div><div>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:</div><div><br></div><div>- 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.</div><div><br></div><div>- 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.</div><div><br></div><div>- 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.</div><div><br></div><div>- 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.</div><div><br></div><div>- 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.</div><div><br></div><div>- As a sub-example of the above, Martin and I wrote the "glyph filtering" proposal:</div><div><br></div><div>  <a href="https://github.com/OpenType/opentype-layout/blob/master/proposals/glyph_filtering.md" target="_blank">https://github.com/OpenType/opentype-layout/blob/master/proposals/glyph_filtering.md</a></div><div><br></div><div>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.</div><div><br></div><div>That's just a few I could type right now. There's probably another dozen I will type next week.</div><div><br></div><div>It is the fact that you don't see any of these as problematic that I question your fairness and objectivity.</div><div><br></div><div>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.” </div><div><br></div><div>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.</div><div><br></div><div>behdad</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><p class="MsoNormal"> </p><p class="MsoNormal"><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Peter<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> mpeg-otspec <<a href="mailto:mpeg-otspec-bounces@lists.aau.at" target="_blank">mpeg-otspec-bounces@lists.aau.at</a>> <b>
On Behalf Of </b>Dave Crossland<br>
<b>Sent:</b> Friday, August 14, 2020 1:19 PM<br>
<b>To:</b> Behdad Esfahbod <<a href="mailto:behdad@behdad.org" target="_blank">behdad@behdad.org</a>><br>
<b>Cc:</b> mpeg-otspec <<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a>><br>
<b>Subject:</b> [MPEG-OTSPEC] SHORT vs int16 vs ???<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Fri, Aug 14, 2020 at 1:36 PM Behdad Esfahbod <<a href="mailto:behdad@behdad.org" target="_blank">behdad@behdad.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">On Fri, Aug 14, 2020 at 7:40 AM Eric Muller <<a href="mailto:eric.muller@efele.net" target="_blank">eric.muller@efele.net</a>> wrote:<u></u><u></u></p>
</div>
<div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">What alternatives do you propose, Behdad, Peter, Eric, anyone? :) <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>

</blockquote></div></div>
</blockquote></div>
</blockquote></div>