RE: Fonts from EBUP3 test suite violating WOFF 1.0 spec

Thanks Vlad,

I looked for discussion like that, but somehow missed it. I am fine with fixing Edge. Although I would prefer description explicitly describing two allowed scenarios, I‘ll not insist in making changes to the spec.

But said that, W3C WOFF validator (http://dev.w3.org/webfonts/WOFF/tools/validator/validator.py) is still marking this as an error at line 824. This should at least be fixed and tests checking both situations are needed in test suite.

Thanks,
Sergey

From: Levantovsky, Vladimir [mailto:Vladimir.Levantovsky@monotype.com]
Sent: Friday, January 29, 2016 7:49 AM
To: Sergey Malkin <sergeym@microsoft.com>; public-webfonts-wg@w3.org
Subject: RE: Fonts from EBUP3 test suite violating WOFF 1.0 spec

Hi Sergei,

Thank you for bringing this up to WG attention.
The WG has actually discussed this at length back in November 2010 - see the email thread [1]. Our initial intent was to apply MUST for padding when the private data block is present and no padding when the metadata is the last block in a WOFF file, however, following the discussion on the list and after discussing the OT table padding behavior we decided during the telcon [2] to “fix” that (which was captured as action 41 [3]). The agreement was that by changing MUST to SHOULD we would give certain flexibility to tool vendors and allow up to three bytes of padding if tools are designed to always add padding to OT tables (as OT spec recommends) and apply the same behavior to metadata section. The test for this conformance case checks for extra [unnecessary] padding and rejects the file as invalid if padding is in excess of three bytes.

I believe that the spec, as it exists right now, offers sufficient amount of flexibility and, at the same time, provides clear guidance of what is expected as far as padding is concerned – see the second paragraph in section 8 [4]. I think that changing the IE and Edge behavior to allow up to three bytes of padding would be the right way to fix the issue you encountered and I don’t think that any additional spec changes are needed to address this.

Thank you,
Vlad

[1] https://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/0020.html

[2] https://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/0033.html

[3] https://www.w3.org/Fonts/WG/track/actions/41

[4] https://www.w3.org/TR/WOFF/#Private



From: Sergey Malkin [mailto:sergeym@microsoft.com]
Sent: Thursday, January 28, 2016 7:01 PM
To: public-webfonts-wg@w3.org<mailto:public-webfonts-wg@w3.org>
Subject: Fonts from EBUP3 test suite violating WOFF 1.0 spec

Hi,
It was brought to my attention that some fonts that are part of EPUB3 test suite (http://epubtest.org/testsuite/, test 0103) are violating WOFF 1.0 specification. In particular, there is extra byte of padding after metadata block at the end of the file. Spec says that: “If the metadata block is the last block in the WOFF file, there SHOULD be no additional padding after the end of the block”.

For some reason we’ve chosen to use SHOULD for padding after metadata, but I don’t see any discussion specifically about it. Apparently this is the only SHOULD in the spec in relation to enforcing WOFF structure by user agents, everything else I see uses MUST. Test blocks-extraneous-data-006 checks if font is rejected when there are 4 bytes of padding after metadata, but font in question has only one.

IE and Edge are rejecting the font based on this requirement, but Chrome and Firefox don’t. Do you think Edge is too strict rejecting the font or spec can be changed to MUST in this case?
If yes, should spec be changed to explicitly make padding of metadata to 4-byte boundary optional? This look more realistic than making spec stricter. I am fine with relaxing our code if this is the case, but I would like spec to be clear on this first.
If not, can we make this requirement MUST in the spec and add additional test checking for that? And will Firefox and Chrome plan to fix their code to reject such fonts? This would also require EPUB test suite to be updated with valid fonts.

Thanks,
Sergey