morisawa-biz-ud-gothic

[axis6404]

xAvgCharWidth in the OS/2 table is buggy

Describe the bug

The xAvgCharWidth in the OS/2 table is 1997 due to a bug in fontforge. The correct value is 1024. (All 0-9A-Za-z (space) widths are 1024)
This value is wrong and causes various bugs (extra spaces between characters, poor hit detection) in wine on Linux and in apps on Windows.

To Reproduce

Extra white space between characters in the Microsoft font viewer that starts when you click on a font in Windows.
https://x.com/o_tamon/status/1506193655123505154

Expected behavior

No extra white space between characters

Screenshots

https://x.com/o_tamon/status/1506193655123505154

Additional context

Reference URL:
googlefonts/morisawa-biz-ud-gothic#45
https://www.google.co.jp/search?q=UD+xAvgCharWidth
mintty/mintty#808
https://itouhiro.hatenablog.com/entry/20140910/font
https://x.com/o_tamon/status/1506193655123505154
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012399

[emmamarichal]

@simoncozens could you have a look?

[simoncozens]

due to a bug in fontforge

Biz UD Gothic was not compiled with Fontforge.

The correct value is 1024. (All 0-9A-Za-z (space) widths are 1024)

I don't think this is true. I see the claim in wine#52951 that "xAvgCharWidth is half of the unitsPerEm for Japanese fixed-pitch font". But this is not what the OpenType spec says at all.
The calculation of xAvgCharWidth depends on the version of the OS/2 table:

When first defined, the specification was biased toward Basic Latin characters, and it was thought that the xAvgCharWidth value could be used to estimate the average length of lines of text. The following formula for calculating xAvgCharWidth was provided: For characters given in the table below, sum the width of each character times the weight factor indicated, then divide the total by 1000. This method of calculating the value of this field was superseded with the introduction of version 3 of the OS/2 table and is deprecated.

But now:

The value for xAvgCharWidth is calculated by obtaining the arithmetic average of the width of all non-zero width glyphs in the font.

Biz UD Gothic has an OS/2 table version number of 3, so this second calculation (average width of non-zero width glyphs) should apply. The correct value should therefore actually be 1963 - only very slightly narrower than the current value.

I read itouhiro's blog and it's great that he got IPA Gothic working by changing the value to 1024... but that does not mean this I the correct fix for this font. I think the rendering software is to blame here.

[axis6404]

It may be against the specification, but xAvgCharWidth must be 1024 or it will malfunction with older software that cannot modify the source. xAvgCharWidth is used in a lot of software, including Microsoft's.
The advantages outweigh the disadvantages.
As far as I know, the only Japanese monospace font whose xAvgCharWidth differs from the width of 0-9A-Za-z is the UD* font.

vim-jp has fixed the problem with a dirty hack.
vim-jp/issues#1235
vim/vim@93d77b2

[aaronbell]

@axis6404 The problem is ultimately a software problem, rather than a font problem per se. Do we hack the font to solve the problem, or leave the font as it is intended to be and put pressure on software developers to follow the rules? And it doesn't help when some legacy software environments are unlikely to be updated.

A potential workaround would be to disable the post.isFixedPitch bit, which would cause the font to be treated like a proportional one (aka, PGothic). That should allow it to work properly in a broad set of Microsoft GDI environments, but could have negative outcomes for monowidth environments such as coding or terminal, where it may not even be accessible. But maybe that's OK since the alternative would be a hacked font, or poor rendering.

PS, I personally kind of like vim-jp's dirty hack :). It solves the problem universally for fonts that follow the legacy method of setting this field, and those that follow the v3 requirements.