I've noticed when rendering a lot of text that is split over multiple lines it can happen that the text is truncated and ellipse is appended to the end of the text despite there being plenty of remaining space to render the text.
Here's a screenshot of what I'm talking about. In the screenshot below, the rectangle shows the area being given to render the text in, and you'll notice that the text is cut-off despite there being plenty of space remaining. I was working on integrating Japanese translations into an app. So, the text is in Japanese:
http://ftp.eventide.com/ljdl/www/JuceTruncatedTextBug.png
I've created a small sample app demonstrating the problem and uploaded it to github. It's what that screenshot comes from.
git clone https://github.com/gkellum/JuceTextTruncationBug.git
Having spent a few hours going through the GlyphArrangement::addFittedText method in a debugger, I think the basic problem is that the method tries to estimate at the start of the method how many lines it will need to render the text, but because it doesn't know where line breaks will occur it can only estimate who many lines it will need. And then it proceeds to try to render the text into these given number of lines. And if it runs out of space, it just truncates the text despite there being plenty of vertical space remaining.
I think what it should do is not try to pre-calculate how many lines it will need but just keep track of the y offset of the text rendering. It should be able to tell from the y offset when it's reached the last line and then truncate that line. This means it will always use all of the space available and won't need to make a potentially incorrect estimate of how many lines the algorithm will need.
Thoughts? I could submit a fix if you all are in agreement about what the problem is.