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
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.
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?
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
** 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
Dear strata_ranger, 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
Still present up to 6.0.6.2 and 6.3.6.2 (which I just updated to). Version: 6.3.6.2 (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.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/350dbba44ee7703b1da11cc4732a5090ce5efe3d 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 https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/37d85df2d2fd53ee436f24484b48aafc91d501b1 tdf#105967 sw change tracking: fix pilcrow color It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I verify the fix Arch Linux 64-bit Version: 7.1.0.0.alpha1+ Build ID: 1a4ae360d06ae300a8fd5482b3b3a86dc021750d CPU threads: 8; OS: Linux 5.9; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 30 October 2020
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/58f64686cd83a349611daa52188db8bca347b3d4 tdf#105967 sw change tracking: fix line break symbol It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Buovjaga from comment #9) > I verify the fix @Many thanks for testing. It seems, this bug covers a lot of similar problems handled different places in the code base. I've fixed the line break symbol, too, but only in not empty lines (also empty lines contain paragraph marks with blue redlining instead of the author/custom color as specified in Tools->Option->LibreOffice Writer->Changes).
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/db25f1e2e3ae7a078f8f3c080ff3c4802f83b853 tdf#105967 sw change tracking: fix pilcrow in empty line It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/72ec44bc294dd814c0ba8657337b6b2646382b02 tdf#105967 sw change tracking: fix line break symbol in empty line It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d842f8cdab1ceec151fdc9b5b0c5b55553fc46c8 tdf#105967 sw: add unit test for redlining of break symbols It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 167000 [details] test document of the fix
Verified in: Version: 7.1.0.0.alpha1+ (x64) Build ID: 693553210828538680408832157faad9654758c8 CPU threads: 4; OS: Windows 10.0 Build 17134; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: threaded Thanks for fixing!