Bug 115291 - List incompatible features when saving to alien formats in detail (see c5)
Summary: List incompatible features when saving to alien formats in detail (see c5)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.3.2 release
Hardware: All Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice
: 116458 (view as bug list)
Depends on:
Blocks: DOCX-Character DOC-Character
  Show dependency treegraph
 
Reported: 2018-01-29 06:08 UTC by Mark
Modified: 2019-04-20 21:47 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Example of .odt text highlight color change when saved as .doc file (25.50 KB, application/msword)
2018-01-29 06:08 UTC, Mark
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark 2018-01-29 06:08:00 UTC
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: 5.4.3.2 (x64)
Build ID: 92a7159f7e4af62137622921e809f8546db437e5
CPU threads: 4; OS: Windows 6.19; UI render: default; 
Locale: en-US (en_US); Calc: group


Windows 10 Pro
Version 1709
OS Build 16299.192
Comment 1 Dieter Praas 2018-01-29 08:40:46 UTC
I confirm it with

Version: 6.1.0.0.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)
Comment 2 Telesto 2018-01-29 19:10:47 UTC
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:
https://blogs.technet.microsoft.com/hub/2011/04/05/how-to-select-more-highlight-colors-in-word/

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

So, probably not a bug..
Comment 3 Telesto 2018-01-30 08:49:56 UTC
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. 

Pro
* 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?)

Contra
*It will break the experience of MS Word users wanting to edit a file..
Comment 4 Heiko Tietze 2018-01-30 09:22:32 UTC
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.
Comment 5 Yousuf Philips (jay) (retired) 2018-01-31 00:59:28 UTC
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)
> Contra
> *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.

http://technastic.com/wp-content/uploads/2016/02/Microsoft-Word-Compatibility-checker.jpg
Comment 6 Thomas Lendo 2018-02-20 21:18:23 UTC
(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 today.
Comment 7 Buovjaga 2018-03-18 13:29:11 UTC
*** Bug 116458 has been marked as a duplicate of this bug. ***
Comment 8 Heiko Tietze 2018-04-11 08:44:13 UTC Comment hidden (no-value)
Comment 9 QA Administrators 2019-04-12 02:56:14 UTC Comment hidden (obsolete)
Comment 10 mckinnonrc 2019-04-12 04:07:58 UTC
The bug is still active in the latest version of LibreOffice:
Version: 6.2.2.2 (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
Calc: CL

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.
Comment 11 Dieter Praas 2019-04-12 05:16:40 UTC
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?
Comment 12 Heiko Tietze 2019-04-17 11:24:52 UTC
(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.
Comment 13 Roeland 2019-04-19 08:09:07 UTC
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
Comment 14 Dieter Praas 2019-04-19 08:39:15 UTC
Heiko, I think we should close this as duplicate of bug 104822. Do you agree?
Comment 15 Heiko Tietze 2019-04-19 08:45:26 UTC
I brought it up in the ESC call yesterday

   * List incompatible features when saving to alien formats in detail
     + https://bugs.documentfoundation.org/show_bug.cgi?id=115291 
     + 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.
Comment 16 Dieter Praas 2019-04-19 08:58:03 UTC
(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.
Comment 17 Heiko Tietze 2019-04-20 07:41:15 UTC
(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
> warning-message.

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).
Comment 18 mckinnonrc 2019-04-20 10:00:01 UTC
(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
> today.

(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!
Comment 19 Cor Nouws 2019-04-20 21:47:49 UTC
(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):
> https://wiki.documentfoundation.org/User:Kerwyn/informationoncompatibility

Still lots to do :)
You may want to ask on users@ or QA@ lists?