Inconsistent font rendering between Windows and MacOS / iOS

[andrew-vincer]

Describe the bug

We have found that certain fonts, such as Arial Rounded MT Bold, do not appear correctly on MacOS or iOS despite being present on those platforms. They appear to have a glyph typeface of Helvetica instead.

To Reproduce

A small app, available at https://github.com/Smartbox-Assistive-Technology/Avalonia-Font-Test , shows the effect. When run on Windows it will show "The quick brown fox..." in a bold font, as it is correctly rendered in Arial Rounded MT Bold.

On MacOS or iOS this text appears in Helvetica. The debug text shown below is also different between the platforms, seeming to suggest that an incorrect (or more likely default) glyph typeface is used for this font.

Screenshots of the difference are below. Windows first (expected appearance), then iOS in the simulator (incorrect)

Expected behavior

I note that this font is listed in the FontManager.Current.SystemFonts collection, so my expectation is that it should appear much the same on all platforms.

Avalonia version

12.1.1

OS

No response

Additional context

This issue came to light after porting part of our application from .NET iOS with UI Kit front end to Avalonia. This font is displayed correctly in UI Kit.

[Gillibald]

The font family is correctly called "Arial Rounded MT"

[andrew-vincer]

Thanks for the rapid reply. Unfortunately that doesn't seem to fix it. On Windows we get the correct font with slightly different debug text. This shows that requesting a font family of "Arial Rounded MT" results in the same glyph typeface of "Arial Rounded MT Bold" as before.

The issue still persists on iOS. Requesting "Arial Rounded MT" falls back to "Helvetica" as before

I've tried to debug this on Mac but haven't got very far. The below functions seem to be relevant, and I've explored calling them with all permutations of "Arial Rounded MT Bold" / "Arial Rounded MT" and font weight of Normal / Bold.

• I can find no combination of parameters to FontManager.Current.TryGetGlyphTypeface that does not return Helvetica
• I can find no combination of parameters to FontManager.Current.SystemFonts.TryGetGlyphTypeface that doesn't return false

Possibly of note, the platform font manager seems to only have Arial Rounded MT Bold within its list

The set of system fonts looks different, and seems to contain both

This could be completely expected for all I know. Please let me know if there is anything else we can try or information we can provide to be able to select this font face.

Finally, when looking at this font face on font drop I notice that it is encoded as having a font weight of normal despite the bold appearance. Again, this might be expected for all I know.

[andrew-vincer]

We have looked at this again and may have identified the code involved in this issue. Resolution of the glyph typeface for the font in question - Arial Rounded MT Bold - passes through SystemFontCollection.TryGetGlyphTypeface . In the first line of this method, the familyName argument is overwritten by the call to Typeface.Normalize, in this case to have the value "Arial Rounded MT". Later on, this value is passed to _platformImpl.TryCreateGlyphTypeface. On Windows, this font is known as "Arial Rounded MT", so everything works just fine. But on MacOS / iOS, this font is known to the system as "Arial Rounded MT Bold", so it is not found and we ultimately get the default font (Helvetica) instead.

We believe this affects any font with words like "Bold", "Italic" and so on within the system name.

I understand that Avalonia provides several mechanisms for customising font resolution, such as FontManagerOptions.FontFamilyMappings, however these don't quite seem to fit this scenario, at least as far as I can see. Embedding the font is not an option as doing so is against the terms of licence. We have considered options such as writing a custom font collection with an implementation of TryGetGlyphTypeface that does not normalise the name in this case, but it feels like a bit of a hack and we can't do this without accessing non-public or unstable APIs (e.g. FontManager.PlatformImpl). Is there another way?

We would be happy to work on a small PR to address this issue, but would need a bit of guidance first to know what a good fix for this should look like.