When the very end of a line (right margin) is reached, white spaces entered are not moved to the second line, but hidden from view. (Switch on non-printing characters to view.)
White spaces entered at the very beginning of an automatically broken second line are hidden beyond the end of the right margin of the previous line, only to reappear when the previous line is broken manually by a hard or soft return. When navigating with the arrow keys at the end of a line, the unseen presence of hidden white spaces may be noticed (you have to tap the arrow key as many times as there are spaces, in order to get the cursor to visibly move again).
To reproduce: Switch on non-printing characters. Enter a full line of text, right up to the right margin. Press enter to go to the line below. Enter ten white spaces. Move to the beginning of the second line and press backspace. The spaces will disappear beyond the right margin, but you can still navigate them with the arrow keys.
This bug has been in previous versions of OO, and I have reported it before to the Open Office bugzilla site, a year or so ago. There turned out to be, I believe, five different related bug reports in the Open Office bug database. This bug breaks the WYSIWYG principle and also affects Tables. When a series of white spaces fill up more than one line in a table cell, they become invisible, beyond the right boundary of the cell.
Unfortunately, I do not have the knowledge to fix this bug. I think it has something to do with the line breaking functions in OO. When more than one consecutive white space is detected, they should be put on the next line. A single space at the end of a line may conveniently be hidden when it cannot be displayed before the margin, but multiple spaces must be detected and moved to the second line.
Thanks for taking the time to read this. I know you are probably doing this on a voluntary basis, and I am grateful for that. But maybe this very basic text input bug can be given slightly higher priority. I would think many users run into problems with this, especially in large manually input documents (theses) it can be a real pain.
Binary package hint: openoffice.org
When the very end of a line (right margin) is reached, white spaces entered are not moved to the second line, but hidden from view. (Switch on non-printing characters to view.)
White spaces entered at the very beginning of an automatically broken second line are hidden beyond the end of the right margin of the previous line, only to reappear when the previous line is broken manually by a hard or soft return. When navigating with the arrow keys at the end of a line, the unseen presence of hidden white spaces may be noticed (you have to tap the arrow key as many times as there are spaces, in order to get the cursor to visibly move again).
To reproduce: Switch on non-printing characters. Enter a full line of text, right up to the right margin. Press enter to go to the line below. Enter ten white spaces. Move to the beginning of the second line and press backspace. The spaces will disappear beyond the right margin, but you can still navigate them with the arrow keys.
This bug has been in previous versions of OO, and I have reported it before to the Open Office bugzilla site, a year or so ago. There turned out to be, I believe, five different related bug reports in the Open Office bug database. This bug breaks the WYSIWYG principle and also affects Tables. When a series of white spaces fill up more than one line in a table cell, they become invisible, beyond the right boundary of the cell.
Unfortunately, I do not have the knowledge to fix this bug. I think it has something to do with the line breaking functions in OO. When more than one consecutive white space is detected, they should be put on the next line. A single space at the end of a line may conveniently be hidden when it cannot be displayed before the margin, but multiple spaces must be detected and moved to the second line.
Thanks for taking the time to read this. I know you are probably doing this on a voluntary basis, and I am grateful for that. But maybe this very basic text input bug can be given slightly higher priority. I would think many users run into problems with this, especially in large manually input documents (theses) it can be a real pain.