<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I think we should divide "breaking changes" into two kinds:</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<ul>
<li>The difference could be hidden under a font library.</li><li>The difference could <b>not</b> be hidden under a font library.</li></ul>
<div>CFF2 lies in the first category: unless a client application explicitly reads font tables, this format difference is well encapsulated under font libraries (i.e., DWrite), so most applications could simply update their dependencies and do not need to do
any substantial change.</div>
<div><br>
</div>
<div>GID32 is the second kind: At least one well-known font library <b>must update their interfaces</b> to properly support such features, and applications need update themself too, since the interfaces are changed. This kind also include
<i>tangled shaping</i> (i.e., position-dependent substitution). For these features, putting them together and create an OFF2 should be the easiest method to get them realized, and OFF2 should provide a "LGCY" table to allow fonts to provide additional information
for graceful downgrading. (for GID32, it should be a subset of glyphs?)</div>
<div><br>
</div>
<div>Yours,</div>
<div>Renzhi</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> mpeg-otspec <mpeg-otspec-bounces@lists.aau.at> on behalf of Peter Constable <pgcon6@msn.com><br>
<b>Sent:</b> Wednesday, September 16, 2020 18:18<br>
<b>To:</b> Dave Crossland <dcrossland@google.com><br>
<b>Cc:</b> mpeg-otspec <mpeg-otspec@lists.aau.at><br>
<b>Subject:</b> Re: [MPEG-OTSPEC] Introducing breaking changes into the spec (was: RE: [EXTERNAL] Proposal to deprecate derived search values)</font>
<div> </div>
</div>
<style>
<!--
@font-face
{font-family:"Cordia New"}
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:Calibri}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif}
a:link, span.x_MsoHyperlink
{color:blue;
text-decoration:underline}
.x_MsoChpDefault
{font-family:"Calibri",sans-serif}
@page WordSection1
{margin:1.0in 1.0in 1.0in 1.0in}
div.x_WordSection1
{}
-->
</style>
<div lang="EN-US" link="blue" vlink="purple">
<div class="x_WordSection1">
<p class="x_MsoNormal">In that vein, I’ve opened an issue to seed discussion on one particular topic: “32-big glyph IDs: what and why”</p>
<p class="x_MsoNormal"> </p>
<p class="x_MsoNormal"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMPEGGroup%2FOpenFontFormat%2Fissues%2F10&data=02%7C01%7Crenzhi.li%40microsoft.com%7C52896f52316949b05d8208d85aa7aa49%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637359023472799484&sdata=0G87oWI2zdhdvmvEcevTxtLfQugFConEFuRsDD1rMHA%3D&reserved=0" originalsrc="https://github.com/MPEGGroup/OpenFontFormat/issues/10" shash="wl7acdsSk2mO9zwY/nt/ZRlUhkDzhnM7SfaJGB60tweQDrrbj5PDCjW5dcqmE5wjz8JNUXLXm8a1FL+aWQTGSLUwCWujgk8CQlGArRMOdKm2y9qnRQO+SrkZK/Bvih/Un04xUK8AZw4DltI6W7VuIWjZHkT8xTkkWzkuthli3OY=">https://github.com/MPEGGroup/OpenFontFormat/issues/10</a></p>
<p class="x_MsoNormal"> </p>
<p class="x_MsoNormal"> </p>
<div style="border:none; border-top:solid #E1E1E1 1.0pt; padding:3.0pt 0in 0in 0in">
<p class="x_MsoNormal"><b>From:</b> Dave Crossland <dcrossland@google.com> <br>
<b>Sent:</b> Wednesday, September 16, 2020 4:47 PM<br>
<b>To:</b> Peter Constable <pgcon6@msn.com><br>
<b>Cc:</b> Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com>; mpeg-otspec <mpeg-otspec@lists.aau.at><br>
<b>Subject:</b> Re: [MPEG-OTSPEC] Introducing breaking changes into the spec (was: RE: [EXTERNAL] Proposal to deprecate derived search values)</p>
</div>
<p class="x_MsoNormal"> </p>
<div>
<p class="x_MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<div>
<p class="x_MsoNormal">On Wed, Sep 16, 2020, 1:30 PM Peter Constable <<a href="mailto:pgcon6@msn.com">pgcon6@msn.com</a>> wrote:</p>
</div>
<blockquote style="border:none; border-left:solid #CCCCCC 1.0pt; padding:0in 0in 0in 6.0pt; margin-left:4.8pt; margin-right:0in">
<div>
<div>
<p class="x_MsoNormal" style="">My main concern for this email list has been that discussion on technical issues in relation to potential new formats could quickly run into a hundred different areas and rabbit holes, and could quickly become very randomizing.
And I don’t think that’s good because (i) some could be chased away by volume of traffic they’re not interested in, (ii) it would be harder someone to focus on any of those discussions if they _<i>are</i>_ interested, and (iii) in the meantime it would make
it harder to focus on any work relevant to the _<i>current</i>_ OFF project.</p>
<p class="x_MsoNormal" style="">Dave has suggested a github issues repo; I haven’t closely followed discussion between him and you on that, but perhaps that’s an idea to consider.</p>
</div>
</div>
</blockquote>
</div>
<div>
<p class="x_MsoNormal">100%, and this isn't a hypothetical as Peter has very politely posed it! </p>
</div>
<div>
<p class="x_MsoNormal"> </p>
</div>
<div>
<p class="x_MsoNormal">Liang already stated he is tired of this list, as any email list would be tiring.</p>
</div>
<div>
<p class="x_MsoNormal"> </p>
</div>
<div>
<p class="x_MsoNormal">I think email lists are incapable of managing the clear open/closed status of any thread of discussion, and lack tags, and the special kind of tag called a milestone, which comes with a few associated properties - like completion date,
stack rank, and that an issue can only have one milestone tag. </p>
</div>
<div>
<p class="x_MsoNormal"> </p>
</div>
<div>
<p class="x_MsoNormal">So, if someone is only interested in discussing 1.8.x updates, they can just look at the 1.8.x milestones' lists of issues (discussion threads.) </p>
</div>
<div>
<p class="x_MsoNormal"> </p>
</div>
<div>
<p class="x_MsoNormal">I'd like to start directing all meaningful discussion away from this list to the mpeggroup GitHub repo. Does anyone object to this?</p>
</div>
</div>
</div>
</div>
</body>
</html>