Download it now!
Bug 105967 - Tracked edits to line/paragraph breaks not formatted according to inserted/deleted status
Summary: Tracked edits to line/paragraph breaks not formatted according to inserted/de...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium minor
Assignee: Not Assigned
Whiteboard: target:7.1.0
Depends on:
Blocks: Track-Changes
  Show dependency treegraph
Reported: 2017-02-12 23:14 UTC by strata_ranger
Modified: 2020-10-28 18:15 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Sample file with tracked changes and descriptions thereof (14.08 KB, application/vnd.oasis.opendocument.text)
2017-02-12 23:40 UTC, strata_ranger

Note You need to log in before you can comment on or make changes to this bug.
Description strata_ranger 2017-02-12 23:14:27 UTC
When editing a document with LO's review features enabled, not all changes are displayed equally.  In particular, when I split a paragraph (by adding a ¶) this change is reflected in the display, but when I combine two paragraphs (by removing the ¶) this change is NOT reflected in the display.

Furthermore, when I display nonprinting characters, the ¶ marks are rendered independent of the styles set in Tools > Options > Writer > Changes; it is impossible to tell at a glance which marks are original, added, or deleted.

Steps to Reproduce:
1 - Open any convenient document and enable tracked changes.
2 - Make assorted whitespace edits (add/remove spaces, tabs, and paragraphs).
3 - Show nonprinting characters.

Actual Results:  
Spaces and tabs obey the styles specified in Tools > Options (except for foreground color).

Linebreaks do not; it is impossible to tell which ones are original, or inserted/deleted.

Expected Results:
At a minimum, linebreaks that are part of a tracked edit should be displayed regardless of whether nonprinting characters in general are displayed; they should also inherit the same display style as other tracked edits.

Reproducible: Always

User Profile Reset: 

Additional Info:
Unsure what Severity to assign this -- it's technically just a display issue with no loss of function, BUT the impact it has on an editing/review workflow is definitely not 'trivial'.

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Comment 1 strata_ranger 2017-02-12 23:40:43 UTC
Created attachment 131159 [details]
Sample file with tracked changes and descriptions thereof

Upon further inspection, it appears that when tracked changes is on and shown, LO displays *all* linebreaks in the file, regardless of whether they were original or inserted/deleted -- and *not* a trivial matter when you are trying to review/edit a document and you are splitting/merging paragraphs.
Comment 2 Buovjaga 2017-02-13 12:57:40 UTC
Note that linebreaks are different from paragraph endings. You have a linebreak after the first line "Sample document"

The deletion of a pilcrow mark ¶ seems to be reflected by underlining. Do you think it should have strikethrough?
Comment 3 strata_ranger 2017-02-19 01:05:56 UTC
Yeah, I apologize for any ambiguity between line and paragraph breaks -- the underlying behavior is the same for both, and I'm aware my sample file contains both.

Take paragraph 3 ("sample paragraphs one"). When displaying nonprinting characters, paragraph breaks inherit the formatting of the character immediately preceding them (foreground color aside). This behavior creates a huge problem for this line specifically: the pilcrow is formatted like insertion when it's actually part of a deletion.

So I guess the problem is more accurately summarized as follows (should I rename?) :

- Tracked edits to line/paragraph breaks not formatted according to inserted/deleted status
Comment 4 QA Administrators 2018-02-20 03:37:40 UTC Comment hidden (obsolete)
Comment 5 QA Administrators 2020-02-21 02:50:17 UTC Comment hidden (obsolete)
Comment 6 strata_ranger 2020-05-10 23:20:21 UTC
Still present up to and (which I just updated to).

Version: (x64)
Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

Now the 6.4 release notes mention a fix involving tracked changes and numbered list items (per tdf#42748) which might be relevant here too, as list items are also separated via hard (paragraph) breaks.
Comment 7 Commit Notification 2020-10-28 18:13:41 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

tdf#105967 sw change tracking: fix pilcrow symbol

It will be available in 7.1.0.

The patch should be included in the daily builds available at in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.