Different TextLayout behaviour across platforms

General JUCE discussion
1

The behaviour of TextLayout::createLayout is different across platforms. On macOS and Linux the text is rendered to the end of the bounding rect while on Windows overflowing text is silently truncated. See the attached screenshot.

28
Screen Shot 2019-04-02 at 15.17.28.png1296×646 65.7 KB

This is with word wrap set to AttributedString::WordWrap::none. In my opinion the first behaviour is right while the second isn’t. We would like to exploit the overflow behaviour to add an ellipsis character to indicate truncation.

Q: Why not use drawText, GlyphArrangement, etc?

  • Because we are in a painstaking transition of supporting mixed scripts and font fallbacks. The combination of AttributedString and TextLayout seems to be the only viable option in JUCE for the moment.
  • Also we need to know if a text has been truncated so we can show a tooltip containing the whole text. (I should probably issue a separate feature request post for better international script support.)

Q: Why not overshoot maxWidth in TextLayout::createLayout

This will potentially cause trouble when the text isn’t left-aligned anymore.

As a side question: Is it possible to determine if a TextLayout::Run is rendered RTL or LTR?

2

Not with JUCE, no. Been there, tried that, and went with ICU + Harfbuzz + Freetype 10 years ago to fully support bidi and vector glyphs.

1 Like
3

@luzifer You know what, I may be wrong: grep for AttributedString::ReadingDirection.

On Windows and macOS/iOS, JUCE provides the RTL directionality. Unfortunately the framework doesn’t seem to apply that to the other platforms…

This should help you write up specific requests if you’re looking after new functionality, say adding that to TextLayout::Run or whatever.