Created attachment 181008 [details] bug report and sample to reproduce it This bug happens in LibreOfficeWriter Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 086055b0d7e44d1d07b3f23af55503e6a3924d87 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded Consider the Preformattet Text sample in the attachment. 1. Put the cursor after the last characters in the next paragraph (i.e. between // CellPrint and the paragraph mark after it. 2. Keep an eye on the two, four or six blancs in front of many lines which make the indentation on page 2, 3. Arrange the window such that you see upper parts of the Preformatted Text paragraph which is split by the page break between pages 2 and 3. If necessary, reduce the magnification to accommodate seeing the lower part of page 2 too. 4. Then press Enter at the insertion point described in step 1. This should merely add a new paragraph of type Text body. But in addition, some of the spaces deliberately added for this special indentation get lost in the part on page 2. They happen to be the blue marked ones exactly on page 2, depending on where the page break actually is.
The same bug is also present in LibreOfficeWriter Version: 6.4.4.2 Build-ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff CPU-Threads: 4; BS: Linux 5.4; UI-Render: Standard; VCL: gtk3; Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded but after Ctl-z the suppressed spaces at the beginning of the affected lines are not shown in blue. But the bug is present there too!
Tools -> AutoCorrect -> Autocorrect Options -> Options -> Uncheck Delete spaces and tabs at end or start of line The Autocorrect delivers sometimes undesired results, and worse the correction happens somewhere else compared area where you're editing The feedback should be improved, IMHO. Autocorrect is sometimes really intrusive But how...? Note: I often run into the with the automatic markdown feature: typing /italic/ + space = italic + italic formatting.. Typing *bold* + space becomes bold with bold formatting
Telesto, thank you. In fact, I had to uncheck four checkmarks (two for each case, [M] and [T]): * Delete spaces and tabs at the beginning and end of paragraph * Delete spaces and tabs at the end and start of line. (Why the different order and different terms: *start and end of line* would be shortest and most logical for most of the world: from left to right.
I had marked this bug as resolved because it circumvents my problem. But that was probably a bit early: Deleting spaces and tabs at the start or end of a line/paragraph seems to work only under special circumstances and under other circumstances it does not work: Especially it seems to quit its work when a paragraph spans a paragraph in which it would otherwise start working, as my attachment shows. Therefore I set this bug report back to unconfirmed, although my problem got solved by Telesto's comment.
@UX Some feedback on comment 3 and comment 4 would be nice
(In reply to Adalbert Hanßen from comment #3) > (Why the different order and different terms: *start and end of line* would > be shortest and most logical for most of the world: from left to right. Probably you start at the end of the line and continue at the beginning of the next. Don't know why but the offline help shows [M][T] and some information about the options but not the online version. Anyway, the help could be more informative here. (In reply to Adalbert Hanßen from comment #4) > ...seems to work only under special circumstances... Cannot follow. Keep an eye on the "Apply Style" option.
Im my example, the lines with the paragraph style Preformatted Text were copied from a Mathematica session (Copy as>Plain text) and then they were inserted by Paste Special>Paste unformatted text into LO Writer. Then I had marked all these lines and exchanged the paragraph marks (\p) at the ends of the lines by forced linefeeds (\n) with the extension AltSearch1.4.2 and I assigned the paragraph style "Preformatted Text" to it. The benefit of doing so is that 1. Ctl-↓ takes you to the beginning of the next paragraph, Ctl-↑ to the beginning of the current paragraph, which is quite convenient to handle in documents with text and code paragraphs, 2. rules breaking pages for orphans and widows are applied. When LibreOfficeWriter applies any rule during page breaking only up to a page break happens and not for the rest of the same paragraph, this is definitely a glitch. It is not a major issue, rather a small one and here we have an example by which it can be reproduced. I suspect that the history of how the line breaks inside the paragraph were created, i.e. whether I really pressed Shift-Enter at the end of the lines, doesn't really matter. As I know exactly how I came across the error, however, I'll add it here.
The topic was on the agenda of the design meeting. There is no urgent need to change the order of items and/or the labels. And "special circumstances" and involvement of extensions makes it hard to follow and issue, so the generic answer is "autocorrection works". Please submit clear steps to reproduce reduced to the actual problem.
Dear Adalbert Hanßen, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Created attachment 184514 [details] Example of the bug with screenshot. Can be reproduced in 6.4.4.2 Fortunately this bug did not show up any longer with my example in the current development version: Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: da3dd48eaf9086f8ab28d6a6655f9a638e51433a CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded Unfortunately in the example given originally, the bug could not be observed because it already had happened when I stored the example. Unfortunately I don’t have the development version at hand, with which I first observed the bug. But I was able to reproduce it in the older Version: 6.4.4.2 Build-ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff CPU-Threads: 4; BS: Linux 5.4; UI-Render: Standard; VCL: gtk3; Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded If somebody wants to reproduce it, attached is an example in which the bug shows up with 6.4.4.2. It also contains a screenshot of the situation before and after the bug has happened.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Adalbert Hanßen from comment #11) > Created attachment 184514 [details] > Example of the bug with screenshot. Can be reproduced in 6.4.4.2 > > Fortunately this bug did not show up any longer with my example in the > current development version: So let's close this bug. Feel free to change it back to UNCONFIRMED, if you disagree. Please also test in LO 24.2 => RESOLVED WORKSFORME
I tested my example from the bug report with Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded and the bug did not show up again. During my test, both options dealing with spaces and tabs had checkmarks set for both columns were set, i.e. a total of four checkmarks. But the indentation of the lines before the page break did not change despite of this and Telesto's Comment 2. I repeated the same test with the four checkmarks being removed: same result.