[OTVar] Typos and editorial issues with OT 1.8

Simon Cozens

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".

Hin-Tak Leung

@Simon Cozens  - the Opentype list is subscriber-only, but you could e-mail your comments to both the microsoft typography website comment address, as well as the mpeg discussion group list on yahoo (the Opentype iso standard is part of the mpeg bunch of standards). Many people who are on the editorial of the Opentype spec are on these 3 addresses/lists.

Peter Constable

Reporting OT1.8 typos in this thread will work fine.

Simon Cozens

Interpolation example

This example is based on glyph 45 of the Skia font, which is the glyph for the hyphen-minus character.

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.

Simon Cozens

Sorry, they keep coming. This one's a genuine bug, though, not just a confusion:

Coordinate Scales and Normalization

if (userValue < axisDefaultValue)
{
    normalizedValue = -(axisDefault - userValue) / (axisDefault – axisMin);
}
else if (userValue > axisDefaultValue)
{
    normalizedValue = (userValue – axisDefault) / (axisMax – axisDefault);
}

Variable name alternates between axisDefault and axisDefaultValue; should be identical. (Also, and this is really persnickety, some of those minuses are actually en dashes.)

Simon Cozens

And another:

Algorithm for Interpolation of Instance Values

Let d be the delta value in the variation data associated with a given region,

The variable used in the pseudocode is "delta", not "d".

Denis Moyogo Jacquerye

@Simon Cozens

there isn't a hyphen-minus

There is, it’s U+002D HYPHEN-MINUS in Unicode.
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.

Masaya Nakamura

I found some editorial issues in CFF 2 table, so I'd like to report them:

3. Data Types

In Table 2, the definition of Card32 is missing.

D3. Top DICT Data

The allowed operators are:
    FontMatrix
    CharStringType
    CharStrings
    FDArray
    FDSelect

While CharStringType is listed here, there is no descriptions for this operator elsewhere. It also appears in the code in 10. Local/Global Subrs INDEXes.

ROS 12 30 SID SID number
[...] The ROS used should be Adobe-Identity-1. [...]

It means Adobe-Identity-0?

Peter Constable

Typos in otvaroverview.htm:

- Terminology section: "Opentype" s/be "OpenType".
- "arbirtrary" s/be "arbitrary".
- pseudocode for interpolation algorithm should include some blank lines

Peter Constable

Typos in stat.htm:

- "supressed" s/be "suppressed"

Peter Constable

Typos in hvar.htm:
- "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.

Peter Constable

Typos in merg.htm:
- "antialising" s/be "antialiasing" (2 instances)

Peter Constable

Typos in fvar.htm:
- "correspondence" s/be "correspondence"

Typos in gvar.htm:
- "argument1 (Y offset)" s/be "argument2 (Y offset)"

Peter Constable

In the delta version of post.htm, the Note in the "'post' Table and OpenType Font Variations" section should be highlighted.

Peter Constable

Another typo in stat.htm (should be a technical corrigendum):

- In the table for the AxisValueFormat3 format, "Format identifier — set to 1." s/be "Format identifier — set to 3."

Peter Constable

Typos in gpos.htm:
- In the note after the table for the ValueRecord format, "variations fonts" s/be "variable fonts".

Peter Constable

Typos in languagetags.htm:
- In the paragraph before the table, "wihtin" s/be "within".
- Missing period at the end of the paragraph before the table.

Masaya Nakamura

Another one in CFF 2 table:

11. Font DICT Index, Font DICTs and FDSelect.

Table 15 FDSelect Format 3
[...]
Card16    sentinel    Sentinel GID (see below)

Table 17 FDSelect Format 4
[...]
Card32    sentinel    Sentinel GID (see below)

The detailed description of Sentinel GID is missing.


ping @Read Roberts

Peter Constable

Erratum in hvar.htm: The formula for calculating innerIndex is missing "+1":

innerIndex = entry & ((1 << (entryFormat & innerIndexBitCountMask)) – 1)

s/be

innerIndex = entry & ((1 << (entryFormat & innerIndexBitCountMask)) – 1) + 1

Peter Constable

Denis Moyogo Jacquerye said:

@Simon Cozens

there isn't a hyphen-minus

There is, it’s U+002D HYPHEN-MINUS in Unicode.
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.

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?

Peter Constable

Typo in hvar.htm: In these sentences:
"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".

Hin-Tak Leung

Masaya Nakamura said:

Another one in CFF 2 table:

11. Font DICT Index, Font DICTs and FDSelect.

Table 15 FDSelect Format 3
[...]
Card16    sentinel    Sentinel GID (see below)

Table 17 FDSelect Format 4
[...]
Card32    sentinel    Sentinel GID (see below)

The detailed description of Sentinel GID is missing.


ping @Read Roberts

That probably assume knowledge of CFF?

Peter Constable

Technical issue in hvar.htm: the formulas for outerIndex and innerIndex overlook the "minus one" in the description of innerIndexBitCountMask. Formulas should be:

outerIndex = entry >> ((entryFormat & innerIndexBitCountMask) + 1)

innerIndex = entry & ((1 << ((entryFormat & innerIndexBitCountMask) + 1)) - 1)

Peter Constable

We’ve made some updates to the OT1.8 spec, which are now published online. Most are fixing typos that have no technical significance. There are a few things that have technical significance, however. These are called out in a new Errata page.

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.

Masaya Nakamura

Typos in the CFF 2 CharString Format:

2.3 Subroutines

A charstring subroutine must end with either an endchar or a return operator. If the subroutine ends with an endchar operator, the return is not necessary.

The Type 2 operators endchar and return are removed in the CFF 2 CharString.

Appendix A. CFF 2 Charstring Command Codes

11 0b return

It should be -Reserved-.

Georg Seifert

What is the reason that the STAT table, the 'offsetToDesignAxes' is a ULONG and the axisValueOffsets are USHORT. Very often offsets are USHORT, only here we find one that is ULONG. Is it to be expected, that the STAT table is bigger than 65k?

Georg Seifert

And an actually issue? 
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.

Belleve Invis

What is the meaning of blending a subroutine index?
Can a blended result used as a parameter in a new <blend> operator?

Peter Constable

Two new errata notices for OpenType 1.8 have been published, both technical errors in the CFF2 CharString specification. One is about the interpretation of byte values in number encoding; the other is in the byte code values for the vsindex and blend operators.

See OpenType 1.8 errata for details.

Peter Constable

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

John Hudson

https://www.microsoft.com/typography/otspec/features_ko.htm#med2

The feature friendly name is recorded as 'Medial Form #3'

SHOULD BE 'Medial Form #2'