Re: Combining ZOT with .webfont metadata

On Jul 25, 2009, at 8:50 PM, Håkon Wium Lie wrote:

> A star indicates that the data also exists inside the TT/OT file. So,
> most of this information can already be coded into the TT/OT file.
> Redundancy is frowned upon in specifications: what do we do if there
> is a mismatch? Who is right? .webfont doesn't say anything about this,
> but since it doesn't demand any particular behavior from the UA, one
> can argue that it shouldn't matter to browsers.

Actually, we did specify this:

>    [3] In the case of conflicts between the data in the info.xml file
>        and the name table data in the wrapped font file, the data in
>        info.xml MUST take precedence.

As for the duplicated data, we recognize that some things can be  
located in the name table of OpenType fonts. The name table is not  
without problems itself. It has options for storing duplicate data for  
specific platforms and languages. We are trying to clarify this  
for .webfont.

Other formats may not include everything that the name table does. For  
example, I don't think SVG has much of this data at all. If other  
formats are covered, this data should move to a higher level.

> Some of the redundancy is shared with CSS; the @font-face declarations
> contain information about the format and the name of the font (to be
> used in 'font' and 'font-family'). What if there is a mismatch between
> the format declared in @font-face and inside the info.xml? The
> .webfont specification should specify who is right.

We think that the CSS would specify "webfont" as the format. The User  
Agent would look at the format specified in the info.xml and load it  
appropriately. We thought that this would actually make it easier for  
web authors. They wouldn't have to know the specifics about the core  
font formats.

> The .webfont proposal say that the
> creation date should act as a version identifier for the font. I think
> it's a poor version identifier. For example, if the time zone is off,
> is it still the same version?

The wording about <creationdate> was very clumsy. That's my fault.  
What I was trying to get at was that it could be a version identifier  
of the .webfont for the user, not the User Agent. In the case  
of .webfont, there is the possibility that a font vendor could be  
making these on the fly. We do a surprising amount of tech support for  
fonts and it's important to know exactly what version of the font the  
user is working with.

> And, are fonts really created within one
> minute? Doesn't it take years and years of efforts?

I think you are being cheeky, but I'll explain :-). Yes, the design  
phase can take years, decades even. But, the files themselves are  
software and we need to version them just as you would do for a  
release of Opera. Fonts go through revisions. A customer may come to  
me and ask for coverage for a language that was not supported in the  
initial version of the font. I may have missed a kerning pair. There  
could have been an undetected compiler error. Each of these require a  
revision that will bump the version number.

> Some of the elements in the info.xml sample file contain HTML markup.
> Is this generally allowed? All elements? Including <link> and
> <script>, with their obvious security concerns? The proposal doesn't
> say.

This is where we defer to the HTML experts here as it isn't our area  
of expertise. We did see some instances of this in at least one other  
proposal to the W3C. The basic idea is to provide richer information.

> So, I suggest that one (a) separates the semantics from the syntax in
> .webfont, and (b) come up with a proposal on how the semantics can be
> encoded within TT/OT. The resulting files can easily be encoded in
> ZOT. As such, this combines the best of both proposals.

This is an interesting idea. We're going to give it some serious  
consideration.

> One remaining argument for keeping the info.xml and its indirection is
> that it yields a solution independent of font formats; it can be used
> with any new format that may come along, or even an existing one like
> SVG. I don't think this is a strong argument. Popular new font formats
> don't show up too often.

If you get to worry about a hypothetical situation regarding the  
<allow> element, I think we should be allowed to worry about future  
font formats. :-)

Tal

Received on Sunday, 26 July 2009 18:18:02 UTC