In w3c/preload#118 there's a use case describing preloading of variable fonts only in supporting browsers. preload already has mechanisms to solve that, but they are based on MIME type, and AFAICT there's no MIME type defined for the variable font variants of WOFF2, TTF, etc.

Is it possible to define such a MIME type so that content negotiation or client-side preloading of the right font is possible?

/cc @svgeesus

Four of the six WOFF 2.0 candidate changes are typos, or obvious for-completeness things (Uint32). Two should be tested.

• Candidate Correction 1: for a typo no tests needed
• Candidate Correction 2: preserve optional symple glyph overlap flag
• Candidate Correction 3: definition of the UInt32 type was omitted no tests needed
• Candidate Correction 4: polarity of on-curve flag bit
• Candidate Correction 5: typo in list numbering no tests needed
• Candidate Correction 6: update IETF links no tests needed

From https://twitter.com/mikekasprzak/status/1484641859079229440

/facepalm

It took way too much of my day to learn that Variable OpenType fonts compressed in WOFF2 format are unsupported in FireFox.

Variable TrueType fonts in WOFF2, or uncompressed Variable OpenType fonts, no problem.

https://bugzilla.mozilla.org/show_bug.cgi?id=1302685

In section 5.1 of https://w3c.github.io/woff/woff2/: "wass encoded"

Other than declaring the version field to be present and set to zero, there is nothing in the WOFF2 recommendation about its purpose and / or intended use.
It is currently defined as Fixed version field, and we are planning to split it to two separate UInt16 fields: UInt16 version and UInt16 optionFlags. It would be logical to say something about how this version field is intended to be used.

1a. Read a UInt16 from compositeStream. This is interpreted as a component flag word as in the TrueType spec. Based on the flag values, there are between 4 and 14 additional argument bytes, interpreted as glyph index, arg1, arg2, and optional scale or affine matrix.

2a. Read the number of argument bytes as determined in step 2a from the composite stream, and store these in the reconstructed glyph. If the flag word read in step 2a has the FLAG_MORE_COMPONENTS bit (bit 5) set, go back to step 2a.

I think the first two references I've highlighted in bold are actually referring 1a, I'm less confident about the third one, but it might be in the same situation.

WOFF2 says

User agents supporting the WOFF2 file format for linked fonts must respect the requirements of the CSS3 Fonts specification ([CSS3-Fonts] Section 4.1: The @font-face rule). In particular, such linked fonts are only available to the documents that reference them; they MUST NOT be made available to other applications or documents on the user's system.

Maybe the link should be updated to [CSS Fonts 4]https://www.w3.org/TR/css-fonts-4/#font-face-rule) which has the same text:

Downloaded fonts are only available to documents that reference them. The process of activating these fonts must not make them available to other applications or to documents that don’t directly link to the same font. User agent implementers might consider it convenient to use downloaded fonts when rendering characters in other documents for which no other available font exists as part of the system font fallback procedure. However, this would cause a security leak since the contents of one page would be able to affect other pages, something an attacker could use as an attack vector. These restrictions do not affect caching behavior, fonts are cached the same way other web resources are cached.

No urgency, the text is the same, and CSS Fonts 4 is not a Rec.

In the WOFF File Format 2.0 the section that describes decoding of bounding boxes would benefit from its own subheading to distinguish it from the "Decoding of Composite Glyphs" section that precedes it.

Specifically, I recommend inserting a subheading "Decoding of bounding boxes" before the paragraph that starts:

Finally, for both simple and composite glyphs…

We can also remove the word "Finally".

Johannes Hägele wrote:

I'm currently reading and working with the WOFF2 Spec (https://www.w3.org/TR/WOFF2/)
In the spec you are working with the Data Type "UInt32" (for example at the WOFF2 Header section https://www.w3.org/TR/WOFF2/#woff20Header).
But in the section "Data Types" (https://www.w3.org/TR/WOFF2/#DataTypes) this data type is not specified.
I have also checked the WOFF1 spec and there it is specified. (https://www.w3.org/TR/2012/REC-WOFF-20121213/#OverallStructure)
Is this a mistake on your side (W3) or do i understand something wrong?

The most significant bit of a flag indicates whether the point is on- or off-curve point, the remaining seven bits of the flag determine the format of X and Y coordinate values and specify 128 possible combinations of indices that have been assigned taking into consideration typical statistical distribution of data found in TrueType fonts.

This does not indicate whether the bit is set or cleared to indicate whether the point is on or off curve. It turns out that it's actually cleared, which is opposite to the non-transformed glyf table.

From MicroType:

We use one bit of the first byte to indicate whether the point is an on- or off-curve point (if the most significant bit is 0, then the point is on-curve).

OpenType:

ON_CURVE_POINT | Bit 0: If set, the point is on the curve; otherwise, it is off the curve.

In the WOFF File Format 2.0 there are numerous references to "bit arrays" and one reference to "packed bit array".

However bit arrays are not well defined. Even if one understands the abstract concept of 8 bits packed per byte, one may yet wonder whether the bit with index 0 in the bit array is represented in the first byte as 0x01 ("bit 0") or 0x80 ("bit 7"). In fact the bit with index 0 in the bit array is represented as 0x80 ("bit 7") in the first byte, and successive right shift operations (>>) yield masks for subsequent bits in the byte.

Therefore, specifying how the bits within a byte are numbered will be useful, with an example. Also useful will be the formula to calculate the number of bytes required for n bits [ceiling(n/8)].

I therefore propose:

• add an entry in the "Data types" section "bit array"
• add a short definition: Encoding of a number of bits by packing them into a sequence of bytes
• add a long definition after the definition for "UIntBase128 Data Type": Bits are packed into a sequence of bytes, starting at the high bit of each byte, such that bit 0 is represented as 0x80, bit 1 as 0x40, bit 2 as 0x20, bit 3 as 0x10, bit 4 as 0x08, bit 5 as 0x04, bit 6 as 0x02, bit 7 as 0x01. Bit 8 is encoded in a subsequent byte, restarting at 0x80, and so on. To represent an array of n bits, the bit array occupies a sequence of ceiling(n/8) bytes, with unused bits set to 0.
• substitute "bit array" for "packed bit array" in the definition for bboxStreamSize

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?