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...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.2.4.2 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Track-Changes
  Show dependency treegraph
 
Reported: 2017-02-12 23:14 UTC by strata_ranger
Modified: 2018-02-20 03:37 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


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

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
Description:
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
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug