RE: Authoring Tool Test Suite

On Monday, March 14, 2011 11:45 AM Tal Leming wrote:
> 
> I'm beginning work on the Authoring Tool test suite and I have some
> questions. I've been reading over the spec and looking at the test plan
> on the wiki (http://www.w3.org/Fonts/WG/wiki/TestPlan-AuthoringTool).
> Below is a list of the assertions in the spec along with ideas and/or
> questions about how to test them.
> 
> 
> 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.

> http://dev.w3.org/webfonts/WOFF/spec/#conform-uncompressed 
> 
> > Tools MAY also opt to leave other tables uncompressed (e.g. all
> tables less than a certain size), in which case compLength will be
> equal to origLength for these tables as well.
> 

IMO, we can leave this out of the test suite - this requirement is MAY and cannot really be tested.
 
> http://dev.w3.org/webfonts/WOFF/spec/#conform-ascending 
> 
> > WOFF-producing tools MUST produce a table directory with entries in
> ascending tag value order.
> 
> I'm not sure how to create test cases for these three. They are about
> the results of a conversion to WOFF. The compression variability means
> that we can't provide a pairs of SFNT and expected WOFF for binary
> comparison. So, I'm not sure what we can do apart from listing these
> requirements in the spec. Any ideas on how we can provide tests for
> these?
> 

Let's discuss this tomorrow

> ---
> 
> 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). One way to solve this issue is to offer a reference decoder (e.g. woff2sfnt) as part of the test suite, so that output of authoring tools can be verified against it.

> ---
> 
> http://dev.w3.org/webfonts/WOFF/spec/#conform-checksumvalidate 
> 
> > Tools producing WOFF files MUST validate these checksums, and reject
> the font if errors are found.
> 
> This is easy to test. Test cases:
> 
> 	invalid checksum for one table
> 	invalid checksum adjustment in head table
> 
> ---
> 
> http://dev.w3.org/webfonts/WOFF/spec/#conform-incorrect-reject 
> 
> > If the input font has defects or anomalies that make this impossible,
> the WOFF-generating tool SHOULD either reject the font or issue an
> appropriate warning that lossless round-trip conversion will not be
> possible.
> 
> This one is easy. We just need invalid SFNT data. This is what I can
> think of:
> 
> 	padding
> 		padding that does not result in a four byte boundary
> 		padding that exceeds three bytes
> 		padding that is not null
> 		final table is not padded
> 	hidden data
> 		data between properly padded tables
> 	overlapping blocks
> 		two table data blocks overlap
> 
> Can anyone else think of any other things that would make an SFNT
> invalid for conversion?
> 
> 
> Any advice would be appreciated.
> 
> Tal
> 

Thank you,
Vlad

Received on Tuesday, 15 March 2011 21:39:44 UTC