Reading the
OpenType Font Variations Overview today to get my head around the new shiny, I noticed a number of oddities:
Introduction:
Each axis is defined by a numeric range, using 16.16 floating values.
If you know 16.16 is a data representation format, (called "Fixed" in the rest of the specification) this makes sense. It took me a moment to realise this is what it meant. Are there 16 values in the range?
AFAICS, Fixed numbers are only used as version numbers in the other tables. So maybe this could be clearer. Something like "a numeric range of three values, each represented as 32-bit fixed-point numbers."
Conceptually, this provides a continuous gradient of variation, a allowing for
Extraneous "a".
So, for instance, if a user or application requires a very-slightly narrower width or slightly more pronounced serifs, fine control over such axes of variation is available.
This sentence should be taken out and shot.
Coordinate Scales and Normalization:
Positions within the variation space can be represent as an n-tuple
Should read "represented"
Variation Data Tables and Miscellaneous Requirements
On certain platoforms, bit 5 affects metrics in vertical layout
Should read "platforms".
Comments
Interpolation example
I got confused trying to replicate this example, because: there isn't a hyphen-minus; hyphen and minus are different characters; hyphen is glyph ID 337, and has 26 points; minus is glyph ID 369, and has four points but they're not in the right place for the example. Glyphs 45 is actually
hyphen.oldstyle
, and is the one the example refers to.Sorry, they keep coming. This one's a genuine bug, though, not just a confusion:
Coordinate Scales and Normalization
Variable name alternates between
axisDefault
andaxisDefaultValue
; should be identical. (Also, and this is really persnickety, some of those minuses are actually en dashes.)Algorithm for Interpolation of Instance Values
In Skia.ttf, the cmap tables map U+002D to hyphen.oldstyle, that is the hyphen-minus being referred to as you discovered.
I guess the glyph name could be used instead of the Unicode character name to avoid this kind of confusion.
3. Data Types
In Table 2, the definition of Card32 is missing.D3. Top DICT Data
FontMatrix
CharStringType
CharStrings
FDArray
FDSelect
[...] The ROS used should be Adobe-Identity-1. [...]
- Terminology section: "Opentype" s/be "OpenType".
- "arbirtrary" s/be "arbitrary".
- pseudocode for interpolation algorithm should include some blank lines
- "supressed" s/be "suppressed"
- "Major version number of the metrics variations table..." s/be "... of the horizontal metrics variations table..."
- ditto for minor version field description
The same typos exist in vvar.htm as well.
- "antialising" s/be "antialiasing" (2 instances)
- "correspondence" s/be "correspondence"
Typos in gvar.htm:
- "argument1 (Y offset)" s/be "argument2 (Y offset)"
- In the table for the AxisValueFormat3 format, "Format identifier — set to 1." s/be "Format identifier — set to 3."
- In the note after the table for the ValueRecord format, "variations fonts" s/be "variable fonts".
- In the paragraph before the table, "wihtin" s/be "within".
- Missing period at the end of the paragraph before the table.
11. Font DICT Index, Font DICTs and FDSelect.
[...]
Card16 sentinel Sentinel GID (see below)
[...]
Card32 sentinel Sentinel GID (see below)
ping @Read Roberts
innerIndex = entry & ((1 << (entryFormat & innerIndexBitCountMask)) – 1)
s/be
innerIndex = entry & ((1 << (entryFormat & innerIndexBitCountMask)) – 1) + 1
Note that what the text says is (emphasis added), "This example is based on glyph 45 of the Skia font, which is the glyph for the hyphen-minus character."
By giving the glyph ID and the Unicode character name of the codepoint that maps to that glyph, I thought it would be sufficiently clear, but perhaps not? Additional things I could do to avoid confusion would be to specify the glyph name and the Unicode code point:
"This example is based on glyph 45 of the Skia font (glyph name "hyphen.oldstyle"), which is the glyph for the character U+002D HYPHEN-MINUS."
Is that worth changing?
"The width field is a packed field that describes the compressed representation used in the given deltaSetIndexMap table. The format of the width field is as follows:"
The name "width" s/be "entryFormat".
outerIndex = entry >> ((entryFormat & innerIndexBitCountMask) + 1)
innerIndex = entry & ((1 << ((entryFormat & innerIndexBitCountMask) + 1)) - 1)
Some of the items that have been called out in this thread are a bit more substantive and will be addressed in a future, versioned update.
2.3 Subroutines
The Type 2 operators endchar and return are removed in the CFF 2 CharString.
Appendix A. CFF 2 Charstring Command Codes
axisValueOffsets[axisValueCount] is defined as USHORT, but there is an specific type of the same size 'offset' that is used in other places in this situation.
Can a blended result used as a parameter in a new <blend> operator?
See OpenType 1.8 errata for details.
An error in the ‘avar’ table chapter of the OT spec was just pointed out: the axisCount field was defined in OT as uint16, which matches what is used for the corresponding field in the ‘fvar’ and ‘gvar’ tables in both OT and Apple’s TrueType spec. However, Apple’s ‘avar’ table spec used int32 for the axisCount field — I assume this was done to provide four-byte alignment of header fields. This was not noticed when the ‘avar’ chapter for the OT spec was drafted. But clearly compatibility with Apple’s ‘avar’ spec is necessary.
We’ve published errata for OT 1.8 and OT 1.8.1 with a correction for this issue.
https://www.microsoft.com/typography/otspec/errata.htm
https://www.microsoft.com/typography/otspec180/errata.htm
The feature friendly name is recorded as 'Medial Form #3'
SHOULD BE 'Medial Form #2'