RE: Last call comments on WOFF

Hello Bert,

Thank you very much for your comments.

On Wednesday, January 12, 2011 10:16 AM Bert Bos wrote:
> 
> Hello Fonts WG,
> 
> Here are my personal comments on the last call for
> http://www.w3.org/TR/2010/WD-WOFF-20101116/

> 
> 1) I'd like to say one more time that letting a URL carry information
> about the meaning of a resource is counter to W3C's common
> architecture for the Web and simply a bad idea. If I move a file to a
> different server (and hopefully leave a redirect behind), the file
> still means the same thing. If I distribute it over p2p, on a CD, or
> coin a URN for it, it is still the same file and should not act any
> differently. Going against this architecture *will* lead to problems.
> 
> And it's not like we don't know how to do it right. The way to encode
> usage metadata for fonts, in a protocol-independent and machine
> readable way, was invented by Microsoft for EOT more than ten years
> ago. The exact syntax doesn't matter, but the data has to be at the
> application level, not in the URL and not in the protocol.
> 

Can you please provide specific references to those parts of the spec that you believe the comment is relevant to? AS it is, the comment seems to be rather general and it is not clear on what particular changes you would like to see in the spec.

> 2) I like the clear and careful language in the introduction. (So
> this is not an issue, not even a criticism, but it *is* a
> comment. :-) ) Especially the way it explains what WOFF is not (a new
> font format), and what it is for (@font-face).
> 

Thank you.

The WG will discuss your comments during the telcon on Jan. 26th (i.e. today in your time zone). If you could please provide any additional clarifications before the call, it would be greatly appreciated.

Best regards,
Vlad


> That doesn't meant there will be no confusion, but I think the spec
> does as well as it can. EXI can explain that it is just XML with a
> syntax optimized for streaming, but people still see it as a new
> format. With WOFF it will be the same.
> 
> 3) Section 7 Private date block: Why is the padding at the end a
> "should"? I could understand "must" (something you can test), or
> "may" (just ignore it). But if you are going to ignore the padding
> anyway, why should generators try hard to not write it? Ditto for the
> padding of the extended metadata block.
> 
> It is also ironic that the specification accuses the OpenType spec of
> not being clear about the padding of the final table, and then itself
> allows that padding to vary. (Sure, WOFF is not _unclear_, but the
> effect is the same. Imagine that some future Meta-WOFF wants to
> encode WOFF: it will have the same problems as WOFF in ensuring
> roundtrip encoding...)
> 
> Which means that a "must" seems the best choice. Whether it is "must
> be omitted" or "must be included" is less important, although doing
> the same for all blocks, whether the last or not, seems easiest.
> 
> 4) Section 6 Extended metadata: If it is in XML and is metadata, it
> would seem logical to have chosen XMP. Existing XMP and RDF tools
> would be able to read it, no need for new parsers; it could be linked
> to other RDF ontologies, to enable Semantic Web tools to make
> inferences; and it would be extensible without the need to have
> different syntaxes for predefined and extended elements.
> 
> 5) Section 4 / section 8. I like the rigorous error handling: if the
> decompressed length is not what was declared as origLength, the file
> _must_ be rejected. No attempts to second-guess what the encoder
> "intended" to do.
> 
> On the other hand, it's a bit wasteful to use four bytes to store an
> origLength. One bit to indicate compression would have been enough.
> There is no actual need to check the length, because there is already
> a checksum.
> 
> 6) A context-free grammar for WOFF in the spec would have been nice,
> even if there are long-distance dependencies a CFG cannot express
> (such as that some number must correspond to the number of bytes
> somewhere else). A grammar gives a concise view of the structure of a
> file, better than the English text can, and thus helps programmers.
> 
> 7) Is there really an advantage to aligning tables to 4-byte
> boundaries? It's another bit of extra work for a generator, another
> place where a programmer can make mistakes.
> 
> 8) Section 4: It is a pity that there are multiple ways to encode the
> same font, and even to encode the same OpenType file: each table
> may be compressed or not, extended metadata may be added or not,
> private data may be added or not. That means you cannot do a simple
> binary compare to see if two files encode the same OpenType file, let
> alone the same font. A unique (canonical) format would also have
> helped with digital signing: Now it is possible to decode and re-
> encode the font without doing anything else and still end up with a
> broken digital signature.
> 
> Is there an advantage to having different ways to encode the same
> OpenType file?
> 
> 9) The specification is called "1.0" but the actual format contains
> neither a version number, nor a way to define extensions. It is
> probably a good thing that there is only one WOFF format. It means
> that a correct implementations cannot be incompatible with another
> correct implementation, just because one was written later than the
> other. But why then is there that "1.0" in the title of the spec?
> 
> (The optional metadata has a version. Is that what the "1.0"
> corresponds to? Although that part of the file can be ignored by many
> kinds of implementations, it is still a pity that there can, in the
> future, be different formats that are all called WOFF, with the same
> file extension, the same magic string, and, probably, the same MIME
> type.)
> 
> 10) Section 8: I didn't check that the summary is indeed compatible
> with the earlier sections, but it is clear that it contains some
> things that were already said earlier. I get uncomfortable when a
> spec repeats things in a normative section. There is almost certainly
> a contradiction somewhere. And if not now then in the next version of
> the draft. Shouldn't this section be labeled as informative instead?
> 
> 11) Section 8: The note about "extra" data in OpenType files between
> the tables doesn't seem to belong in this section. It doesn't explain
> anything about the conformance of WOFF files. It relates to
> roundtripping, and while an interesting remark in itself, it was
> already mentioned earlier.
> 
> 
> 
> Bert
> --
>   Bert Bos                                ( W 3 C ) http://www.w3.org/

>   http://www.w3.org/people/bos                               W3C/ERCIM
>   bert@w3.org                             2004 Rt des Lucioles / BP 93
>   +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Wednesday, 26 January 2011 02:02:24 UTC