w3c
Clarify WOFF2 header majorVersion and minorVersion
In the WOFF File Format 2.0 we find the following field definitions in the WOFF2 Header:
UInt16 majorVersion: Major version of the WOFF file. UInt16 minorVersion: Minor version of the WOFF file.
It is nowhere explained how to set these fields, nor how to interpret them. One might guess that majorVersion should be 2, from the name WOFF2 and from the fact that CFF2.majorVersion=2. Alternatively, one might wonder if the font maker is free to set them arbitrarily to refer to the version of the font itself.
From an inspection of existing fonts, the fields seem always to be set to 1 and 0 respectively. @vlevantovsky confirms to me (personal email) that they "are woff2 format versions, and are completely different from the whatever version numbers are associated with the payload of woff2 file".
Therefore I propose the following change:
UInt16 majorVersion: Major version of the WOFF file: 1 for current version. UInt16 minorVersion: Minor version of the WOFF file: 0 for current version.
It should also be clarified what a font reader is supposed to do when if finds values other than 1,0. Should the font be rejected?
This comment seems to have fallen through the cracks, sorry @Lorp
The proposal (for current values) seems good to me, what do you think @vlevantovsky @garretrieger
We could put this as a Candidate Correction in the WOFF2 spec (which will, hopefully, be published in a few weeks with the old PC1 and PC2 rolled in).
We have not had any discussion on existing behavior and desired behavior when other values are encountered.
I agree that we should say that the majorVersion = 1 and minorVersion = 0 for the current version of the WOFF2 spec.
Agreed, if existing encoders are using major 1, minor 0 let's put that in the spec.
Do existing decoders fail on majorVersion = 1 and minorVersion = 1 or majorVersion = 2 and minorVersion = 0? Should they? This would be a new normative requirement.
The Google decoder implementation just ignores the fields: https://github.com/google/woff2/blob/master/src/woff2_dec.cc#L1104
So I don't think we'll want the spec to require failure if they are not 1.0
The Google decoder implementation just ignores the fields:
That’s a shame and means the fields are useless. In principle, unknown major version fields should always fail, shouldn’t they?
I worry that since we didn't specify what they should be set too, and the existing decoders don't care what they are: we now can't guarantee what version numbers are currently in use in existing encodings. If we start enforcing them we may break existing encodings if they aren't using 1.0.
Yeah, in general I would normally expect the decoder to fail on an unknown major version number.