<font face="verdana,sans-serif">The second option seems much more clear to me, and makes extra distinctions that I expect to be useful to some consumers.</font><div><font class="Apple-style-span" face="verdana, sans-serif"><br>
</font></div><div><font class="Apple-style-span" face="verdana, sans-serif">Two small propositions:</font></div><div><font class="Apple-style-span" face="verdana, sans-serif"><br></font></div><div><font face="verdana,sans-serif"></font><font class="Apple-style-span" face="verdana, sans-serif">1) Rather than "format" perhaps "outlines" would be a good label for TTF for CFF? (I realize there is more than outlines, but outlines are certainly part of it.)<br>
</font><div><font face="verdana,sans-serif"><br></font></div><div><font face="verdana,sans-serif">2) Although there should only be one type of outlines, multiple layout formats in a single font should be supported.</font></div>
<div><font face="verdana,sans-serif"><br></font></div><div><font face="verdana,sans-serif">T<br></font><br><div class="gmail_quote">On Mon, May 2, 2011 at 8:14 AM, Levantovsky, Vladimir <span dir="ltr"><<a href="mailto:vladimir.levantovsky@monotypeimaging.com">vladimir.levantovsky@monotypeimaging.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">













<div style="background-color:#fff">
<span> </span>


<div>
  <div>


    <div>
      
      
      <p></p><div class="im">On Tuesday, April 26, 2011 7:46 PM David Singer wrote:<br>
> <br>
> > Levantovsky, Vladimir wrote:<br>
> ><br></div><div class="im">
> > WOFF is intended to be used explicitly with web documents using CSS.<br>
> WebFonts WG believed that no additional optional parameters were<br>
> necessary because CSS itself has a mechanism to identify the meaning of<br>
> the resource, and it doesn't really use MIME types.<br>
> ><br>
> > However, I don't think that the same approach would automatically<br>
> apply to other environments where CSS is not used, and where<br>
> applications rely primarily on MIME types to identify a resource. We<br>
> could use a single MIME type to define a font, and rely on a set of<br>
> optional parameters to provide more specificity but, like it was<br>
> mentioned earlier, we have at least two orthogonal issues that need to<br>
> be addressed - type of outlines within a font and supported text layout<br>
> mechanism(s). Currently, the suggested set of different MIME types<br>
> differentiates font resources by format and various types of outlines,<br>
> and leaves text layout machinery to be defined using optional<br>
> parameters.<br>
> <br>
> OK, maybe I have it wrong.  I thought that what was proposed was<br>
> mime type A if you know the outlines are A format<br>
> mime type B if you know the outlines are B format<br>
> mime type C if you don't know, both are supplied, or something...<br>
> <br>
<br></div>
David, you got this is exactly right - this is what is currently proposed.<div class="im"><br>
<br>
> If this is the case, this is at least odd for mime types.  Are A, B, C<br>
> normally distinguished by file extension?<br>
> <br>
<br></div>
Normally, but not always. One good example is .mp4 file that may contain various types of payload. As a result, we have multiple different media types defined [1]:<br>
<br>
video/mp4 - for visual content;<br>
audio/mp4 - for audio streams;<br>
application/mp4 - for system stream;<br>
application/mpe4-iod - for object descriptors, etc.<br>
<br>
This is similar to what is proposed for fonts. OFF defines a format (based on sfnt) where different types of outlines and layout data can be encoded. In an ideal world (i.e. if we had top-level "font" media type) it would be logical to encode it as font/ttf, font/cff, font/aat, etc. The proposed approach is similar, but all types are using the 'application' tree:<div class="im">
<br>
<br>
application/font-ttf;<br>
application/font-cff;<br>
application/font-off;<br></div>
application/font-sfnt,<br>
<br>
with possible additional optional parameter that can be used to define supported text layout option.<br>
<br>
I do not have a strong preference for one way vs. another. As I understand, the alternative approach would be to define a single media type, e.g. "application/font-sfnt" with two sets of optional parameters like:<br>

<br>
1)      Name: Format<br>
        Value: TTF, CFF<br>
2)      Name: Layout<br>
        Value: OTF, AAT, SIL<br>
<br>
All, for the purposes of a straw poll only - please respond to this email with your preferred choice (I would specifically want to hear from those who proposed this activity)!<div class="im"><br>
<br>
Thank you and regards,<br>
Vladimir<br>
<br></div>
[1] <a href="http://tools.ietf.org/html/rfc4337" target="_blank">http://tools.ietf.org/html/rfc4337</a><br>
<br>
<p></p>

    </div>
     

    
    <div style="color:#fff;min-height:0"></div>


</div>



  






</blockquote></div><br><br clear="all"><br>-- <br><font face="verdana, sans-serif"><span style="line-height:19px">“Puritanism: The haunting fear that someone, </span></font><div><font face="verdana, sans-serif"><span style="line-height:19px"> somewhere, may be happy.”</span></font><div>
<font face="verdana, sans-serif"><span style="line-height:19px"> —H.L. Mencken</span></font></div></div><div><font face="verdana, sans-serif"><span style="line-height:19px"><br></span></font></div><br>
</div></div>