search

airsdk / Adobe-Runtime-Support

Report, track and discuss issues in Adobe AIR. Monitored by Adobe - and HARMAN - and maintained by the AIR community.
206 stars 11 forks source link

Traditional Chinese characters are garbled on some iOS18 devices #3521

Open a9848840 opened 1 month ago

a9848840 commented 1 month ago

Describe your problem in detail. Include the following information:

AIR SDK : 51.1.1.5 Device : IPhone 14 Pro, IPhone 13 Pro Max

After updating to IOS18, the Chinese font body is built with image image

Open the APP for the first time, the Chinese text is displayed normally. If you return to the background, then when you open it again, some areas of the Chinese field will display garbled characters. The font is : _sans

image

Steps to Reproduce

Returning to the background and opening it again will cause garbled characters with a high probability, but not all Chinese fields are garbled. The text in some scenes is garbled, and some scenes still display normally.

in addition iPhone 12 Pro Max No garbled characters

Please fix this bug

ajwfrost commented 1 month ago

We have been trying to reproduce this one, someone else had reported this (with 18.0.1 but not with 18.0.0?) - but no success yet. Are you able to share a SWF that could be used to reproduce it? And please confirm details such as the type of text field you're using, and the rendering mode (and if 'direct', any use of starling or feathers etc). Also a copy/paste of the text characters that should be being displayed?

thanks

a9848840 commented 1 month ago

1.Is iOS 18.0.1

Static Text Characters: _sans ，輸入密碼，輸入帳號 Rendering Mode : GPU

Enter Text Characters: _sans ，輸入密碼，輸入帳號 Rendering Mode : GPU

The file will be packaged into a SWC call class

No starling or feathers used

image image

thanks

ajwfrost commented 1 month ago

Thanks .. we're still unable to reproduce this though:

We had an earlier issue (#3354) which was pretty generic for all fonts on iOS 18 - the root cause there was that the font files that Apple are now using did not have the traditional glyph data tables that the AIR code was expecting, so when those (fallback) fonts were checked, they were not properly parsed.

This seems to be different: it is displaying the characters fine the first time, but the common theme here is that it happens when you return to the application. Plus, this is happening when using direct/GPU mode, and I'm pretty sure for these modes we render the font into an intermediate texture before uploading this and compositing in the GPU..

Would it be possible to run your application in "CPU" renderMode and see whether you see the same problem?

If you have any relatively straightforward SWF we could use to try to reproduce this here, it would be handy..

thanks

a9848840 commented 1 month ago

issue (https://github.com/airsdk/Adobe-Runtime-Support/issues/3354) The garbled fonts appear very similar to mine, and the method of reproducing them is the same.

Change to CPU rendering. Due to some reasons, I have to wait a few days before trying it.

I took out the file, left the text field part, and published it as SWF. How can I upload the file?

thank u

ajwfrost commented 1 month ago

Thanks @a9848840 - if you can upload your SWF to the below link, we'll be able to package it and run it here.. https://transfer.harman.com/requests/mVZ6bsjryPFh7gO3cqkPZx

thanks

ajwfrost commented 1 month ago

@a9848840 received the files but unable to reproduce still. We've just packaged those SWF files into applications with 'gpu' render mode, and run them on an iPhone 14 Pro with iOS 18.0.1...

Ender22 commented 1 month ago

Hmm not sure why you guys can't reproduce it, but just FYI in case it's device specific, the device we used was an iPhone 15 pro and one of our users reported using an iPhone 16 pro max

a9848840 commented 1 month ago

Make a record Originally, iPhone 12 Pro Max was not garbled. I have two applications, both display Chinese characters, Air 51.1.1.5 When the application returns to the background and switches back and forth There is a chance that garbled characters will occur

a9848840 commented 3 weeks ago

@ajwfrost

<renderMode> cpu </renderMode>

Doesn't work... Garbled characters still occur

I know this is an issue caused by IOS 18.1 But it is currently at a standstill Any suggestions?

Thanks

ajwfrost commented 3 weeks ago

Hi

We've just been trying to reproduce this again, we've tried now on an iPhone 15 and can't reproduce it there either. I am wondering if there's some other setting or condition on the phone that would trigger this ..

If you're able to reproduce it though, we could try adding some logging output to the code that should render the font characters, to check what fonts and glyph IDs are being used.

In the screenshots posted earlier, with the labels and input text, it looks like all of the text had been changed? i.e. there were meant to be 4 characters (輸入密碼, as shown in the lower screenshot) but the upper screenshot is showing two line-based glyphs and two character glyphs but those are also the wrong ones?

One of the line glyphs looks like Unicode character code 0x2561 ( ╡ ) which makes me think either there's something gone wrong with the font selection - i.e. we're using a cached glyph ID but have the wrong font selected - or the Unicode string character values are getting corrupted.

So, we can put together a runtime library that adds a lot of information out via the trace() method; if you're able to run this and capture output via Scout or a remote debugger, we can see what's going on internally?

thanks

a9848840 commented 3 weeks ago

Hi

Setting Settings > General > Language & Region

Traditional Chinese Taiwan Live Text ( V )

I can reproduce,If there is a test file, I can try to package it and find the Log.

Posted before, after "輸入密碼" turned into garbled characters, all 4 symbols were wrong. Even issue (#3354), I suspected that the garbled characters were converted into fixed characters. I saw the same problem from issue (#3354) Garbled characters, they were originally supposed to be the same Chinese character → (仇)

After turning into garbled characters, the garbled text is fixed every time, and it feels like it is just translated into another text language.

THX

Ender22 commented 3 weeks ago

FYI I've confirmed that this issue happens on some iOS18.0.1 devices but not others.

So I think it must be something with a device setting, like maybe which language the OS is set to or something else? I'm asking my colleague to experiment, but so far no luck in figuring it out.

This is a really confusing issue. If you have any general ideas of what could cause this that I can ask my colleagues to try please let me know. I don't understand the underlying mechanics well enough to know what to play with.

ajwfrost commented 3 weeks ago

I think there could be a few different root causes here .. but none of them really make sense for it to work once and then fail the second time, particularly in cpu mode and particularly given the garbled text is still actually valid text...

We are creating a build that will output a lot of information about this whenever a text field is redrawn, which should then help us work out what's going wrong.

But I've also seen that iOS 18.1 is out now, so it would be useful if you're able to check whether that had resolved the problem automatically?

thanks

a9848840 commented 3 weeks ago

I updated to iOS 18.1 Install GPU version and CPU version separately But there is still a chance of triggering garbled code

thx

Ender22 commented 3 weeks ago

Woo! We finally found a reliable way to reproduce this!

We too had a device that no matter what we did we couldn't reproduce this, (and we tried many things!) but now with this method it happens consistently.

The key is the first language set on the iOS device settings screen. The first language in the list needs to be a 'regional' form of Traditional Chinese, for example, Traditional Chinese -> Hong Kong, or Traditional Chinese Taiwan, or Traditional Chinese Maccao

In this example, we have Traditional Chinese Hong Kong set first: image

As long as a 'regional Chinese' is set as the first in the list, the issue happens consistently. It doesn't matter if you are looking at traditional Chinese or simplified Chinese in the app, as soon as the app loses focus, then regains focus, then the textfields are newly drawn they will be garbled.

However, if you change the first language in the list to another form of non-regional Chinese i.e. the options that are just called 'Simplified Chinese' or 'Traditional Chinese' (or some other language like English) then the issue 100% will not occur.

It seems the 2nd and 3rd language options don't matter, we've reproduced it with Traditional Chinese (HK), English, Simplified Chinese and also Traditional Chinese (Taiwan), English, Thai

Note: also, confirmed it still happens on 18.1

ajwfrost commented 3 weeks ago

Thanks @Ender22 ! In our case, we also have to tap on the text field, but we do then see the invalid characters appearing. With the debugging that we'd added into the runtime, this is showing that we are using the same font object, and the same set of glyphs, which implies there's something wrong in the CoreGraphics function (or the way we're using it). But looking at this, the particular function being used here has been deprecated, so it's probably best if we look into alternative options..

Now that we can reproduce this here, we'll be focusing on this and trying to get a fix out asap.. many thanks for your efforts and analysis to get to this point!

ajwfrost commented 3 weeks ago

@Ender22 @a9848840 are you able to download a test runtime library from the below message, and see if this might resolve the issue? https://transfer.harman.com/message/jCIN3CX9qrPcfReOnLhQQG

thanks

a9848840 commented 2 weeks ago

@ajwfrost

The current testing status is good Repeatedly return to background opening No garbled characters appear

Thank you for your hard work

Devin-Licastro commented 2 weeks ago

Hmm, I see that a9848840 says it is fixed, but in my test we saw no difference. I'll write exactly how we tested in just in case you can see anything we did wrong.

  1. Downloaded the new libRuntimeHMATO.arm-air.a file
  2. In the correct AirSDK folder, renamed the existing file (lib/aot/lib) file to libRuntimeHMATO.arm-air.a_bu, and put the new file in the folder
  3. Built a new version (IntelliJ) and sent it to AppStoreConnect and had my colleague test the new build via TestFlight. He reported no change to the issue, still occurring in exactly the same way.

So as long as there isn't an issue with having a libRuntimeHMATO.arm-air.a_bu file remaining in the folder, and as long as IntelliJ isn't caching some build data or something, then it doesn't seem to be fixed for our case.

a9848840 commented 2 weeks ago

Hi @Devin-Licastro

Describe my approach Not sure I can help you

  1. Download files
  2. I am using a Mac to package the files. I removed lib\aot\lib-tvos in MAC (libRuntimeHMAOT.arm-air.a) and replaced it with the downloaded file (libRuntimeHMAOT.arm-air.a).
  3. Follow the original packaging upload process
ajwfrost commented 2 weeks ago

Hi @Devin-Licastro

I would have hoped your description of the process would have meant you got the changed runtime files in there - not 100% sure about IntelliJ caching things, but I'd be surprised if they cached such a large file (and not sure how that would even work given the .a file is an input to our linker..).

I can perhaps do a build with some additional debug output left in, so that we know what's actually being sent to the Apple API, and can confirm that your colleague is definitely running this code (or this path within the code - we can double-check in case there's a parallel code path that needs to also be patched..)

In terms of reproducing it though - is there a known way that you can reproduce it, I'm just wondering whether we can try to do the same here. The approach that @Ender22 proposed then worked for us, i.e. with the handset set to "Chinese, Traditional (Hong Kong)" then we could reproduce this with a simple SWF containing a dynamic TextField object, taking the app to the background, bringing it back to the foreground, and clicking in the text field to cause it to redraw. But with the phone language as "Chinese, Traditional", we could not reproduce it.

thanks

Devin-Licastro commented 2 weeks ago

Ugh so sorry about that, Ender22 is my other github account. I need to switch between them for certain tasks and I forgot to switch back before replying here.

Hmm perhaps the build with the additional debug output left-in would be the way to go... I'm not sure what else to try here.

I see that a9848840 says he made the change to his lib\aot\lib-tvos folder instead of lib\aot\lib ? I'm a bit confused about that. Maybe I should replace it in both folders and try again just in case?

Just to reiterate, my project is Starling based (so renderMode direct) and for iOS mobile phones, this fix is expected to work for that right?

ajwfrost commented 2 weeks ago

Ah :-) that explains it!

We've just kicked off an updated build with more debug output .. via trace (Scout etc) or via NSLog if you can connect it to a console (filter for "AdobeAIR").

That was an iPhone runtime library though, so it shouldn't have been put into the lib-tvos folders! that might have been a typo? The use of Starling means that something else is happening during rendering - but ultimately it should drill down into the same function here, as long as it's not a FTE-based text field (e.g. within Feathers there are different types for text entry/display, we are updating the TextField based ones...). Looking at the code, we didn't find other instances of the deprecated method, if that was the culprit, which means that FTE-based rendering should always have worked..

I'll upload the new runtime .a file shortly, if you're able to try again with that, we can hopefully see what's happening..

thanks

Devin-Licastro commented 2 weeks ago

Just in preparation for this, would you be able to provide me with some steps of how I can get you the logs after?

I haven't used Scout before and I only use the mac for building the app and don't actually do any development there so I'm not so familiar with logging tools. (Haven't heard of NSLog)

I guess I'd need to get my colleague's device to test this in person? (He works from another location which is why we've just been testing this via Testflight so far) but perhaps I can find another iOS 18.1 device here if needed.

ajwfrost commented 2 weeks ago

Sure thing. Updated runtime is available here: https://transfer.harman.com/message/PKQYC1AuQrdF5PFqnQXXd7

If you have a macOS computer, it's probably the simplest way to do this. Steps would be: 1) Connect the phone to the macOS machine via a usb cable 2) On macOS, use Command-Space to bring up the spotlight search, and enter "Console" and then launch this app 3) You should see your phone name listed under your computer name on the left hand side.. click on this 4) If you then hit "Start" on the top set of buttons, you'll see logs start to arrive. Enter "AdobeAIR" in the search field on the top right, and this should then start filtering the content just for those outputs. 5) Run the application on the device, and reproduce the error 6) In the log stream, click on an item and do "command-a", "command-c" to copy all the log entries, then paste these into an email or into a reply of the above transfer.harman.com message

The alternative is to use Scout: you have to have the computer (pc or mac) and the iphone both on the same wifi network. 1) Install Scout on the computer from https://airsdk.dev/docs/tools/development/scout/getting-started 2) Install the Adobe Scout mobile helper on the phone from the App Store 3) Open Adobe Scout on the computer, and then the Scout app on the phone 4) On the phone, use the toggle button to enable Scout, and after a few seconds it should connect.. 5) Run the application on the device - and allow local networking and "allow paste" so that it can connect to Scout - and reproduce the error 6) In Scout on the computer, click the bright red square on the lower left to stop the recording (if nothing appeared in Scout, you may need to close and open the application again on the phone, sometimes the first run doesn't connect properly if the app permissions weren't in place quick enough...) 7) Save the log file via the file menu and attach it to a reply to the transfer.harman.com link

I have an 18.1 device in case you wanted to add me to your TestFlight set-up to try to reproduce it? The transfer link has my email address in it which is used for my work Apple ID.

thanks!

Devin-Licastro commented 2 weeks ago

Hey Andrew,

Sorry for the delay. I like the idea of adding you to our TestFlight setup! I've just submitted a build with the new runtime and sent you an email with all instructions for login and reproduction.

Because you are an 'external' TestFlight user the build has to pass review but usually that only takes a couple of hours. The app name you're invited to is Atiom. I'm not 100% clear if you've gotten the TestFlight invite link already or if the build needs to pass review first, I'll check the status in a couple of hours.

Thanks!

Devin-Licastro commented 2 weeks ago

I got tired of waiting for the build to be reviewed and approved by Apple so I sent you a invite to be one of our internal testers. (I'll just remove you from that afterwards). Please let me know when you've accepted that and I'll be able to do the next step of inviting you to the build.

ajwfrost commented 2 weeks ago

Hi

Thanks - I've accepted the team invite, not entirely sure what the next steps are or how I could download a test version? I didn't see any TestFlight invite - previously I had got a separate invite for that (and it had gone into my work Junk folder..)

Re your earlier note above .. you mentioned you'd emailed me, but I hadn't received anything to my work email address around the time of that message (and have checked Junk) - it's hopefully possible to hit 'reply' on that download link message and it should then send an email via the transfer system..?

thanks

Devin-Licastro commented 2 weeks ago

Hey, okay I have now sent you the TestFlight app invite. Assuming you have TestFlight installed on your device, then I believe next you need to open the new invite on your iOS device, press a button or two and you should then see the app inside of Testflight.

I've also tried the 'reply' method to send the content of the email with the login instructions so hopefully you're all set.

Let me know if you run into any issues

ajwfrost commented 2 weeks ago

Thanks - got the invite, and also the instructions via the transfer link... will check it all now. Thanks!

ajwfrost commented 2 weeks ago

Summary:

So we will start looking at a bigger change in the iOS text rendering to try to prevent this problem and will try to get a test runtime available asap for that.

In the meantime we had started to prepare a 51.1.2.2 release that had the interim change in it, which hopefully will help in some cases!

thanks

Devin-Licastro commented 2 weeks ago

Thanks for the update!

a9848840 commented 2 weeks ago

Hi @ajwfrost

Report the test results The file is placed in 1.lib\aot\lib-tvos 2.lib\aot\lib No garbled code is generated

Thanks

Devin-Licastro commented 2 weeks ago

@a9848840 Are you saying if you place it only in lib\aot\lib then garbled code is still generated, but if you place it in both lib\aot\lib-tvos and lib\aot\lib then no garbled code is generated?

Wouldn't a build for iOS only rely on the lib\aot\lib folder? Why are you placing the file in lib\aot\lib-tvos?

a9848840 commented 2 weeks ago

There are new files put on lib\aot\lib Or lib\aot\lib-tvos

There is only one updated file at the same time No garbled codes will be generated

Place it in lib\aot\lib-tvos Actually I put it in the wrong place :P

ajwfrost commented 1 week ago

Hi @Devin-Licastro - apologies for the delay, but we have a test build now that has a different mechanism for rendering fonts, which we hope may help in your case... are you able to try this in your application build and see if it resolves the problem please? https://transfer.harman.com/message/lRzrgN0ZcHobheC8ueLyGk

thanks

Ender22 commented 4 days ago

Hey @ajwfrost Great news! Looks like the fix worked! We've been unable to reproduce the issue again now. Feel free to try our testflight version 4.1.32 if you'd like to verify anything yourself since I still have you added to that.

Also, we're actually about to launch an unrelated app update, is this lib file ready for production use, or is using that a bad idea for any reason?

(ah sorry, I'm using the other github account again, reminder that this is Devin-Licastro)

ajwfrost commented 4 days ago

Hi - thanks, yes I had spotted the testflight notification earlier this morning and tried it out, and couldn't reproduce the issue. Great news!

The build there wasn't done on our main build server so isn't an "official" build - it's done on a preview of our next (51.2) release, because this change was significant enough that I'm not comfortable doing it as just a dot-release (bug fix) - there's a bit of a risk of regression with this, I think, particularly around the use of FTE and different text orientations etc.. we will do a bit more testing with it, before we push this out properly.

But that said: you can use this in production if it helps, the only downsides would be (a) our lack of testing of it, and (b) the fact we wouldn't be able to reproduce it as a labelled build, and didn't store the related symbol files etc. So, basically, use at your own risk! But if you test your apps and they work, then there's probably not a huge risk and you can always then update to 51.2.1.1 when it's ready..

thanks