Fix ofTrueTypeFont: wrong width calc (only when string contains \n)

[hiroMTB]

Problem

ofTrueTypeFont::stringWidth() and ofTrueTypeFont::getStringBoundingBox() give a wrong width value because these ignore \n, and width value piles up, getting longer and longer if you have multiple \n.

screenshots

• Before

• After

• After (OF_TTF_RIGHT_TO_LEFT)

Link to the current code

• stringWidth https://github.com/openframeworks/openFrameworks/blob/2b8cab27d5b2dfc85be6cffc5119dce3d609f79c/libs/openFrameworks/graphics/ofTrueTypeFont.cpp#L1164-L1169

• getStringBoundingBox https://github.com/openframeworks/openFrameworks/blob/2b8cab27d5b2dfc85be6cffc5119dce3d609f79c/libs/openFrameworks/graphics/ofTrueTypeFont.cpp#L1193-L1199

Tested with ...

• latest master
• on macOS 13.4
• OF_TTF_LEFT_TO_RIGHT
• OF_TTF_RIGHT_TO_LEFT

Gist

https://gist.github.com/hiroMTB/e5c746c6403da714f74cf4f37b711451

[dimitre]

Great one! I'm wondering if in the future in another PR we can test calculating it inside tab getGlyphProperties(' ').advance property. I see a lot of duplicated code with getGlyphProperties(' ').advance * spaceSize * TAB_WIDTH and some of them are different than others like

g.props.advance + getGlyphProperties(' ').advance * spaceSize * TAB_WIDTH

[hiroMTB]

I agree, we could make a helper function like getTabWidth()

ofTrueTypeFont class needs good update and tidy up. But at the same time, it's easy to add another bug and hard to find it because we need to see output graphics.

That makes me(or contributers) nervous to touch this class, and avoid sending PR. It might be nice to have a test code. (e.g. check bounding box for different strings input, for different font, check kerning value etc, only for default font). Or render a png of font example app and compare before after the commit so that we make sure it doesn't break other feature.

[hiroMTB]

Also I found my changes have strange indent. I will fix it but it looks good on Xcode.

[hiroMTB]

ready for merge😀