TTF_GetTextSubString returns wrong rectangle when offset is trailing whitespace

[JBetz]

This seems to be an issue with how whitespace is trimmed at the end of input.

To reproduce, run the showfont demo with ./showfont -textengine renderer font.ttf, move the cursor to the end of the input inside the edit box, and then press space. Instead of advancing the cursor, the cursor remains in the same position. Only after inputting non-whitespace characters does the cursor advance to the correct position.

From some experimenting, this only seems to be an issue with the last line of the input. If you add multiple newlines to the showfont edit, then go back to the first line and add spaces after "the lazy dog", the cursor will be drawn in the correct position.

-textengine surface has the same issue.

[JBetz]

I've just tested the new code and it now works correctly for the last line of input but not any of the previous. Additionally, it now renders a newline(?) glyph on the last line, which it didn't before.

[slouken]

Okay, so the problem is you want different behavior when editing than when you are just displaying text. I'm adding a function, TTF_SetTextWrapWhitespaceVisible() to allow you to select which behavior you want. You'll set this to true for your editor.

[JBetz]

Additionally, it now renders a newline(?) glyph on the last line, which it didn't before.

This turned out to be unrelated, and was due to me using TTF_InsertTextString with a carriage return (\r) rather than a newline (\n) on enter key press. Newline or carriage return + newline are the only valid line endings.