Re: [apps-discuss] font/*

[Eric Burger <[e-mail]>]

Sounds like a call for a BOF.

On Nov 9, 2011, at 8:06 AM, John C Klensin wrote:

> Hi Martin,
> 
> The links you gave to earlier messages don't work, but I don't
> recall "killing" a font proposal.  See inline below.
> 
> --On Tuesday, November 08, 2011 15:49 +0900 "\"Martin J.
> Dürst\"" <[e-mail]> wrote:
> 
>> ...
>>> 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
>> ...
>> 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.
> 
> I was, and remain, very hesitant about creating new top-level
> types.  As others have noted, it is a big deal.  There are
> several reasons for that but at least one important one is that
> the model for what an application is expected to do when it
> encounters an unknown top-level type is not, IMO, really well
> sorted out.  One cannot do much of anything (in that sense, it
> isn't much different from an application/ subtype), but it isn't
> clear how one should present that fact to a user who doesn't
> have much understanding or vocabulary about what is going on at
> the content-type level.
> 
> "Model/" (as described in RFC 2077) was not a problem because
> the request came from a particular community for a particular
> type of use, one on which there was little or no likelihood of
> interaction with other types, especially with multipart content.
> I assume that the community that wanted that type is using it,
> but confess to never having seen the type in the wild.  If
> others haven't either, that reinforces the claim that the
> "model/" type really is independent of the others.
> 
> If font/* is simply a "type and a subtype", then I'm inclined to
> agree with those who say "use application/".  Certainly it is
> feasible to say, e.g., "application/OpenType", specify it as
> being bound to the OpenType font definition model, say some
> things about encoding and parameters, and move on.  The fact
> that it and an equally hypothetical "application/TrueType" both
> encode/carry fonts creates no more of a requirement or
> justification for a top-level type than the observation that
> there application/ subtypes for Open Document and MSWord formats
> implies that we should have a top-level type for WordProcessor/
> or DocumentFormatter/.  And, as Graham and others have pointed
> out, we use "application/" (a lot) for subtypes that require
> processing or installation before something else can make use of
> them.
> 
> I think a font/ top-level type would be worth looking at
> carefully if there really were a use case for which some
> application/ subtypes would not be appropriate.  One of those
> might lie along the path of compound documents that I mentioned
> in the context of "image/".   Perhaps there might be others, or
> perhaps not.  "Distinct media type" doesn't do much for me
> because what is, and is not, is largely in the mind of the
> beholder.
> 
>> 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.
> 
> I used "Definition Language" to refer to what you are referring
> to as a "format" (which often means something else in this
> context).  I don't have enough contemporary knowledge to know
> what would be most accurate and consistent with current
> terminology -- another topic for Mark's wife or some other
> typographic expert.
> 
>> 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.
> 
> I don't know what that means in practice.  Having struggled
> several times with what needs to be a parameter on a media type
> and subtype, it isn't obvious that parameters are unnecessary
> even if the information can be deduced from content.   I am
> particularly concerned about transmission of files that contain
> parts of a typeface family, but not all of it, as well as about
> a type and subtype that don't even identify the type family and
> hence may require a lot of work before a system can decide
> whether to install it.
> 
> I also don't know whether all "Definition Languages" in use
> today contain the same descriptor information in reasonably
> compatible formats.   If some do and others require, e.g., the
> name of the font in supplemental information because only the
> glyph descriptions are stored in the file, then there is a lot
> of justification for parameters across the board if one is going
> to have a well-designed top-level type with homogeneous
> subtypes.  Of course, homogeneous subtypes are not a
> requirement, but, if each subtype will have to establish its own
> parameter model, it seems to me that the argument for just
> sticking with "application/" becomes stronger.
> 
>> 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.htm
>> l). 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.)
> 
> While the "model/" spec is rather short, it contains the
> elements I'm trying to advocate here: a clear description of why
> a top-level type is needed, a discussion of use cases, and
> definitions of enough subtypes to make the use cases clear, as
> well as the required templates and mechanisms for defining
> future subtypes.
> 
> Recommendation to those who want this:  Work on a few subtype
> definitions.  Sort the details, such as what parameters are
> needed, out with the typographic community.  Examine the use
> cases.   The would would need to be done --and would be almost
> the same-- for a subtype of application/ or a subtype of font/.
> With those tentative subtype descriptions in hand, the rest of
> us will be a lot more able to identify commonalities and to
> participate in an evaluation of whether a top-level type is
> really justified.
> 
> best,
>   john
> 
> 
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss