Name table parsing is incorrect

[kekekeks]

Describe the bug

Was looking at this PR and noticed that while LCIDs map nicely to platformID=3, we pretty much ignore other platform IDs. E. g. platformID = 1 has its own set of language codes.

While being generally safe to do when filtering language IDs we can't ignore the platformID when selecting the encoding here, since non-windows fonts have different encoding identifiers and it will cause exceptions.

@Gillibald

To Reproduce

Try loading some font with mac/unicode platform in its name table

Expected behavior

No response

Avalonia version

master

OS

No response

Additional context

No response

[kekekeks]

We should also probably fall back to using PostScript font names if name table is unavailable or unreadable.

[Gillibald]

Such ancient encodings require a reference to https://learn.microsoft.com/en-us/dotnet/api/system.text.codepagesencodingprovider?view=net-8.0
Modern fonts only use the Unicode encoding.

To make this work we need some feature flag to enable support for older platforms

[kekekeks]

We need to explicitly skip reading them and explicitly fall back to PS font name then. Right now we are simply ignoring the relevant encoding field.

[MIRIMIRIM]

I think correctly parsing old fonts' name record is a troublesome job, they may use different encoding from name record.

If you just want to get the correct language code when platformID=3, you can do a simple conversion, such as https://github.com/HinTak/Font-Validator/blob/aa6d6bc0f1b5eb257877a998f97dbb323f7ddabb/OTFontFile/Table_name.cs#L102

[kekekeks]

The thing is, we can't rely on all encodings to be available in the published app. So we still need to silently ignore the name table entries we can't decode properly.