- From: Jonathan Kew <jonathan@jfkew.plus.com>
- Date: Fri, 7 Aug 2009 18:13:07 +0100
- To: Laurence Penney <lorp@lorp.org>
- Cc: Tal Leming <tal@typesupply.com>, Erik van Blokland <erik@letterror.com>, www-font <www-font@w3.org>
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