Re: [apps-discuss] font/*

["t.petch" <[e-mail]>]

----- Original Message -----
From: "Mark Nottingham" <[e-mail]>
To: "Eric Burger" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, November 08, 2011 6:15 PM

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

<tp>
and typeface, versus typeface family (which, I suspect, is what many mean when
they say 'font')

Tom Petch

</tp>







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




_______________________________________________
apps-discuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/apps-discuss