- From: jfkthame via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 May 2023 09:46:39 +0000
- To: public-css-archive@w3.org
> Interestingly, I found Gecko uses an average character width for the fallback [1, 2], Note that when the fallback uses `GetMetrics(nsFontMetrics::eVertical).aveCharWidth`, this is actually a *vertical* advance (i.e. height), not width. The `gfxFont::Metrics` struct has legacy field names where a number of the fields have "width" in their names, but for vertical-mode metrics these are actually advance heights. So the fallback used is the "average" *vertical* advance, which in turn is based on the font's ascent + descent, as there's no vertical-mode equivalent to the OS/2 table's `xAvgCharWidth` field. I think this is better than falling back to ic-width because of the possibility of significantly non-square fonts. I know most common fonts will have square or near-square glyphs for 水 and other ideographs, but in a highly-stylised (e.g. condensed or expanded) font this might not be true. So Gecko's implementation is instead based on the assumption that in vertical mode, all characters will simply get the same fixed advance (height) if specific vertical metrics are not present. -- GitHub Notification of comment by jfkthame Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8792#issuecomment-1534433267 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 4 May 2023 09:46:41 UTC