Bug 43244 - VIEWING nonprinting characters (spaces) missing at page margin
Summary: VIEWING nonprinting characters (spaces) missing at page margin
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Master old -3.6
Hardware: Other All
: medium normal
Assignee: Not Assigned
: 48654 (view as bug list)
Depends on:
Blocks: Formatting-Mark
  Show dependency treegraph
Reported: 2011-11-25 07:06 UTC by Korrawit Pruegsanusak
Modified: 2021-08-23 14:13 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

screenshot describe an issue (144.73 KB, image/jpeg)
2011-11-25 07:06 UTC, Korrawit Pruegsanusak
odt file (9.03 KB, application/vnd.oasis.opendocument.text)
2011-11-25 07:08 UTC, Korrawit Pruegsanusak
test file in Notepad++, wrapped (188.54 KB, image/jpeg)
2011-12-01 13:04 UTC, msjasinski
test file in Notepad++, unwrapped (185.54 KB, image/jpeg)
2011-12-01 13:05 UTC, msjasinski
test file in MS Word normal layout (219.51 KB, image/jpeg)
2011-12-01 13:06 UTC, msjasinski
test file in MS Word, print layout (283.13 KB, image/jpeg)
2011-12-01 13:06 UTC, msjasinski
screenshot describe an issue, in LibreOffice 3.5 dev (154.73 KB, image/jpeg)
2011-12-01 13:21 UTC, msjasinski

Note You need to log in before you can comment on or make changes to this bug.
Description Korrawit Pruegsanusak 2011-11-25 07:06:44 UTC
Created attachment 53848 [details]
screenshot describe an issue

I've received this issue from Michał Jasiński via private e-mail.

The new feature in LibO 3.5: "Display non printable characters on the end of line" has an issue. The spaces after page margin are not displayed. He also attached a screenshot and odt file describing this issue.

See also:
* http://wiki.documentfoundation.org/ReleaseNotes/3.5#Writer
* http://wiki.documentfoundation.org/File:Non_printable.png
Comment 1 Korrawit Pruegsanusak 2011-11-25 07:08:09 UTC
Created attachment 53849 [details]
odt file
Comment 2 Korrawit Pruegsanusak 2011-11-25 07:18:29 UTC
Following is my opinion:
I don't know what to expect if there are many spaces that they go over page margin.

Michał is expecting that spaces will be transferred to next line, as he described in the last line in screenshot. Anyway, I don't think this is a solution, since if we turn off displaying non-printable characters, a following text/paragraph should be re-formatted (or not ?) Because IMHO turning on/off should not re-format the whole text, ie the text should look same whether we display non-printable characters or not.

But what if we display these spaces as if there is no page margin? I can't imagine the line with 552 spaces in the screenshot. :)
Comment 3 Rainer Bielefeld Retired 2011-11-25 08:10:52 UTC
[Reproducible] with reporter's sample and parallel installation of MinGW Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID:  7ba7cba-5d03837-adcf6d5-c4bb9bd)] (daily/MinGW_cross-compilation2011-11-26_02.11.53)"

Currently I do not understand all aspects of the bug, but there is a bug without doubt.

Opening the sample document with LibO 3.4.4 there is only 1 blank above "552 spaces (even more invisible)".

Select all blanks above "176 spaces ..." by dragging mouse cursor from start of line to the end, find and replace all spaces in selection by dots. In 3.4.4 176 replaced, in 3.5 160 replaced.
BTW, when you select all line with click at the beginning and <shift+end>, all 176 blanks will be selected and replaced

I also see only 1 blank between "A" and "W".

Other effects not tested.

Currently I believe the "nonptinting ..." subject might be a little misleading -  isn't it a simple "spaces" problem?
Comment 4 msjasinski 2011-12-01 03:19:59 UTC
This problem is of a more complex nature than I initially thought. And there are a few possible solutions to it.

1. At first I expected the feature with spaces to behave in the same manner as in e.g. Notepad++. If you toggle on option VIEW/WRAP, spaces behave like any other characters (letters, dots, slashes etc.) i.e. they are automatically transferred to the second line if they exceed the char limit in the one they start in.

2. If in Notepad++ the WRAP option is off, you can write (and continue to see) spaces indefinitely, as the line becomes longer and longer ad infinitum. This corresponds to the behavior in the normal layout in MS Word (VIEW/NORMAL LAYOUT).

3. However, the feature introduced by Bartosz Kosiorek in LibO 3.5 is a rough equivalent of MS Word print layout (VIEW/PRINT LAYOUT), with slight differences. The differences consist in the fact that in MS Word (my version: 2003) print layout you can see that spaces go beyond the page or that they do not. Like in LibO, they are not wrapped, and in print they are not wrapped either.

So, if you can follow my explanation, it turns out that it is not necessarily a bug, and there are several possible ends to the problem, as follows:

1. Improve visibility of spaces exceeding page margins to make the difference between exceeding/non-exceeding spaces more apparent (as it is done in MS Word).
2. Introduce WRAP mode as it is done in Notepad++
3. Decide which approach is better for printing (MS Word/Notepad++).
4. Perhaps introduce other layouts in LibreOffice (there is no NORMAL LAYOUT) (???). 

I hope all is clear now. I'll try to attach screenshots of MS Word and Notepad++ to illustrate my point.

Cf "nonptinting ..."  - yes, it may be misleading, but I only the developer's denotation...
Comment 5 msjasinski 2011-12-01 13:04:56 UTC
Created attachment 54036 [details]
test file in Notepad++, wrapped
Comment 6 msjasinski 2011-12-01 13:05:31 UTC
Created attachment 54037 [details]
test file in Notepad++, unwrapped
Comment 7 msjasinski 2011-12-01 13:06:14 UTC
Created attachment 54038 [details]
test file in MS Word normal layout
Comment 8 msjasinski 2011-12-01 13:06:54 UTC
Created attachment 54039 [details]
test file in MS Word, print layout
Comment 9 msjasinski 2011-12-01 13:21:32 UTC
Created attachment 54040 [details]
screenshot describe an issue, in LibreOffice 3.5 dev
Comment 10 Rainer Bielefeld Retired 2011-12-05 10:51:50 UTC
Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Comment 11 msjasinski 2011-12-06 18:28:24 UTC
Another strange observation: if I copy a text from LibO 3.4.4 and paste it to LibOdev 3.5, then the copied section behaves as if it was still in 3.4.4 - if I produce excessive spaces, they disapear... Very strange indeed.
Comment 12 Korrawit Pruegsanusak 2011-12-07 04:16:15 UTC
(In reply to comment #11)
> Another strange observation: if I copy a text from LibO 3.4.4 and paste it to
> LibOdev 3.5, then the copied section behaves as if it was still in 3.4.4 - if I
> produce excessive spaces, they disapear... Very strange indeed.

From some mail in dev mailing list, IMHO thing that matter is not "copy and paste between version", but "does new version open the file correctly when saving from older version, and vice versa". This is because real-world user wouldn't run 2 instances of different version simultaneously :)

So, could you please test this? Thanks!
Comment 13 Simo Kaupinmäki 2014-06-15 11:10:17 UTC
From attachment 53849 [details]: “How many spaces are there between A and W? One? No, eight. But it looks as if there was one.”

Actually, with nonprinting characters visible, I can't see any indication of a space between A and W (other than the automatic line break of course). Curiously, the nonprinting middle dot representing a space is only visible if there is a single space at the end of line, but if you add another space, the nonprinting symbol disappears. This only seems to happen if there is room for no more than one space character at the end of line. As long as there is room for two or more characters, these remain visible, but any extra spaces that flow over the margin cannot be seen.

Another issue is that the line-ending spaces are only visible in left-aligned text, but they become invisible if the text is aligned right or centered or justified. An exception to this is the line with 160 spaces running from margin to margin: these remain visible regardless of the text alignment.

Found in LO and
Comment 14 Simo Kaupinmäki 2014-06-15 11:12:55 UTC
*** Bug 48654 has been marked as a duplicate of this bug. ***
Comment 15 QA Administrators 2015-07-18 17:44:06 UTC Comment hidden (obsolete)
Comment 16 Buovjaga 2015-10-23 08:06:37 UTC

Win 7 Pro 64-bit Version:
Build ID: fcc2415ade6ae93710bbbda9f7e163045e323105
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-21_16:55:13
Locale: fi-FI (fi_FI)
Comment 17 QA Administrators 2016-11-08 11:17:33 UTC Comment hidden (obsolete)
Comment 18 Thomas Lendo 2017-06-05 22:23:37 UTC
Reproduced with Version:
Build-ID: b08217989558addbcaded122a4e7211ae24bbcff
CPU-Threads: 4; Betriebssystem:Linux 4.8; UI-Render: Standard; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-05-31_06:36:03
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
Comment 19 QA Administrators 2018-06-06 02:46:14 UTC Comment hidden (obsolete)
Comment 20 Karsten 2019-01-16 11:15:34 UTC Comment hidden (obsolete)
Comment 21 QA Administrators 2021-01-16 04:17:11 UTC
Dear Korrawit Pruegsanusak,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team