Re: [apps-discuss] font/*

[Mark Nottingham <[e-mail]>]

Oh, I had thought it would be

  font/PostScript
  font/TrueType

i.e., NOT identifying the specific typeface in use. After all, we don't have text/html/home-page, do we?

BTW, before naming this thing, please have a discussion with a typographer about the difference between a "font" and a "typeface." 

(My wife, who teaches typography, would beat me if I didn't make that distinction)

Cheers,


On 08/11/2011, at 8:20 AM, Eric Burger wrote:

> Is the idea we would see something like
> 
> 	font/Times
> 
> or one of 
> 
> 	font/PostScript/Times
> 	font/TrueType/Times
> 	font/OpenType/Times
> 	font/METATYPE/Times
> 
> or one of
> 
> 	font/Times/PostScript
> 	font/Times/TrueType
> 	font/Times/OpenType
> 	font/Times/METATYPE
> 
> One cannot just say it's font/* and assume it is an opaque container, as one could see battles over the latter examples.
> 
> On Nov 8, 2011, at 1:49 AM, Martin J. Dürst wrote:
> 
>> Hello John,
>> 
>> On 2011/11/08 8:32, John C Klensin wrote:
>>> 
>>> 
>>> --On Monday, November 07, 2011 15:49 -0700 Peter Saint-Andre
>>> <[e-mail]>  wrote:
>>> 
>>>> In talking with folks at the W3C meeting last week, I heard
>>>> yet again of interest in defining a Content Type for fonts.
>>>> Would anyone active in the IETF Applications Area want to work
>>>> on such a spec? And do folks here think a new top-level
>>>> content type is needed for fonts?
>>> 
>>> Well, I think that a top-level would be in order -- these are
>>> really different from the existing types.  Things may have
>>> changed, but my recollection from when I had some exposure to
>>> them in the early 90s is that there are a bunch of font
>>> definition languages out there.  Unless all but one has
>>> atrophied or one could pick one to go with the top-level type,
>>> there is going to be a messy problem in which one either needs
>>> to have
>>>  font/DefinitionLanguage fonttype=Foo
>>> or another round of
>>>  font/Foo+DefinitionLanguage
>>> I'd hope we could avoid the latter, especially since some of
>>> those languages and definitional methods don't scale over a very
>>> broad range, s.t. one might actually need a tuple of Definition
>>> Language, Typeface, Style, and applicable range of sizes.
>>> 
>>> Happy to try to help with this, but there better be some real
>>> typographic experts involved.  We do not want to create a
>>> top-level type only to find ourselves locked into one particular
>>> kind of solution (even if it is open source rather than
>>> vendor-specific).  I might still be able to carry on a useful
>>> conversation with such an expert, but it has been a very long
>>> time since I've had to do that, things have changed, and I've
>>> forgotten a lot of what I once knew.
>> 
>> There is no need to overengineer this stuff. Like all other types, it's simply a top level type, and a subtype. A very rough approximation of what could end up in the subtype can be found here: http://en.wikipedia.org/wiki/Category:Font_formats.
>> 
>> If some kind of 'Definition Language' is used inside a font format, then that's just something under the hood. My understanding is that some popular formats such as OpenType essentially are mergers resulting from the "Definition Language" wars in the early 1990. Also, typeface, style, and applicable range of sizes shouldn't be necessary as part of the mime type because it's part of the content.
>> 
>> Some such parameters were proposed in http://tools.ietf.org/html/draft-singer-font-mime-00, and may still be necessary, but not as much as 7 years ago, when you apparently shot down the proposal (see http://www.ietf.org/mail-archive/web/ietf/current/msg33267.html). So if the font experts say they really need a parameter, we'll keep it, but we don't have to make thing more complicated than necessary in advance.
>> 
>> The only RFC that defined a new top-level type is RFC 2077 (http://tools.ietf.org/html/rfc2077). It's rather short, and I expect the font/ RFC to be even shorter unless it also includes some registrations for actual subtypes (I'd probably do it in two separate documents, one for the top-level type and another for some low hanging subtypes, but I'll leave the decision to whoever does the actual work.)
>> 
>> 
>> Regards,   Martin.
>> 
>> _______________________________________________
>> apps-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham
http://www.mnot.net/