[FR] MultiLineText / Improved Line Height Handling

I see two options for multi line text:

drawMultiLineText() & drawFittedText()

With draw fitted text you can render multiline text with ellipses handled when the text is too large, but the function is weird and tries to squash and do all sorts of stuff no one wants.

With multiline text, you can set the line height (leading?) but it has no overflow options and uses some strange baseline start point which I’ve never seen used anywhere.

I think this is honestly due for an update – line height should be a part of the font class, and the multiline functions should defer to the font for that value. We shouldn’t ever use this baseline Y start point thing where it starts outside the bounds like:

Screenshot 2023-09-21 at 11.06.34 PM

Text should always have a bounding box and justification with that box like:

Screenshot 2023-09-21 at 11.07.04 PM

It seems it would be possible to do a non breaking change to improve this all?

For reference, in design software – lineheight is handled with fonts like so:

Screenshot 2023-09-21 at 10.54.12 PM

^ the 16 above is the line height

Same in CSS & anywhere else I’ve worked with font really.

Why JUCE no work here?

(Edit: I modified this post it was originally about a lack of ability to do multiline text with lineheight and overflow handling, but I think the concerns shared above are more important)

@jakemumu thanks for taking the time to share this. As part of unicode support for JUCE 8 a lot of code regarding fonts is being addressed. While I can’t promise that this will definitely be resolved, JUCE 8 will probably be the best opportunity we have to take a good look at these kinds of issues.


Thanks @anthony-nicholls – Happy to share more when the team has time. I have a UI designed in Figma that I’ve implemented in both CSS & JUCE so I feel like I’m intimately aware of the quirks between all three right now.

In the meantime, is there any way we could think of to render multiline text with line height & a ... overflow handler?

You can easily get rid of the squishing by passing 1.0f to drawFittedText() as the 8th parameter:

void Graphics::drawFittedText 	( 	const String &  	text,
		int  	x,
		int  	y,
		int  	width,
		int  	height,
		Justification  	justificationFlags,
		int  	maximumNumberOfLines,
		float  	minimumHorizontalScale = 0.0f 
	) 		const

"The minimumHorizontalScale parameter specifies how much the text can be
squashed horizontally to try to squeeze it into the space. If you don't want
any horizontal scaling to occur, you can set this value to 1.0f. Pass 0 if you
want it to use a default value."

I believe that you can also disable this globally by using this to set the default to 1.0f, thereby getting rid of any text-squishing on any font drawing routines (haven’t used it myself):

static void Font::setDefaultMinimumHorizontalScaleFactor 	( 	float  	newMinimumScaleFactor	) 	
1 Like

For sure but even with the minimum horizontal scale set to 1 the function doesn’t do line breaks at the expected point, it will do them much earlier than the end of the container and there’s no way to modify the behavior. And then yeah – no line height support as well makes it pretty much impossible to translate a design to JUCE which spans multiple lines and doesn’t use whatever default line height JUCE is using.