Subject: Re: [apps-discuss] Proposed charter for justfont

From: Chris Lilley <[email-masked]>
Date: Wed, 11 Nov 2015 10:30:12 +0000

Hello Apps-discuss,

(I just joined; apologies for not having the original thread starter
message to reply to).

I have ready the proposed charter and it seems fine to me. I'm glad to
see that my ID is to be used as the basis, and confirm my willingness
to be document editor for the proposed group IDs and eventual RFC.

I agree with Ned Freed that a brief sentence or two of justification,
lifted from the ID and pointing to the same data about current usage,
would be helpful.

I see that the topic of fragment identifiers has come up. Some formats
will indeed need fragment identifiers to be defined (TrueType
collections is one example, SVG Fonts was another) and the correct
place to do so is clearly the Media Type registration.

(I also see calls for fragment identifiers to be ruled out of scope; I
see no reason to do so and it would be actively harmful so let's not
do that).

I concur with the opinions Barry, John, Mark and others have expressed
that a tightly focussed group is preferable to extending the scope for
additional top-level types, which is an unbounded problem.

I see pushback on initial registrations. I don't understand this, at
all. Forcing the initial set of registrations out to another venue
means extra work for no benefit. The original MIME document had
initial registrations for image/gif and image/jpeg if I recall
correctly, despite there being no commonality in terms of internal
structure between the two. Both however could be (and were, in the
early days) handed off to a multiformat image viewing program. This
looks like exactly the same case.

So I think the initial registrations should stay. The ones for WOFF1
and WOFF2 come from the W3C WebFonts WG, which this charter proposes
to tightly coordinate with; the sfnt, TrueType and OpenType ones come
from ISO SC29 WG11 whoo maintain the Open Font Format (aka OpenType)
specification. So these formats are all widely deployed already, they
are not speculative or tentative. Let's avoid splitting those all out
into separate documents, please.

I do agree with Sean however on the terminology "primary content
type". I'm used to the term "top-level type" but I read the model/*
registration shortly before submitting this iD and suddenly worried I
was using the wrong term, hence the occurrences of "primary content
type". Happy to revert to using the right term.

-- 
Best regards,
 Chris  Lilley
 Technical Director, W3C Interaction Domain

---

From: Sean Leonard <[email-masked]>
Date: Wed, 11 Nov 2015 10:06:43 -0800

> (I just joined; apologies for not having the original thread starter
Greetings. Here you go:

http://mailarchive.ietf.org/arch/msg/apps-discuss/Y7jED50ZCAprh3WGqn5TH5vaIfM

> see no reason to do so and it would be actively harmful so let's not

Fragment identifiers are complicated, because:
* the character encoding is not necessarily straightforward, especially 
when dealing with legacy types
* when generalizing about any group of types, you should survey as many 
of the types as possible (including those that you personally don't 
consider "popular") to make sure that your syntax does not exclude those 
types
* fragments can represent anything so you have to make choices about 
what is addressable and what is not addressable. For example, text/html 
uses fragments for <a name="foo"> anchors; this precludes using fragment 
syntax to identify, for example, the nth element in the tag soup, or 
some XPath expression (absent active JavaScript code on the page that 
reinterprets the anchor). One also does not really use fragments with 
text/html to express "ranges" of the document.

At a high level, collections of fonts are not single fonts; my 
impression prior to researching was that font/x represents a single 
font. A generic font collection would best be described in archive/* (if 
the collection is a group of files, such as a ZIP archive), or possibly 
in message/* or multipart/* depending on the structure. It could even be 
application/cms or application/cbor if one were so inclined.

However I just read 
<https://www.microsoft.com/typography/otspec/otff.htm> and it appears 
that TTCs are actually SFNT data with a header, TTCHeader, that 
indicates the presence of multiple individual font table collections. So 
font/ttc may well be appropriate because it is a kind of SFNT. I am 
curious what happens if a font rendering engine that is *not* TTC-aware 
is supposed to do with the font file. Will the rendering engine just 
treat it as a single font, such as the first font in the table?

As for fragments: if you want the fragment of a font/ttc to be useful to 
identify a single font, that has very different semantics from a 
single-font SFNT, where people might want fragment identifiers to 
address individual tables (or possibly individual glyphs or data items 
in individual tables). There is nothing wrong with defining fragment 
identifiers specifically for font/ttc, as long as we understand that 
it's not necessarily generalizable to the generic case.

If we can agree that SFNT is the de-facto structure for types in font/*, 
that could keep the work more focused.

If TTC & font collections are a significant use case, then the WG 
charter should be updated to include (or exclude, put it in 
multipart/ttc or application/font-collection; type="ttc" or 
what-have-you) that. The choice seems to be directly related to how TTC 
handling might gracefully degrade to a generic font/sfnt, and based on 
my preliminary research, it should probably be in.

(I have no domain knowledge about SVG Fonts so don't want to say 
anything about that.)

Sean