Hey, just encountered an obscure problem involving word wrap (1.13.2). If the final character of a line is a hyphen, it looks like the wrapping doesn't occur until afterward. This seems to happen regardless of whether Insert Hyphens is enabled. This causes the text to expand outside of the RectTransform's bounds, which probably isn't intended behavior (and it can be a problem if the STM is inside a mask, which is what happened to me just now).

I was able to reproduce this quickly in a blank project, so I think you'll be able to do the same, but let me know if it looks different on your end.

Hey!

This is something that's been in STM for a long time, and I kept wondering if I should change it or not... essentially, it works like this so that as it inserts hyphens, the rest of the mesh doesn't change to accommodate this, and manual hyphens get included in this too.

I really should revisit this and make it work in the way that would feel more natural, though. I feel like I would have tried to make it work that way and hit some wall in the past, but maybe I can come up with a real solution, now.

Hey, good to know. Yeah, I think it makes sense to treat auto-hyphens and manual hyphens differently (or you could set it to take manual hyphens into account if the insertHyphens bool is turned off, because in that case it wouldn't matter).

It can be an issue for any situation where there isn't much whitespace around the RectTransform, because the hyphen ends up sticking out (especially with a monospaced font). And, as mentioned, it can be a problem when working with masks — this one is within a ScrollRect, and the Viewport has a mask. If the content and viewport are the same size, the hyphen ends up getting skipped entirely, because the whole char is outside the bounds of the viewport. I sort of worked around this by changing how the padding is set up, but you get the idea.

right, i think one of my reasonings for leaving it in was that I was making a lot of textboxes with ample whitespace on the sides at the time (like the sample scene) but for something with a scrollrect... I'll revisit my line-end algorithm soon! It might be a bit since it's a low priority and you already have a workaround and I've been very busy recently, but I do want to make this change!

Actually, I'm not sure if this is the same issue, but it looks like word wrapping in Japanese doesn't work too well when Break Text is turned off. You can try it with the following block:

この世界のゲームマスターである我でさえ、<c=binary><w=superglitch>彼を止める力はない。<c=binary><w=superglitch>彼は、憎しみで成長し、愛をも糧とする、不正なAIだ。

<c=binary><w=superglitch>彼を止められる唯一の武器は無関心だ。しかし、現時点では、己が彼に無関心になることは不可能だと……本物のカメロンに対しては。

<c=binary><w=superglitch>カメロンは、<c=highsatrgb>gekka_senninの最も野心的な夢をもはるかに超える存在に成長した。「パンドラの砂場」には、<c=binary><w=superglitch>彼を倒すのに役立つ秘密兵器やアイテムはない。<c=binary><w=superglitch>彼は存在するはずのなかったボスであり、ゲームにプログラムされることのなかった存在で、ゲームそのものよりも強力になってしまった。

いざという時、主人公はいつも「愛の力」に頼って形勢を逆転してきた。しかし、愛そのものが<c=binary><w=superglitch>彼の動力源であるとき、どうやって倒すことができるのだろうか？ <q=clicktocont>

(It should be possible to test this without all of the <c> tags).

Basically, if you attach a Content Size Fitter with Vertical Fit: Preferred Size, and then drag the width around, the wrapping will eventually get messed up. It might be related to the 「 chars.

I'll give it a look shortly! But yeah that doesn't sound right... it should use the linebreak rules for japanese unless break text is turned *on* (which just, ignores formatting)

Maybe there's a rule I missed in regards to 「 characters so I'll give it a look next

Just checking in - do you think you can look at it this week?

I might have to copy-paste the solution into the scripts rather than installing the update, just to avoid introducing other bugs. I'm getting close to wrapping things up with this game, so I'm trying to be extra-careful with updating things now.

Hello,

Honestly, I don't think I can look at it this week... Big life changes just happened, so I need to take the week off for the first time in a long time. 

For the time being, is it possible to leave a bit of extra room on the right side of the text box? I really do want to revisit this, I just remember it being a very tricky issue, so I really don't want to give a time promise...

Hey - all right, thanks for the update.

Yeah, the phone interface works okay in English (the most that it can spill over is just one char). It's a bigger problem in Japanese though, because the 「 chars seem to be unpredictably breaking the word-wrapping. It still renders okay in this specific situation (the text is center-aligned, and I guess there's more padding than normal), but it sometimes spills over by more than a char, so it isn't necessarily fixable by adding more padding.

If you want to try and make a change yourself, inside of SuperTextMesh.cs there's a large array named "linebreakFriendlyCharacters" and another for unfriendly characters... I think. It might be that I forgot 「 or put it on the wrong list?

Hmm... I had a look at that part of the code, but the solution might be more complex. Here's how it looks for me:

We can see that the problem is at the 「愛の力」 line, but it's unclear why the line didn't break at the end of the sentence, at the しかし、愛 part. Even if there's a rule saying that a linebreak can't occur at a 「 or 」, the end of the line should be unaffected by that, if I'm not mistaken.

Okay yeah that is weird... It should want to break at that period there... I'm still not able to look just yet, so my temporary hacky answer is... make a pre-parsing script that inserts a zero-width space before a 「 and after  」? Really sorry again, I've got a lot to take care of at the moment but I want to give this a close look soon

Sure, let me know when you take a look at it. For now, our hacky solution is to just add manual linebreaks for certain situations. Not sure how many of these are in the game, but this is the first one I've found so far, so it might be possible for us to just manually avoid this situation in the meantime.