Re: [apps-discuss] font/* (and draft-freed-media-type-regs)

"Levantovsky, Vladimir" <> Fri, 18 November 2011 15:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7069721F89BA for <>; Fri, 18 Nov 2011 07:17:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.233
X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j1f8JI38GQDa for <>; Fri, 18 Nov 2011 07:17:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 092FE21F88AB for <>; Fri, 18 Nov 2011 07:17:06 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKTsZ28gl52MfFUtext0m6Qz/; Fri, 18 Nov 2011 07:17:07 PST
Received: from ([]) by ([]) with mapi; Fri, 18 Nov 2011 10:17:05 -0500
From: "Levantovsky, Vladimir" <>
To: "\"Martin J. Dürst\"" <>
Date: Fri, 18 Nov 2011 10:17:04 -0500
Thread-Topic: [apps-discuss] font/* (and draft-freed-media-type-regs)
Thread-Index: AcylxvYSRSPoOj1mRmeScfmjQcQt3gAO/ddQ
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: " Adams" <>, Ned Freed <>, David Singer <>, "" <>
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Nov 2011 15:17:08 -0000

On Friday, November 18, 2011 2:52 AM Martin J. Dürst wrote:
> On 2011/11/16 8:22, Levantovsky, Vladimir wrote:
> > In fact, SC29/WG11 is in the process of finalizing a new application
> (as part of the ISO/IEC 14496-22:2009/Amd.2 work) where we decided to
> apply for a new "application/font-sfnt" type using additional optional
> parameters to specify types of outlines and advanced layout mechanisms
> supported by a font. Doing so allows creating a flexible and extensible
> (albeit slightly cumbersome) mechanism to identify any SFNT-based font
> using same MIME type definition for a number of font flavors combining
> either TTF or CFF outlines with any currently known layout engine
> support (e.g. OpenType, AAT or SIL). Under the circumstances, this
> seemed to be a pragmatic way to compensate for the lack of "font" type.
> I have no idea about the details involved, but what you say here about
> optional parameters sounds rather dangerous to me.
> Setting parameters correctly on Web servers, while in theory not too
> complicated, turns out to be quite brittle and impractical in many
> scenarios. Even the base media type often isn't correct.
> What you call a "flexible and extensible (albeit slightly cumbersome)
> mechanism" may turn out, in actual practice, to be highly cumbersome,
> confusing, and rarely used.
> Again, I have to admit that I'm not familiar with the details, so if for
> example these parameters are only advisory and in practice things work
> perfectly well even if they are not used, then it might be less big of
> a deal.
> Can you give use a bit more information to help understand the
> trade-offs involved?

The SC29/WG11 planned to register the "application/font-sfnt" type with the following two optional parameters:
1) 	Name: 	Outlines
	Value: 	TTF, CFF
2) 	Name: 	Layout
	Value: 	OTF, AAT, SIL 

This would allow to identify fonts of multiple flavors, e.g.:
TrueType - application/font-sfnt (Outlines=TTF);
OpenType with TTF outlines - application/font-sfnt (Outlines=TTF, Layout=OTF);
OpenType with CFF outlines - application/font-sfnt (Outlines=CFF, Layout=OTF);
AAT fonts - application/font-sfnt (Outlines=TTF, Layout=AAT); etc.

I understand that the alternative would be to register a number of separate subtypes for each font flavor, and it would probably be the way we will go if font/* is available.

Thank you,