<div dir="ltr"><div>Thanks Vlad,</div><div><br></div><div>What would be the deadline to submit contribution for the October 19-24 meeting?</div><div><br></div><div>I'm hoping that we can get away with a corrigendum.</div><div><br></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><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sat, Oct 3, 2026 at 10:54 AM Vladimir Levantovsky <<a href="mailto:vladimir.levantovsky@gmail.com">vladimir.levantovsky@gmail.com</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="auto">Hi Behdad, all,<div><br></div><div>To start the process of making corrections, it would be ideal if you prepare an input contribution for the upcoming SC29/WG3 meeting that will be held on October 19-24.</div><div><br></div><div>Depending on the amount and the severity of proposed changes, we can decide whether issuing a corrigendum would be a suitable option, or if it requires an amendment. A corrigendum would be quicker path forward; an amendment would have to follow the typical path of WD - CD/PDAM - FDAM (with ballots issued at every stage), before it is finalized and published. </div><div><br id="m_1557965707954879020lineBreakAtBeginningOfSignature"><div dir="ltr"><div>Thank you,</div>Vladimir </div><div dir="ltr"><br><blockquote type="cite">On Oct 2, 2026, at 9:18 PM, Dave Crossland <<a href="mailto:dcrossland@google.com" target="_blank">dcrossland@google.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="auto"><span>Thanks for flagging these, Behdad. Glad to see you're cross-checking the implementations already.</span><div dir="auto"><span><br></span></div><div dir="auto"><span>Vlad, sounds like this is enough to Kickoff a 1st amendment :) if so, what would you for cast as an overall end to end timeline?<br></span><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div dir="ltr"><div dir="ltr" align="left" style="color:rgb(34,34,34);margin-left:0pt"><div dir="ltr" align="left" style="margin-left:0pt"><font color="#999999">-- </font></div><div dir="ltr" align="left" style="margin-left:0pt"><table style="border-width:medium;border-style:none;border-color:currentcolor;border-collapse:collapse"><colgroup><col width="72"><col width="282"></colgroup><tbody><tr style="height:0pt"><td style="vertical-align:top;padding:5pt;overflow:hidden"><img src="https://storage.googleapis.com/gdp1p/GDP_sig.gif" width="96" height="96" alt="GDP logo"><br></td><td style="vertical-align:top;padding:5pt;overflow:hidden"><p dir="ltr" style="line-height:1.54286;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:Arial,sans-serif;color:rgb(102,102,102);background-color:transparent;font-weight:700;vertical-align:baseline"><br></span></p><p dir="ltr" style="line-height:1.54286;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(102,102,102);background-color:transparent;font-weight:700;vertical-align:baseline">Dave Crossland</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-family:"Google Sans",sans-serif;color:rgb(128,134,139);background-color:transparent;vertical-align:baseline">Font Expert</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-family:"Google Sans",sans-serif;color:rgb(128,134,139);background-color:transparent;vertical-align:baseline">Google Design Platform </span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-family:"Google Sans",sans-serif;color:rgb(128,134,139);background-color:transparent;vertical-align:baseline"><br></span></p></td></tr></tbody></table></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 2, 2026, 3:30 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"><div>Hello everyone,</div><div><br></div><div>Thank you, Vlad, and everyone else who worked in the past four years to get the boring-expansion proposals into the ISO OFF 5th ed.</div><div><br></div><div>Since the PDF became freely available on Monday, I've been busy cross-checking my implementations against the spec. Generally things are holding up well, but unfortunately I discovered three issues in the VARC table that I recommend fixing in the spec. Details and recommendation in the github issues:</div><div><br></div><div><b>1. VARC ConditionList: restore omitted uint32 conditionCount<br></b><br>This one is was lost in translation from my working design to the ISO proposal. It's currently impossible to implement the ISO spec, because it defines an array without defining its length anywhere:<br><br>  <a href="https://github.com/harfbuzz/boring-expansion-spec/issues/176" rel="noreferrer" target="_blank">https://github.com/harfbuzz/boring-expansion-spec/issues/176</a></div><div><br></div><div><b>2. VARC: make SparseVariationRegion axis offsets table-relative and correct its designation</b></div><div><br></div><div>This was was a mistake from the review modifications of the table format to promote a struct to a table, but this was not done properly. Offsets should be relative to the beginning of their table, not the grandparent table as currently speced.</div><div><br></div><div>  <a href="https://github.com/harfbuzz/boring-expansion-spec/issues/177" rel="noreferrer" target="_blank">https://github.com/harfbuzz/boring-expansion-spec/issues/177</a></div><div><br></div><div><b>3. VARC: Remove the exception to ordinary LSB/origin alignment for components</b></div><div><br></div><div><div class="gmail_signature">This is a design leftover from when I had encoded the variable-composites in the `glyf` table. In that design, the recommendation made sense. In a separate `VARC` table, it doesn't, and hinders implementation. This change wouldn't affect properly-made fonts (lsb=xMin).</div><div class="gmail_signature"><br></div><div class="gmail_signature">  <a href="https://github.com/harfbuzz/boring-expansion-spec/issues/173" rel="noreferrer" target="_blank">https://github.com/harfbuzz/boring-expansion-spec/issues/173</a></div><div dir="ltr" class="gmail_signature"><br></div><div dir="ltr" class="gmail_signature"><br></div><div class="gmail_signature">That's it for now. I will be spending a lot more time with the spec, but I don't expect other major issues to arise.</div><div class="gmail_signature"><br></div><div class="gmail_signature">Thanks,</div><div dir="ltr" class="gmail_signature">behdad<br><a href="http://behdad.org/" rel="noreferrer" target="_blank">http://behdad.org/</a></div></div></div>
</div>
</blockquote></div>
</div></blockquote></div></div></blockquote></div>