Subject: [Justfont] Internet Media type for font collections

From: Chris Lilley <[email-masked]>
Date: Sat, 6 Feb 2016 15:21:32 +0100

Hello,

It is unclear in the current spec what Internet media Type to use for
Collections (previously, TrueType Collections but now expanded to
OpenType as well). I can see several possibilities, which have
different impacts on the spec.

a) Just use font/truetype for TTC.
+ avoids adding another type
- no way to indicate support for collections in an Accept header
- complicates specifying a fragment identifier (only sometimes legal)

consequences:
  need to add .ttc to the file types section
  change fragment identifiers to allow an optional fragment (but only
  if ttc)

Similarly, just use font/opentype for OTC (is .otc the usual filetype?)
(same pluses, minuses and consequences as for TTC)

b) Same as a) but add a parameter like collection="true" or something.
I don't like this option, partly because params are often awkward to
configure on servers and tend to be little used (or hard coded to
particular filetypes) and also because it has all the disadvantages of
a) regarding optional fragments.

c) Define two new media types, for TTC (TrueType outlines, no OpenType
layout) and for OTC (CFF or TTF outlines, OpenType Layout)
- two more types (but at least, no parameters)
+ easy to map to existing filetypes .ttc .otc
+ fragment identifier easy to specify (numeric, the n'th font in the
collection where n starts at one. If omitted, same as #1)
+ Easy to use in an Accept header

Option c) is my preferred option, would be interested to hear what
others think.

This refers to github issues:
   Media type for OpenType collections #6
   https://github.com/svgeesus/ietf-justfont/issues/6

    Fragment syntax for collections #7
    https://github.com/svgeesus/ietf-justfont/issues/7

although the main question for #7 is what media type to put the
fragment syntax onto. The actual syntax of #1, #2 is uncontroversial
and already used (but as a non-normative example) in CSS3 Fonts.

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

---

From: Ken Lunde <[email-masked]>
Date: Sat, 6 Feb 2016 15:27:15 +0000

Chris,

I am not sure how helpful this information is, or how it would factor into this issue, but all of the OpenType/CFF Collections of which I am aware use the ".ttc" filename extension, not the ".otc" one. These include the Source Han Sans, Source Han Code JP, and Noto Sans CJK families, along with the large number of OpenType/CFF Collections that are bundled with OS X Version 10.11. The main reason is due to the latter filename extension not being recognized.

It is somewhat unfortunate that two different filename extensions have been deployed for non-collections, meaning ".ttf" and ".otf," and the current situation with collections provides an opportunity to use a single filename extension, specifically the ".ttc" one.

I will add the above to Issue #7.

Best...

-- Ken

> On Feb 6, 2016, at 6:21 AM, Chris Lilley <[email-masked]> wrote:
> 
> Hello,
>

---

From: "Levantovsky, Vladimir" <[email-masked]>
Date: Mon, 8 Feb 2016 04:42:54 +0000

I am not sure if there is a use case where specifying the fact that a font file is the font collection is important but if there is - we can define another subtype for font collections and use the same optional parameters to specify what types of outlines / layout mechanism are supported.

Thanks,
Vlad

-----Original Message-----
From: Justfont [mailto:[email-masked]] On Behalf Of Chris Lilley
Sent: Saturday, February 06, 2016 9:22 AM
To: [email-masked]
Subject: [Justfont] Internet Media type for font collections

Hello,

It is unclear in the current spec what Internet media Type to use for Collections (previously, TrueType Collections but now expanded to OpenType as well). I can see several possibilities, which have different impacts on the spec.

consequences:

Similarly, just use font/opentype for OTC (is .otc the usual filetype?) (same pluses, minuses and consequences as for TTC)

b) Same as a) but add a parameter like collection="true" or something.
I don't like this option, partly because params are often awkward to configure on servers and tend to be little used (or hard coded to particular filetypes) and also because it has all the disadvantages of
a) regarding optional fragments.

c) Define two new media types, for TTC (TrueType outlines, no OpenType
layout) and for OTC (CFF or TTF outlines, OpenType Layout)
- two more types (but at least, no parameters)
+ easy to map to existing filetypes .ttc .otc fragment identifier easy 
+ to specify (numeric, the n'th font in the
collection where n starts at one. If omitted, same as #1)
+ Easy to use in an Accept header

Option c) is my preferred option, would be interested to hear what others think.

although the main question for #7 is what media type to put the fragment syntax onto. The actual syntax of #1, #2 is uncontroversial and already used (but as a non-normative example) in CSS3 Fonts.

_______________________________________________
Justfont mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/justfont

---

From: Chris Lilley <[email-masked]>
Date: Thu, 11 Feb 2016 00:05:34 +0100

Hello Vladimir,

Monday, February 8, 2016, 5:42:54 AM, you wrote:

> I am not sure if there is a use case where specifying the fact that
> a font file is the font collection is important but if there is - we
> can define another subtype for font collections and use the same
> optional parameters to specify what types of outlines / layout mechanism are supported.

That is the option I have gone with.

(I also added a curent directory with text, html and pdf versions for
easier review.)

https://github.com/svgeesus/ietf-justfont
-- 
Best regards,
 Chris  Lilley
 Technical Director, W3C Interaction Domain