Bug Hunting Session
Bug 112961 - EDITING: Editing selected text copies the format of the text to its left
Summary: EDITING: Editing selected text copies the format of the text to its left
Status: RESOLVED DUPLICATE of bug 79717
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Character
  Show dependency treegraph
 
Reported: 2017-10-07 05:09 UTC by Luke Kendall
Modified: 2019-02-10 19:15 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Short example .odt document (13.70 KB, application/vnd.oasis.opendocument.text)
2017-10-07 05:09 UTC, Luke Kendall
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kendall 2017-10-07 05:09:19 UTC
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
Comment 1 Dieter Praas 2017-10-07 08:43:11 UTC
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.
Comment 2 Luke Kendall 2017-10-07 10:17:55 UTC
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.
Comment 3 Dieter Praas 2017-10-07 12:41:23 UTC
You're right. I read not precisely enough => set to NEW
Comment 4 Luke Kendall 2017-10-21 12:59:33 UTC
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).
Comment 5 Phil Krylov 2018-04-05 13:45:55 UTC
Reproducible in 6.0.3.2. Probably, like in Calc bug 107857, is caused by delete-then-insert implementation of selection replacement.
Comment 6 Phil Krylov 2019-01-30 21:56:10 UTC
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).
Comment 7 Phil Krylov 2019-02-09 16:00:06 UTC
Related AOO bugreport: https://bz.apache.org/ooo/show_bug.cgi?id=24049
Comment 8 Luke Kendall 2019-02-09 16:18:41 UTC
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.
Comment 9 Phil Krylov 2019-02-10 15:08:42 UTC
(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/
Comment 10 Phil Krylov 2019-02-10 19:15:15 UTC

*** This bug has been marked as a duplicate of bug 79717 ***