Created attachment 151370 [details] sample document (source) When saving the attached document containing colored text to Doc (word97-2003) or docx (Word2007+)-format, the colored text is broken. When loading the resulting file, LibreOffice as well as Word2016 show constent results.
Created attachment 151371 [details] document saved as Word97 file
Created attachment 151372 [details] the document saved to docx format
Created attachment 151373 [details] screenshot comparing the ODT (top) source to the resulting docx file (bottom)
confirm in Version: 6.3.0.0.alpha0+ Build ID: 773ac3abbf8ab1343367e51b1774d2ee1f8c4f49 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
Looks like bug 97865 see also bug 107793 (and related bug 116458 bug 115291 bug 113872) @Buovjaga Any advise on handling this re-occurring type of bug report. Keeps coming up once in a while (and gets confirmed too) Ends in NOTABUG, WONTFIX, DUPLICATE of something.. Feels a bit like suppressing the issue There is quite the 'surprise factor'. You save A and get B on reload. I would even consider it calling DataLoss.. Current situation is quite terrible; IMHO. However no solution has come up in the mean time (except better documentation). But I call that more a 'excuse' type of argument. I personally prefer the 'old way' prior to LibO 5.0 by default (so using text background). But technical/ terminological 'wrong' I guess. And the number of complains are rather limited (or people stopped used LibreOffice for this reason) --------------- 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. https://wiki.documentfoundation.org/ReleaseNotes/5.0
(In reply to Telesto from comment #5) > Looks like bug 97865 see also bug 107793 (and related bug 116458 bug 115291 > bug 113872) > > @Buovjaga > Any advise on handling this re-occurring type of bug report. Keeps coming up > once in a while (and gets confirmed too) Ends in NOTABUG, WONTFIX, DUPLICATE > of something.. Feels a bit like suppressing the issue > > There is quite the 'surprise factor'. You save A and get B on reload. I > would even consider it calling DataLoss.. > > Current situation is quite terrible; IMHO. However no solution has come up > in the mean time (except better documentation). But I call that more a > 'excuse' type of argument. > > I personally prefer the 'old way' prior to LibO 5.0 by default (so using > text background). But technical/ terminological 'wrong' I guess. And the > number of complains are rather limited (or people stopped used LibreOffice > for this reason) > > --------------- > > 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. > https://wiki.documentfoundation.org/ReleaseNotes/5.0 I don't think I am the right person to ask, so pinging Tamás.
(In reply to Telesto from comment #5) > Looks like bug 97865 see also bug 107793 (and related bug 116458 bug 115291 > bug 113872) > > @Buovjaga > Any advise on handling this re-occurring type of bug report. Keeps coming up > once in a while (and gets confirmed too) Ends in NOTABUG, WONTFIX, DUPLICATE > of something.. Feels a bit like suppressing the issue > > There is quite the 'surprise factor'. You save A and get B on reload. I > would even consider it calling DataLoss.. > > Current situation is quite terrible; IMHO. However no solution has come up > in the mean time (except better documentation). But I call that more a > 'excuse' type of argument. > > I personally prefer the 'old way' prior to LibO 5.0 by default (so using > text background). But technical/ terminological 'wrong' I guess. And the > number of complains are rather limited (or people stopped used LibreOffice > for this reason) > > --------------- > > 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. > https://wiki.documentfoundation.org/ReleaseNotes/5.0 Before the change, the complaint was that the user could not change the highlighting color in Word because it was not highlighting, but shading and it is actually more intuitive that this color is highlighting since LO calls it also that way. Before this change, user can't do anything with that, by now the user can change the settings and export text background as shading if he needs it to work on that way. About the data loss. That is true, but it's always a risk to save to an alien format that something is not exported as is. Even Word warns you when you save something in the older DOC format that you may lose something. It's the same in LO. Changing default value there and back also a bad idea, because after that those user will come to complain who are happy with the current default and then what will you do? So I would stick to this default behavior and when there is a complaint always mention the corresponding option. If there is a better solution to handle these two types of character background (e.g. shading and highlighting) patches are always welcome, but changing the default behavior does not actually improve the situation.
*** This bug has been marked as a duplicate of bug 97865 ***
> > There is quite the 'surprise factor'. You save A and get B on reload. I > > would even consider it calling DataLoss.. About the surprise factor, when the user is surprised that they get a different color, it may worth to point out that MSO supports only 16 colors for text highlighting. After the user gets to know what they are trying to use, I guess they can choose whether to use these 16 colors or switch to using shading. Using shading still has the disadvantage that another user might not able to remove the colored background because he / she expects it is highlighting.
> About the surprise factor, when the user is surprised that they get a > different color, it may worth to point out that MSO supports only 16 colors [...] 15 colors actually.
(In reply to Tamás Zolnai from comment #9) > > > There is quite the 'surprise factor'. You save A and get B on reload. I > > > would even consider it calling DataLoss.. > > > About the surprise factor, when the user is surprised that they get a > different color, it may worth to point out that MSO supports only 16 colors > for text highlighting. After the user gets to know what they are trying to > use, I guess they can choose whether to use these 16 colors or switch to > using shading. Using shading still has the disadvantage that another user > might not able to remove the colored background because he / she expects it > is highlighting. How about introducing a 15-color character-highlight-compatibility palette and an Options - Writer - Compatibility config option to enable that and only that palette in the Character - Highlight tab; Color button? Surely a lot of work, but one less "surprise" for users. (see also my talk at this years FOSDEM :) )
> How about introducing a 15-color character-highlight-compatibility palette > and an Options - Writer - Compatibility config option to enable that and > only that palette in the Character - Highlight tab; Color button? It's a great idea.
*** Bug 126264 has been marked as a duplicate of this bug. ***
(In reply to Tamás Zolnai from comment #12) > > How about introducing a 15-color character-highlight-compatibility palette > > and an Options - Writer - Compatibility config option to enable that and > > only that palette in the Character - Highlight tab; Color button? > > It's a great idea. => cc: Design-Team I think discussion / decision is needed, because observation from Telesto in comment 5 is still valid.
*** Bug 131215 has been marked as a duplicate of this bug. ***
*** Bug 107793 has been marked as a duplicate of this bug. ***
(In reply to Dieter from comment #14) > (In reply to Tamás Zolnai from comment #12) > > > How about introducing a 15-color character-highlight-compatibility palette > > > and an Options - Writer - Compatibility config option to enable that and > > > only that palette in the Character - Highlight tab; Color button? > > > > It's a great idea. > > => cc: Design-Team > > I think discussion / decision is needed, because observation from Telesto in > comment 5 is still valid. I'm adding the mso-highlight color palette for LO in this patch: https://gerrit.libreoffice.org/c/core/+/90905 It contains those colors which are supported by MSO highlight feature and these colors are expected to be exported to MSO formats without conversion. So from now, we can suggest the users to use this color palette if they use MSO file formats.
Created attachment 158890 [details] mso-highlight color palette
Thank you, Tamás. Based on my own experience with bug #131215 I'd make two suggestions: 1. Change the default behavior such that an export from ODT to DOCX changes colors as little as possible. I now understand there is an option under Options -> Tools -> Load/Save -> Microsoft re shading vs highlighting, but this is rather hidden and as a user the primary expectation is one of interoperability where possible. 2. Timur pointed me to https://help.libreoffice.org/7.0/en-US/text/shared/optionen/01130200.html which absolutely would not have helped me (without the actual example he showed.) "Microsoft Office has two character attributes similar to LibreOfficeDev character background. Select the appropriate attribute (highlighting or shading) which you would like to use during export to Microsoft Office file formats." It would be great to enhance this. I am not an expert, but definitely volunteer to validate whether any such update would have proved helpful. And perhaps the following suggested addition can be a start? "Shading tries to maintain color fidelity between LibreOffice and Microsoft Office to the extent possible. Choose this if interoperability is your primary concern. Highlighting uses a brighter color palette when exporting to Microsoft Office formats, which makes text stand out more strongly while creating more of a visual difference. Choose this is your priority is the highlighting effect over visual fidelity."
(In reply to Gerald Pfeifer from comment #19) > And perhaps the following suggested addition can be a start? > > "Shading tries to maintain color fidelity between LibreOffice and > Microsoft Office to the extent possible. Choose this if interoperability > is your primary concern. Highlighting uses a brighter color palette > when > exporting to Microsoft Office formats, which makes text stand out more > strongly while creating more of a visual difference. Choose this is your > priority is the highlighting effect over visual fidelity." This explanation is helpful (at least for me). And heading in help page should be named "Character Highlighting" instead of "Character Background" to follow the naming in LO settings (But perhaps it's better to open a new bug report for this?)
Tamás Zolnai committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/41dcf55d347d4f4810379148b2db0fb4a41d3465 tdf#125268: Add mso-highlight color palette. It will be available in 7.0.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.
> 1. Change the default behavior such that an export from ODT to DOCX > changes colors as little as possible. > > I now understand there is an option under > Options -> Tools -> Load/Save -> Microsoft > re shading vs highlighting, but this is rather hidden and as a user > the primary expectation is one of interoperability where possible. I'm not a fan of changing the default behavior back and there. You see only your own problem now, but other users had a problem with exporting this color as MSO shading, because they could not change the character background when they opened the document in MSO. In MSO, shading is kinda hidden on the UI, while highlight tools is the obvious item to use for character background. So both options cause interoperability issues. So I don't think that changing the default value back and there will improve the situation in general.
Improving the help page is a good idea.
(In reply to Tamás Zolnai from comment #22) > > 1. Change the default behavior such that an export from ODT to DOCX > > changes colors as little as possible. > > > > I now understand there is an option under > > Options -> Tools -> Load/Save -> Microsoft > > re shading vs highlighting, but this is rather hidden and as a user > > the primary expectation is one of interoperability where possible. > > I'm not a fan of changing the default behavior back and there. > You see only your own problem now, but other users had a problem with > exporting this color as MSO shading, because they could not change the > character background when they opened the document in MSO. In MSO, shading > is kinda hidden on the UI, while highlight tools is the obvious item to use > for character background. So both options cause interoperability issues. So > I don't think that changing the default value back and there will improve > the situation in general. But I'm exhausted by this. So I'll change the default behavior and I'll point this bug out for those users who will complain about the new default.
https://gerrit.libreoffice.org/c/core/+/90909
Tamás Zolnai committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/701238ea7d8a06fe7a90de15b7660b7c6d854f09 tdf#125268: Export LO character background as MSO shading by default. It will be available in 7.0.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.
The patch will be part of the next release, which is 7.0.
(In reply to Tamás Zolnai from comment #24) > But I'm exhausted by this. So I'll change the default behavior and I'll > point this bug out for those users who will complain about the new default. Sorry, I did not mean to exhaust you. That was my perspective as a user (which I've voiced here for the first time); others may differ of course. (In reply to Tamás Zolnai from comment #23) > Improving the help page is a good idea. And I am still committed to help with that. Should I open a new issue with my suggested text? (I'm not sure it is completely accurate, it just reflects my personal experience.)
(In reply to Gerald Pfeifer from comment #28) > (In reply to Tamás Zolnai from comment #24) > > But I'm exhausted by this. So I'll change the default behavior and I'll > > point this bug out for those users who will complain about the new default. > > Sorry, I did not mean to exhaust you. That was my perspective as a user > (which I've voiced here for the first time); others may differ of course. UX team should have discussed this first, the commit was made too quickly. Of course it can be reverted after proper consideration.
(In reply to Gerald Pfeifer from comment #28) > > Improving the help page is a good idea. > > And I am still committed to help with that. Should I open a new issue with > my suggested text? (I'm not sure it is completely accurate, it just reflects > my personal experience.) Yes, I think that would be better than mixing it with this bug here.
As mentioned on IRC, I don't have a solution. I'll just use the log as an infodump. [14:51] <jmux> buovjaga: the change is just in 7.0, so plenty of time to agree on some "final" solution. Probably start with a revert, so LO won't accidently release the current state. [14:52] <buovjaga> sure [14:52] <jmux> And I agree with buovjaga that this is a primary a usability, not a coding problem. [14:56] <jmux> What I seem to understand is: character background handling is different between ODF and DOCX. I don't know, why DOCX has shading and highlight. [14:57] <lo-dsgn-tg> <Kompilainenn> History [14:58] <jmux> I don't think it's a good idea to open a DOCX and allow the user to make changes, which aren't representable in the format. [14:59] <jmux> As we already see, this results in frustration. Since the user doesn't know about this limits, no blame on him. [15:01] <jmux> So I guess the idea about the MS color palette is not the worst to start with. [15:03] <jmux> It obviously breaks, if the import document now actually uses shading colors, as LO at this point can't know, if the color was highlight or shading to begin with. [15:05] <jmux> IMHO the UX team should provide a suggestion to handle these constraints in their preferred way given the restrictions. [15:05] <jmux> And then we can discuss, if an implementation is feasible. [15:08] <jmux> And from my current POV, it doesn't look that there will be any perfect solution. Also when the term highlight is already used different in DOCX and ODF. [15:11] <jmux> Maybe for DOCX documents there should be explicitly two ways to set the background: highlight and shading, so the user can be aware of the difference? [15:16] <jmux> Or have a color picker with two areas, one depicting the 15 highlight colors and one for the shading? [15:17] <jmux> BTW: what happens, if the user sets highlight and shading? Is that possible? [15:36] <lo-dsgn-tg> <Kompilainenn> We already have two variants for saving highlights/shading for docx documnets [15:36] <lo-dsgn-tg> <Kompilainenn> You'll find option in Tools-Options dialog [15:42] <jmux> Kompilainenn: I'm aware of the compatibility settings. But I don't think this is the most agreeable solution from the UX POV. [15:43] <lo-dsgn-tg> <Kompilainenn> Why not? It worked many years [15:44] <lo-dsgn-tg> <Kompilainenn> If UX-team will suggest a better solution it would be good... [15:46] <lo-dsgn-tg> <Kompilainenn> But I don't think it's an UX problem [15:46] <lo-dsgn-tg> <Kompilainenn> In general [15:48] <jmux> Maybe. I don't know if this is a common problem or not. I read the bug as that it is, but really don't have a way to evaluate the claims. [15:50] <jmux> If "we" decide the compatibility flags is still good, fair enough. Less work to be done.
I was also taken by surprise that I had selected "Light Yellow 3" in a document, saved it as .doc , and to see that the color was changed to "Yellow" after I had reopened it. So I hope that I have a useful suggestion. For me as a user everything is much less surprising if they are visible. Image "HighlightAndShading.png" gives a photoshopped impression. In this suggestion Highlighting and Shading can be seen at the same time. Users should be better aware of the two when both are visible at the same time. So ... would it be worth a thought to remove: "Character Highlighting, Export As Highlighting / Shading" from "Tools -> Options -> Load/Save -> Microsoft Office" and do something like the image instead? As a user, I am also much happier with less options under "Tools -> Options -> etc.". I never know if an option is there, and if it's there, I never know where it's located or what its name is. More than once I clicked all (!) the boxes and tabs under "Tools -> Options", in various programs repeatedly (!), only to find that the thing I was looking for, wasn't there. If the developers don't like this idea, that's fine with me, but if it can be given a thought, that would be really nice. I hope that implementing this suggestion leads to less confusion with users, I hope that less confusion leads to less bug reports, and I hope that less bug reports leads to less work for the developers. :) :) :) With this suggestion I did keep in mind that documents can be created in Libre Office and then sent to MS Word users, that they can go the opposite way, but also that they can go back and forth all the time. I don't know if it's better if a user can select both shading and highlighting at the same time, OR if they should only be able to choose one of the two. If they can select both at the same time in MS Word, then it may be better for compatibility to do this in Libre Office too. Most of all I hope that I made a user-friendly suggestion. :) (Obviously, I hope it's developer-friendly too. :) ) Thanks again to all the developers for all the time and effort that you are putting into this. PS: I had first posted this suggestion in topic 131466. When first posting, I had not read jmux's comment "Maybe for DOCX documents there should be explicitly two ways to set the background: highlight and shading, so the user can be aware of the difference?".
Created attachment 158906 [details] This photoshopped image gives a suggestion for showing the user Highlighted and Shading at the same time.
In MSO, character shading and character highlight are the same functionality implemented twice from the user perspective. I assume this is because of historical reasons. We try to reproduce the useful features of MSO, but not MSO's history and not MSO's mistakes. This functionality duplicate lead to bad user experience since when a document has a text color, it's not clear whether it's shading or highlight for the first look. Some users are using only the highlight tool in MSO because that is the more visible feature on the UI and these users are confused when they can't remove existing text color with the highlight tool, because that is shading. The same complaining was about LO before, because it used shading and users were not aware of that feature of MSO. https://groups.google.com/forum/#!topic/microsoft.public.word.docmanagement/NH8mtn67kTM https://askubuntu.com/questions/224760/highlights-in-libreoffice-writer-cannot-be-undone-in-office-word So, all-in-all it's not a good idea to implement two character backgrounds in LibreOffice to mimic MSO bad design. So we have one character background in LO, which means displaying two sections of text colors just does not make sense for LO users. The two-section has no difference both set the character background or highlight or whatever we name it. If a user says there is any difference between the two features I think it's just justifying the existence of them, not actual difference. MSO shading and MSO highlight are both for setting background of the selected text. I think the suggestion of adding two sections of colors can't be added in general for all users, because "native" LO users don't care about MSO, so they don't need to be confused about two character background color. However, we already have some MSO compatibility option, so I can imagine a new option which enables this UI for those who need better MSO compatibility.
Tamás, thank you for your explanation!
(In reply to Bart from comment #32) > I was also taken by surprise that I had selected "Light Yellow 3" in a > document, saved it as .doc , and to see that the color was changed to > "Yellow" after I had reopened it. This! This is the challenge in a default configuration right now, which also caught me by surprise. > So I hope that I have a useful suggestion. For me as a user everything is > much less surprising if they are visible. > > Image "HighlightAndShading.png" gives a photoshopped impression. In this > suggestion Highlighting and Shading can be seen at the same time. Users > should be better aware of the two when both are visible at the same time. I think this is an interesting suggestion. Thanks for putting this forward, Bart. For a "normal" LibreOffice user it may not be intuitive - the challenge, however, remains how we can inform users of the challenge (change of colors when interoperability with Microsoft Office is required) and how to avoid it? (In reply to Tamás Zolnai from comment #34) > In MSO, character shading and character highlight are the same functionality ...which is very confusing, though of course nothing we have control over; rather, it has been a source of challenges for us. > I think the suggestion of adding two sections of colors can't be added in > general for all users, because "native" LO users don't care about MSO, so > they don't need to be confused about two character background color. > However, we already have some MSO compatibility option, so I can imagine a > new option which enables this UI for those who need better MSO compatibility. Thank you for the detailed background, Tamás. Do you have an idea how we can point people towards that option (which is really hidden)? Or could some work on the color palettes, in a default config, help?
I don't think we should fix this by itself. Better we would fix a different issue, which is unclear set of what is broken on export. The warning user gets when saving to an external format doesn't list specifics what will break; and e.g. in this case, it could have an item for "A character background cannot be represented using MSO's highlighting and will be approximated to [this color]. Alternatively, you may select character backgrounds to be exported as shading, which is less-known MSO feature and may cause UX issues..." with possible links to descriptions, etc. That is a big task, but you just cannot hope to solve problems like this one, where there's a feature set mismatch (and even inherent other program's UX problem!), to fit all.
> Better we would fix a different issue, which is unclear set of what is broken > on export. The warning user gets when saving to an external format doesn't > list specifics what will break; This is an old-chestnut. There is a very significant cost in code complexity, maintenance and CPU time of walking the entire LibreOffice document model before starting to serialize it. Worse - whatever output we produce is never going to be completely accurate anyway. Worse - this will inevitably produce a long, and impenetrable series of highly technical 'stuff' as text (if we had even more infinite resource we could link each item to the document somehow) - that is going to be frightening and/or not interesting to all of our end-users who just want to understand: "why does it not work?", "Why did you let me get into this situation I don't understand !?" - etc. Any good UX should not be spending lots of time, developer work, debugging etc. to do an imperfect job of providing extremely dense and unhelpful information. No matter how satisfying that is to developers who can say "I told you so in a footnote on page 135 of that dialog you clicked through" ;-) Microsoft of course were leaned on by their customers to try to do this for their ODF export filter. They produced 900+ pages of documentation - you can read it here: https://docs.microsoft.com/en-us/openspecs/office_standards/ms-oodf/68b99f79-842f-4db2-9249-0f71b611712b in a 10Mb PDF download. I'm not in the UX team; but I would be staggered if this was thought to be a good idea. Almost certainly it is far easier to solve the problem in a more elegant way. As an example: if you load a DOCX file - then we can safely assume you will save as DOCX (this covers some vast proportion of the use cases) - and so we can hide the UI options associated with doing more powerful ODF supported things =) On ODF export to DOCX people expect some format shifting problems, so we select the nearest feature, and the nearest matching hue for this case. At least, that's my 2 cents.
(In reply to Michael Meeks from comment #38) > This is an old-chestnut. There is a very significant cost in code > complexity, maintenance and CPU time of walking the entire LibreOffice > document model before starting to serialize it. Worse - whatever output we > produce is never going to be completely accurate anyway. I don't think it's that complex. Just moving the warning dialog from beginning of the export into "in the middle", when an export model was created, but not yet written t the file, would allow each export function to output its warnings to a provided logger. No need to create a dedicated step. > Worse - this will inevitably produce a long, and impenetrable series of > highly technical 'stuff' as text (if we had even more infinite resource we > could link each item to the document somehow) - that is going to be > frightening and/or not interesting to all of our end-users who just want to > understand: > "why does it not work?", > "Why did you let me get into this situation I don't understand !?" - etc. Believing that you may always come with an "elegant" solution to problems caused externally is daydreaming IMO. The list might be collapsed by default, but not providing it because many wouldn't understand it is demeaning users. In fact, currently many users just disable the warning that has no value at all, because it seems to be wrong ("I saved my simple document to DOCX many times, and never got any problems - it must be a joke!") only to later stumble upon a problem with a thing that they never used before, and come here or to AskLibO with "you ruined my many hours of work without warning!". If instead we only output the dialog when there's actual dataloss, like here, or at least make it "we didn't identified specific issues, but still there might be some problems" when nothing specific was identified, it would provide value to people. > I'm not in the UX team; but I would be staggered if this was thought to be a > good idea. Almost certainly it is far easier to solve the problem in a more > elegant way. > > As an example: if you load a DOCX file - then we can safely assume you will > save as DOCX (this covers some vast proportion of the use cases) - and so we > can hide the UI options associated with doing more powerful ODF supported > things =) On ODF export to DOCX people expect some format shifting problems, > so we select the nearest feature, and the nearest matching hue for this case. Which would effectively mean "let's implement MS Word for those who load DOCX; Pages for those who load .pages, etc.". That would become a nightmare of multiple inconsistent UIs, each trying to satisfy some subset of users, and at the same time dissatisfy e.g. users who receive a DOCX and are editing it to save as ODT.
(In reply to Michael Meeks from comment #38) > As an example: if you load a DOCX file - then we can safely assume you will > save as DOCX (this covers some vast proportion of the use cases) - and so we > can hide the UI options associated with doing more powerful ODF supported > things =) On ODF export to DOCX people expect some format shifting problems, > so we select the nearest feature, and the nearest matching hue for this case. Let me provide an example of a (different) problem that this would bring. In Writer, there's a concept of page styles, which is totally absent in Word. Trying to "hide" this functionality from users opening DOCX would simply disable any means of manipulating pages in Writer (there's nothing except of page styles for that in Writer, and that is its strength). So that would result in need of spending so little developer effort implementing an alternative machinery - UI, but also internal stuff. Of course, that won't bring any maintenance costs with it, and no problems with interoperability of stuff created by the same Writer when in different modes.
We discussed the topic in the design meeting. While introducing a color palette is the easiest solution it cripples our features for no good reason. MSO might change the behavior at any time. The better approach is to warn in detail what attribute in the current document might not work when saved as docx (or other formats). That means to analyze the document, compare against a list of incompatibilities, and show it to the user. The newly introduced mso-highlight.soc palette is questionable.
So - this should go to the ESC, the debate doesn't belong in a bug. We have discussed this before, I explained what IIRC was the consensus then. Taking this to extremes is unhelpful in any direction. We need a solution that doesn't surprise the users - and endless caveats in a hidden dialog is not that IMHO. Miklos / Kendy can you add to the ESC agenda for next week ? all are welcome to show up & contribute there of course.
(In reply to Heiko Tietze from comment #41) > We discussed the topic in the design meeting. While introducing a color > palette is the easiest solution it cripples our features for no good reason. How does a MSO color palette cripple the features of Libo? And is interoperability not a good reason. In this line of argument I would question the capability to export to different formats in general. ODT or nothing. > MSO might change the behavior at any time. Yes, but the have the same backward compatibility issue. Not every-one is running the latest version of MSO. Pushing something like that is only possible with MSO cloud only solutions. Where everbody is forced to work with latest and greatest version. > > The better approach is to warn in detail what attribute in the current > document might not work when saved as docx (or other formats). That means to > analyze the document, compare against a list of incompatibilities, and show > it to the user. I'm not really convinced here. Specific to highlighting. I have a created a document, with tons of highlighting. I want to share it somebody with MSO (docx/doc). On export (say after 20 hours of work) I get a warning "A character background cannot be represented using MSO's highlighting and will be approximated to [this color]". Grumble. I see three outcomes: 1. Export anyway with approximated color (Current situation) 2. Export the document with highlight saved as background color (which can't be edited in MSO easily (or at least unconventional). So ending up with questions for MSO user (situation before 5.0) 3. Redo the document with the limited color palette (The LibO user has tones fixes to do anyway) More in general: it would set a president to do this for all types for compatibility issues. Which is probably quite a long list of all types of stuff. What so happen when a anchor is positioned differently (or different one is used in MSO). Exported DOC/DOCX maybe look the same, but technically different [no knowledge if this problem really exists, but expect something similar to do so] > The newly introduced mso-highlight.soc palette is questionable. Please explain why. I know you don't like it. Is it the own identity of LibO? It feels a bit like MS arrogance. Set a standard and force others into it. With the difference that MS Office has large part of the office marked? Compatibility issues is the reason why people don't want to use LibreOffice or turn the back on LibreOffice after the run into trouble. I'm personally quite content with the mso-highlighting color palette. It at least gives the possibility to work MSO complaint (which wan't possible before). I would opt for renaming mso-highlight to mso-compability-highlight (should fit in dialog). Which would be a subtitle warning & proper documentation. And maybe optionally set mso-compability-highlight default for doc/docx. But only if this type of problem is really limited docx/doc. Btw, are palette setting also saved inside the ODT? If this is the case, it would also fix the DOCX/doc to ODT variant. [Note: not suggestion palette setting should be saved, if this isn't the case currently.]
The issue with "It took many hours to make this, and now it tells me it can't be saved into DOCX is a serious one (although if one would try to save to, say, TXT, many would agree that it's not an issue ;-))". But instead of creating sets of UI for different scenarios, maybe a service that could dynamically check the document for "compliance" with currently active filter could be better? (I don't see a problem in compatibility palettes; the problem is when to use one.) E.g., the service could work in the background, like spellchecker; and when it finds an issue like this one, it adds a warning info panel (similar to "read only") with explanation. Or it could react to uno commands, analyze the result, and show a tooltip. The warning message in the info panel or tooltio could be something like "This color cannot be saved as highlight in DOCX". As that would popup right when user made the change (or 10 seconds later, if run in the background), it would be easy to act timely, and not stack problems until it takes a full re=creation of the document from scratch. However, this doesn't remove the need for save-time check. No amount of magic would prevent a user to create a new document, add any formatting (while it doesn't have a chosen filter yet), then decide to save to DOCX. Only save-time dialog with enough information could help then.
I read the reactions and I hope that I can offer something that pleases most of the people here. Of course these suggestions are -again- just suggestions. Feel free to disagree. I have been in software development myself (although more back-end than front-end) and that's why I see this topic from four perspectives: - The Libre Office standard user - The Libre Office sophisticated user - The Microsoft Word user - The Libre Office developers (last but not least) To address the concerns that I noticed, I changed the image that I had made and I added a few lines and a few buttons. (That's image "HighlightAndShading2.png") That screen however, gets too detailed for me as a user. I no longer see what's relevant and what's not. That's why I made image "HighlightAndShading3.png". Now only Highlight Colors are initially shown. After clicking "More Colors (= Shaded Colors)" the user also gets to see the Shaded Colors. The user can either get what he gets now, OR the user can get something with both Highlighted and Shaded (like in "HighlightAndShading3.png"). Which of the two the user gets is not up to me, but since the user already choose for Shaded Colors, showing the Highlight Colors also may be redundant. BTW, I think there's a nice undertone in the sentence: "Other word processors may or may not fully supported Shaded colors". To me this sounds as if Microsoft only offers regular chocolate, while Libre Office offers Cherry Chocolate. :) I suspect that most standard users will choose a Highlighted Color, while most sophisticated users may choose from a Shaded Color. I also expect sophisticated users to be aware of compatibility topics better. The buttons "More Info" could give some explanation and warnings about compatibility and exporting. Maybe it could explain how to remove Shaded Colors in Word. Although ... I'm not sure if it's the responsibility of Libre Office to explain how Word works. Although again ... there may be less questions on forums if this information is added, and less users moving away from Libre Office. I hope that this suggestion also makes it easy for developers to decide if a piece of text should be stored as Highlighted (and be supported by Word), or if it should be stored as Shaded (only partly supported by Word). I hope that this way users are better aware that there are Highlighted Colors and Shaded Colors, even if the two are the same in the document itself. I do see one important difference: Highlighted Colors can easily be changed in Word, while Shaded Colors are less easy to change in Word. For me as a user, screens like this will avoid confusion and surprises. Again, this is just a suggestion. It's up to others what to do with it. I hope it's an elegant solution. If not, I'm perfectly willing to polish it or to come with alternatives. Feel free to shoot at it, but please be kind when shooting. :D PS: An idea popped up how to persuade users to save their documents as .odf and how to persuade MSO to change their behavior at any time. It's exactly where compatibility issues arise, but I think it's better if I post that as a separate suggestion. Regarding the "Libre Office standard user", a senior friend of mine uses Libre Office. His documents were always saved as .odt. Before traveling he always emailed his itinerary to friends and family. Many of them would be struggling to open his documents and he got a lot of unpleasant emails back. When he asked me for help I explained what had happened. On his request I changed the settings and now his documents are saved as .doc by default. Regarding the buttons "more info", when updates went into production at work, I often sent an email to the users with the most important changes, only to find out ... that nobody ever read them. So I did it differently. On the screens that I had changed I added buttons "more info" with the most important information about that screen and their fields. When clicking these buttons, users would get the information they needed, when they needed it, and not more not less. They loved it. I got less emails and phone calls, so hehe, I loved it too. :D (That's also the idea behind buttons "More info" in the images.) In Word version 14 I could only find one way to remove shaded color. I select the text, cut it, and choose "paste unformatted text" somewhere without shaded color. Maybe there are other ways, but this is the only way I found. Regarding the terms "Highlighted Colors" and "Shaded Colors", for me, "Highlighted Colors" are compatible with Word documents. "Shaded Colors" are less compatible with Word. As a developer I try to keep solutions simple and easy. I know that that's not always possible, but very often when I choose sophisticated solutions, they would bite-me-in-the-butt later. :p
Created attachment 159081 [details] Showing Highlighted Colors and Shaded Colors simulaneously, Version II (I added a few lines and buttons in the image)
Created attachment 159082 [details] Showing Highlighted Colors first, showing Shaded Colors if the user selects that option
> The newly introduced mso-highlight.soc palette is questionable. Hmm, I have found one downside.. The palette exists across all color pickers and isn't limited to the highlight color button.
Created attachment 159150 [details] MSO highlighting MSO character highlighting (left, green) and (paragraph or selection) shading (expanded). Just to illustrate how much the MSO users "suffer" from shading.
I have to agree with Tamás that this is exhausting--at 5.0 release, for bug 64490 we implemented filter import of both Highlighting and Shading from .doc/docx as LibreOffice Character background. Changing defaults for the export filter mode back and forth, between MSO Highlighting vs. MSO Shading, makes little sense--we changed it for the better at 5.0, leave it that way. Export to MSO Shading remains a user selectable option. The addition now of the mso-highlight.soc (or even rename it mso-compatability-highlight.soc) pallet was a logical addition for interoperability in the GUI, so that the default Highlight mode color would behave on round trip. +1 for > 5.0 status quo and retention MSO Highlight compatibility mode by default. Addition he mso-highlight.soc, with the 15 fixed colors that MSO supports, helps the GUI for the color pickers. But these MSO swatches should not be mixed into the standard.soc which was reworked to support RYB additive color model, they don't belong. Rather, the MSO Highlight colors need to remain in a distinct palette--maybe suppressed for use when needed just for MSO Highlight mode--or globally available to the color pickers as now, but not added to the standard.soc So, please revert https://gerrit.libreoffice.org/c/core/+/90909 it is a backward step in interoperability.
OK, I'm reverting the default change. In the last five years we have this as a default, so better not to change it. None of the default will fix the issue perfectly. Hopefully, somebody comes up with a different solution, which satisfies the user's needs.
(In reply to Tamás Zolnai from comment #51) > OK, I'm reverting the default change. Thanks. That makes me happy. I like the concept of having a limited palette by default for highlighting too.
Tamás Zolnai committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/24be308681a84937dbd510009e266bacb16cf2fa Revert "tdf#125268: Export LO character background as MSO shading by default." It will be available in 7.0.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 Michael Meeks from comment #42) > Miklos / Kendy can you add to the ESC agenda for next week ? all are welcome > to show up & contribute there of course. Done.
(In reply to Miklos Vajna from comment #54) >> Miklos / Kendy can you add to the ESC agenda for next week ? all are welcome >> to show up & contribute there of course. > Done. Thank you. For a use case I don't think has been mentioned here, consider bug #131215 that was closed as a duplicate: I create a document in ODT all along the way, and in the last minute was asked to share as DOCX, exported, and was surprised how differently it appeared.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a4c5e940881520834c19573c5b1119afa1c17744 tdf#125268 officecfg: export LO character background as MSO shading by default It will be available in 7.0.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 Gerald Pfeifer from comment #55) > I create a document in ODT all along the way, > and in the last minute was asked to share as DOCX, exported, and was > surprised > how differently it appeared. That's a polite way to describe a data loss. :-) That piece of the problem is now fixed (again), thanks Tamás for the original commit. Marking as resolved.
ESC -- scratching my head over that... with a flip-flop of default export aren't we are back to issues of bug 64490--the more common MSO 'Highlight' casual user with a "what's 'Shading'" grasp of their UI. If LO users are concerned about interoperability, they should in general be using appropriate colors for their background colors--made easier now with the MSO compliant color values from the new mso-highlight.soc palette--destined for highlight or shading. And if they stray from that limited palette of 15 colors for character background colors, understanding an export to MSO (binary or OOXXML) as MSO "shading", toggle to that value in Tools -> Options -> Load/Save -> Microsoft Office -> Character Highlighting. In other words, the export filter needs refactoring to be made smarter. Nothing fancy, just export the 15 MSO highlight colors as "highlighting". And any other background color as "shading"--the Load/Save for MSO Character Highlighting becomes "automatic" by default. And then allow override to force export of highlight or shading.
and me - I only had read comments up until #53 - was just about to express my support for Bart's comment #46 and comment #47 (Not perfect, but as I see it, the most simple _solution_, i.e. offering information and choice. And it must be doable to have this only on places where it is relevant.) And say thanks to @Tamás for all efforts made!
The 'right' approach will probably never be found, argh. Anyhow, what happens if docx with highlighting is shared to a LibreOffice user. Who edits the file, saves it, and sends it back? In my small test: A) Original 'highlighting' saved as 'highlighting' B) Compatible mso-highlight.soc highlighting saved as 'shading' C) Incompatible highlight saved as 'shading' comment 49 MSO users are suffering. You need know which of both tools you need. Is part of text highlighted or shaded. A mixture of both seems to be the worsed outcome. comment 54 The Tools -> Options -> Load/Save -> Microsoft Office -> Character Highlighting stuff is nice, but no solution. The setting has been implement in 5.0, but I don't expect a regular to know this (I didn't either, reported a bug as 'everybody' does) comment 59 * Does LibreOffice/ ODT format make a difference between "shading" and "highlight". The dialog suggests it's stored as the same thing * How do people get to the point to export a document to doc/docx. A group is initial working for themselves (without having a reason to limit the highlight color usage) and are considering export afterwards. The will run into trouble anyway. A group will be working with doc/docx documents intended to share (but are they aware of the limitations of highlight colors in MSO?). A mso-highlight palette is never requested before as far I know (or did I ask for it?). So the interest doesn't seem pretty low. And it doesn't really fit into the gui nicely. --- Converting all the highlighting to shading when saved as doc/docx will prevent the mixture, but at the same time create a surprise effect. I have highlighted this, but I can't edit anymore Converting all the highlighting to the next best thing of the mso compatible palette generates a document nobody intended. I'm starting even to consider what the docx warning dialog suggests: This document may contain formatting or content that cannot be saved in the currently selected file format “Office Open XML Text”. The incompatible highlighting shouldn't be saved at all (instead of doing supposedly next best thing, which is also causing dataloss). --- Preventing this type of dataloss - lack of file format compatibility - I would even consider a separation between saving a document and exporting a document. The user shouldn't be allow to directly save a file into a (not fully supported) foreign format. Imported DOCX/DOC/RTF (or XLSX) documents should only be saved into the native Libo format (or any other format fully supported). It's already a common advise, but not 'enforced'. A document can only be exported foreign format (similar to handling of Epub/PDF). So separated button/menu entry (maybe including epub). And export doesn't count as save (so still save document dialog popup up when closing a document, already export before). [More the area of the UX-team] The current file format warning is ignored or even disabled, because it works most of the time.. And people come complaining if it doesn't work as expected. And it would prevent 'real' dataloss. The 'data' is secure and safely stored as, say ODT. The export is only a facility for sharing document without guarantee it will work. LibreOffice 7.0 would be nice opportunity to push this, IMHO. In the context of seeing doc/docx as export format, I would opt for shading. But please convert *ALL* the highlighting to shading, even the MS compatible highlight formatting created by MSO (preventing a mixture of highlighting and shading in one document caused by LibreOffice). [Note: Yes, the Word user can edit it again and use a highlighter, so again a mixed document. But it's easy to fix by exporting it again in LibO] In this case, drop: mso-highlight.soc. It doesn't matter anyway. And add some explanation in the help that 'highlighting' in doc/docx is saved as shading for compatibility reasons (and how a Word user can edit it) Or add a dialog and ask the user when exporting the docx/doc what he want, and let him or her make the impossible choice between shading and highlighting. MSO unsupported color highlighting shouldn't be stored at all, if somebody opts for highlighting. Leave the mso-highlight.soc around if somebody wants to be mso highlight complaint (a case which probably isn't happening to often). Nobody asked about MSO highlight palette before. The surprise occurs after saving/exporting to doc/docx.
I'm wondering if I explained my suggestion not enough in my previous posts. In the suggestion that I made, the option under Tools -> Options -> Load/Save -> Microsoft Office -> Character Highlighting. would no longer exist. Instead, if the user selected a "Highlight Color" (as shown in attachment 159081 [details]), that color would be saved or exported as MSO highlight. If the user selected a "Shading Color" (in the same attachment), that color would be saved or exported as MSO shading. Personally I prefer the the solution that attachment 159082 [details] shows. In attachment 159082 [details] the only difference is that initially only the palette with "Highlight Colors" will be shown. If the user chooses one of those colors, the color will be saved or exported as MSO highlight. If the color clicks button "More Colors (= shaded colors)" and chooses a color from the palette that comes next, that color will then be saved or exported as MSO shading. I hope and expect that most LO users will choose from "Highlight Colors", because that's what they see first. MSO users should not be suffering too much. Advanced LO users may choose from "Shaded Colors", but I also expect them to be able to explain to MSO users that the color is not a "Highlight Color". (This is also why I made the distinction between "Highlight" and "Shaded" colors, even if that's just a distinction in words, and even if both are stored as the same thing.) I'm a developer myself. I have seen that some things can be super clear for me, because I work with those things every day, while a regular user has no idea of what's happening. I don't know how the LibreOffice program and documents are organized internally. Maybe this solution is doable, maybe it isn't possible at all. The only thing that I can do is present it. ;) But resuming, the option under Tools -> Options -> Load/Save -> Microsoft Office -> Character Highlighting. would no longer exist in this solution. PS: This post gives me the feeling that I'm trying to "push" the this solution, but I'm trying to remove misunderstandings. ;)
(In reply to Cor Nouws from comment #59) > and me - I only had read comments up until #53 - was just about to express (In reply to Bart from comment #61) > I'm wondering if I explained my suggestion not enough in my previous posts. In my understanding, this can be bought to a new ticket, independent of the decision made here. ( I hope I'm correct in that ;) ) Will do (but later - sun is shining here ;) )
Hi everyone, Please let's stop updating this bug, it has way too much information already. :-) Sorry, I forgot to post the ESC minutes to this bug, only linked them from the above commit. Let quite the relevant part of <https://lists.freedesktop.org/archives/libreoffice/2020-April/084813.html>: > * Wrong text highlight color when export document to doc/docx (Heiko) > + https://bugs.documentfoundation.org/show_bug.cgi?id=125268 > + MSO allows "shading" with any color and "highlighting" with 15 colors only; > LibO highlighting corresponds to MSO's shading > + http://zolnaitamas.blogspot.com/2015/03/word-compatible-text-highlighting-in.html > + Help: "Microsoft Office has two character attributes similar to > LibreOfficeDev character background. Select the appropriate attribute > (highlighting or shading) which you would like to use during export > to Microsoft Office file formats." => documentation issue > + Solution #1a: Use highlighting (WFM/NAB) > - LibO character background might get replaced => the issue in this ticket > + Solution #1b: Use shading > - not intuitive for MSO users (paragraph > theme colors), > in particular on round trip > - default for the export until 5.0 but replaced with highlighting then > (tools > options > load/save > char highlighting) > - changing defaults back and forth is not good > - improve help > - patch has been submitted by Tamaz (c26) but reverted (hc53) > + Solution #2: Introduce shading in LibO > - unclear use case besides compatibility, confuses users (c34) > - could extend the palette widget (c45,46) > + Solution #3: Special palette activated per compatibility flag > - another patch by Tamaz (c21) > - cripples LibreOffice while MSO may change at any time > - code needed as the new palette is offered now unconditionally > + Solution #4: analyze the document and warn the user when using a not > supported feature (if the file was opened as doc/x) or when saving > - might be a long list and need some time to compile > > + current situation: the new default from Tamas Z is reverted > + Word UI is not that obscure anymore (Heiko) > + trade-off: > + save to shading: no data loss, but not a highlight anymore > + save to highlight: no switch to shading > + no strong opinion (Micheal S) > + ideal: do both in Writer, like Word (Kendy) > + agree – always have problems if format is different (Caolan) > + means fewer highlighting colors but can prolly live with > + perhaps put it on the tendering list. > + suggest flip the default as Tamas Z did (Miklos) > + agree having shading (Heiko) > + short-term hidden option ? (Thorsten) > + option is already there but complaints wrt. finds it (Miklos) > + trade-off of MS Office usability vs. data-less > => decision – switch back to not loosing data > AI: do this (Miklos) > => add to tender list having compatible highlighting > + naming of compat palette ? (Heiko) > + same colors as HTML, don’t have a strong dislike > => naming is a UX topic Heiko to pick a name. I believe the ESC carefully considered the options available, decided to quickly go with the best option that is doable short-term, so the action was thought through. I also think it's fair enough to have a follow-up bug that wants the full "highlighting + shading at the same time" feature, it would make sense to work on that longer term. I've filed 131920 for that, please let's continue the discussion about a longer-term solution there. Please try to update this bug further, so this summary at the end has the needed visibility. Thanks!
(In reply to Miklos Vajna from comment #63) > > + naming of compat palette ? (Heiko) > > + same colors as HTML, don’t have a strong dislike > > => naming is a UX topic Heiko to pick a name. "Compatibility" was proposed earlier, done in https://gerrit.libreoffice.org/c/core/+/91584
(In reply to Cor Nouws from comment #62) > In my understanding, this can be bought to a new ticket, independent of the > decision made here. ( I hope I'm correct in that ;) ) > > Will do (but later - sun is shining here ;) ) Cor, it's a good thing that you don't live here in San Diego. Over here the sun is shining nearly every day. If you lived here, making that new ticket might take half a year. :p (joking) (In reply to Miklos Vajna from comment #63) > I also think it's fair enough to have a follow-up bug that wants the full > "highlighting + shading at the same time" feature, it would make sense to > work on that longer term. I've filed 131920 for that, please let's continue > the discussion about a longer-term solution there. > > Please try to update this bug further, so this summary at the end has the > needed visibility. Thanks! Miklos, are you suggesting that I add my suggestion to bug 131920? I'll be happy to do so, including the photoshopped examples, but I'm new here. If adding my suggestion to bug 131920 wouldn't be the best thing to do, then that bug could get blurry from the start, and that's what I want to avoid. So ... do I add my suggestion to bug 131920? PS: I realize that bug 125286 (this one) has 20 users. If you email back to me only, that's perfectly fine with me. (I'm bart-dn@ etc.)
So that everybody is up to date, I added my suggestion to bug 131920. ;)
(In reply to Gerald Pfeifer from comment #19) > 2. Timur pointed me to > https://help.libreoffice.org/7.0/en-US/text/shared/optionen/01130200.html > which absolutely would not have helped me (without the actual example he > showed.) > > "Microsoft Office has two character attributes similar to > LibreOfficeDev character background. Select the appropriate > attribute (highlighting or shading) which you would like to > use during export to Microsoft Office file formats." > > It would be great to enhance this. I am not an expert, but definitely > volunteer to validate whether any such update would have proved helpful. > > And perhaps the following suggested addition can be a start? I filed this documentation issue with my proposal on how to possibly improve as https://bugs.documentfoundation.org/show_bug.cgi?id=132695 .
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b184d39e212a4af6fcec723cfec58af61da121e0 tdf#125268: sw_ooxmlexport15: Add unittest It will be available in 7.2.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.
*** Bug 127034 has been marked as a duplicate of this bug. ***