<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">On Wednesday, August 19, 2020 2:07 PM Norbert Lindenberg wrote:<br>
</span>> On Aug 18, 2020, at 19:59, Levantovsky, Vladimir <<a href="mailto:Vladimir.Levantovsky@monotype.com">Vladimir.Levantovsky@monotype.com</a>> wrote:<br>
> <br>
>> On Tuesday, August 18, 2020 3:15 AM Norbert Lindenberg wrote:<br>
>> <br>
>> I’d like to have a forum where font rendering implementors, font developers, font tool developers, text application developers, script experts, and others with relevant expertise can collaborate on roughly equal footing. It’s unavoidable that implementors
 in the end have a stronger voice because without them it’s all just talk, but I think it’s essential to get out of this situation where a single company or person can control the process.<br>
> <br>
> Agree completely that we need to make sure that every voice is heard on equal footing. On a few occasions, I mentioned that this AHG strives to make our decisions based on consensus, which means that anyone who has a valid concern should be able to bring
 it for consideration of the group, and these concerns have to be resolved to make a progress. At the same time, the mechanism to resolve a blocking objection should also be in place if reaching a consensus decision becomes impossible – I very much like [and
 for many years have followed] one of the basic HTML design principles: “In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.” I believe we can adopt it pretty much verbatim.<br>
<br>
That’s a good principle, but doesn’t actually resolve anything when there’s disagreement between implementors and specifiers (the main people in the room) over what’s best for users and authors (who for the most part are not present).<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">It depends. Even if we don’t have users represented in the room, if a good case can be made that one solution is going to benefit users more than another, reasonable
 people would agree. For example, when deciding on web fonts implementations, it was clear to me that effective font-specific compression would be a valuable and needed component (and I argued for it since 2008 when first Monotype proposal was submitted). But
 then an argument was made that widely supported minimally viable solution would offer far better outcome for the users than a great solution that is only supported by a single browser vendor, and I agreed (here comes WOFF 1.0). As web fonts adoption using
 WOFF1 skyrocketed, it became clear to _<i>everyone</i>_ “that effective font specific compression would be a valuable and needed component”, and no one ever argued against WOFF 2.0. So, these basic design principles worked exactly as they should!
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">J</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">  <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in">>> Standards produced by the group should have a specification, a conformance test suite, and at least two conformant implementations. There should be defined stages from idea to standard, as used by the W3C or
 Ecma TC39.<br>
> <br>
> Again, this is a decision that may not be in “one size fits all” category – there is always a tradeoff between spec publication steps and implementation / test requirements. I mentioned earlier about WOFF2 development at W3C and the effect W3C implementations
 & conformance tests requirements had on final Recommendation approval – it took roughly three more years until the WOFF 2.0 Recommendation was officially finalized [to progress from its Candidate Recommendation stage to Proposed Recommendation presented for
 Advisory Committee approval].<br>
<br>
What caused the three-year delay? And why do you think finalizing the standard without the thing that caused the delay would have been a better outcome?<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">A couple of reasons for delay: 1) development of the conformance test suite took a lot longer than was originally anticipated, for various reasons due to resource
 availability, bandwidth, etc.; 2) The WG (Google folks primarily) produced a really good WOFF2 reference implementation – secure, well tested, good performance, … - so good that no one else wanted to spend time developing a second implementation, everyone
 (including MS folks) decided to use the one and only codebase. Took a while to figure out what to do to satisfy “two implementations” requirement. And in that particular case, the delays related to both CTS and implementation efforts didn’t really produce
 any significant feedback for the spec to incorporate, I really don’t remember anything major we had to change to improve the spec once the CTS results were in. Finalizing WOFF2 sooner wasn’t really a critical path for W3C folks (most browser vendors supported
 it even when it was a WD), but for organizations like ISO – holding off on final standard ratification for three more years pending on reference implementation availability would’ve been a very different story.
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><br>
>> The outputs of this forum, and all inputs used in decisions, should be available to anyone with an internet connection, free of charge, in HTML or PDF format. I know that people commonly rely on second-hand information about ISO standards because they don’t
 want to pay €€€ for a PDF document. I also find it ridiculous that this AHG is supposed to work on a mandate whose input most of us don’t have access to.<br>
> <br>
> Agree in principle, the caveat is in different processes. Some organizations like W3C have all their working documents and most [but not all] of their communications available to general public. Some other organizations (e.g. ISO) prefer to keep their internal
 working documents accessible only to those who have proper credentials. It doesn’t mean it is impossible to make them publicly available, it means that one need to take an extra step to make it happen. In fact, in most cases when intermediate ISO documents
 (such as OFF Committee Draft or DIS) would be up for approval via ballot, I often requested to make that document publicly available in order to share it with this group. It’s doable, just doesn’t happen automatically by default.<br>
> And as far as final output documents are concerned, there is another mechanism in place that allows submitting a request to make the ISO standard publicly available, free of charge. The ISO/IEC 14496-22 OFF standard from its 1st edition and up until now (4th
 edition with amendment #1) has always been publicly available free of charge, but it is also on the official ISO bestsellers list, even though the ISO store page where you can buy the PDF text has a link right next to the “Buy” button that says you can download
 it for free.<br>
<br>
John’s suggestion was that we “consider to what kind of process do we want, collectively and voluntarily, to submit ourselves. How do we want to collaborate? And then we look at existing organisations and determine which, if any, provide that kind of process”.
 So if we agree that publishing all inputs is essential, what are the chances of getting ISO to allow us to do that *by default*?<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">ISO isn’t likely to publish inputs, but it is up to us to do so, and no permission is required – it is our input. Publishing output / working documents at different
 stages of the ISO process is a possibility, but it doesn’t happen by default, we need to ask for it. The only output documents ISO will never publish is the FDIS text submitted for a final approval ballot (if that text is published, no one would ever need
 to buy anything from ISO). But, like I said [and the OFF is a proof], if a good case is made why the particular ratified standard need to be made publicly available, it will be.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thank you,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Vlad<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
</div>
</body>
</html>