[openfl 6.1.0] Textfield issue with bold text

#1

Hi everyone !
I’ve come across a rare bug when the text inside a textfield isn’t properly formated when reaching the end of the textfield width and being bold, here’s an example:
textfield_issue

The word “sentence” should go to the next line and not be separated :frowning: .
Here’s the code to test the issue:

//txtfld is the textfield instance
txtfld.width = 270;
txtfld.htmlText = "Test string to test if anything works well <b>using some bold text at the end of some sentence</b>.\nEnd of the test";

The width of the textfield must be 270 for the bug to appear, if not there is no issue.
With about 250 strings on my game, i have this issue on something like 10 strings.
If i remove the bold tags, the textfield behave just fine.

Do you have any idea what is causing this ?

Thanks for reading ^^.

Also i’m sorry to only post when coming accross bugs, and i know i never mention it, but i love openfl and all the hard work you did on 6.1.0 ^^, cheers !

EDIT: i forgot to mention, it’s for a html5 export, using the canvas renderer, lime 5.4.0

#2

Do you think this is the same issue?

Thanks for putting OpenFL to good use! :smiley:

#3

I’m not sure, i tried to reproduce the bug:
fantastic test
But again, i think it’s because the textfield’s width is “not right” to reproduce the bug.

I noticed a few things, the bug appears whenever i have arial “normal” and “bold” in the same textfield.
It appears whether there is a line break after the bugged word, or not, like here:
diabete_issue

Sometimes if i remove the text after the end of the sentence, it fixes the issue. (but there is also the case where the bug appears if there is no line break after the bugged word :frowning:.

So yeah maybe it has to do with mixing different textformat and having a particular textfield width.

#4

Okay, I’ve added your case here to the issue. This is probably an issue with non-printing characters (such as <font> tags) affecting the calculation for breaks

#5

Possibly, yeah. I’ll check this out today, but if it’s the same issue as the one in Github, we’d need some time in coming up with a complete solution.

#6

Yeah, it’s the same issue.

Edit: probably the issue @fye is that your closing b tag is between “sentence” and the period. As far as the word wrap cares, the period is part of the word. And my GitHub issue is “changing text formats in the middle of a word causes issues.” It may not be ideal, but try putting the b after the period. I’m not sure if that solves it, just a guess.

I found a good test case from this. The period is the only character that pushes line 2 over, but putting something after it causes a very visible line issue.
image

tf.width = 270;
tf.htmlText = "Test even a bit more test string to test if anythin works well <b>using some bold text at the end sdome sentence</b>. stuff";
#7

Hi ^^
I tried your fix @MSGhero using this:

someText = StringTools.replace(someText, "</b>.", ".</b>");
txtfld.htmlText = someText;

In the few cases i could test, it worked when there is no more sentence after the period, but if there is a line break after the period, sometimes it doesn’t :
english_test_period

I tried to reproduce your example but it works fine for me, maybe it’s because the textfield i’m using is created from a swf ? or the font i’m using ? (arial, or font size):
bold_stuff_issue

Anyway, thank you both for looking into it ^^

EDIT: hmm, i tried adding a space after the closing bold tag like this:

someText = StringTools.replace(someText, "</b>.", ".</b> ");

And so far, in 5 cases where i encountered the issue it fixed it, i will test it further.
EDIT2: nevermind, the bug is still here in some cases :frowning:

#8

Yeah it’s kind of a matter of getting lucky tbh. It’s a hard fix (and I’m doing a game jam starting today), but it’ll get there one of these days.

#9

@fye, can you test this with all your use-cases?: https://github.com/openfl/openfl/pull/1771

#10

@MSGhero what version of openfl is this file for ? i tried to compile in 6.1.0 but i have several missing variables.

#11

Latest, I think 6.5.0 and lime 5.8.0 or something like that. But, you can copy the exact changes into your own TextEngine class, and it’d probably work.

#12

When updating to openfl 6.5.0 it seems the issue isn’t there anymore, the words are no longer truncated, but i have some graphics issues. (weird colors on png animations)

I tried to replace the textEngine file of 6.5.0 but the game doesn’t load, the bar is stuck around 55%, and then chrome tab crashes after some time. (lime version is 5.8.2, haxelib 3.3.0, openfl 6.5.0)
I can’t see any errors, it seems the tab froze :\.

#13

Wait, 6.5.0 and using the change I linked to? Or just 6.5? (The change isn’t merged into the main lib yet)

If you didn’t use the change, that’s a coincidence… and the graphical issues are unrelated.

Edit: I can use it fine on HTML5, so idk what issue you’re having. Sounds like an infinite while loop, but I already fixed that in a patch to the linked PR. If possible, a reproducible case would be good.

#14

Could you share more information about the color issues are you are seeing, using a newer version?

#15

I found out what the color issue was, the movieclip had in flash, a hue modifying filter which was not rendered in openfl 5.1.5 (the version i’m currently using in production), but in openfl 6.5.0 it tries to render it but no correctly, here’s what it should do:
face_with_filter
And the result in openfl 6.5.0:
5
And in 5.1.5, the movieclip is rendered without the filter.(which is normal i guess ^^)

For the text engine file, using openfl 6.5.0 without any modification, the loading screen has no issue, but when i replace the TextEngine file, the loading screen is stucked around 55%.
Maybe i didn’t get the correct version, i’m not super familiar with github ^^; i went to this link https://github.com/MSGhero/openfl/blob/c18fcbaeec46d9e758c77ed70cb67f0018734389/openfl/_internal/text/TextEngine.hx and downloaded the raw version.

#16

I think we have a fix in the dev builds:

#17

I just tried it and indeed it works ^^.

1 Like
#18

You have the correct file, but are you also on Lime 5.8.0 when trying it out? If you can figure out which text field and format is causing the problem, that would help.

My patch isn’t complete, so it’s not surprising that there may be issues.