Re: Combining ZOT with .webfont metadata

Also sprach Tal Leming:

 > > 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.

Indeed, I somehow missed this.

 > 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.

If so, the UA has to load the zip file before it knows if it can read
the format inside. This is not optimal; one of the purposes of the
format() construct is to allow UAs to skip unnecessary downloads.

 > > 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.

I agree that version numbers can be handy. But I don't think date/time
is a good version indicator.

 > > 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 :-). 

I was trying to be funny, but missed the smiley. Yes, I know, it takes
much efforts to create fonts. I've never completed any of my own
attempts.

 > > 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.

My advice would be to not allow HTML inside the elements.

 > > 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.

Great!

 > > 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. :-)

Deal.

One more idea. If you need to encode some inforamation and make it
very visible, the filename/URL can possibly be used. For example, you
could write:

  @font-face {
    font-family: foo;
    src: url(http://example.com/font-licensed-to-acme.zip);
  }

Not pretty necessarily, but very visible.

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Sunday, 26 July 2009 21:34:34 UTC