Re: Authoring Tool Test Suite

On Mar 15, 2011, at 5:39 PM, Levantovsky, Vladimir wrote:

>> http://dev.w3.org/webfonts/WOFF/spec/#conform-compressedlarger 
>> 
>>> If the length of a compressed font table would be the same as or
>> greater than the length of the input font table, the font table MUST be
>> stored uncompressed in the WOFF file and the compLength set equal to
>> the origLength.
>> 
> 
> I think since this is a MUST, it needs to be tested. One possible way to do it (I am thinking out loud here) is e.g. to create a test TTF font with 'TZIP' (test zip) table with already compressed arbitrary data - something that, if compressed again, would guarantee to produce the compressed length same or greater than the original input.

I was thinking of something similar today. The SFNT could contain a table that consists of a single null byte. As best as I understand DEFLATE (which is not very much to be sure) the compressed form would always be larger than the original. The test cases documentation could explain that this one table should not be compressed in the WOFF.

>> http://dev.w3.org/webfonts/WOFF/spec/#conform-identical 
>> 
>>> The result of creating a WOFF file and then decoding this to
>> regenerate an sfnt font MUST result in a final font that is bitwise-
>> identical to the well-formed input font.
>> 
>> I suppose that for this one we can create one or more valid SFNT files
>> for an authoring tool to roundtrip. Is that the best way to handle this
>> assertion?
>> 
> 
> We don't really have a "WOFF decoder" as a standalone entity (other than it being part of a UA).

Right. What I was implying was that an encoder could also have a simple decoder for testing purposes.


I have most of the invalid SFNT files built and hopefully I'll have more done before the call tomorrow:

	http://dev.w3.org/webfonts/WOFF/tests/AuthoringTool/Tests/testcaseindex.xht

Tal

Received on Tuesday, 15 March 2011 23:09:01 UTC