Migrated from adobe-type-tools/afdko#1775.
Quote from current FEA syntax spec regarding vmtx table:
In OpenType, each glyph may have a unique vertical origin y coordinate and a unique vertical advance width. By default, for each glyph the vertical origin y coordinate is set to the value of the OS/2.TypoAscender field, and the vertical advance width is set to the distance between the values of the of OS/2.TypoAscender and the OS/2.TypoDescender. However, other values may be assigned to a glyph as follows:
table vmtx {
VertOriginY <glyph> <number1>;
VertAdvanceY <glyph> <number2>;
} vmtx;
It was safe to assume that OS/2.sTypoAscender and OS/2.sTypoDescender are align to the ideographic em-box per current CJK industry standard. However, Google Fonts has recently changed the vertical metric requirements for CJK fonts with a new standard that was not observed in CJK fonts before, which includes spacing out OS/2.sTypo* values to include extraneous line gaps by default, and also using the BASE table to store the ideograhic em-box values.
The discussion can be found on google/fonts#8911 and googlefonts/googlefonts.github.io#159. The latest GF spec is on https://googlefonts.github.io/gf-guide/metrics.html#cjk-vertical-metrics.
The current AFDKO toolset does not allow changing the default values for the vmtx table. A new syntax is required to define the default vmtx values.
Suggestions for vmtx syntax extension
Suggestion 1: without glyph name. This should only appear once in the table block.
table vmtx {
VertOriginY <number1>;
VertAdvanceY <number2>;
} vmtx;
Suggestion 2: add two new keywords: defaultVertOriginY/defaultVertAdvanceY as in the VORG. New keywords are required.
table vmtx {
defaultVertOriginY <number1>;
defaultVertAdvanceY <number2>;
} vmtx;
Suggestion 3: use the DFLT/dflt/includeDFLT keyword. Might crash with glyph names?
table vmtx {
VertOriginY includeDFLT <number1>;
VertAdvanceY includeDFLT <number2>;
} vmtx;
Suggestion 4: use the DFLT/dflt/includeDFLT keyword with a bracket.
table vmtx {
VertOriginY [dflt] <number1>;
VertAdvanceY [dflt] <number2>;
} vmtx;
Suggestion 5: instead of defining new entries, read the metrics from BASE table vert.ideo and vert.idtp. However BASE does not provide VertAdvanceY directly, instead only provides the ascender/descender values similar to how current OS/2.sTypo*. Note that many font editors does not support BASE table yet.
Fallback to OS/2.sTypo* should still be kept to maintain backwards compatibility.
CC @aaronbell.
Migrated from adobe-type-tools/afdko#1775.
Quote from current FEA syntax spec regarding
vmtxtable:It was safe to assume that OS/2.sTypoAscender and OS/2.sTypoDescender are align to the ideographic em-box per current CJK industry standard. However, Google Fonts has recently changed the vertical metric requirements for CJK fonts with a new standard that was not observed in CJK fonts before, which includes spacing out OS/2.sTypo* values to include extraneous line gaps by default, and also using the BASE table to store the ideograhic em-box values.
The discussion can be found on google/fonts#8911 and googlefonts/googlefonts.github.io#159. The latest GF spec is on https://googlefonts.github.io/gf-guide/metrics.html#cjk-vertical-metrics.
The current AFDKO toolset does not allow changing the default values for the vmtx table. A new syntax is required to define the default vmtx values.
Suggestions for
vmtxsyntax extensionSuggestion 1: without glyph name. This should only appear once in the table block.
Suggestion 2: add two new keywords: defaultVertOriginY/defaultVertAdvanceY as in the VORG. New keywords are required.
Suggestion 3: use the DFLT/dflt/includeDFLT keyword. Might crash with glyph names?
Suggestion 4: use the DFLT/dflt/includeDFLT keyword with a bracket.
Suggestion 5: instead of defining new entries, read the metrics from BASE table vert.ideo and vert.idtp. However BASE does not provide VertAdvanceY directly, instead only provides the ascender/descender values similar to how current OS/2.sTypo*. Note that many font editors does not support BASE table yet.
Fallback to OS/2.sTypo* should still be kept to maintain backwards compatibility.
CC @aaronbell.