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

[Thomas Phinney]

The second option seems much more clear to me, and makes extra distinctions
that I expect to be useful to some consumers.

Two small propositions:

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

2) Although there should only be one type of outlines, multiple layout
formats in a single font should be supported.

T

On Mon, May 2, 2011 at 8:14 AM, Levantovsky, Vladimir <
vladimir.levantovsky at monotypeimaging.com> wrote:

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



-- 
“Puritanism: The haunting fear that someone,
 somewhere, may be happy.”
 —H.L. Mencken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20110502/45d38728/attachment.html>