bug#65803: 29.1; Noto Sans Mono CJK JP has doubled-width on Windows

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

> This is strange.  AFAIU, frame-char-width returns the "average width"
> attribute of the font, so why do we get different results on Windows
> and on X?  Po Lu, can you help?  Do font backends on X perform some
> trickery on the font's average_width attribute that we don't do on
> Windows?

For a nominally monospace font, the ft*font backends infer the average
from the width of the space glyph, instead of giving undue credence to
its reported ``average width''.  CJK fonts customarily contain tens of
thousands of glyphs, of which only a small subset represent ASCII
``monospace'' characters relevant to Emacs, but the `tmAveCharWidth'
field, which is derived from the font's OS/2 table:

  https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6OS2.html

represents the average width of all the glyphs within the font, and is
ergo naturally biased towards the large number of CJK glyphs
incorporated within the font.  The W32 backend should either infer the
average width itself, or ground it upon on the width of the space glyph.
Refer to this code in ftfont_open:

      font->min_width = font->average_width = font->space_width = 0;
      for (i = 32, n = 0; i < 127; i++)
	if (FT_Load_Char (ft_face, i, FT_LOAD_DEFAULT) == 0)
	  {
	    int this_width = ft_face->glyph->metrics.horiAdvance >> 6;

	    if (this_width > 0
		&& (! font->min_width || font->min_width > this_width))
	      font->min_width = this_width;
	    if (i == 32)
	      font->space_width = this_width;
	    font->average_width += this_width;
	    n++;
	  }
      if (n > 0)
	font->average_width /= n;