Potential conformance statements in WOFF2, sections 1 to 3

Hello,

Here are the statements that I have found in WOFF2 (18 Aug ED) that
could be changed to be conformance statements

3.
"The data for the tables is compressed in a single stream comprising all
the tables."

I didn't find "single stream" anywhere else in the spec, and this is a
change from WOFF 1.0 where each table was compressed separately.

Suggest [FF]

"Unlike WOFF 1.0 which uses per-table compression, in WOFF2
the data for all the tables MUST be compressed in a single stream."

3.1. Data types, 255UInt16 Data Type
"An encoder may produce any of these"

This is checkable by a validator so should be marked as [FF] normative.

An example of a test would be two fonts, one of which expresses a
value < 253 as, for example

code: 123
and another which uses the longer but allowed form
code: 253
value: 123

the validator passes if both fonts are checked as valid.

3.1. Data types, 255UInt16 Data Type
"encoders should choose shorter encodings, and should be consistent in
choice of encoding for the same value"

The two "should" statements are not obviously testable in a
pass/fail sense, only in a warning sense. If we want to do warnings,
that would be [FF].

3.1. Data types, UIntBase128 Data Type
"suitable for values up to 2^32-1"

Thus, since 7 bits per byte are used for all but the last byte, the
the maximum length would be 32/7 = 4.57 = 5 bytes, right? If so, add
[FF]

"A valid UIntBase128 encoded form MUST take up one to five bytes."

Test with a UIntBase128 of six bytes, first five all have MSB set,
sixth has MSB unset. It is too long so
[FF] a validator passes if it checks the font as invalid
[UA] a UA passes if it does what? Discuss.

We clearly need some conformance statement on what a UA does when the
input contains an invalid UIntBase128 form. As far as I can see, too
long is the only detectable error condition.

What does the deployed code in Chrome do when this happens?

Our options are the "must catch fire" halt on error, and the "silent
hiding of errors" recovery (for example, always treat the fifth byte
as if MSB was unset). I'm not a fan of silent recovery for decoders
because it encourages sloppy encoders.

However, we could define this as a feature rather than as error
recovery - if the sequence is already four bytes long, since the max
length is five bytes we always know that the next byte is the last so
we ignore the MSB. Thus, MSB unset in bytes one to four is an "early
termination" flag.

3.2. WOFF2 Header
Some of the header values are constants which must have that value
(e.g. signature). That one is easy to check. In WOFF 1.0 we had

[FF]"The signature field in the WOFF header MUST contain the "magic
number" 0x774F4646." [UA] "If the field does not contain this value,
user agents MUST reject the file as invalid."

Suggest adding the same two statements here 9with updated magic
number).

Some are enumerations which depend on what the OFF spec says and may
change over time (e.g. flavor) so a validator could warn but not
provide an error. WOFF 1.0 had some language for flavor which could be
used unchanged here. it doesn't add any conformance statements, just
clarity on the allowed values.

Some are computed values (length, numTables) which could be checked
against the decoded font. However, glyf and loca transformations
complicate this checking. The offsets to the metadata and private
blocks could usefully add the conformance ststements from WOFF 1.0:

[FF] "If either or both of the metadata or private blocks is not
present, the relevant offset and length fields MUST be set to zero"
[UA] "If the metadata or private data offset and length fields
indicate byte ranges that overlap other data blocks or tables, or
extend beyond the end of the file, a conforming user agent MUST reject
the file as invalid."

Also good to add from WOFF 1.0:
[FF] "The header includes a reserved field; this MUST be set to zero."
[UA] "If this field is non-zero, a conforming user agent MUST reject
the file as invalid."

What does the deployed Chrome code do if reserved is non-zero?

I have seen other standards that failed to defend their reserved
values, which meant they could not be relied upon for later expansion.
So I suggest continuing to make non-zero reserved an error, as with
WOFF 1.0.

(later sections in a subsequent mail)



-- 
Best regards,
 Chris                          mailto:chris@w3.org

Received on Tuesday, 19 August 2014 17:22:35 UTC