Re: Telcon today!

On Wed, Mar 22, 2017 at 07:35:59PM +0000, Levantovsky, Vladimir wrote:
> Ok, guys - considering the four regrets I've got in response to my telcon announcement, let's postpone it for one more week until Wed., March 29. This will be our last chance to talk in March (duh! :), and then I am out traveling for almost the whole month of April.
> 
> Some observations on the test results that exhibit abnormal uniform failures:
> Test Case: tabledata-glyf-bbox-003<http://test.csswg.org/suites/woff2_dev/nightly-unstable/html/tabledata-glyf-bbox-003.htm> - failures are reported on all UA platforms but this is strictly an encoder / AT test, where the test condition is only dependent on the input font data. I think running this test on UA platforms is by itself an error.
> Test Case: tabledata-bad-origlength-loca-001<http://test.csswg.org/suites/woff2_dev/nightly-unstable/html/tabledata-bad-origlength-loca-001.htm>, tabledata-bad-origlength-loca-002<http://test.csswg.org/suites/woff2_dev/nightly-unstable/html/tabledata-bad-origlength-loca-002.htm> and tabledata-transform-hmtx-003<http://test.csswg.org/suites/woff2_dev/nightly-unstable/html/tabledata-transform-hmtx-003.htm> - need further investigation (verify the input data, check that the WOFF2 test files are correct, etc.). The tests themselves (and the normative requirements we test here) seem to be pretty simple and straightforward, I wonder if this is just a case of bad data.

In tabledata-transform-hmtx-003 we are testing that when the reserved
bits (2-7) of the transformed hmtx flags are set the font should be
rejected. I double checked and the value is 255 so all bits are indeed
set. Looks like the reference implementation does not check for this.
Actually I already reported this back in August:
https://github.com/google/woff2/issues/55

It looks like tabledata-bad-origlength-loca-001 and 002 are already
reported as well:
https://github.com/google/woff2/issues/53

Regards,
Khaled

Received on Thursday, 23 March 2017 07:45:22 UTC