Differences in Mac system fonts (ot + `trak`) results between HarfBuzz ot and HarfRust

[drott]

From Chromium bot runs:

I'll try to break those down to hb-shape calls if possible - the differences might however be related to how we retrieve metrics information through Skia. In some cases, the choice or positioning of advances does not look a tiny bit worse in those renderings.

[drott]

In this example, the y and m are positioned a bit more forward, further away from previous glyph than before:

[behdad]

It would help a lot if you can distill these down to hb-shape invocations. Or at least which font is involved. Thanks.

[drott]

Unrounded Advance Width Differences: C++ HarfBuzz vs. Rust HarfRust

Non-zero layout advance width differences (within 0.001f threshold) for the sentence "System italic font at weight n" at size 20 on macOS across weights 100 to 900. Font is SFNSItalic.ttf.

So far from Blink unittests: https://crrev.com/c/8035206 - I'll try to distill this into a test directly based on HarfBuzz.

Weight	Char Index	Char	C++ HarfBuzz (px)	Rust HarfRust (px)	Difference (px)
100	0	S	11.6469	11.6504	+0.0035
	1	y	9.2164	9.2188	+0.0023
	3	t	5.6847	5.6836	-0.0011
	8	t	5.9147	5.9180	+0.0033
200	0	S	11.7250	11.7285	+0.0035
	1	y	9.4312	9.4336	+0.0024
	2	s	9.4613	9.4629	+0.0016
	8	t	6.1176	6.1133	-0.0043
	14	f	5.6710	5.6738	+0.0028
	22	w	14.2906	14.2871	-0.0035
300	0	S	11.8031	11.8066	+0.0035
	1	y	9.6361	9.6387	+0.0026
	2	s	9.4603	9.4629	+0.0026
	8	t	6.3205	6.3184	-0.0021
	14	f	5.8735	5.8691	-0.0044
	22	w	14.4597	14.4629	+0.0032
	29	3	11.7236	11.7188	-0.0049
400	0	S	11.8715	11.8750	+0.0035
	1	y	9.8508	9.8535	+0.0027
	2	s	9.4594	9.4629	+0.0035
	3	t	6.4142	6.4160	+0.0018
	14	f	6.0662	6.0645	-0.0017
500	0	S	12.1449	12.1484	+0.0035
	2	s	9.8017	9.8047	+0.0030
	3	t	6.7591	6.7578	-0.0013
	14	f	6.4110	6.4062	-0.0047
600	0	S	12.4281	12.4316	+0.0035
	1	y	10.4898	10.4883	-0.0015
	2	s	10.1539	10.1562	+0.0023
	3	t	7.1040	7.0996	-0.0044
	14	f	6.7460	6.7480	+0.0020
700	0	S	12.7015	12.7051	+0.0036
	1	y	10.8043	10.8008	-0.0035
	2	s	10.4963	10.4980	+0.0017
	3	t	7.4489	7.4512	+0.0023
	29	7	11.2846	11.2891	+0.0045
800	0	S	12.9750	12.9785	+0.0035
	1	y	11.1189	11.1230	+0.0041
	2	s	10.8387	10.8398	+0.0011
	14	f	7.4355	7.4316	-0.0039
	29	8	13.4050	13.4082	+0.0032
900	0	S	13.2484	13.2520	+0.0036
	1	y	11.4432	11.4453	+0.0021
	3	t	8.1388	8.1348	-0.0040
	14	f	7.7705	7.7734	+0.0029

[drott]

harfbuzz/harfbuzz@main...drott:harfbuzz:aatDiff has a tester that can be run with
meson test -C build aat-diffs-hb-hr --verbose

producing differences like:

--- WEIGHT 500 ---
Text: "System italic font at weight 500"
  Glyph  1: C++ ("ot") = 9.3229, Rust ("harfrust") = 9.3262 (diff = +0.0033)
  Glyph  2: C++ ("ot") = 8.9876, Rust ("harfrust") = 8.9844 (diff = -0.0033)
  Glyph  3: C++ ("ot") = 5.8740, Rust ("harfrust") = 5.8789 (diff = +0.0049)
            1/4 px Snap: C++ = 5.7500, Rust = 6.0000 (diff = +0.2500)
  Glyph 14: C++ ("ot") = 5.5339, Rust ("harfrust") = 5.5371 (diff = +0.0033)

I highlighted one particular case here when rounding to quarter pixels leads to a shift. I am not sure what type of horizontal quantization Skia or CoreText rendering are doing - but I suspect that sometimes a subpixel quantization difference occurs which might explain the rendering differences in the above image.

[behdad]

Claude found the smoking-gun. HR calls Fontations' compute_delta(), which rounds delta to font unit before returning. It should never have been done that way but oh well. There's compute_float_delta() already. Claude's patching HR to use that solely now.

[behdad]

FWIW, reproduces for me with:

hb-shape SFNSItalic.ttf 'System italic font at weight n' --font-size 1280 --variations wght=500

across the two shapers.

[behdad]

compute_float_delta()

The accessors on the return value of this need to be changed to public in fontations.

[behdad]

compute_float_delta()

The accessors on the return value of this need to be changed to public in fontations.

googlefonts/fontations#1954

[behdad]

Fix in #403