<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=us-ascii">
<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;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1123884214;
        mso-list-type:hybrid;
        mso-list-template-ids:-886305624 82503980 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
        {mso-level-start-at:0;
        mso-level-number-format:bullet;
        mso-level-text:-;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Calibri",sans-serif;
        mso-fareast-font-family:Calibri;}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></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="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Sorry for a slow response on this topic. I have some thoughts in reply to Myles’ comments.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Before jumping in, let me mention that Microsoft in general is supportive of the COLR v1 proposal, and has contributed to its development; and Microsoft’s web-platform team is aligned with Chromium on COLR v1 support.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Now for specific remarks. I’m looking at this from the perspective of what makes sense for the OpenType spec and colour fonts generally, though along the way I’ll take into consideration what may or may not make sense for WebKit.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">>Inversely, here is a list of things we don’t like about the proposal:<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">>It re-invents the wheel. This new format is as expressive and powerful as any general-purpose 2D graphics serialization format. There are many,
 many existing serialization formats for general-purpose 2D graphics.<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="color:black">It’s fair to ask whether there is some existing, binary serialization format. And, I find it particularly interesting since, in past interactions (five or so years ago), I was given to
 understand that Apple engineers would have been interested if Microsoft had pursued a COLR enhancement or _<i>some</i>_ vector format for color glyphs _<i>other than</i>_ SVG.</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="color:black">For an enhancement in OT, I’d rule out something based on XML (or JSON, etc.) rather than a binary format since these are inherently less efficient size-wise. There are, of course, things
 like .swf, .emf, .eps, and of course .pdf, though I don’t know of any that would clearly a better choice: If they’re not too product-specific (such as .emf), they’re also too generic, supporting far more than is needed. We’d face the same issue you’ll recall
 we had with OT-SVG of figuring out what parts to explicitly exclude. (It’s the same issue why, in the OT spec, PDF is excluded as a supported format for the sbix table.) Moreover, none of those formats can take advantage of tables OT already has for representation
 of vector geometries: the ‘glyf’, CFF or CFF2 tables. (This is an issue, as well, for OT-SVG.)<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">>It doesn’t exist yet (outside of a development configuration of Chrome).
<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="color:black">“Doesn’t exist elsewhere” could have been used to argue against any number of other things. It could have been used as an argument against adding variations to OT back in 2016. I don’t
 think it’s a useful argument of itself. Rather, one needs to ask whether or not there are technical merits that might make a case for supporting it elsewhere.</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">>OT-SVG, which is just as expressive*, exists and has shipping implementations in DirectWrite, Core Text, Firefox, and many (most? all?) of Adobe
 creation apps.<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="color:black">That’s true; but one can’t say that OT-SVG is ubiquitous by any stretch. As we know, it’s not supported in Chromium. But there are also many other contexts in which the OT spec is supported
 as a font format, yet in which OT-SVG is not; and there’s fair reasons to think there are contexts in which OT-SVG would not likely be supported if there were another binary-format alternative. OT / OFF is supported in lots of consumer electronic or other
 classes of device beyond computers and phones. There will be many small-device contexts in which there may be interest in colour fonts but in which there will concerns such as size that will make OT-SVG less than ideal.</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="color:black">></span><span style="font-size:10.0pt;font-family:"Courier New";color:black"> Many OT-SVG fonts already exist.<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="color:black">Yes, there are existing OT-SVG fonts. But OT-SVG fonts aren’t _<i>that many</i>_ in number, and aren’t exactly taking off. I suspect that font developers have shied away because there hasn’t
 yet been one clear winner for colour font format.</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">>Because this proposal doesn’t exist yet outside of Chrome, there is no ecosystem in existing authoring tools.
<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="color:black">Again, this is the “doesn’t exist elsewhere” argument I commented on above.</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">>Conversely, many design authoring tools already export SVG.<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="color:black">True; and I expect that SVG will remain an important format in COLR v1 font development workflows because it is a common format supported in most/all graphics-authoring tools. In that regard,
 it’s a much better choice as input to a font compiler than font-compilation tools having to support a variety of formats supported in various graphics-authoring apps—.eps, .ai, .dwg, etc..</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="color:black">But support for SVG as an input format doesn’t imply that font compilation tools wouldn’t support compilation from SVG to COLR v1: I suspect the consideration for the likes of FontLab and
 Glyphs will be about how many of their customers want to generate COLR v1 fonts, and not about whether they could otherwise have generated OT-SVG fonts. I can’t predict that FontLab, etc. _<i>will</i>_ support compilation to COLR v1. My point is only that
 I don’t see this as a strong argument against enhancing OT with COLR v1 and supporting it in apps or on the Web.</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="color:black">Of course, for browser / application developers, availability of font tools to generate COLR v1 is not irrelevant since it’s an indirect predictor of the prevalence of COLR v1 fonts. For
 app developers, current or anticipated prevalence of COLR v1 fonts will certainly be an important consideration. If you’re saying that you _<i>do not</i>_ anticipate much use of COLR v1 in fonts, then I can’t really argue against that since there isn’t enough
 data yet one way or another.</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="color:black">></span><span style="font-size:10.0pt;font-family:"Courier New";color:black">Supporting both OT-SVG and this new proposal is twice (-ish) the maintenance burden, for a format that isn’t
 any more expressive* than the format we support already.<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">Supporting both OT-SVG and this new proposal increases our binary size. We expect the additional binary size increase to be roughly equivalent
 to the binary size increase we observed after implementing OT-SVG. (OT-SVG does involve an XML parser, but WebKit already links with an XML parser, so we expect the size of this new proposal to be roughly equal to the size increase we saw after implementing
 OT-SVG.<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="color:black">That’s a fair argument… for a browser developer whose product already has XML and CSS parsers built in. But as mentioned above, there are many other contexts for OT fonts that do not have
 independent reason to support SVG/XML/CSS parsers. For those contexts, your reasoning above strongly suggests that the runtime binary size increase for supporting COLR v1 would be _<i>much smaller</i>_ than for supporting OT-SVG. This isn’t making the case
 that, therefore, WebKit should support COLR v1 at this time; but I think it does make the case that, in the long term, COLR v1 may have an advantage over OT-SVG for at least some app or device contexts in which colour font support might be considered.</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">> This proposal would require its own novel parsing / overflow detecting / interpretation code.)<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">Supporting both OT-SVG and this new proposal roughly doubles the surface area for security attacks for vector-based color fonts.<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">Even considering an engine that only supports this proposal and not SVG, we haven’t seen any evidence that avoiding XML will reduce security bugs
 compared to a novel binary format. Historically, in WebKit, we’ve observed that opaque binary formats (like image formats) have plenty of their own security bugs.<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="color:black">True, it will require new parsing. That will be true of any new enhancement to OT. Of course, that comes with new surface area for security attack. This is a cost to be considered for many
 potential features that might be considered for software products. As is always the case, the fact that there are such costs isn’t of itself a deal-breaker, but one considers this with other costs of development to evaluate against anticipated benefits.</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">>The spec has over 2,500 lines, and the images/ directory of the spec has 77 figures, and there is only a single implementation of this proposal.
 It’s complicated enough that we’re not confident that it can be implemented interoperably.<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="color:black">I don’t think it’s actually all that complicated. There was potential to misunderstand: I, myself, misunderstood important aspects of the proposed design on reading an earlier, much shorter
 proposal doc. And I made a point to put lots of details into the spec with a view to providing clarity that would lead to interoperability. The possibility that implementations will not be interoperable is a hypothesis that would be empirically tested each
 time someone attempts to implement.</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="color:black">But I’m not sure it’s valid to make a sweeping generalization that it’s too complicated to lead to interoperability. That feels to me like a premise being crafted to support an a priori
 conclusion. If you can point to specific aspects of the spec that are not sufficiently clear, then that would be helpful --- and the spec can be improved.</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="color:black">Frankly, I think variations was **<b>much**</b> more complex than this.
</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1;background:white">
<span style="color:black">The amount of content added to the spec for variations was **well over double** that added for COLR v1, and that was for mostly extending existing concepts with a few new concepts versus mostly-new concepts for COLR v1.</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1;background:white">
<span style="color:black">Variations introduced eight entirely new top-level tables, versus zero new tables for COLR v1.</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1;background:white">
<span style="color:black">The binary formats added for variations included several complexities:
</span><o:p></o:p></li><ul style="margin-top:0in" type="circle">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level2 lfo1;background:white">
<span style="color:black">run-length-encoded data; </span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level2 lfo1;background:white">
<span style="color:black">table members that semantically comprise multiple sub-fields that need to be parsed and processed separately;
</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level2 lfo1;background:white">
<span style="color:black">many places in which inter-table references and validations are involved; and
</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level2 lfo1;background:white">
<span style="color:black">several new concepts that interact in complex ways (see how many people can explain why HOI works).</span><o:p></o:p></li></ul>
</ul>
<p class="MsoNormal" style="text-indent:.5in;background:white"><span style="color:black">In contrast, the new formats for COLR v1 are much simpler to parse with only a few inter-table references (‘glyf’ or CPAL entries) or validations (maxp.numGlyphs).</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="color:black">Yet very quickly many different implementations for variable fonts arose with a high degree of interoperability.
</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">> We’re worried the behavior of the drawing operations may be specific to Skia, and difficult/impossible to implement on Core Graphics. For example,
 at first glance, we are not sure that the radial gradients in this proposal can be implemented on Core Graphics.<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="color:black">The radial gradients are very similar to those defined in PDF and those in HTML Canvas 2D, the only differences being with extend modes.</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">> As far as we’re aware, this proposal has not undergone a rigorous standardization process from many independent stakeholders.<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="color:black">It is in the midst of that very process. There is an alpha for OT 1.9 published for broad review (<a href="https://docs.microsoft.com/en-us/typography/opentype/otspec190alpha/ot190alpha">OpenType
 1.9 Alpha Review - Typography | Microsoft Docs</a>); a working draft for the corresponding ISO standard has been available for review for several months; and there have been a number of technical comments submitted from reviewers that have been addressed in
 the spec.</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">>Embedding raster image data inside color font tables is common today, but this new proposal has no affordances for allowing it, despite its vector
 facilities being as expressive as any general-purpose 2d graphics serialization format. Therefore, it doesn’t actually improve upon the color font table fragmentation situation, which is widely regarded as one of the biggest drawbacks to color fonts today.<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="color:black">I’m a little puzzled as to why a lack of support for raster data embedded within COLR v1’s vector formats is seen is a big gap. Raster data with a vector image might be useful as a pattern
 fill that can be repeated as the geometries are scaled, but otherwise a raster image doesn’t scale, which is a key aspect of vector graphics. Addition of patterns is something that could potentially be added in the future.
</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="color:black">Also, noting that, in some cases, someone might want to a raster image alone as a colour glyph for a character, giving the designer control over every pixel, nothing in the spec prevents
 a hybrid approach in which colour glyphs for some characters are implemented as vector data using COLR v1 while the colour glyphs for some other characters are implemented as raster data using sbix.</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="color:black">If raster image data were assumed to be the best of all possibilities for colour glyphs that would put an end to the colour font fragmentation problem, then I think that’s clearly not a
 valid assumption since colour raster formats have been available to font developers since colour fonts first became a thing almost a decade ago.</span><o:p></o:p></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:black">>Given these two lists, Apple’s WebKit team and Core Text team are negative on this proposal.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As one vendor considering support in an app, I can certainly understand a perspective of saying,
<i>This has costs but doesn’t provide immediate benefits for what I use in my products.</i> When considering support in a platform or an app that needs to support user content, I can certainly understand a perspective of saying,
<i>I will wait to see how much demand there will be</i>. But there are several aspects in the reasoning given by Myles that I don’t find compelling.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Cheers!<o:p></o:p></p>
<p class="MsoNormal">Peter<o:p></o:p></p>
</div>
</body>
</html>