Created attachment 139421 [details]
Example of .odt text highlight color change when saved as .doc file
Text segments, not necessarily a full paragraph, but it could be, open with a totally different background color after the original document (in .odt format) was saved as a Word 97-2003 (.doc) document. In my case, I used color "Blue gray" for the initial highlight color. When I opened the new document, the background color came up as "Blue 3". To do the formatting, I used the "Highlight Color" toolbar button to set the background color of the first segment, then the "Clone Formatting" button to "paint" additional text with the selected color. I saved the document to the Word 97 format. When opened, the new Word 97 document had a different color (Blue 3) for all highlighted segments.
Version: 220.127.116.11 (x64)
Build ID: 92a7159f7e4af62137622921e809f8546db437e5
CPU threads: 4; OS: Windows 6.19; UI render: default;
Locale: en-US (en_US); Calc: group
Windows 10 Pro
OS Build 16299.192
I confirm it with
Version: 18.104.22.168.alpha0+ (x64)
Build ID: 77a535285f0fd5f2464430abdc67cf99be024868
CPU threads: 4; OS: Windows 10.0; UI render: GL;
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-01-23_23:04:23
Locale: de-DE (de_DE); Calc: CL
1. I used highlight color Light Blue 4 (from standard palette)
2. Saved as .doc
3. Reopened document. Highlight color was blue (#0000FF)
Quote from: https://bugs.documentfoundation.org/show_bug.cgi?id=97865#c9
This thing happens because MS highlighting has only 15 highlighting color and when you save Writer text background \ highlighting to an MS format it is converted to this color palette.
It's the default behavior, but you can change this at Tools -> Option -> Load/Save -> Microsoft Office, to save Writer text background as MS Shading and so colors won't change. Nut in this case when you open that *.doc file in MS Word you could not change the text background with highlighting tool, but with the shading tool:
Before the 5.0 version sometimes we saved Writer text background as shading (doc, docx), sometimes as highlighting (rtf). From that version an option is added, so the user can select the preferred behavior. Highlighting became the default, because on LO UI text background is called highlighting. This option can be set also via user profile.
So, probably not a bug..
Has UX any opinion on this? The type of issue has been reported multiple times... all of them where closed with the explanation given in comment 2. (see bug 96016, bug 97865, bug 113872) However it doesn't feel right...
It's might be better to switch the setting the other way around -> saving the highlighting as MS Shading.
* It would prevent unexpected dataloss (in the sense of losing highlighting)
* it's compatible with MS Word (viewing)
* People aware of the risk of switching to MS highlighting mode (mouse over text?)
*It will break the experience of MS Word users wanting to edit a file..
Switching to the save mode makes sense. Guess most users don't know the difference.
Alternatively, we could ask the user when exporting a document may result in corrupt properties.
Microsoft only allows 15 colors to be used as highlight colors in both .doc and .docx, so this is a format limitation bug that isnt ours.
(In reply to Telesto from comment #3)
> *It will break the experience of MS Word users wanting to edit a file..
Users being able to modify the highlighting is the most important thing, so i'd stick with this by default.
(In reply to Heiko Tietze from comment #4)
> Alternatively, we could ask the user when exporting a document may result in
> corrupt properties.
We already give users the 'Confirm File Format' dialog when not saving to ODF, which does state 'This document may contain formatting or content that cannot be saved in the currently selected file format'. We could go beyond this, if devs are interested in implementing it, and create a dialog similar to the MS compatibility checker.
(In reply to Yousuf Philips (jay) (retired) from comment #5)
> (In reply to Heiko Tietze from comment #4)
> > Alternatively, we could ask the user when exporting a document may result in
> > corrupt properties.
> We already give users the 'Confirm File Format' dialog when not saving to
> ODF, which does state 'This document may contain formatting or content that
> cannot be saved in the currently selected file format'. We could go beyond
> this, if devs are interested in implementing it, and create a dialog similar
> to the MS compatibility checker.
This would be really genius to have a list of things that change instead of a vague statement that something could happen--or not.
In such a dialog also the possibilities in the options dialog can be referenced because nobody finds the option to change highlighting saving today.
*** Bug 116458 has been marked as a duplicate of this bug. ***
Removing UX as input has been given. QA: Is it still a minor issue?
** 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!
The bug is still active in the latest version of LibreOffice:
Version: 22.214.171.124 (x64)
Build ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d
CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win;
Locale: en-CA (en_US); UI-Language: en-US
I will highlight a passage with "Blue 1" for a Writer .docx format. I will save it, and close Writer, and then I open it again, and the highlighted passage will now be "Blue 3".
I tried it with another colour and I chose "Cyan 8" this time, and I saved it, and opened it up again, and this time it was #008080.
Since this is the result of a MSO limitatin (see comment 2), the discussion in cemments 3 - 6 is about how to deal with such limitations. So my question is: Should we close this bug (and open a new one with the mor general topic of comment 3-6) or rename the bug summary?
(In reply to Dieter Praas from comment #11)
> Should we close this bug or rename the bug summary?
Either way we have to come to a conclusion. I like the way it's done by MSO (see c5) - but it's a question to devs. So needsDevAdvice.
I submitted a similar request some time ago, see bug 104822
I also started working on such a list on the wiki (work i progress due to time constraints): https://wiki.documentfoundation.org/User:Kerwyn/informationoncompatibility
Heiko, I think we should close this as duplicate of bug 104822. Do you agree?
I brought it up in the ESC call yesterday
* List incompatible features when saving to alien formats in detail
+ prototype for solution in c5; feasibility unclear
+ trad. answer is – better to fix the interop problems (Michael)
+ 15 highlighting colors doens’t go to MSO (Heiko)
+ why do we have so many ? (Michael)
+ its lots of work scanning the doc to find problems (Michael)
+ two sides – better to spend energy supporting (Miklos)
+ on other side – the CSV filter “only current sheet”
+ some merit to this.
+ in the past did have some scanner code to detect
+ this was removed.
+ remember the filter collection / warning (Caolan)
+ back in the day – more effort to detect missing than impl. It
+ perhaps for big features works, but micro-level tricky.
+ PDF export has something like this too.
AI: + drop chunk into the bug & send to QA (Heiko)
I suggest to resolve this request as WONTFIX.
The link to compatibility setting is not a big deal though also not really helpful. But I wouldn't make it a duplicate.
(In reply to Heiko Tietze from comment #15)
> I suggest to resolve this request as WONTFIX.
Additional suggestion: Perhaps it is possible to collect incomtable features in a wiki-page or something like that and add a link to that page in the warning-message.
(In reply to Dieter Praas from comment #16)
> Perhaps it is possible to collect incomtable features
> in a wiki-page or something like that and add a link to that page in the
I'm afraid such a page is not really accessible. It might be good for odt vs. doc (would be a nice comparison sheet, btw) but if you save as rtf, txt or whatever almost every feature is not existent. Adding Italo since the format comparison was always his topic. The idea is to have a (large) sheet with supported features that gives an overview of the interoperabilty (wouldnt be surprised if we have something like this).
(In reply to Thomas Lendo from comment #6)
> (In reply to Yousuf Philips (jay) (retired) from comment #5)
> > (In reply to Heiko Tietze from comment #4)
> > > Alternatively, we could ask the user when exporting a document may result in
> > > corrupt properties.
> > We already give users the 'Confirm File Format' dialog when not saving to
> > ODF, which does state 'This document may contain formatting or content that
> > cannot be saved in the currently selected file format'. We could go beyond
> > this, if devs are interested in implementing it, and create a dialog similar
> > to the MS compatibility checker.
> > http://technastic.com/wp-content/uploads/2016/02/Microsoft-Word-
> > Compatibility-checker.jpg
> This would be really genius to have a list of things that change instead of
> a vague statement that something could happen--or not.
> In such a dialog also the possibilities in the options dialog can be
> referenced because nobody finds the option to change highlighting saving
(User and Bug Reporter here)
I've confirmed that this issue is due to the .doc and .docx file format that I've saved my files in because when I saved the file in .odt there's no problem with the colour changes. I only really saved my documents in the .docx format for university, so I don't have a need to use that format now, so I'll be using .odt from now on.
If a user changes the save as format to be .doc or .docx, rather than just give a dialogue that there could be some incompatibility in saving it to that specific format, is it possible to actually block out the extended colours that are available for the .odt format? So, in this instance, I've set my default save format to be .docx, and so LibreOffice will only show the colours that the MSO will allow, and thereby preventing me from choosing other colours that will just change back to the default MSO colours. The program is already doing this once I use the .docx format, so would it be too difficult to block off everything that isn't MSO for the colour palette? And if this is possible, then perhaps the program could go into a "MSO Compatibility Mode" and even show it somewhere on the program, where everything would change to be compatible with MSO and block off options that work with .odt, but won't in MSO's formats, so that user, especially inexperienced users, won't have to even worry about incompatibility?
I should point out that even with different versions of MSO there are colour palette issues, so it's not just with LO, but within MSO itself. This is one of the reasons I've been MSO free for years.
Thanks for putting out a fantastic office suite!
(In reply to Roeland from comment #13)
> I submitted a similar request some time ago, see bug 104822
IMO it's most logic to keep this bug 115291 in it's original sense, and link
to 104822 as a META-issue.
> I also started working on such a list on the wiki (work i progress due to
> time constraints):
Still lots to do :)
You may want to ask on users@ or QA@ lists?
Creating such a list is a hell of a task, given that OOXML as a document format is not consistent even within the same release of Microsoft Office. We will add the list to the documents generated by the soon to be announced ODF Advocacy Open Project at OASIS.
Added Marina Latini, as she will be co-leading the ODF Advocacy Open Project.
*** Bug 68489 has been marked as a duplicate of this bug. ***