Description: I have an exam with highlighting on some of the questions and highlighting on some of the answers. I selected all text and set the highlighting drop down to no fill. Some of the highlighting remained. I saved, closed the window, and reopened the document. Now there was green highlighting on number 8. I export a pdf and the pdf has highlighting on the first three characters of the answers. Steps to Reproduce: 1.I selected all text and set the highlighting drop down to no fill. Some of the highlighting remains. 2. Save the file. Keep it in word format. 3. Close the window. 4. Reopened the document. Now there was green highlighting on number 8. 5. Export a pdf and the pdf has highlighting on the first three characters of the answers. Actual Results: PDF with the first few characters of previously highlighted answers are still highlighted. Expected Results: No highlighting. Reproducible: Always User Profile Reset: No Additional Info: I have files I can provide. User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/56.0.2924.76 Chrome/56.0.2924.76 Safari/537.36
Created attachment 132370 [details] Original highlighted file
Created attachment 132371 [details] File that has 8 in highlighted in green. After selecting all text and setting highlight to no fill the file was saved and reopened.
Created attachment 132372 [details] screen shot showing highlighted 8 after reopening file.
Created attachment 132373 [details] What I see in my pdf viewer. Evince 3.18.2
Repro with: Version: 5.4.0.0.alpha0+ CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-04-05_23:32:27 Locale: nl-NL (nl_NL); Calc: CL but not with Versie: 4.4.6.3 Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d Locale: nl_NL
The behavior was changed in multiple commits that were dealing with character highlighting with MSO formats, for this particular file the following two commits show visible difference in behavior. Adding Cc: to Tamás Zolnai, please take a look sometimes. https://cgit.freedesktop.org/libreoffice/core/commit/?id=8f01925d98dabdbf400c9263e08242267b2b9701 author Zolnai Tamás <zolnaitamas2000@gmail.com> 2015-03-18 10:19:25 +0100 committer Zolnai Tamás <zolnaitamas2000@gmail.com> 2015-03-21 16:19:07 +0100 Char highlight: enable DOCX import https://cgit.freedesktop.org/libreoffice/core/commit/?id=08cfbbaca2d23727bc95912082ae46b8f8a37f03 author Zolnai Tamás <zolnaitamas2000@gmail.com> 2015-03-15 15:31:09 +0100 committer Zolnai Tamás <zolnaitamas2000@gmail.com> 2015-03-21 16:19:10 +0100 Char highlight: editing by "Highlighting" button Whole range of commits: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=8f01925d98dabdbf400c9263e08242267b2b9701..08cfbbaca2d23727bc95912082ae46b8f8a37f03
A workaround is using clear direct formatting option (Format -> Clear Direct Formatting)
Tamás Zolnai committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa02ed306f7c633bbffede16e44e8e736977ace4 tdf#106991: Highlighting remains after select no fill It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 114799 has been marked as a duplicate of this bug. ***
Created attachment 139014 [details] The example file saved from current master Looks a lot better, when removing highlighting, the highlighting is removed from the numbering, and this is correctly saved. However, when a non-highlighted paragraph is highlighted, the numbering does not get the coloring. But after saving and reloading the numbering is colored. One more problem: the numbering is set as capital letter+dot, but saving and reloading removes the dot after the capital letter. This did not happen earlier.
Created attachment 139015 [details] Screenshot of the file in current master Answers 1 D and E were highlighted after removing all highlighting from the document, then the document was saved and reloaded. Note the missing dot after the capital letters. Answer 1. C was just highlighted in the editor. Note that the numbering is not highlighted.
(In reply to Gabor Kelemen from comment #11) > Created attachment 139015 [details] > Screenshot of the file in current master > > Answers 1 D and E were highlighted after removing all highlighting from the > document, then the document was saved and reloaded. Note the missing dot > after the capital letters. > Answer 1. C was just highlighted in the editor. Note that the numbering is > not highlighted. The missing dot is not related to the highlighting I think, so I have no idea about that. Create a separate bug for it. I see that adding new highlighting is still problematic. It's seems to be related to MSO compatibility flags which make the numering also formatted with character properties of the paragraph (one of these flags is ApplyParagraphMarkFormatToNumbering, but I expect there is an other flag too). If you create a new document in LO these flags are not set and text highlighting of the paragraph is not applied on the numbering. So it's an MSO specific functionality that paragraph numbering gets the formatting of the paragraph, which seems to be not implemented correctly in LO. You can reproduce the same bug using striketrough. Apply it on the numbering in MSO and try to remove it later in LO. So I would say this problem was not actually about the highlighting. Now you can remove highlighting from the numbering, so I would close this bug, but yes it's still a problem to apply a new highlighting. It's seems related to the editing only. Save and reload solves the issue. Also if you push enter inside a problematic paragraph the numgering gets the color. I reopen the other bug for the issue of applying a new highlighting.
Ok, let's close it now. I don't have a better idea here. Other bug report is opened for editing highlighting after import.
*** Bug 114649 has been marked as a duplicate of this bug. ***