<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 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@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;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 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
{mso-style-priority:99;
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";}
code
{mso-style-priority:99;
font-family:"Courier New";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
p.attach, li.attach, div.attach
{mso-style-name:attach;
mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:9.0pt;
font-family:"Arial","sans-serif";}
p.bold, li.bold, div.bold
{mso-style-name:bold;
mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:10.0pt;
font-family:"Arial","sans-serif";
font-weight:bold;}
p.green, li.green, div.green
{mso-style-name:green;
mso-style-priority:99;
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";
color:#628C2A;}
p.replbq, li.replbq, div.replbq
{mso-style-name:replbq;
mso-style-priority:99;
margin:3.0pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.ad, li.ad, div.ad
{mso-style-name:ad;
mso-style-priority:99;
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";}
p.underline, li.underline, div.underline
{mso-style-name:underline;
mso-style-priority:99;
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";}
p.ad1, li.ad1, div.ad1
{mso-style-name:ad1;
mso-style-priority:99;
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";}
p.ad2, li.ad2, div.ad2
{mso-style-name:ad2;
mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
margin-bottom:7.5pt;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.underline1, li.underline1, div.underline1
{mso-style-name:underline1;
mso-style-priority:99;
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";
text-decoration:underline;}
span.yshortcuts
{mso-style-name:yshortcuts;}
span.yshortcuts1
{mso-style-name:yshortcuts1;
font-family:"Verdana","sans-serif";
font-weight:bold;}
span.yshortcuts2
{mso-style-name:yshortcuts2;
font-family:"Verdana","sans-serif";
font-weight:normal;}
span.EmailStyle34
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle35
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.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 bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Dear Leonardo, all,<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">Yes, MPEG does have a time-tested standard approach that defines device profiles to enable and ensure interoperability between different devices / standard
implementations. This is something we (the folks who used to be involved in the development of MPEG-4 part 18 “Font compression and streaming”) at one point attempted to use to define “text profiles and levels” but quickly realized that the number of various
features that can be desirable for one certain environment but not the other is daunting. So, the existing text profiles and levels defined by the ISO/IEC 14496-18 come way too short and only cover some basic different classes of functionality (like e.g. support
for TrueType outlines, support for CFF outlines, etc.). The actual number of permutations that need to be considered for various language environments and the features that would be required for one but not the other would make it extremely difficult to develop
a reasonably well structured system of device profiles (in my opinion).<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">I am not saying though that this is something that cannot be done or should not be done – given a strong interest of the group participants and the industry
support for such a development we can definitely consider this as a possible future work item. Hence, I’d like to ask all AHG members to give this idea of developing a well-structured set of OFF profiles and levels a serious consideration and bring your ideas
and views back to this list as the starting point. <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">Vladimir<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"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Leonardo Chiariglione [mailto:leonardo@chiariglione.org]
<br>
<b>Sent:</b> Wednesday, October 29, 2014 2:08 PM<br>
<b>To:</b> Levantovsky, Vladimir; 'Sairus Patel'; mpeg-OTspec@yahoogroups.com; 'Cameron McCormack'; 'Chris Lilley'<br>
<b>Subject:</b> RE: [OpenType] Re: [mpeg-OTspec] SVGZ in SVG+OpenType<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Dear Vladimir,<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">I believe that mandating what each individual implementation may or may not support is out of scope of the OFF standard<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"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Well, “mandating” is certainly out of scope, but identifying which combination of tools are used and recording them as “profiles”is what MPEG has been doing
since late 1992.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Judging from the number of (used) profiles in MPEG and the number of different organisations that employ the profile approach, it looks like “profile” is a
standard and market friendly approach to problem solving<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Leonardo
<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>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><span style="font-size:11.0pt;line-height:105%;font-family:"Calibri","sans-serif";color:#1F497D">Visit
<a href="http://leonardo.chiariglione.org/"><span style="color:#0563C1">Leonardo’s web site</span></a><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:8.0pt;line-height:105%"><a href="http://leonardo.chiariglione.org/"><span style="font-size:11.0pt;line-height:105%;font-family:"Calibri","sans-serif";color:#1F497D;text-decoration:none"><img border="0" width="148" height="64" id="Picture_x0020_2" src="cid:image001.png@01CFF905.CF1953D0" alt="logoLeonardo-web site"></span></a><span style="font-size:11.0pt;line-height:105%;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">
<a href="mailto:mpeg-OTspec@yahoogroups.com">mpeg-OTspec@yahoogroups.com</a> [<a href="mailto:mpeg-OTspec@yahoogroups.com">mailto:mpeg-OTspec@yahoogroups.com</a>]
<b>On Behalf Of </b>'Levantovsky, Vladimir' <a href="mailto:vladimir.levantovsky@monotype.com">
vladimir.levantovsky@monotype.com</a> [mpeg-OTspec]<br>
<b>Sent:</b> Wednesday, 29 October, 2014 17:55<br>
<b>To:</b> Sairus Patel; <a href="mailto:mpeg-OTspec@yahoogroups.com">mpeg-OTspec@yahoogroups.com</a>; Cameron McCormack; Chris Lilley<br>
<b>Subject:</b> RE: [OpenType] Re: [mpeg-OTspec] SVGZ in SVG+OpenType<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div id="ygrp-mlmsg">
<div id="ygrp-msg">
<div id="ygrp-text">
<p style="margin-bottom:12.0pt">Hi Sairus,<br>
<br>
I am at the W3C TPAC meeting this week (in Santa Clara), and Chris, Behdad and I had a chance to discuss whether the compressed SVG encoding is already part of the specification that we are referencing. If this is the case, it is indeed possible to simply add
a clarification language to the text of the standard to explain what types of SVG encodings that can be used for glyph descriptions, and this is definitely something that can also be independently described in the appropriate section of the SVG Integration
document. Behdad has agreed to review the current OFF text and make a proposal on what parts need to be changed / clarified, and I will talk to Chris to discuss the details.<br>
<br>
When it comes to implementations - I believe that mandating what each individual implementation may or may not support is out of scope of the OFF standard. We define technologies and tools to enable certain levels of functionality, and in order to ensure interoperability
the OFF spec does define a core set of required tables but it would be too overreaching to try to mandate what a particular implementations do as their supported functionality is usually determined by target markets / language /application requirements. I
don't think we can change that easily.<br>
<br>
Thank you,<br>
Vlad<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:mpeg-OTspec@yahoogroups.com">mpeg-OTspec@yahoogroups.com</a> [<a href="mailto:mpeg-OTspec@yahoogroups.com">mailto:mpeg-OTspec@yahoogroups.com</a>] On Behalf Of Sairus Patel
<a href="mailto:sppatel@adobe.com">sppatel@adobe.com</a> [mpeg-OTspec]<br>
Sent: Wednesday, October 29, 2014 10:36 AM<br>
To: <a href="mailto:opentype-list@indx.co.uk">opentype-list@indx.co.uk</a>; <a href="mailto:mpeg-OTspec@yahoogroups.com">
mpeg-OTspec@yahoogroups.com</a>; Cameron McCormack; Chris Lilley<br>
Subject: Re: [OpenType] Re: [mpeg-OTspec] SVGZ in SVG+OpenType<br>
<br>
Cam/Chris, could support of such encodings (gzip, deflate) be seen as required of SVG viewers even for an "SVG Integration" such as SVG-in-OT?<br>
Or could the encodings be restricted just to plaintext and gzipped content for SVG-in-OT? Is there a reason to reject deflate? Perhaps all should be allowed, and the fact that certain impls may not support all of them could be pointed out in the spec and seen
as an impl limitation. The font-making world already has many "best/prudent practices" to keep in mind and this will be one of them.<br>
<br>
Vlad: if it's clear that this is a clarification, can it be added without going through the amendment process? That would simplify things, e.g. for developers who right now don't have a central place to find the latest SVG-in-OT spec.<br>
<br>
By the way, all the color formats are OpenType (well, OFF) now, and are not Adobe/Mozilla's or Microsoft's or Google's. In my view, impls should try to or aim to support all of them: SVG, glyph overlay, and color bitmaps, just as impls should aim to support
CFF as well as TT.<br>
<br>
Sairus<br>
<br>
-----Original Message-----<br>
From: Behdad Esfahbod <<a href="mailto:behdad@behdad.org">behdad@behdad.org</a>><br>
Reply-To: "<a href="mailto:opentype-list@indx.co.uk">opentype-list@indx.co.uk</a>" <<a href="mailto:opentype-list@indx.co.uk">opentype-list@indx.co.uk</a>><br>
Date: Sunday, October 26, 2014 at 6:04 PM<br>
To: "<a href="mailto:listmaster@indx.co.uk">listmaster@indx.co.uk</a>" <<a href="mailto:listmaster@indx.co.uk">listmaster@indx.co.uk</a>><br>
Subject: [OpenType] Re: [mpeg-OTspec] SVGZ in SVG+OpenType<br>
<br>
>Message from OpenType list:<br>
><br>
><br>
>Thanks Chris,<br>
><br>
>On 14-10-26 05:07 PM, Chris Lilley <a href="mailto:chris@w3.org">chris@w3.org</a> [mpeg-OTspec] wrote:<br>
>> <br>
>> <br>
>> Hello Behdad,<br>
>> <br>
>> Saturday, October 25, 2014, 9:56:18 AM, you wrote:<br>
>> <br>
>>> Allow gzip-compressed SVG documents where SVG documents are <br>
>>> currently accepted.<br>
>> <br>
>> This is a useful clarification. I say clarification because a <br>
>> conforming SVG viewer is already required to accept gzip-compressed<br>
>> content:<br>
>> <br>
>> SVG implementations must correctly support gzip-encoded [RFC1952] and <br>
>> deflate-encoded [RFC1951] data streams, for any content type <br>
>> (including SVG, script files, images).<br>
><br>
>Right. You mentioned this before, and I tried to confirm it, but got <br>
>confused and thought the requirements only affect HTTP transport. I <br>
>checked again now and see your point.<br>
><br>
>This distinction is important though, because if your reasoning is to <br>
>be followed, then deflate-encoded SVG must also be supported.<br>
><br>
>However, from the point of view of SVG+OpenType specification / working <br>
>group, they may not feel bound by the SVG viewer conformance <br>
>requirements.<br>
><br>
>Anyway, I think you know better what the implications are one way or <br>
>another.<br>
> In the mean time I'll go build a font, such that Jonathan can take a <br>
>look at implementing it in Firefox.<br>
><br>
>behdad<br>
><br>
>> SVG implementations that support HTTP must support these encodings <br>
>> according to the HTTP 1.1 specification [RFC2616]; in particular, the <br>
>> client must specify with an "Accept-Encoding:" request header <br>
>> [HTTP-ACCEPT-ENCODING] those encodings that it accepts, including at <br>
>> minimum gzip and deflate, and then decompress any gzip-encoded and <br>
>> deflate-encoded data streams that are downloaded from the server.<br>
>> When an SVG viewer retrieves compressed content (e.g., an .svgz<br>
>> file) over HTTP, if the "Content-Encoding" and "Transfer-Encoding"<br>
>> response headers are missing or specify a value that does not match <br>
>> the compression method that has been applied to the content, then the <br>
>> SVG viewer must not render the content and must treat the document as <br>
>> being in error.<br>
>> <br>
>> <a href="http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers">http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers</a><br>
>> <br>
>>> As there are only one current implementations and the format is <br>
>>>backwards compatible, it was recommended on the mailing list by <br>
>>>Sairus to keep the table version number to the current number.<br>
>> <br>
>> Yes, I think that makes sense; because arguably implementations <br>
>> should have accepted this from the start. If they did not, they were <br>
>> non-conforming.<br>
>> <br>
>> --<br>
>> Best regards,<br>
>> Chris Lilley, Technical Director, W3C Interaction Domain<br>
>> <br>
>> <br>
><br>
>--<br>
>behdad<br>
><a href="http://behdad.org/">http://behdad.org/</a><br>
><br>
><br>
><br>
>List archive: <a href="http://www.indx.co.uk/biglistarchive/">http://www.indx.co.uk/biglistarchive/</a><br>
><br>
>subscribe: <a href="mailto:opentype-subscribe@indx.co.uk">opentype-subscribe@indx.co.uk</a><br>
>unsubscribe: <a href="mailto:opentype-unsubscribe@indx.co.uk">opentype-unsubscribe@indx.co.uk</a><br>
>messages: <a href="mailto:opentype-list@indx.co.uk">opentype-list@indx.co.uk</a><br>
><br>
><br>
<br>
------------------------------------<br>
<br>
------------------------------------<br>
<br>
------------------------------------<br>
<br>
Yahoo Groups Links<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:white"><o:p></o:p></span></p>
</div>
</div>
</body>
</html>