Created attachment 149039 [details]
Before and After screenshots of the breakage annotated using Draw.
Hi all. I upgraded from 188.8.131.52 to 184.108.40.206 last evening and am now seeing some truly odd behavior. My install is from the Linux x86_64 RPM batch but I very much doubt that the issue I'm experiencing is OS specific.
My current use case involves manuscripts and screenplays in traditional "old-school" typewriter format, thus mandating 10pitch mono-space fonts with two spaces between sentences and after colons, etc. The key point here is that I always keep the AutoCorrect Options' "Ignore double spaces" setting unchecked.
Since the move to 220.127.116.11, I've been noticing that if a sentence division within a paragraph breaks between two lines (i.e. one line ends with a <PERIOD><SPACE><SPACE> combination and the following sentence is pushed to the next line) my upcoming Carriage Return will cause the two spaces at the division to be reduced to one space and all characters at the beginning of all subsequent lines to be themselves replaced by spaces. The paragraph will then reflow with the text mangled. Confusing right? Hopefully the attached screenshots will clarify what I'm describing.
I haven't been able to determine what's causing it, but I have discovered that the issue only plagues the most fundamental Paragraph Styles bundled with Writer. I've so far confirmed the problem to affect the "Caption", "Heading", "First Line Indent", "Hanging Indent", and "Text Body Indent" styles. Others will probably manifest the issue as well, but I haven't tested them all. "Default Style" and "Text Body" are unaffected!
Based on the above, I wondered if paragraph indentation was causing the problem. Nope. I fiddled with the properties (indentation, linespacing, etc.) of the various out-of-the-box styles and could neither induce the bug in those unaffected, nor prevent it from occurring in those that were. I created a number of custom styles at various points along the style tree and none of them displayed the problem. This was weirdly true even if I "cloned" a malfunctioning one. For example, I created an unmodified child of "First Line Indent" and it did *not* inherit the issue from its parent.
STEPS TO REPRODUCE:
1. Open a new blank document. Some steps below assume a new instance of the Default (A4) template. You'll likely also want to Toggle Formatting Marks (CTRL+F10) to visible.
2. Confirm that Tools -> AutoCorrect Options... -> Options Tab -> "Ignore double spaces" is unchecked.
3. Populate the document with enough text to produce a paragraph several lines long and ensure that at least one line breaks (that is to say, *ends*) on two space characters. In my screenshots I used the following:
Here is a short sentence demonstrating this very peculiar bug. Here is a short sentence demonstrating this very peculiar bug. Here is a short sentence demonstrating this very peculiar bug. Here is a short sentence demonstrating this very peculiar bug. Here is a short sentence demonstrating this very peculiar bug. Here is a short sentence demonstrating this very peculiar bug. Here is a short sentence demonstrating this very peculiar bug. Here is a short sentence demonstrating this very peculiar bug. Here is a short sentence demonstrating this very peculiar bug.
4. Set the paragraph style to "First Line Indent". If you copy-pasted my text from Step 3, set the font for all text to Liberation Serif (if it isn't already) and change the font size to 14. This should cause a two-sentence division to break across the 4th and 5th lines with two space characters at the end of the 4th. If you didn't use my text, use whatever font and size you please (it doesn't seem to matter) but, again, make sure at least one line ends with two spaces.
5. Move to the end of the paragraph and press ENTER.
I fully expect the paragraph to have become mangled. If no one else can confirm or reproduce this (mis)behavior I'll scream and pull my hair out. Well, no, not really. Instead I'll revert to 6.1.5.x in the meanwhile but still be very, very annoyed.
Seriously though, I'm tempted to mark this bug as CRITICAL because data loss can occur if a user fails to notice the characters disappearing, saves the document, and then closes it. If they are lost, putting all those missing characters back one-by-one, after-the-fact, across multiple paragraphs in a large document would be an absolute nightmare! Note that CTRL+Z *will* undo the damage if it's caught in time while the document is still open.
Thanks in advance to all those who look into this matter, and thanks in general to everyone for all your continued hard work.
Having gone back and (re)tested the old, familiar behavior with 18.104.22.168 and 22.214.171.124, I now see that two (or more) spaces at the end of a line were already being truncated to one in those versions. I likely never noticed this because the corruption of other characters wasn't occurring.
I didn't state an expected behavior in my initial report, but obviously it would be that, when the "Ignore double spaces" setting is unchecked, *all* characters input by the user (recurrent white-space or otherwise) should be preserved, intact, within a paragraph, regardless of their position on a line.
Problem persists in 126.96.36.199.
I confirm this with
Version: 188.8.131.52.alpha0+ (x64)
Build ID: 91cdf22b88a4f7bec243c8fb187627e766d3294c
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win;
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-08_00:38:10
Locale: en-US (de_DE); UI-Language: en-US
but not with
Version: 184.108.40.206 (x64)
Build ID: 90f8dcf33c87b3705e78202e3df5142b201bd805
CPU threads: 4; OS: Windows 10.0; UI render: default;
Locale: de-DE (de_DE); Calc: group threaded