Text truncation bug in GlyphArrangement::addFittedText

General JUCE discussion
1

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.

 

2

Here's a diff which implements the fix I described which I'm now using in my local copy of Juce:

http://ftp.eventide.com/ljdl/www/JuceTruncatedTextBugFix.diff

3

I'm digging into another text rendering problem with multi-line help text this morning.  I have some multi-line help text that was being rendered in an abnormally small font.  I tracked the problem down to a utility method I have that estimates how much height is needed to render a particular block of text.  Sometimes, it was under-estimating how many lines it would take to render a given block of text and therefore not enough height was being afforded to the given label so the given text was being rendered in an abnormally small font.  

It occurred to me that the GlyphArrangment class should have a method that tells you how much height is needed to render a given block of text with the given font using the same algorithm that it used to actually split a block of text into lines.  This isn't something that the caller should need to try to approximate in a separate method before (indirectly) calling into the GlyphArrangment class.