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.

Hey, coming back to this for a moment - now that we're doing LQA, the exact scope of the problem is pretty clear. The issue is, if breakText is false, STM tries to add a line break before the 「 or [ chars.

You can try it yourself with this text:

スライムとして生活すれば、それは本当に「自分」なのか？<d=0.5sec> 我の自我は「身体」と「心」のどっちでござる？<d=0.25sec> もはや違いはあるじゃろう？

Below is with breakText = false:

And this is with breakText = false:

The zero-width space didn't work, but using your idea about the pre-parse event, I decided to make a script to swap the breakText setting if the upcoming string contains one of those bracket chars, and then switch back to default after.

I'm guessing this all has something to do with the block of code at line 3596 in STM, but it looks too finnicky to edit myself.

I might have mentioned in some other thread, but I basically can't risk updating STM at this point, because any changes might break things unexpectedly in other parts of the game. So I'll probably stick to this pre-parse solution. But, the information is here, anyway. Right now, the asset isn't really usable in Japanese without this workaround, because setting breakText to false all the time isn't the best solution (it could cause too many line breaks if a sentence has several commas etc).

I'll give the code a look on a workday! Chances are, if it's something in *this* part of the code, we should be able to retrofit the solution into your project. I want to fix this asap...

Sure, sounds good. It's worth looking into on your side anyway - and for me, yeah, I can take a look at what the change is and maybe add it in.

Hey!

Just checking, is this a more desirable result?

I found that some logic was misbehaving involving the "insert hyphens" variable, where STM was giving different (and way too far) breakpoints when hyphen insertion was disabled. This is some of the oldest code in STM and is pretty english-oriented, so it was only a matter of time until some cases like this popped up. 

I also temporarily removed the japanese comma and period as being linebreak-friendly positions for the above result, as STM would overly favour them as linebreak positions. I'd still like it to be a "friendly" position, but only when it's near the edge of the text box. Going to keep working on that, but if this looks good, I can hack it into your version of SuperTextMesh.cs for you!

I'm still working on this, there's still a few text elements that can go over the box limits...

Still playing with this, now I've got this result:

Break text off:

and break text on:

This seems to be a more desirable result for Japanese, but the first result should be respecting the bounding box size, and it's not. So I'm looking into why that's the case

Ok, i think I got it... this is how it looks with "break text" off, now.

Hey - yeah, I think that last one is about right! I'm not sure if that last break between ある and じゃろう is normal/intended, but I guess that's to keep it in line with the rest of the box? And yeah, I can see that it's auto-breaking at the 「 chars like it should.

Either way, as long as it stays within the bounding box and follows a reasonably consistent pattern for breaks, that's good enough for me. Let me know what the changes are, and I'll see if I can fit it into my version of STM. Thanks!

emailed you the script!