Authoring Tool Test Suite

Hello Everyone,

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.

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.

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?

---

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?

---

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

Received on Monday, 14 March 2011 15:45:19 UTC