RE: Wrapper not format

Wednesday, March 03, 2010 10:44 PM <list.adam@twardoch.com>:

First, John Hudson wrote:
>> Is this helpful, though, to the web font issue, which is that it is
>> sometimes important for an agent to know whether a .woff container
>> format contains a CFF or TTF font? If everything is a container format,
>> how does one make useful distinctions between the container and the
>> thing contained?

Adam Twardoch answered, in part:
>The sfnt-based container formats can contain one or more sfnt streams,
>plus potentially additional metadata streams. Each sfnt stream is made
>out of one glyph imaging substream (in TrueType or CFF coding format)
>and out of zero or more text layout substreams in TrueType (i.e. "kern"
>table), OpenType, AAT or Graphite coding formats. Additional substreams
>(for example private VOLT or VTT tables) can be included in the sfnt
>stream. Each substream is made out of sfnt tables.

Ok, so we've got what's colloquially called "Chinese Boxes" and it's undoubtedly pertinent for a working group to deal with each box and what happens when it's opened to reveal the next. With my network engineer hat on, I understand the importance of this. But for authors, that's somebody else's problem and rightfully so. It's one reason there are standards bodies like the W3C.
As an author, I'm "wrapping" up a TTF or a CFF or some other file "format" and I want, in some cases, for the user agent to use the TTF and, in other cases, the CFF. I might need other options, as yet unidentified, as well. I don't see how this can be achieved with the current "font stack" approach in the CSS3 draft alone. When creating the ordered src list, there's no way to say to a particular user agent, "If you support more than one of these formats, I want you to give preference to the second in the list".
But then again, maybe such distinctions are properly left in the realm of JavaScript - where you can query for platform and user agent. But the problem certainly rates some additional thought.
In the meantime we use what we have. With the release of Opera 10.5, we now have all five of the "major" browsers featuring comparable @font-face support. Licenses for web fonts are being sold, thousands of free fonts are available for web use, and the barriers to using web fonts are steadily being chipped away. There *is* a reliable cross-browser syntax that works. File sizes *can* be made manageable through compression and sub-setting. And best of all, IE's installed user base won't slow adoption - IE6, 7, and 8 all support @font-face.

Even if WOFF wasn't on the table, there is plenty of need for a working group, and the time is now.

(Maestro, key the wrap music, please.)

Regards,
rich

-----Original Message-----
From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of Adam Twardoch (List)
Sent: Wednesday, March 03, 2010 10:44 PM
To: John Hudson
Cc: Adam Twardoch (List); Chris Lilley; Thomas Phinney; Tab Atkins Jr.; www-font@w3.org
Subject: Re: Wrapper not format

John Hudson wrote:
>> Following this analogy, .woff, .eot, .otf, .ttf, .ttc, .dfont, FFIL are
>> different container formats for sfnt-based digital font files.
> 
> Is this helpful, though, to the web font issue, which is that it is
> sometimes important for an agent to know whether a .woff container
> format contains a CFF or TTF font? If everything is a container format,
> how does one make useful distinctions between the container and the
> thing contained?

Being more precise, continuing the analogy:

The sfnt-based container formats can contain one or more sfnt streams,
plus potentially additional metadata streams. Each sfnt stream is made
out of one glyph imaging substream (in TrueType or CFF coding format)
and out of zero or more text layout substreams in TrueType (i.e. "kern"
table), OpenType, AAT or Graphite coding formats. Additional substreams
(for example private VOLT or VTT tables) can be included in the sfnt
stream. Each substream is made out of sfnt tables.

The coding format of the glyph imaging substream is identified by the
sfnt version field at the beginning of the sfnt stream. In TrueType
coding format, the sfnt version field is "\00\01\00\00". In CFF coding
format, the sfnt version field is "OTTO".

Now:

*.ttf is a container format for desktop fonts (and, currently, web
fonts) that contains just one sfnt stream with the glyph imaging
substream in TrueType coding format

*.otf is a container format for desktop fonts (and, currently, web
fonts) that that contains just one sfnt stream with the glyph imaging
substream in TrueType or CFF coding format

*.ttc is a container format for desktop fonts that contains one or more
sfnt streams with glyph imaging substreams in TrueType coding format

*.dfont is a container format for desktop fonts that contains one or
more sfnt streams with glyph imaging substreams in TrueType (or possibly
CFF) coding format, plus a metadata stream (i.e. other Mac resources)

*.eot is a container format for web fonts that contains one sfnt stream
with the glyph imaging substream in (potentially compressed) TrueType
coding format (potentially CFF is an alternative but is not supported in
IE), plus a metadata stream (the EOT metadata)

*.woff is a container format for web fonts that contains one sfnt stream
with the glyph imaging stream in compressed TrueType or CFF coding
format, plus a metadata stream (the WOFF metadata)

Roughly so.

A.

-- 

Adam Twardoch
| Language Typography Unicode Fonts OpenType
| twardoch.com | silesian.com | fontlab.net

Reporter: "So what will your trip to Ireland look like?"
Lech Wałęsa: "I get into a car, then onto a plane, and then the other
way around."

Received on Thursday, 4 March 2010 16:14:25 UTC