[OTVar] Typos and editorial issues with OT 1.8

Simon CozensSimon Cozens Posts: 188
edited September 2016 in Font Technology
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".
«1

Comments

  • @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.
  • Reporting OT1.8 typos in this thread will work fine.
  • Simon CozensSimon Cozens Posts: 188
    edited September 2016

    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 CozensSimon Cozens Posts: 188
    edited September 2016

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

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


  • 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 ConstablePeter Constable Posts: 91
    edited October 2016
    Typos in otvaroverview.htm:

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

    - "supressed" s/be "suppressed"
  • Peter ConstablePeter Constable Posts: 91
    edited October 2016
    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.
  • Typos in merg.htm:
    - "antialising" s/be "antialiasing" (2 instances)
  • Typos in fvar.htm:
    - "correspondence" s/be "correspondence"

    Typos in gvar.htm:
    - "argument1 (Y offset)" s/be "argument2 (Y offset)"
  • In the delta version of post.htm, the Note in the "'post' Table and OpenType Font Variations" section should be highlighted.
  • 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."
  • Typos in gpos.htm:
    - In the note after the table for the ValueRecord format, "variations fonts" s/be "variable fonts".
  • 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.
  • 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

  • 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
  • @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?
  • 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".
  • 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?
  • 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)

  • 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.
  • 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-.
  • 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?
  • 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.
  • What is the meaning of blending a subroutine index?
    Can a blended result used as a parameter in a new <blend> operator?
  • 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.
  • 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 HudsonJohn Hudson Posts: 1,063
    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'
Sign In or Register to comment.