search

airsdk / Adobe-Runtime-Support

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

Android 12 _sans Chinese text display garbled #1299

Open a9848840 opened 2 years ago

a9848840 commented 2 years ago

Hi

I use text field default system word _sans Chinese text display garbled

"_sans" "_serif" "_typewriter" also garbled □□□...

I googled Android 12 sans, this part has some adjustments, Can you help adjust the Chinese display as soon as possible?

thank you

Android 12 AirSDK : 33.1.1.633 / 33.1.1.554

ajwfrost commented 2 years ago

Actually it looks like o.o.m. and then we didn't handle the JNI issue... We can try to get a reproduction of this - not sure whether we need to call 'recycle' on the bitmap, there is a canvas that has a reference to it but the canvas is no longer referenced so it should work through GC anyway...

01-25 19:02:58.528 22033 22033 W System.err: java.lang.OutOfMemoryError: Failed to allocate a 12582924 byte allocation with 9533408 free bytes and 9MB until OOM
01-25 19:02:58.528 22033 22033 W System.err:    at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
01-25 19:02:58.528 22033 22033 W System.err:    at android.graphics.Bitmap.nativeCreate(Native Method)
01-25 19:02:58.528 22033 22033 W System.err:    at android.graphics.Bitmap.createBitmap(Bitmap.java:895)
01-25 19:02:58.528 22033 22033 W System.err:    at android.graphics.Bitmap.createBitmap(Bitmap.java:872)
01-25 19:02:58.528 22033 22033 W System.err:    at android.graphics.Bitmap.createBitmap(Bitmap.java:839)
01-25 19:02:58.528 22033 22033 W System.err:    at com.adobe.air.customHandler.callTimeoutFunction(Native Method)
01-25 19:02:58.528 22033 22033 W System.err:    at com.adobe.air.customHandler.handleMessage(customHandler.java:28)
01-25 19:02:58.528 22033 22033 W System.err:    at android.os.Handler.dispatchMessage(Handler.java:102)
01-25 19:02:58.528 22033 22033 W System.err:    at android.os.Looper.loop(Looper.java:159)
01-25 19:02:58.528 22033 22033 W System.err:    at android.app.ActivityThread.main(ActivityThread.java:6130)
01-25 19:02:58.528 22033 22033 W System.err:    at java.lang.reflect.Method.invoke(Native Method)
01-25 19:02:58.528 22033 22033 W System.err:    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
01-25 19:02:58.528 22033 22033 W System.err:    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)
01-25 19:02:58.559 22033 22033 F art     : art/runtime/java_vm_ext.cc:470] JNI DETECTED ERROR IN APPLICATION: obj == null
01-25 19:02:58.559 22033 22033 F art     : art/runtime/java_vm_ext.cc:470]     in call to CallIntMethodA
Devin-Licastro commented 2 years ago

"please re-try with this one:" Hey, so I tried my app with newest air SDK and this runtime and it was quite promising!

Couple of notes:

FeathersControl.defaultTextRendererFactory = function():ITextRenderer { var renderer:TextFieldTextRenderer = new TextFieldTextRenderer(); return renderer; };

note that I didn't experience any crashes mentioned above.

ajwfrost commented 2 years ago

Thanks for the feedback...

the textfields attempting to use the embedded English fonts were no longer rendered

I wouldn't have expected anything we did to change how the embedded font rendering worked .... but we will check on this. One of the team has been doing some further testing, I should get an update tomorrow.

thanks

ajwfrost commented 2 years ago

@Devin-Licastro having just tested this myself quickly, I can't see a problem with embedded fonts; are you able to provide any code snippets or samples that demonstrate the issue?

Have tried both the TextField and TextBlock/TextLine mechanisms, cpu and direct mode rendering, but I can see the text appearing as normal in both cases..

thanks

Devin-Licastro commented 2 years ago

Hmm, we embed the fonts like this:

[Embed(source="../../../../assets/fonts/proxima-nova-regular.ttf", embedAsCFF="false", fontFamily="Prox_R", fontWeight="normal")] private static const customFont:Class;

Then in general we create textfields like: var textFormat:TextFormat = new TextFormat('Prox_R', 24, 0xffffff); var tf:TextField = new TextField(200, 50, "Text to display"); tf.format.setTo(textFormat.font, textFormat.size, 0xfffff); tf.pixelSnapping = true;

Let me know if this doesn't help and a sample project is needed

Note that it is a Starling.text.TextField and Starling.text.TextFormat

ajwfrost commented 2 years ago

Okay thanks, let me get a test together using Starling for this...

[edit] actually .. it seems that we can reproduce it if we draw a normal TextField into a bitmap data object, where the text field is set up to use embedded fonts. Which is what I would expect Starling to be doing here.

The below function is working unless both useEmbeddedFonts and drawViaBitmapData are true, it's ending up with a black bitmap... (and if I remove the bmData.draw call, I get the green bitmap as expected...)

            const useEmbeddedFonts : Boolean = true;
            const drawViaBitmapData : Boolean = true;
            var tf : TextField = new TextField();
            tf.defaultTextFormat = new TextFormat("alger", 80, 0x0000ff, true);
            tf.embedFonts = useEmbeddedFonts;
            tf.text = "Embedded test";
            if (drawViaBitmapData)
            {
                var bmData : BitmapData = new BitmapData(500, 200, false, 0x00ff00 );
                bmData.draw(tf);
                addChild(new Bitmap(bmData));
            }
            else
            {
                addChild(tf);
            }

So this is one we'll look to fix asap...

thanks

a9848840 commented 2 years ago

Hi @ajwfrost

I need to inform my settings additionally

xml

<BuildLegacyAPK>true</BuildLegacyAPK>

jdk1.8.0_111

ajwfrost commented 2 years ago

@a9848840 thanks although it didn't seem to be a 'debug' build so we weren't able to override the runtime being used there.. but I also couldn't get it to crash, am not sure what steps there should be ... we've added some protection into the code though around the locations where your crash reports highlighted some potential issues.

@Devin-Licastro we've got a fix for that issue with the embedded fonts being drawn into a bitmap data object now.

Plus some optimisations to try to reduce the JNI overheads... so it's pretty much ready now I think.

Below is a link to an ARMv7 runtime (so into air_sdk_folder\runtimes\air\android\device) and we'll kick off a new release shortly.. https://transfer.harman.com/message/uOokKv7FctQi4chRiGuaTx

thanks

Devin-Licastro commented 2 years ago

Awesome, I've confirmed the fix has worked, great to see! Looking forward to the release!

About the request for logcat filtered by AdobeAIR, not much to see, just the loading of ANEs and some creation/deletion of audio tracks. I can only show this for my non-android 12 device because I'm just using the AWS device farm for the android 12 tests. Anyway Here's how it looks:

`C:\Air\air33.1.1.743\lib\android\bin\adb.exe logcat AdobeAIR:V *:S adb server version (32) doesn't match this client (41); killing...

wmtj commented 2 years ago

AIRSDK 33.1.1.758, Chinese characters worked, but the performance was terrible. On some of the older android phones, the lag was obvious and almost unusable. So to say, This bug, remains unsolved.

ajwfrost commented 2 years ago

@wmtj can I check on the older phones, was the previous mechanism working okay still in earlier AIR releases? The 'new' mechanism is using the standard Android rendering for fonts which is slower as we have to use JNI, although we've been reviewing this and think we can see an optimization to avoid some new bitmap creation that would currently be happening in 'direct' mode SWFs. But it might be that we can continue to use the old approach if the running Android version is < 12..

Just to double check: were the apps on the older phones using 'direct' or 'cpu' mode for rendering?

thanks

wmtj commented 2 years ago

'direct' mode.

wmtj commented 2 years ago

Maybe, “to use the old approach if the running Android version is < 12” is not a good choice, Unless Harman will fix those old Chinese font display bugs that have been around for years (for example: on a part of phones with android8/10/11(not all), '_sans' font does not work, it shows just like '_serif'. the '_serif' makes some chinese characters dispaly in wrong form,such as '才','门','关'...). @ajwfrost

wmtj commented 2 years ago

As far as I can remember, the bugs I mentioned above, Adobe had fixed it in Android 5 era, but it repeated in Android 8 and later. At that time, most of AIR develpers agreed that the AIR was dying, no one would paying attention to this problem, and no one in Adobe would fix it. Fortunately, Harman took over the the AIR development, I saw the hope again.But unfortunately, Harman seems never to have tested Chinese before every AIRSDK releases.It was a huge mistake, especially after the release of Android 12 Beta. For now, I just hope Harman will be able to make a thorough argument before making a technical decision, so as not to solve one issue and create more issues.

If you have no one knows Chinese in your team, please listen to your users and we can provide help if necessary.I am sorry for my poor English, I hope my meaning is clear :) @ajwfrost

matrix3d commented 2 years ago

门 为啥会显示错误，有截图吗，正确的啥样，错误的啥样

ajwfrost commented 2 years ago

@wmtj the reason for all these issues with the text is because of how AIR did the font rendering. In earlier AIR versions (i.e. everything, up to our last beta 33.1.1.1.758) there is a build of the Skia library which is what Android use for their rendering, but this is slightly customized by Adobe; the problem seems to be that in order to optimize the rendering, it loses the wider functionality that Android has for font fallback handling. There are a few workarounds that I can see have been added, but this then broke in the latest Android release.

Our choices here were then: 1) try to continue patching and working around the latest Android changes using the older Skia library with the native rendering methods; or 2) switch AIR to render text in the same way that Android apps do, which should then improve the functionality and is more future-proof.

We did start with the first option but part of the challenge is to do this, we need a build environment where we can build the whole Android source code from 4.0. And that's just more and more of a problem as the tools and environments no longer exist. Hence the idea of looking at the new mechanism.... although there have obviously been a few challenges with this, in particular for GPU mode and because of the performance (having to use JNI and also some copying of pixels from 'Android/Java' structures into the AIR framebuffer).

So we're dealing with some of the limitations of Android and the fact that the NDK doesn't give us all of the abilities that we need in order to optimize the rendering. But I think with the fixed/optimizations that we're working on currently, it should improve things a fair bit, and we'll see if there are additional updates we can make in terms of caching text images if possible.

We don't have anyone with native Chinese on our immediate team but we very much appreciate the inputs and comments that folk are making here, I have to confess I wasn't aware that there were such historical issues with Chinese text in AIR in those earlier Android versions.

We'll get a new beta build out before too long with the latest optimizations so hopefully this should improve it.

wmtj commented 2 years ago

@matrix3d @ajwfrost [Compare Image]()

This issue only occurs on a part of phones with android 8/10/11, not all. It might be fine before a system upgrade, but not fine after the upgrade. I guess the customized Android from various manufacturers may change some of the font files in specific versions , the AIRSDK detected it and automatically change '_sans' to '_serif' or others. As the picture above shows, the font is very weird.

matrix3d commented 2 years ago

@wmtj 这是什么原因。为啥门字，会变成错误的。我在游戏中也发现了这个问题

matrix3d commented 2 years ago

也就是那个错误的门是啥玩意？日本字？

matrix3d commented 2 years ago

@ajwfrost what diff textfield and stagetext,the stagetext.drawtobitmap work good

ajwfrost commented 2 years ago

Hi @matrix3d

The StageText implementation is an Android text field (android.widget.EditText) that's displayed in an overlay layer on the screen, so all the calls that you make to format etc in ActionScript are sent through C++ into the Java layer to change that text field. When you capture it in a bitmapdata object, it's then creating an Android Bitmap object and a Canvas associated with this, drawing the StageText container into this canvas, and then getting the pixels from that Bimap.

So that's not massively efficient, but it's fairly similar now to what we're doing. The challenge that we've faced is to integrate into the rendering mechanisms .. there are different approaches for the various different render modes in AIR, hence e.g. not working in GPU mode as they are all set up as textures without background framebuffer objects; in direct mode it seems we've got some issue with elements disappearing which may be due to clip rectangles or caused by the copying ... some of the inefficiencies are because we've got a canvas/bitmap for the text rendering, but this is being drawn on top of something else so we need to allow it to draw what's underneath, then grab that part of the frame buffer and get Android to draw the text on top, and then copy that back into the main frame buffer for anything else to go above that.

Anyway -> getting some progress, I'll try to get an updated runtime posted here later on so that you can all check it...

thanks

ajwfrost commented 2 years ago

FYI there's an updated runtime for arm64 available below. Needs some further work and optimizations as well but would value any feedback! https://github.com/airsdk/Adobe-Runtime-Support/issues/1630#issuecomment-1037230015

thanks

wmtj commented 2 years ago

@ajwfrost

  1. 'Textfield.cacheAsBitmap=true' cause Buttons and other DisplayObjects disappeared.
  2. 'Textfield.useEmbedFont=true' cause textfields disappeared. 31.1.1.758 is OK.
  3. Textfield.width & Textfield.textWidth, it still looks wrong.
  4. The last character is still cut, same to 31.1.1.758.
  5. Textfield colors are totally messed up.
ajwfrost commented 2 years ago

Okay thanks for that feedback .. below is an updated version that should provide better functionality. We've reverted the idea of using an Android Java-backed bitmap for all of the surfaces which means that the cache-as-bitmap etc stuff will work again.

The current issues:

I don't know how much we'll be able to do about the direct-mode text rendering because so much of the logic in the AIR rendering engine expects a particular pixel format and the Android Bitmap object is different. But (a) it's just the emojis (or more specifically, any text glyph that you can't control the colour of) and (b) I'm hoping people don't actually use normal text fields in direct mode a huge amount; it would be better to use Stage3D...

For the render-to-bitmapdata, we can fix that but it would have a performance hit. In fact there's already a performance hit with the fact that we have to copy the text image over to the BitmapData image: my preference here would be to provide a specific new function which would be more optimized, such as TextField.renderToBitmapData() or something where we know that the surface is just for text rendering rather than anything else...

If you see any other colour issues please let us know, it should now just be these emoji colours that are inverted... we'll keep looking at how best to solve this and will put in some further optimisations.

thanks Runtime.zip

wmtj commented 2 years ago

@ajwfrost The performance is a little better than previous verison, but it is still too slow compared to 31.1.1.6xx. In my App, there is a complex page with more than 200 textfields. I tested it on an old phone (Kirin 659 Processor, Android 9), the old version app with AIRSDK 31.1.1.6xx takes only 2 seconds to show, while the new verison with the runtime you given above takes 34 seconds(First time execute after launched), 8 seconds(execute again) :(

wmtj commented 2 years ago

@ajwfrost This bug has been going on for almost 4 months, and we have lost a lot of users.If you are still unable to improve AIRSDK performance to the previous level in February, I suggest you consider“to use the old approach if the running Android version is < 12” as a temporary solution, as soon as quickly! Thus, at least we can release a new version to the Play Store.

matrix3d commented 2 years ago

@wmtj 用嵌入字体

wmtj commented 2 years ago

@matrix3d 嵌入字体可以解决一般场景的汉字显示，比如菜单、按钮等的显示都是没有问题的，但涉及到复杂的场景，则有局限性,例如：

1.一系列 TextFields 先被添加到Sprite上，这个Sprite的尺寸不是固定不变的，要适应不同尺寸的屏幕或者应对某些伸缩变化，改变Sprite的width和height，如果使用嵌入式字体，则会造成字体纵向拉长或者横向压扁。而使用AIR的“_sans”则没有字体拉伸问题。

2.某些需要中文、日文、韩文和泰文等东亚语言文字两种或者多种混合显示的场景，使用嵌入式字体往往力不从心：嵌入中文字体，TextField指定该字体名后则只能显示中文，显示不了泰文……而使用AIR的“_sans”则没有此限制。

以上，也有可能是我的使用方法不对，如有错误之处，请大家不吝指出。谢谢！

Embedded fonts can solve the problem of displaying Chinese characters in general scenes, such as menus and buttons, but there are limitations when it comes to complex scenes, such as:

  1. A series of TextFields are added to a Sprite. The size of the Sprite is not fixed.Changing the width and height of the Sprite to accommodate different screen sizes or to accommodate some scaling changes can cause the font to stretch lengthwise or flatten horizontally if you use an embedded font.AIR "_sans" has no font stretching problems.

  2. In some scenes where two or more east Asian languages such as Chinese, Japanese, Korean and Thai are required to be displayed together, it is often difficult to use an embedded font: If embedded Chinese font, when TextField specifies the font name, it can only display Chinese, but not Thai. AIR "_sans" has no this limitation.

Above, if there are mistakes, please tell me. Thank you!

ajwfrost commented 2 years ago

@wmtj I think the first of those issues - with stretched text - should not happen with embedded fonts unless something's been set up slightly wrongly or unless they're being rendered to a bitmap..?

Anyway -> we are going with your suggestion from earlier which means a version that uses the old library for pre-Android 12 devices and the new mechanism for 12+, with a view to then (a) optimizing the new code, or (b) trying to get a separate native library together from a more modern Android build that we can use without needing JNI...

thanks

wmtj commented 2 years ago

@ajwfrost Here is an example of 'EmbedFont cause stretched text' : [Screenshot]() [Code]()

The example shows the difference between TextField with '_sans' and embedFonts while scaling their parent Object height(keep width the same) : The width and height of TextField with '_sans' are enlarged in equal proportion, TextField with embedFonts enlarged height observably, width is enlarged slightly.

Is there anything wrong in the example code ?

ajwfrost commented 2 years ago

Thanks @wmtj .. so I see what you mean. And I can kind of see it two ways here! What's essentially happening is a sprite is having a text field drawn onto it with a size of 1000x150, and then the sprite height is changed to 220 whilst the width stays the same. So in a way you could assume this is intended to stretch the contents of the sprite - which is actually what the documentation says too (for DisplayObject.height, when you set this it changes the scaleY property...).

So I suspect we could almost say that it's the device text (non-embedded fonts) that's not behaving properly, although of course device text is drawn by the device and doesn't support scaling etc which is why we've ended up with this discrepancy.

Seems a bit weird but I'm not sure we should change how this works, it's very likely that there are people who depend on this behaviour!

An interesting aside though, thanks for the example...

matrix3d commented 2 years ago

这正是嵌入字体的厉害之处。非嵌入字体是不能非等比例缩放的，嵌入字体可以。

wmtj commented 2 years ago

@matrix3d 确实如你所说，这两种方式有不同的表现和用途，在我的使用场景里无法用embedFont代替'_sans'，这就是我为何急于请ajwfrost尽快发布可用版本的原因。

@ajwfrost Yes, It is an interesting example that explains why I can't use embedFont to solve the issue.

FliplineStudios commented 2 years ago

Anyway -> we are going with your suggestion from earlier which means a version that uses the old library for pre-Android 12 devices and the new mechanism for 12+, with a view to then (a) optimizing the new code, or (b) trying to get a separate native library together from a more modern Android build that we can use without needing JNI...

@ajwfrost Since the classic text rendering will still be present and usable in the SDK as you mentioned, is there any chance we can opt-in/opt-out of this new rendering mechanism for Android 12+, perhaps with a setting in our app xml? For developers like us that don't ever use Chinese text or emoji in their apps, I'd love to be able to have the same classic text-rendering experience in our apps regardless of Android version, and not have to worry about performance or other issues arising from some of our end users running Android 12.

mucoci commented 2 years ago

It's not a good idea~

Actually, the garbled text is not only in Chinese.. also in Japanese, Korean...... All the characters like this type will be garbled...

Unless your app only faces the languages which use alphabetic like English or French...... Otherwise, you will need to handle this in the future

FliplineStudios commented 2 years ago

Yes that's what I meant, our apps only use the Latin alphabet and limit the characters for text input, so while this new text rendering is still experimental it would be great for developers to opt-in/opt-out so they can use the classic rendering in the meantime, and not have to stick with an older AIR SDK version until things are stable.

I was thinking more along the lines of back when Adobe made a big change to their AOT compiler, and we could specify the adt -useLegacyAOT flag while they were still fine-tuning it to opt out and stick with the original AOT compilation temporarily, and then eventually when it was considered stable the useLegacyAOT flag was ignored during compilation.

ajwfrost commented 2 years ago

Okay so with an extra tag in the XML descriptor, we can change the Android version on which the change in rendering mechanism takes place. It's actually handy for our testing/comparisons now, as we can just switch the number down to try the old vs the new mechanism. If you want to have this new mechanism on all devices, set it to 14; if you don't want it at all, set it to 99999 or similar, the default is for Android 12 i.e. API level 31.

With some other updates that knock out a lot of the JNI calls, plus copying/manipulating memory via SIMD instructions to speed some of this up, it looks like we're at a fairly similar behaviour between these now. The only change seems to be that we've fixed the colour of the emojis if you're rendering onto a bitmap data object..

Will kick off the release process shortly so this should be available early next week

thanks

a9848840 commented 2 years ago

Hi @ajwfrost

I'm sorry to keep urging you, because android 12 text is related to the company's revenue, can you focus on the text part first?

thank you

ajwfrost commented 2 years ago

Hi @a9848840 - I think we've got a much better implementation now, at least from the test cases that we've got here, and it's just going through the last QA processes this morning. All being well, we'll push it up to the website tonight.

thanks

ajwfrost commented 2 years ago

Hi @a9848840, @wmtj please try the latest build of the AIR SDK: https://airsdk.harman.com/download/33.1.1.779

thanks

a9848840 commented 2 years ago

Hi @ajwfrost

Initial installation and use test functioning normally Thank you very much

wmtj commented 2 years ago

@ajwfrost Thank you and your team for the hard working!

The performance is much better than the previous 758. It is acceptable on Android 12 now. It is still slow on old android phone with new rendering mechanism. After setting '<newFontRenderingFromAPI>31</newFontRenderingFromAPI>',it works.

I found another severe issue(At least it seems to be): A white screen may occur after a specific operation in 'direct' mode. In 'cpu' mode, it works fine, no white screen. I have recorded the 'white screen' video and will send the link to your email later. My app is not a game app, it can run both 'direct' and 'cpu' mode, but in 'cpu' mode, the display effect of Chinese characters is significantly inferior to 'direct' mode with old rendering mechanism.

Although it still doesn't look perfect, at least it works. Maybe I should pack an armv7 package using 33.1.1.743, armv8 using 33.1.1.779 .

PS: 'The last character is cut' is still exist. Some of the textfields, not all. The same code, old rendering mechanism works fine, new rendering mechanism shows cut.

a9848840 commented 2 years ago

HI @ajwfrost @marchbold

AIR SDK 33.1.1.779

A crash occurs on ADMOB operation It happens 1 time out of 5 when I test At the trigger point of requesting an ad

Should I open another question? crash.txt

ajwfrost commented 2 years ago

@wmtj - are you able to create a demo showing the cut characters? not sure what's happening with that.. and in the white screen, do you see anything on the logcat output?

@a9848840 thanks for the log - nothing to do with admob from what I can see:

02-22 17:16:49.019 32087  1569 F winner.bwmj16t: java_vm_ext.cc:675] JNI ERROR (app bug): global reference table overflow 02-22 17:16:49.019 32087  1569 F winner.bwmj16t: java_vm_ext.cc:675]   Summary:
02-22 17:16:49.019 32087  1569 F winner.bwmj16t: java_vm_ext.cc:675]     49626 of android.graphics.Paint (49626 unique instances)

So this means we're creating Paint objects but not destroying them .. will have to work out where this happens!

thanks

wmtj commented 2 years ago

@ajwfrost I've spent the whole day trying to build a demo that recreates the white-screen problem, but I failed. I do not know the cause of the problem and how to trigger mechanically, so …… I will send the link to your email later, I hope you can find it in the phenomenon.

ajwfrost commented 2 years ago

Okay thanks @wmtj we will see if there's anything we can spot happening that may be the culprit.

@a9848840 looks like a base class not having a virtual destructor meant that we weren't releasing the Java paint object reference... :-(

wmtj commented 2 years ago

@ajwfrost Here is a demo showing the cut characters. It looks like that if the first character is a Chinese punctuation mark, TextField.textWidth will be wrong value.This is a pattern that I have just found, and there are many more that have yet been unfound. It is similar to #1630 @itlancer reported.

[ScreenShot]()

Code ： `var _tfmt1:TextFormat = new TextFormat("_sans", 50, 0); _tfmt1.align = TextFormatAlign.CENTER;

var _txt1:TextField = new TextField(); _txt1.defaultTextFormat = _tfmt1; _txt1.text = "简体中文测试，繁體中文測試。"; _txt1.width = _txt1.textWidth + 12; _txt1.height = _txt1.textHeight + 4; _txt1.border = true; _txt1.x = 100; _txt1.y = 200; addChild(_txt1);

var _txt2:TextField = new TextField(); _txt2.defaultTextFormat = _tfmt1; _txt2.text = "简体中文测试（繁體中文測試）测试"; _txt2.width = _txt2.textWidth + 12; _txt2.height = _txt2.textHeight + 4; _txt2.border = true; _txt2.x = 100; _txt2.y = 300; addChild(_txt2);

var _txt3:TextField = new TextField(); _txt3.defaultTextFormat = _tfmt1; _txt3.text = "（简体中文测试繁體中文測試）测试"; _txt3.width = _txt3.textWidth + 12; _txt3.height = _txt3.textHeight + 4; _txt3.border = true; _txt3.x = 100; _txt3.y = 400; addChild(_txt3);`

a9848840 commented 2 years ago

Thank you for your team's hard work, please keep it up

If there is any new progress, please let me know, thank you

ajwfrost commented 2 years ago

@wmtj thanks for that .. so it looks like the "bounds" that we get back from Android (Paint.getTextBounds()) will be just a bounding rectangle that encloses the pixels that would change, rather than including the space at the start of that "（" character. If we switch to using Paint.measureText() then it gives us an accurate value for the width of the text as we'd need when appending it onto other pixels... So, with this change, I can see that test case fixed...

I didn't get any email with the video on it, it may have been rejected/blocked by our email systems. In case you can upload something, please try using this link: https://transfer.harman.com/requests/vYK8tct7lGKQUaqGZhnID1

@a9848840 we did have our test case for this crash with the same error after we left it for a few hours. Once we changed to ensure the specialized class's destructor was properly run, the same test case has just been running overnight and is still going 10 hours later.

thanks

a9848840 commented 2 years ago

Hi @ajwfrost

I currently have a situation using AIR SDK: 33.1.1.779

After package apk file and re-sign upload file to googleplay store 64-bit re-signed apk received the following message

The APK you uploaded is not compressed and calibrated. Please run the compressed calibration tool on your APK and upload it again.

32 bit apk update normally

Then I upload the unresigned 64-bit file can be uploaded normally

Do I need to make changes to re-sign 64-bit?

set CURL_EXE=C:\curl-7.71.1-win64-mingw\bin\ set AF_SDK_URL=https://repo.maven.apache.org/maven2/com/appsflyer/af-android-sdk/6.3.2/af-android-sdk-6.3.2.aar set ZIP_APP=C:\Program Files\WinRAR\WinRAR.exe set SED_APP=C:\Program Files\Git\usr\bin\sed.exe set JSIGN_APP=C:\Program Files\Java\jdk1.8.0_111\bin\jarsigner.exe set ZIPALIGN_APP=C:\Users\myfile\AppData\Local\Android\Sdk\build-tools\31.0.0\zipalign.exe set APKTOOL_APP=C:\Windows\apktool.bat set APKSIGN_APP=C:\Users\myfile\AppData\Local\Android\Sdk\build-tools\31.0.0\apksigner.bat