Character lookup anomalies caused by font ordering

[kerams]

Describe the bug

Try to render kğżȯgda in a TextBlock using combinations of Noto Sans Hebrew and Open Sans.

Noto Sans Hebrew does not contain Latin characters, so kğż are looked up in the Open Sans fallback. However, ȯ (a precomposed character rather than o with a combining dot) does not exist in Open Sans either, so it should use system font fallback, or be interpreted as o with a combining dot, which Open Sans can handle.

On Android

• With the font combination of Noto Sans Hebrew, Open Sans, unknown glyph placeholders are rendered instead of ȯgda. At the very least, the rest of the text after ȯ should be rendered with Open Sans.
• With the font combination of Open Sans, Noto Sans Hebrew, the entire string is rendered correctly, including ȯ, which was intepreted as a combination of o and a dot by the looks of it.
• With no font specified, the string looks right with system fallback.

On Windows

• With the font combination of Noto Sans Hebrew, Open Sans, ȯgda is rendered using system font fallback. At the very least, the rest of the text after ȯ should be rendered with Open Sans.
• With the font combination of Open Sans, Noto Sans Hebrew, ȯ is strangely not intepreted as a combination of o and a dot (unlike on Android above), so system fallback is used, and the rest of the string is Open Sans again.
• With no font specified, the string looks right with system fallback.

To Reproduce

https://github.com/kerams/font3, run TstFs.Android in emulator, ConsoleApp1 is the desktop version.

Expected behavior

The first 2 lines should be rendered in their entirety with Open Sans.

Avalonia version

11.2.999-cibuild0051894-alpha

OS

Windows, Android

Additional context

No response

[Gillibald]

The text is shaped with [OpenSans|Default|OpenSans] because OpenSans isn't mapping any glyph to ȯ I don't see any issue here.

[kerams]

That's just one of 3 different issues described

• different font ordering shouldn't produce different results here (since Noto Sans Hebrew does not contain any of the characters in question)
• ȯ breaks rendering of subsequent characters on Android
• the NFD version of ȯ is rendered with Open Sans on Android, but NFC is used on Windows (which Open Sans does not cover)). I can live with this inconsistency as long as the 2 problems above are ironed out.

[Gillibald]

You specify a fallback sequence for the first two and the first matching font is used. Why should the result any different when the only font that has a matching glyph is OpenSans?

[kerams]

That's exactly my question. Why does the result change with different ordering? Not only that, why is the behavior not consistent between Android and Windows?

[Gillibald]

I do not see any differences on Windows we might need to add a unit test

[kerams]

Using my repro project lines 1 and 2 look the same on your Windows PC?

[Gillibald]

I can repro the issue