Text whitespace handling issues, \t ignored

[jgarvin]

Describe the bug There seem to be some minor inconsistencies with how whitespace rendering is handled.

• Putting \t at the beginning of the string to draw does nothing, but leading spaces instead do work.
• Putting \n at the beginning of a string does change its drawn dimensions, but putting \n at the end does not.

To Reproduce Draw strings with \t, or draw strings with \n at the beginning or end with ggez::graphics::Text.

Expected behavior Always respect and render whitespace and report it as part of text dimensions.

Hardware and Software:

• ggez version: 0.5.1
• OS: Linux, Ubuntu
• Graphics card: Intel integrated
• Graphics card drivers: Open source

[icefoxen]

This one is tricky 'cause the amount of layout done by the text rendering is kinda limited. Related: #687 .

[nobbele]

Putting \n at the beginning of a string does change its drawn dimensions, but putting \n at the end does not.

leading or trailing \n, neither changes dimensions() and both change how its drawn (just that trailing makes no difference). It seems consistent to me

[PSteinhaus]

@jgarvin Do the things you mentioned pose a problem to you in any way, or did you just stumble over some inconsistency and simply wanted to make us aware of them?

Since whitespace is generally not considered part of the dimensions of text in glyph-brush the one real bug hiding in all of this seems to be \t not working at all.

I opened an issue for this problem on the glyph-brush repo, but to make life easier for them it would be good to know whether tabs in text are actually something you (or anyone else reading this) really needs in ggez. If so, the next question would be: How exactly would you expect \t to behave? (i.e. would representing a \t through 4 times space be enough for you?)

[jgarvin]

I was able to work around it, but it does create the need for special cases around text rendering. I used ggez to create a text adventure (with some minor graphical elements). Naturally for a text adventure you need to render paragraphs of text, with indentation. In a text adventure you're often rendering a mix of pre-programmed string literals and dynamic content. You might have a string literal like "Item List:\n\n" and then iterate through a Vec<String> rendering each one separately. Each time you render something you check the y size to determine how far down the next text rendering should appear. But since newlines at the end don't count towards size, this obvious approach doesn't work. Understandably most text in ggez is probably stuff like just making the word SCORE appear in the corner, but for a text adventure or an RPG where there's a quest log or journal or whatever handling these cases might be nice.

[nobbele]

That use case would already work with fragments no?

let mut text = Text::new();
text.push("Item List:\n\n");
for item in items {
    text.push(item);
    text.push("\n");
}

But if you must have it separate, you could just manually calculate it by offsetting the text by (font size * 2), it shouldn't be that much extra work. I don't think it's worth adding extra API for such a niche use case.