Re: WebOTF Proposal

On 7 Aug 2009, at 20:15, Oliver Rigby wrote:

> On Fri, Aug 7, 2009 at 6:47 PM, Tal Leming<tal@typesupply.com> wrote:
>> The structure of the XML is more extensible than a binary table.
>
> It is.
>
> I just don't think licensing data is sufficiently complex that it
> needs such an elaborate extensible structured data format - I simply
> don't think it justifies the extra complexity over a pure binary file
> format.

If we do a pure binary format, we'll be debating exactly what to  
include or exclude for the next N months, where N is a painfully large  
number. Using the more flexible XML approach allows us to avoid much  
of that pain.

>
> And if it _is_ necessary, I don't see why we shouldn't go the whole
> hog and make the whole format, including the header, XML-based,
> therefore gain the advantages of XML for the whole format - a format
> that would be better structured, human readable, and be more
> extensible and future-proof.

The header and table directory are binary for the sake of efficiency:  
accessing the actual font data is on the critical path for browsers  
when they are rendering pages, and people complain about milliseconds.  
The binary header can be handled faster, and with far less code, than  
an XML equivalent.

Accessing the metadata is not time-critical, so here we can favor  
flexibility over raw machine efficiency.

>
> Personally, I think this is a middle-ground compromise which gets the
> worst of both worlds.

As suggested above, I think many of us consider that it offers the  
*best* of both worlds.

> By making it binary, it's not human-readable and
> you need a specialised tool to make the fonts. By including XML, font
> makers need XML parser and read an XML doctype,

The alternatives are either a rigidly-defined binary format that  
doesn't need "parsing", or some other flexible format that still needs  
parsing, and if it's an ad hoc "simple" syntax then it's more likely  
there will be anomalies in parsing than if we use XML, for which there  
are mature, well-tested parsers readily available.

> as well as increasing
> the barriers to reading/writing metadata which may discourage people
> supporting it at all, which would be the opposite of the intention.

No matter what format we come up with, there needs to be a tool (or  
several tools, for different types of workflow) to make it easy for  
people to create. My sfnt2webotf command-line tool allows you to  
specify an arbitrary XML file to embed as metadata, but I expect  
someone will build a user-friendly WebOTF Metadata Editor for those  
who prefer that kind of interface.

JK

Received on Friday, 7 August 2009 19:58:08 UTC