Why change the '_sans' Chinese font ?

[wmtj]

Probably after AIRSDK 51.1.2/3, the '_sans ' Chinese font on the iOS/iPadOS/Mac system has been changed, the new font is not as nice as the old one, especially on a Mac : now '_sans' display as '宋体' font that doesn't look nice on mobile devices, In scenes with a large number of Chinese characters displayed, the visual effect of this font is very poor, and my App has received more and more criticism for this.

I hope '_sans' to be set as the default Chinese font for the system interface. Thanks! @ajwfrost

[ajwfrost]

Hi

Can I check, you see a different font being used when you build using the latest AIR SDK vs when you build using an older one around 51.1.1? on the same device/OS version?

Are you able to confirm what type of text you're creating i.e. TextField vs TextLine vs StageText, and what values you're using for the font formatting? As far as I'm aware we didn't change anything here so I could easily imagine a change in OS version/configuration may result in us picking up a different default font fallback or similar, but am surprised at two different AIR versions resulting in different outputs on the same device when using the same mechanism..! We'd need to have all the details so that we can reproduce this here, to see what's going on..

thanks

[wmtj]

This is the test code, using AIRSDK_51.1.2.3 and AIRSDK_51.1.3.5, iPadOS 17.7.6. The change of the font can be clearly seen. @ajwfrost

`private function testAIRSDKChineseFontChanges():void
{
var _tfmt1:TextFormat = new TextFormat("_sans", 150, 0);
var _tfmt2:TextFormat = new TextFormat("_sans", 150, 0);

		_tfmt1.bold = true;
		_tfmt2.bold = false;
		_tfmt1.align = _tfmt2.align = TextFormatAlign.CENTER;
		
		var _txt1:TextField = new TextField();
		_txt1.defaultTextFormat = _tfmt1;
		_txt1.text = "测试  測試  ABC\n字体  字體  DEF";
		_txt1.width = _txt1.textWidth + 12;
		_txt1.height = _txt1.textHeight + 4;
		_txt1.x = 200;
		_txt1.y = 400;
		addChild(_txt1);
		
		var _txt2:TextField = new TextField();
		_txt2.defaultTextFormat = _tfmt2;
		_txt2.text = "测试  測試  ABC\n字体  字體  DEF";
		_txt2.width = _txt2.textWidth + 12;
		_txt2.height = _txt2.textHeight + 4;
		_txt2.x = 200;
		_txt2.y = 900;
		addChild(_txt2);
	}`

AIRSDK_51.1.2.3, iPadOS 17.7.6.

AIRSDK_51.1.3.5, iPadOS 17.7.6.

[wmtj]

In my memory, this issue emerged after the fix for #3521. This issue is particularly obvious when running an iPad app on MacOS silicon ('_sans' displays as '宋体' which is a Chinese font that doesn't look good when displayed on mobile devices).
The '_sans' should be set as the default iOS/iPadOS/MacOS system UI font. @ajwfrost

[ajwfrost]

I just took a look at those changes.. so it may be that the way we updated the font handling there is resulting in a different default font that's being created if you use "_sans" as the font name. We can try to check this.

But also just to clarify, in the images above, the older version of AIR doesn't seem to have taken into account the "bold" format; the newer version is doing this. Can I double-check that you would expect "bold" to be a format that can be applied?

We can also take a look at default fonts/glyphs used in normal system applications on iPads to check whether we have the same look.

[wmtj]

Please check the difference between these two characters, it's not just in bold. @ajwfrost

...Yes, the old AIRSDK have a long-standing bug where '_sans' chinese bold font did not take effect (only on iOS).

On iPhone and iPad, the new version of the font is actually barely acceptable, but it is not acceptable when running an iPad app on on macOS silicon (This is the point that users complain about the most).

[ajwfrost]

Well interestingly, it appears that the font we're displaying now is actually the system font.. and we get similar results if we just use Chinese text within the MacOS TextEdit application. Actually, it doesn't make a difference from our side when we set the font to "SF Pro" or "Helvetica" etc, those characters are displayed the same, because they're picked up from a fallback font.

Again using TextEdit, if you have a file with mixed characters, select the whole thing and choose "SF Pro" for the font, then you go and select just the Chinese characters, they will be displayed with the "PingFang SC" font, because that's set to the fallback font.

If we change one of those text field fonts to use "PingFangSC-Light" then we get more the effect you're after I think? And the same is actually achieved by "Helvetica-Light". There's no such thing as "SF Pro Light" according to the font list on my Mac; similarly on an iPhone we can see the "Light" versions for Helvetica and PingFang, and despite "SF Pro" being listed online as a system font for iOS, that might be out of date as that doesn't appear available (and when we try to select it in the CoreGraphics API, we end up with a Helvetica font).

So essentially I think this boils down to the fact that the "Light" version of the font works better for Chinese characters. The change in display from the older version of AIR SDK vs the new one is actually down to the fact we needed to switch APIs away from an unsupported/obsolete one (which worked fine for latin characters but didn't cope properly with the fallbacks). So I'm not sure we'll be able to change things just for Chinese text here: either we say that "_sans" falls back to the "Helvetica" system font, which then falls back to "PingFang SC" for Chinese glyphs - or we say that "_sans" should actually by "Helvetica Light" which would result in the "PingFang SC Light" variants.

We cannot see any APIs that would allow us to change the weight for just the fallback/Chinese characters, which means it's the whole string that would be affected here.

Just for reference: https://developer.apple.com/design/human-interface-guidelines/typography

We perhaps need a "light" option along with the "bold" setting in a TextFormat object - or perhaps we should convert that so that we can use it as a "weight" which is where everything else is going (iOS font traits, as well as CSS, etc...). The value that's used for "bold" on TextFormat is an 'object' type which would lend itself to being converted but the rest of the APIs aren't there yet...

So as an interim here, there are a few options:

1. We don't make any change but you manually select a font with "Light" in the name
2. We change the "_sans" translation so that this is automatically a "Light" version
3. We introduce "_light_sans" or similar, to allow this to be more of a user choice
4. We allow a Number value to be passed in to the "TextFormat" constructor to switch from a true/false for bold, to being a weight modifier, and later on introduce get/set APIs in AIR 52

Let me know your preferences for short term and longer term changes!

thanks

[wmtj]

In my opinion :

1. On iOS, the '_sans' font of the latest AIRSDK can be kept unchanged, at least for the short term. It is visually acceptable.

2. iPad app running on MacOS silicon shows wrong font('宋体') for '_sans', it should be fixed. I think there might be a bug in the latest AIRSDK font mapping mechanism on MacOS. There is no way to directly write test codes to show incorrect fonts on MacOS silicon running iPad app...If there is anything here that I haven't explained clearly, please let me know and I will try to explain it in detail.

@ajwfrost Thanks!

[ajwfrost]

Interesting - looking at those screenshots, it's very different from what I'm seeing, when running the iPad app on a MacBook. So potentially this is down to the system set-up or locale .. we may need to add in some debug output to try to understand what's actually happening.

The downside of using "_sans" is that it's just a placeholder for AIR, internally AIR changes that into another font name, but all of these fonts are the Latin-based ones i.e. when you select "_sans" you're not getting a font that has any Chinese glyphs in it. There is then some logic elsewhere which selects what actual font you'll get for the Chinese characters. If you use TLE, there is some control over this that we have, but for a normal TextField with device fonts, it's the OS that decides what to use.

We'll have to get a debug/test library, if you're able to then package and run whilst the Console app is open..

thanks

[wmtj]

debug/test library

What kind of library ? I don't quite understand it...

[ajwfrost]

Library i.e. libRuntimeHMAOT.arm-air.a which is linked in with your app when creating the IPA file. We would need to add in some log outputs and then re-compile it, then send you the custom version of this. Then, after you've created/installed the app, it will spit out some debug logs to the macOS Console application - we'll tag them so you can filter out other stuff and just check this output...

thanks

[wmtj]

The screenshot above was achieved by submitting a new version to Apple App Store. Debug ipa cannot be installed and debugged on the my Macbook yet :( I'm very sorry. I started to try using Macbook as the development environment recently, and I'm not yet proficient in some operations.

[wmtj]

A feasible method: You can use an Macbook (switch to the Chinese language and the region to China) to debug and output. @ajwfrost

[wmtj]

There is still a significant issue with the display of East Asian characters on the Macbook, as shown in the following picture:

The correct :

The wrong :

It can be clearly seen that the upper edge of the TextField text has been cut off. This phenomenon only occurs on Macbook (silicon) and is normal on iPhone and iPad. Moreover, this issue only occurs in the first line of the TextField text, while the second line and beyond are normal. @ajwfrost