Fragment syntax for collections

[svgeesus]

Need to define the fragment syntax to refer to individual fonts in the collection.

[svgeesus]

Discussed with John Daggett at TPAC 2015, he thinks the media type registration is the appropriate place to describe the collection fragment syntax, and I agree.

[rsheeter]

+1; although if there was something we could link to from the note in the woff2 spec that might be nice. Even just to cite "this is where this should be/will be/is specified".

[svgeesus]

(copy of email sent to justfont mailing list):

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 OpenType shaping parameter #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
Fragment syntax for collections #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.

[svgeesus]

Rod, good point that WOFF 2.0 should allow the same fragment syntax in case a collection has been encoded as WOFF.
In that case we need rules for what to do if:

• the font is a collection and no fragment is specified (easy, it is the first font)
• the font is not a collection and a fragment has been specified (also easy, there is only one font, ignore the fragment)

[kenlunde]

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.

[svgeesus]

Thank Ken, helpful to know. Perhaps a single Internet Media type for all collections would be better, in that case?

[kenlunde]

The current situation for collections is certainly helping to set a precedent that suggests a single Internet Media type.

[vlevantovsky]

(copy of email sent to justfont mailing list):
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.

[rsheeter]

+1 for a single media type for all collections.

[svgeesus]

This uses the same fragment syntax as is used (in an illustrative
example) in the CSS3 Fonts spec. It is used on font/collection and
also on font/woff2 because unlike woff1, woff2 can encode collections.

The spec language also adresses the interpretation when the fragment
is omitted (it is the first font in the collection), and for woff2,
also what happens if a fragment is provided but the woff does not
encode a collection (fragment ignored, no effect).

[svgeesus]

seems to be on-list consensus