CJK vertical metrics suggestion

[NightFurySL2001]

According to https://googlefonts.github.io/gf-guide/metrics.html#cjk-vertical-metrics, it is suggested that the OS/2.sTypoAscender is set to 0.88 * font UPM and the OS/2.sTypoDescender is set to -0.12 * font UPM. The table is attached below:

Attrib	Value	Example using 1000upm font
OS/2.sTypoAscender	0.88 * font upm	880
OS/2.sTypoDescender	-0.12 * font upm	-120
OS/2.sTypoLineGap	0	0
hhea.ascender	Set to look comfortable (~1.16 * upm)	1160
hhea.descender	Set to look comfortable (~0.288 * upm)	-288
hhea.lineGap	0	0
OS/2.usWinAscent	Same as hhea.ascent	1160
OS/2.usWinDescent	abs(value) of hhea.descent	288
OS/2.fsSelection bit 7 (Use_Typo_Metrics)	Do not set / disabled	0

Our decision to follow the Adobe schema was based on Dr. Ken Lunde’s comments and his release notes on Source Han Sans:

• Line spacing/vertical metrics approach discussion thread source-foundry/font-line#2
• SourceHanSansReadMe.pdf

However, these metrics are only used in Japanese fonts. In Korean font (such as IBM Plex KR developed by Sandoll Inc), the ratio used is 0.8:0.2, which some Chinese font foundries use too. Another typical Chinese font foundry used is 0.85:0.15, as this allows more descender space compared to 0.88:0.12. There are some other combination of values which is used for individual creators too.

The referenced issue provided to justify these values (source-foundry/font-line#2) only explicitly mention this (quoted from @kenlunde):

To add to the discussion with regard to the sTypoAscender and sTypoDescender values in the 'OS/2' table, while I cannot speak with any authority to non-CJK fonts, at least for CJK fonts I feel somewhat strongly that these values 1) add up to equal the UPM and 2) correspond to the top and bottom of the ideographic em-box in which CJK glyphs are optically centered. For the other vertical metrics values, I see little or no disagreement.

Thus, I would like to suggest the guide to change the guidelines to allow any ratio for the OS/2 sTypo values as long as:

• OS/2.sTypoAscender - OS/2.sTypoDescender = UPM (In the sample it is 880 - (-120) = 1000)
• OS/2.sTypoAscender and OS/2.sTypoDescender reflects the CJK ideographic bounding box only, not any other values.

[RosaWagner]

That is good info, thanks.

@davelab6 @chrissimpkins should we update the vertical metric policy for CJK fonts accordingly?

cc @vv-monsalve @m4rc1e @aaronbell

[NightFurySL2001]

This would also fix the issue of IBM Plex KR is different from its source file as the original KR font uses 780/-220. (Issue reference)

[yisibl]

Why is it recommended to disable Use_Typo_Metrics here?

[NightFurySL2001]

OS/2.sTypoAscender and OS/2.sTypoDescender are used for CJK bounding box. Setting Use_Typo_Metrics will make the font look shorter (usually).
Source quote:

Else If this is a CJK font:

ideoEmboxBottom = OS/2.sTypoDescender
ideoEmboxTop = OS/2.sTypoAscender
ideoEmboxRight = head.unitsPerEm

[NightFurySL2001]

Any updates on changing the guidelines?

[vv-monsalve]

@aaronbell, this proposal requires CJK's expertise, could you please help us to review it?

[aaronbell]

The suggestion seems reasonable to me. Ken's method of 880 / -120 works well for standard CJK use, but I can see other ratios being employed depending on the requirements of the specific project. As long as the CJK bounding box aligns with the UPM, things should be alright.

[vv-monsalve]

Thanks @aaronbell. This would require a consensus before making the change here. Would you like to bring the subject to the next meeting as part of your current job in the CJK fonts?

[NightFurySL2001]

Quick notes:

1. hhea.descender should be negative, so (~0.288 * upm) should change to (~-0.288 * upm) with negative value. It seems that this can be easily confused (see nooriro/nooriro.github.io@2787e25). I have updated this in Update CJK vertical metrics #135 .
2. Fontbakery check should be updated to disable typoascender_exceeds_Agrave when cjk_vertical_metrics is triggered. Errors could be raised with current setting (see Have reviewed the output with fontbakery? line/seed#4).

Checking that the typoAscender exceeds the yMax of the /Agrave.

Check ID: FontBakeryCheck:com.arrowtype.fonts/check/typoascender_exceeds_Agrave

🔥 FAIL OS/2.sTypoAscender value should be greater than 1008, but got 880 instead

[307587]

hi, coming from my issue above, may i suggest: add a 'short height variant' for the CJK family, like how 新一細明體 (2nd example font in the issue) is the 'short height variant' of 一點明體.

[NightFurySL2001]

This issue discuss how to set vertical metrics in digital fonts for all kinds of usage, not only for using in Microsoft Word.

新一細明體 is a metric compatible version of 新細明體 (PMingLiU on Windows) based on the core font 一點明體. The issue that comes with the 'short height variant' is that extra tall characters (eg pinyin ǕǙẾỀ) might get clipped off if they are outside of the ascender/descender range, especially on mobile UI where users cannot adjust the line height.

Quote from Source Han/Noto CJK Readme file:

The 'OS/2' Table

The OS/2.sTypoLineGap value has been set to 0 (zero) units, and is also reflected in the hhea.LineGap and vhea.lineGap values. The OS/2.usWinAscent and OS/2.usWinDescent values have been calculated by removing excessively tall and other vertical-only glyphs—for U+2E3A, U+2E3B, U+302A through U+302D, U+3031, and U+3032—from the equation, and have been harmonized across all seven weights. These same harmonized settings are also reflected in the hhea.Ascender and hhea.Descender values. This is for the benefit of applications that use these values for determining default leading. These and other 'OS/2' table settings are intended to provide consistent cross-platform line spacing (aka vertical metrics).

[NightFurySL2001]

After reviewing the discussion on source-foundry/font-line#2 , I do wonder where does the value of 1.16 and 0.288 comes from for the hhea table. These two values seem to be based only on Source Han Sans.

For reference, in Source Han Sans/Noto Sans CJK (after removing extra-tall characters like U+2E3A, U+2E3B, U+302A through U+302D, U+3031, and U+3032):

• Highest point in Ǜ @ Heavy weight, y=1160
• Next 10 highest characters: ẪỄỖẴẲẮẰǙǗ
• Lowest point in ◌〪 (vertical bar, U+302A) @ Heavy weight, y=-320
• Next lowest point that is not combining character: ￨ (U+FFE8 Halfwidth Forms Light Vertical) @ Heavy weight, y=-288
• Next 10 lowest characters: ¦|¸ÇçẠạẬậẶ

Maybe the suggestion can be changed to allow more flexibility for the hhea values based on the highest and lowest glyph.

[aaronbell]

@NightFurySL2001

The winAscent and winDescent are clipping metrics, so to avoid circumstances where parts of glyphs get cut off in applications like Word, they need to be set to the font's yMax and yMin. However, doing so, as has been pointed out, can result in circumstances where the gap between lines of text is undesirably large. And while most applications allow one to increase line gaps, they don't often allow one to decrease line gaps.

For Latin fonts, the solution was to introduce the useTypoMetrics flag which tells software to use the metrics set in sTypo and can be set more "typographically" to ensure proper line spacing regardless of clipping. Of course there's still the question of what's right for a given font's purpose (as in, should it be set to prioritize taller languages like Vietnamese or shorter ones). hhea will follow whichever metric is given priority—winMetrics if the useTypoMetrics flag is not set, and sTypo if it is set.

This leads me to wonder if introducing that flag to CJK fonts makes sense. Older fonts, like MingLiU, had tight vertical spacing (winMetrics: 820/204 -> 1024 unit height) and creates a rather dense look on the page:

Taking LXGW WenKai TC as an example, following the established GF guidance looks a bit loose (1448 unit height):

If we turned on useTypoMetrics and it instead used the sTypo metric values, we get a rendering more similar to MingLiu (at a 1000 unit height), which may be tighter than is desireable.

So one option is to increase the dimensions outward, say a 15% increase (1150 unit height)

This 15% increase is arbitrary, btw, and can be adjusted as necessary.

The net effect of this change, though, is that the sTypo values will no longer 1:1 align with the ideographic bounding box. But I am not sure if that alignment was providing much value in the first place when useTypoMetrics is not set.

[NightFurySL2001]

It seems the sTypo metrics are the one used to calculate the ideographic box when missing baseline information, which is why it was required to match the ideographic box.

https://learn.microsoft.com/en-us/typography/opentype/spec/baselinetags#ideoembox

The OS/2.sTypoDescender and OS/2.sTypoAscender fields in a CJK font may specify metrics different from the HorizAxis.ideo and HorizAxis.idtp values in the BASE table. However, CJK font developers should be aware that some applications might not read the BASE table at all but simply use the OS/2.sTypoDescender and OS/2.sTypoAscender fields to describe the bottom and top edges of the ideographic em-box. If developers want their fonts to work correctly with such applications, they should ensure that any ideographic em-box values in the BASE table of their CJK fonts describe the same bottom and top edges as the OS/2.sTypoDescender and OS/2.sTypoAscender fields.

[aaronbell]

Hmmm, interesting. My understanding was that there are few, if any, applications (maybe Adobe is the only one) that support any kind of baseline alignment. I'll look into it more.

[NightFurySL2001]

I think for now we can update the metrics information with the PR I had sent in.