Re: WebOTF Proposal

Thanks for the comments, Laurence; some initial thoughts in response:

On 7 Aug 2009, at 17:06, Laurence Penney wrote:

> Tal, Erik, Jonathan,
>
> This is a very useful development.
>
> After a quick digestion, I suggest four modifications:
>
> 1. Add a Version field to indicate in which version of the .webotf  
> format the font is encoded.

I considered this, but wasn't sure it's really needed or helpful when  
the format is designed to be such a close packaging of OpenType. If we  
do find it necessary to revise it at some point in the future, this  
can be indicated by a new "signature" value just as easily as with a  
separate version number.

Perhaps the most likely revision would be to allow a different  
compression algorithm, such as xz, if it is felt to be sufficiently  
stable and well-tested, and gives enough benefit to be worth the added  
complexity of supporting it. But as user agents would have to be  
updated to support this (or any other) revision to the format, it  
might as well be marked with a new signature such as 'wOT2' or 'xOTF'.  
If you like, consider that the signature field *is* the format version  
number. :)

> 2. Add an 'id' attribute or element in the <license> element. Of  
> course this can be encoded in the private data, but openly  
> identifying the contract under which the font is published seems  
> desirable for commercially licensed fonts - just as the Ordnance  
> Survey requires licensees to note their license number on each map  
> publication.

That sounds fine to me.

> 3. Allow compLength to be *any* number higher than origLength for  
> uncompressed tables (e.g. 0xffffffff) to allow slightly faster  
> dynamic .webotf generation.

I don't see the benefit of this; the cost of storing the correct value  
is negligible, surely.

> 4. Replace the Private Data block with an optional <private> element  
> in the metadata, which might contain regular text or base-64 encoded  
> blobs (zipped, it won't take up any more space than the existing  
> proposal).

That would be a possibility, but adds some extra complexity for users,  
who have to ensure their Private Data is valid XML (via base-64 or  
whatever, if necessary). I suppose we could have API that *always* b64- 
encodes the data that is given, then stores it in <private>, which  
then gets zipped, but it seems like a roundabout way of doing things.

>
>
> The abandonment (compared with .webfont) of format neutrality needs,  
> I think, some discussion. Let me kick off.
>
> PRO
> A good argument for abandonment is that .webotf is, quite simply, a  
> way of packaging OpenType fonts for the web. That's why it  
> (deliberately?) does not declare the format of its contents.

You mean that it does not discuss the actual content of the OpenType  
tables? True; though it does declare (in the "flavor" field) whether  
it contains TrueType or CFF data. Perhaps the best way to think of it  
is by comparison to the sfnt format; webotf is simply an alternative  
way of storing a collection of OpenType tables in a file, designed to  
be more compact (by compressing the "raw" table data) and allowing a  
couple of additional data blocks to be attached, separate from the  
"namespace" of OpenType table tags. That's all it is.

> It will be much easier to declare that a UA supports .webotf if the  
> "flavours" of .webotf are kept to the minimum, i.e. OpenType/ 
> TrueType. If implementation of some .webotf flavours were optional,  
> then it would be more difficult for foundries to license and for  
> webmasters to deploy web fonts. Restricting .webotf to OpenType/ 
> TrueType makes it a simple bolt-on to an OS's existing font system.
>
> CONTRA
> It seems a shame to disallow font formats other than OpenType,  
> stifling innovation at a point when innovation may be usefully snuck  
> in.

You can't "sneak in" innovation just by letting the file format carry  
a different payload. You have to upgrade the font engines on the  
target systems, and that's a whole separate matter.

> For example, would it be possible to allow for Fontlab's PhotoFont  
> in a slightly modified format? Multiple files would, at least, need  
> to be handled. How easily could this be accomplished? Note that the  
> method of using table names to refer to blobs is not far removed  
> from using filenames to point to blobs. A fairly simple change to  
> the format could facilitate arbitrary filenames:
> * Have a new 'strings' part of the file, consisting of concatenated  
> null-terminated UTF-8 strings.
> * For OpenType fonts, store the 4-character table names in this  
> 'strings' data block; in the Table directory, instead of the table  
> names, store UInt32 byte offsets into the 'strings' data.
> * For fonts consisting of multiple files, again use the Table  
> directory to point to data blocks, one per file, and use the 'tag'  
> to point to a byte offset in the 'strings' data where the filename  
> may be found (e.g. uppercase/A.png, uppercase/B.png, lowercase/a.png).

But allowing the format to contain arbitrary types of font file will  
not magically make those fonts work anywhere, and making them do so  
will require just as much extra work in browsers (or operating  
systems, or both) as supporting them via a separate file type.

It seems to me that with OpenType being a pretty well-defined and  
universally-supported format, it will only confuse things if we invent  
a "web font" that may embed OpenType -- and so ought to work anywhere  
-- but may also embed various quite different kinds of font, which may  
or may not be supported by any particular UA/OS. Better, IMO, to  
define something like WebPhotoFont (for example) as a distinct font  
type; then it's easy to state clearly what a given system supports. Of  
course, following the general pattern of WebOTF to create a  
WebPhotoFont format would be fine. But let's not try to turn WebOTF  
into some kind of "universal" container.

(Actually, one approach would be to define an sfnt packaging of  
PhotoFont, using some new OT table tags and a new OpenType version.  
For a trivial approach, just zip up the directory of files, and store  
it in a 'zPHF' table. Then WebOTF will automatically be able to  
package this, it will just have a new "flavor" value. In fact, the  
tools I've just been writing today would already handle it fine,  
though they'll print a warning if the OT version is not recognized.  
But none of this packaging trickery will cause the underlying  
rendering systems to support the new font data, so unless this is  
agreed by the various parties implementing rasterizers and text layout  
systems, it's rather pointless.)

Another reason to keep things separate (at the "web font format"  
level) is so that @font-face rules can provide format hints, and  
browsers can avoid downloading resources that they're not going to be  
able to use anyway. If you package all the world's font types inside a  
single "wrapper" format, the browser has to download the file in order  
to check what kind of payload it has, only to find that it's not  
actually usable. Personally, I'm inclined to think it's an unfortunate  
result of history and politics that we have both TrueType and CFF  
fonts in the "same" format (.otf), but we're clearly stuck with that.

JK

Received on Friday, 7 August 2009 17:18:01 UTC