Re: [apps-discuss] font/*

["Martin J. Dürst" <[e-mail]>]

Hello John,

On 2011/11/10 11:56, John C Klensin wrote:

> --On Thursday, November 10, 2011 10:40 +0900 "\"Martin J.
> Dürst\""<[e-mail]>  wrote:

> And, yes, creating a new top level type for a half-dozen or
> fewer subtypes does seem wasteful, but, again, I don't feel
> quite as strongly about that as I did seven years ago (although
> others may).

On the page I pointed to before, at 
http://en.wikipedia.org/wiki/Category:Font_formats, I count 24. Of 
course, we don't know how many of these may get registered, but there's 
a good chance it will be more than half a dozen.


> I'll let Ned or Nathaniel speak to that, but my impression at
> the time was that it allowed for additional types because not
> doing so would represent a claim to really comprehensive
> knowledge of the future.  It wasn't intended as license to go
> out and create a bunch of them

And we haven't, and we aren't proposing to.

> -- application/ was really
> intended to be quite comprehensive wrt the things that need, as
> someone else put it, to be processed and usually stored
> somewhere, not rendered directly to the user.  We render text,
> video, and images.

And application/pdf, and application/msword, and lots of other stuff. 
These days, software may kindly ask whether the user agrees, so that 
they can disclaim responsibility for macro viruses, but that's about the 
only difference.


> Fonts are used to build tables that are then
> used with a list of characters and other information to create
> something that is rendered.  The latter is either pretty close
> to application/

It isn't necesarily. Except for the special case font editors, fonts are 
used as auxiliary documents. They make the main document look more 
pretty, but without the actual text that uses the font, they are rather 
useless.


> or, as I suggested in 2004, represents a
> different sort of creature that should be generalized.

You have brought up "should be generalized" in 2004, and you are 
apparently still believing in it. Can you please, please give a single 
concrete example of what you think should be thrown together with fonts 
so that we can claim that it has been generalized?


> Ok.  But, if you see the distinction in terms of the
> interactions, make that case for fonts.  I'm actually much more
> open to this idea than you seem to have concluded (and was open
> to it in 2004) - I just think the questions I've asked (as
> questions, not rebuttal) are appropriate and should be addressed
> in a serious way... with a default if there aren't satisfactory
> answers of "use application/".

You made a request for generalization. What if people come back and say: 
"Sorry, fonts are fonts, we don't see any way to generalize them without 
getting overly metaphysical and therefore useless."? Or even more 
direct, say "what the hell are you talking about"? (frankly, I'd like to 
know, too)


> To repeat what I said earlier, I'd like to see some I-Ds that
> drill down into the subtypes.  The observation that Bitstream
> thought that application/ was adequate for PFR (and did write a
> document) is some evidence that "these people" are not unanimous
> that a top-level type is needed.  Now, if someone came forward
> and said "we tried using application/font-tdpfr and the fact
> that 'font' wasn't a top level type caused the following
> specific problems so we have learned that putting it into
> application/ was a bad idea", I, at least, would find that
> extremely persuasive.

I have absolutely no inside knowledge, but one plausible story would be 
that somebody at Netscape told Bitstream that they better had a 
registered type for their format, and Bitstream did what they thought 
they could get through most quickly. But that's a wild guess.

As Ned has explained in quite a bit of detail, for most software 
purposes, you could register a font format under video/, or an audio 
format under image/, and sofware wouldn't care because it uses composite 
strings. But the problem is that that looks wrong to humans.


>> So why don't we change policies so that new image types also
>> have to be registered under application/?
>
> See above, plus the fact that image/ already exists as a basic
> type and part of what you are arguing against is a principle
> that we should not create a lot of top-level types... or any
> more of them without considerable justification.

So are you saying that we have image/ just because it already exists, 
but it wouldn't have a chance these days (or at least it would have to 
undergo much, much more scrutinity these days than when it was defined 
originally)?


>> ...
>> With Web fonts, or with fonts attached to other documents such
>> as emails, partial fonts are indeed very important. But they
>> will be installed temporarily. Also, for Web fonts, the main
>> usage is via CSS, which makes sure there's enough
>> meta-information.
>
> But, unless you propose to restrict the use of this type to the
> web, the broader questions need to be addressed.  And I haven't
> seen anything proposed yet that would result in a different
> handling or definitional model for temporary versus more
> permanent installations.  Again, an I-D that explored or
> specified these things would be a big help here.

I don't think there is a need for a different handling or definitional 
model for temporary versus permanent installations. These are not 
questions for transmitting the font, but questions that differ by 
OS/rendering engine,...

And there are many aspects that are quite similar (if not the same) as 
for images. If somebody receives a mail with images included or 
attached, then these images shouldn't be permanently "installed" (i.e. 
saved) on the machine, they should go away when the mail is deleted 
(unless they have been saved separately). Most mailers do a reasonable 
job for this (but not necessarily a perfect one). But I haven't seen any 
details about this in the description of the image/ top level type. So 
why would we need it for font/?


> I said before that I've got a relatively open mind about this.

Great.

> The one thing about which I don't have an open mind is the idea
> of saying "ok, let's create a top-level 'font/' type and assume
> that the subtype definitions and all of the other issues will
> sort themselves out".  I think a top-level type needs an
> architecture, not just a string of characters.  YMMD.

Oh, so what's the "architecture" for image/? From what you have written 
about fonts, I'd expect all image types to have parameters for width and 
height, maybe pixel aspect ration, and so on. Looking at 
http://tools.ietf.org/html/rfc2046#section-4.2, I can find none of that. 
Same for audio/, and video/.

Maybe there's actually a good reason for that. And maybe that's that 
these formats are self-describing, because they get bounced around in 
many contexts (in particular the file system) where they need to be 
self-describing, because there's no place to store additional parameters.

And maybe, and just maybe, the same thing actually could apply to fonts.

So I don't really understand why we need an "architecture" for font/. If 
it turns out there are some common parameters than (optionally) make 
sense, then why not have them. There are some in 
http://tools.ietf.org/html/draft-singer-font-mime-00, and we can review 
and tweak that.


>> Would it be possible to let the font experts figure this out?
>
> Sure.  Get someone to produce an I-D or three.  Don't expect
> people to believe that they will figure it out because they are
> font experts.

I should have been more precise. I didn't mean people who are "font 
experts" just because they are good at using fonts, or because they 
design fonts. I meant font experts who understand the various formats, 
maybe even have helped design one or two, define standards for formats, 
implement these, write converters between formats, and so on.


>> I agree that having a bit of text on why a new subtype was
>> chosen can't hurt at all. But I think we have to be careful
>> and not make this a sysiphean exercise by requiring something
>> like a proof that a new top-level type was absolutely
>> necessary because otherwise the world will go under.
>
> I don't think anyone has suggested that.  Certainly I haven't.

But much of what you write looks pretty close to it, at least from the 
outside.

>> Sorry, John, but they have tried before. They don't have much
>> trust anymore.
>
> As far as I can tell, only one subtype definition has been tried
> and it resulted in RFC 3073.  If "tried before" means "thought
> about it but decided to not post drafts and open discussions"
> then I sympathize but I don't know how to get unstuck (in this
> area or others with which you are familiar) from vague claims
> about obstructions and problems.

When I wrote "tried before", I specifically meant the font/ top level type.

>>   If we again tell them what sounds to them as
>> "bring it on, and we'll do our best to shoot it down and make
>> your life miserable",  then they won't do the work. They won't
>> do it for font/, and they also won't do it for application/. I
>> don't think that's what we want.
>
> I agree.  So your help, and Peter's, and that of others, are
> going to be needed to be sure that the message comes across
> well.  But I don't think that either a top-level type, or even
> an application/ subtype, are going to get very far unless there
> are definitions that can be examined by others and shown to work
> and to be sufficiently comprehensive.

"or even an application/ subtype"? Now I really don't understand things 
anymore. There are well-defined font formats that work on millions and 
millions of computers (and soon probably more than that number of 
smartphones), have published specifications and several independent 
implementations including open-source ones. What exactly do you want to 
"examine" before we allow them to be registered?


Regards,   Martin.