[Question] line breaks in textbox

[zpl-zak]

Hey,

we've recently updated canvas and have noticed few improvements, however there are still some edge cases (that were also present in older iterations) that we aren't sure about and it feels like the line breaks don't seem to behave correctly.

Here's a demo image:

To me it feels like the first highlighted sentence could contain a few more words than it does right now. I've tried removing the comma, that does not seem to have any effect at all either. If this works as intended, I'd like to ask for some clarification for why this edge case happens,

Here is an isolated demo with the textbox above being rendered:
linebreaks.zip

Note the demo currently uses a fork of your font repo (matches master), because of an issue we've opened just recently: tdewolff/font#5. Otherwise the demo would panic while loading the provided font.

[tdewolff]

Thanks for the issue, this should now be fixed!

[zpl-zak]

Hey,

I had a look at the textbox wrap handling, while the change did ensure more words fit on a single line, it had a side effect where occasionally, the text would overflow textbox width, causing some overlaps with other elements.

However, I tried to figure out what exactly has changed the line break behavior in the first place and I feel like f1581cb#diff-55d9a4bda7ac820feb7545bb7c241602a510d8ddcc5598a03c60f147eaf21b1bR296 was the change since when these edge cases (mentioned in the original post) started to occur.

Reverting back to a linebreak.go from before this commit revision got me back to old renders, where line breaks still happened more naturally.

[tdewolff]

Yes, but that would undo the change above and the problem of your previous post would reappear, doesn't it? It is true that the commit you reference is a custom addition to the algorithm and is not part of the original, but the original doesn't handle all cases correctly as far as I can see.

I believe the problem you describe is mostly in combination with literal line breaks. I'll try and reproduce the problem and see if it can be fixed.

[zpl-zak]

Yes, but that would undo the change above and the problem of your previous post would reappear, doesn't it? It is true that the commit you reference is a custom addition to the algorithm and is not part of the original, but the original doesn't handle all cases correctly as far as I can see.

I believe the problem you describe is mostly in combination with literal line breaks. I'll try and reproduce the problem and see if it can be fixed.

True, the change above might still be beneficial in the long run, I have not tested a combo of having this change applied with the custom addition from commit above reverted, maybe there's a wiggle room in there we could work with.

In fact the line breaks do appear to be more natural with the change you made, but sadly the overlap issue prevents us from going that route. I agree, could be a combo of changes causing this issue.

Thank you for looking into it!

[tdewolff]

This should now be fixed, I've added tests so that we don't see regressions anymore.