[mpeg-OTspec] RE: font media types [1 Attachment] -- WOFF?

[Levantovsky, Vladimir]

On Tuesday, April 26, 2011 7:46 PM David Singer wrote:
> 
> > Levantovsky, Vladimir wrote:
> >
> > WOFF is intended to be used explicitly with web documents using CSS.
> WebFonts WG believed that no additional optional parameters were
> necessary because CSS itself has a mechanism to identify the meaning of
> the resource, and it doesn't really use MIME types.
> >
> > However, I don't think that the same approach would automatically
> apply to other environments where CSS is not used, and where
> applications rely primarily on MIME types to identify a resource. We
> could use a single MIME type to define a font, and rely on a set of
> optional parameters to provide more specificity but, like it was
> mentioned earlier, we have at least two orthogonal issues that need to
> be addressed - type of outlines within a font and supported text layout
> mechanism(s). Currently, the suggested set of different MIME types
> differentiates font resources by format and various types of outlines,
> and leaves text layout machinery to be defined using optional
> parameters.
> 
> OK, maybe I have it wrong.  I thought that what was proposed was
> mime type A if you know the outlines are A format
> mime type B if you know the outlines are B format
> mime type C if you don't know, both are supplied, or something...
> 

David, you got this is exactly right - this is what is currently proposed.

> If this is the case, this is at least odd for mime types.  Are A, B, C
> normally distinguished by file extension?
> 

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]:

video/mp4 - for visual content;
audio/mp4 - for audio streams;
application/mp4 - for system stream;
application/mpe4-iod - for object descriptors, etc.

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:

application/font-ttf;
application/font-cff;
application/font-off;
application/font-sfnt,

with possible additional optional parameter that can be used to define supported text layout option.

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:

1)	Name: Format
	Value: TTF, CFF
2)	Name: Layout
	Value: OTF, AAT, SIL

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)!

Thank you and regards,
Vladimir

[1] http://tools.ietf.org/html/rfc4337