- From: John Daggett <jdaggett@mozilla.com>
- Date: Tue, 22 Oct 2013 09:10:57 -0700 (PDT)
- To: Chris Lilley <chris@w3.org>
- Cc: "Adam Twardoch (List)" <list.adam@twardoch.com>, public-webfonts-wg@w3.org
Chris Lilley wrote:
>> Of course there's some caveats: since TTC is "one file" which
>> stores several "subfonts", I believe @font-face might need to be
>> modified somehow so that it allows selection of the subfonts.
>
> Rather than modify @font-face, I suspect the correct approach would
> be to define a fragment identifier syntax (the part of a url after
> the #) that points into a TTC.
Right. And that fragment syntax is already defined. ;)
http://dev.w3.org/csswg/css-fonts/#src-desc
# Similarly, font container formats that can contain more than one
# font must load one and only one of the fonts for a given @font-face
# rule. Fragment identifiers are used to indicate which font to load.
# If a container format lacks a defined fragment identifier scheme,
# implementations should use a simple 1-based indexing scheme (e.g.
# "font-collection#1" for the first font, "font-collection#2" for the
# second font).
That said, I'm not sure I see TTC support as so useful. Even the
original CJK use case which was for sharing kanji/kana glyphs across
different families with proportional and monospaced Latin glyphs can
be mimicked with font features:
/* default family */
@font-face {
font-family: mincho;
src: url(mincho.ttf);
}
/* variation family */
@font-face {
font-family: mincho variation;
src: url(mincho.ttf);
font-feature-settings: /* features that enable variation */
}
In short, TTC is a useful bundling format, not sure it's so useful in
the webfont context. EPUB user agents might find it more useful just
for the simplicity of packaging.
Cheers,
John Daggett
Received on Tuesday, 22 October 2013 16:11:28 UTC