Potential Bug: Unintentional line breaks in labels

[kengineer]

With wordwrap enabled for text/labels, I have found that spaces (and dashes) directly preceding an explicit line break character (like \n) will actually result in two lines breaks. This appears to be due to the following function:

static bool is_wrap_space(uint16_t c)
{
    return c == ' ' || c == '\n' || c == '\t' || c == '\r' || c == '-';
}

I haven't dug into the use of this function but seems like it may be trying to determine if it is safe to break the line at this character (if necessary because of width). However, it means that if you have a space/dash and then a newline character, you will get two line breaks.

 

See various cases below showing string and result:

Case 1: Line break immediately follows non-space characters. Wrap reads a single line break.

char x[] = "hello world\nA";

hello world
A

 

Case 2: Linebreak follows space character. Wrap interprets space as a line break as well resulting in two breaks.

char x[] = "hello world \nA";

hello world

A

 

Case 3: Single character before line break (similar to case 1 but just showing the problem more clearly).

char x[] = "hello world 1\nA";

hello world 1
A

 

Case 4: Another character that is interpreted as an additional line break if preceding newline.

char x[] = "hello world -\nA";

Hello world -

A

 

[inmarket]

The issue here is that the word wrapping algorithm in the font engine is broken (or rather just not intelligent enough). It assumes the word break character takes space thus leading to the double line break when the line break is followed by an explicit line break. In reality it may or may not and in different circumstances the rules are different.

Eg a '\n' doesn't take up space (ever)

A space or tab takes up space if the line break is not taken but doesn't take space if the break is taken,

A '-' always takes up space regardless of whether the break is taken or not. A '-' must also fit on the preceeding line if the word break is taken.

The rules above can change if the word break character is a printing character. Eg some fonts the space displays as a period in the middle of the line spacing. For those fonts the space is more like a '-' except that it may be placed on either the preceeding line or on the wrapped line. uGFX also makes no attempt to handle any other non-printing characters which should probably almost certainly be treated as a word break. Also, should symbols be treated as word break characters? 

... and these are just the rules for english!

Other languages may have extra or different word break characters with different placement rules.

In summary, the word wrapping algorithm that uGFX uses is extremely simple and is probably appropriate for uGFX's "small" nature. It's better that the programmer takes more care with their string literals than try to add the full complexity to the algorithm. 

[kengineer]

Thank you for explaining that, makes sense.