Created attachment 136820 [details] Short example .odt document When editing text adjacent to text with a different format, the format of the edited text changes from what it was, to the format to its left. This has been true for LibreOffice for many, many years, and it is as annoying or even as infuriating now as it was then. Steps to reproduce (See attached document): 1. Prepare some text with different formats. 2. Select the first word (or character) of the text at the start of a new format. 3. Type some new text in. 4. Instead of keeping its format, the format is copied from the text to its left. Expected result: the format of the selected text is unchanged. I note that this behaviour also seems to be in Calc: https://bugs.documentfoundation.org/show_bug.cgi?id=107857 I wonder whether it is also the cause of the bug reported here: 62603
I confirm the behaviour you describe. But I would like to differ: 1) You select a word and type a new text. I would expect that the format of the selected text remains. That's not the case. So I agree, that this is a bug. 2) You type a new word between to formats. The new word keeps format of the left. That's logical for me. So in this case I would say it's not a bug.
I agree with you. I don't think I spoke about your point no. 2, and I agree with your assessment. For that case I also think it should take the format from the text to the left.
You're right. I read not precisely enough => set to NEW
Could this bug be given higher priority if it may fix bug 62603 too? The problem with Find/Replace (bug 62603) makes LibreOffice unsuitable for editing books, because it introduces subtle formatting errors throughout a book that are quite hard to manually find and fix - because they're hard to find. I.e., Replace All is too dangerous an operation to use at present, if your document is long and uses more than a single type style. And instead stepping through hundreds or thousands of pattern matches to either Replace or manually correct (depending one whether the match occurred next to a font format change is very, very laborious).
Reproducible in 6.0.3.2. Probably, like in Calc bug 107857, is caused by delete-then-insert implementation of selection replacement.
As of version 6.1.4.2, the observed behaviour is slightly more complicated than described above: When replacing selected text which has direct formatting or a character style, if the adjacent text to the left of the selection has no direct formatting or a character style, the new text keeps the direct formatting or the character style of the replaced text (as it should). When replacing selected text which has no direct formatting and no character style, if the adjacent text to the left of the selection has direct formatting or a character style, the new text is given the formatting of the text at the left (this is a bug).
Related AOO bugreport: https://bz.apache.org/ooo/show_bug.cgi?id=24049
So does that AOO bug report explain why it affects Find & Replace too? (Which makes Replace All, especially, unsafe in editing books if you care about exact formatting). "The real problem is, that API functions (i. e. XTextRange:setString and XSimpleText:insertString) produce the same effect when applied at the beginning of a text fragment with specific formatting." I note the bug is now 15 years old.
(In reply to Luke Kendall from comment #8) > So does that AOO bug report explain why it affects Find & Replace too? > (Which makes Replace All, especially, unsafe in editing books if you care > about exact formatting). The bug 62607 seems to be unrelated - or at least your example only demonstrates that regex substitution drops formatting from the original matched groups. I had issues with Find&Replace without regex, when the replacement took formatting from adjacent text portions, like in this bug, but I can no longer (since several stable releases) reproduce it. In the meanwhile, I've submitted a fix for this bug, but it needs to be reviewed by core developers and thoroughly tested as it's my first experience with LO codebase: https://gerrit.libreoffice.org/#/c/67597/
*** This bug has been marked as a duplicate of bug 79717 ***