Description: If you are working with a DOCX file, Writer lets you insert comments in footnotes with no warning, but after you save the file, they are lost. Reopening the file, both in Writer and in Word, shows no comment at all. I understand Word doesn't allow comments in footnotes, but I consider it a bug because Writer allows you to insert them and doesn't give any warning about this. It should restrict the user from entering a piece of data that will be lost. Steps to Reproduce: 1. Open (or create and save) a DOCX file. 2. Insert a footnote. 3. Insert a comment in the footnote. 4. Save and reopen. Actual Results: Comment is not saved. Expected Results: User should be unable to insert a comment in a footnote if the file is in DOCX format. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.0.2 (X86_64) / LibreOffice Community Build ID: 41d6f628ba3f046f16b5fa9fa8db8d4c2ab3b582 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-AR (es_AR); UI: en-US Calc: CL threaded
There is a compatibility option for this use case: Go to Options - Advanced - Open Expert Configuration Search for AllowCommentsInFootnotes key -> change it to false, now the option will be disabled in the UI It would be nice to have some UI option to enable all similar MSO-compat options in one step. Currently these are hard to find and scattered all over the Options dialog. - There are some more keys in the same ooO.Compatibility.View category - Also now for Calc - Compatibility: bug 156611 - Also considering that recently a Forms menu related option was removed in bug 157006 - There are some MSO-compatibility settings under Load/Save - MS Office. Perhaps all these could be now consolidated into one UI setting to enable/disable all of them? Otherwise, feel free to mark duplicate of bug 86188.
No objection to have access to this option from Tools > Options > Writer > Compatibility. But would you have checked this, Nadie? (In reply to Gabor Kelemen (allotropia) from comment #1) > - There are some more keys in the same ooO.Compatibility.View category See https://github.com/LibreOffice/core/blob/master/officecfg/registry/schema/org/openoffice/Office/Compatibility.xcs
I would, before getting to work in an important document. I certainly didn't think of going to the "Expert Configuration", so it would be a clear improvement.
So is this bug now only about this specific compatibility option, or the general MSO compatibility, or both?
This topic was on the agenda of the design meeting. We should not clutter the (compatibility) options and add important features only. My take here is AllowCommentsInFootnotes and ClockwisePieChartDirection but not ReverseSeriesOrderAreaAndNetChart and ReverseXAxisOrientationDoughnutChart. This could be easyhackable, code pointer is sw/source/ui/config/optcomp.cxx.
So is this a move towards limiting the UI for each external type, based on which file we open? So when we open a TXT, we should turn into a gedit clone? I do not see why should this be implemented. It would still be a problem, if one creates a new document, which then they would save as, say, DOCX. The important bit here is: (In reply to Nadie Nada Nunca from comment #0) > Writer ... doesn't give any warning about this. Well, technically speaking, it does: it warns by default, that saving to an external file format may loose data/formatting. If a user selects DOCX as their default file type, this warning would not show for DOCX; also, one may "do not show it again" in the warning - but in both cases, user tells that they know what they are doing. However: there is a longstanding issue of not having a *more detailed* warning about problems in export. We *may* provide details on export, if we postpone the warning until the export has collected the data for that; indeed, it would require some substantial work, and each such detailed warning needs to include some expansion notice like "Other incompatibilities may also happen", or the like...
I reviewed this issue today, and I think this can not be considered as an EasyHack. In an EasyHack, it is obvious what should be implemented, and then, code pointers are provided to do that implementation. Considering comment 6 from Mike, it is not obvious how this issue should be handled. I agree with Mike's suggestion to provide "more detailed" warning, but then it will be also out of the scope of an EasyHack. @Heiko: If you do not object, I will remove the easyHack keyword. What do you think?
(In reply to Gabor Kelemen (allotropia) from comment #1) > Options - Advanced - Open Expert Configuration - AllowCommentsInFootnotes (In reply to Heiko Tietze from comment #5) > (add= AllowCommentsInFootnotes and ClockwisePieChartDirection (to) > sw/source/ui/config/optcomp.cxx Straight-forward solution, IMO, and we neither change the default nor add functionality. It's just another option in the existing at list tools > options > writer > compatibility.
(In reply to Heiko Tietze from comment #8) Writer compatibility options are not about limiting / modifying UI; they are about differences in internal logic.
(In reply to Mike Kaganski from comment #9) > they are about differences in internal logic. officecfg/registry/schema/org/openoffice/Office/Compatibility.xcs <prop oor:name="AllowCommentsInFootnotes" oor:type="xs:boolean" oor:nillable="false"> <info> <!-- See tdf#86188 for rationale --> <desc>Specifies whether adding comments to footnotes etc. is allowed. These are allowed for ODF but not in OOXML and can result in invalid docx files being saved.</desc> <label>Allow adding comments to footnotes, headers and frames. Disable for better OOXML interoperability.</label> </info> <value>true</value> </prop> The envisioned patch makes this option available in the UI.
(In reply to Heiko Tietze from comment #10) Sure, but please not in compatibility options.
(In reply to Mike Kaganski from comment #11) > Sure, but please not in compatibility options. Why do you think an option to make Writer behave like MS Word defined under Compatibility.xcs must not be available at t>o>w > compatibility?
(In reply to Heiko Tietze from comment #12) Because, as I mentioned, the page is not for any configuration settings, but for properties of the document, that affect how the document elements are e.g. rendered.
(In reply to Mike Kaganski from comment #13) > properties of the document... document elements rendered. That's a very narrow interpretation. Don't see much harm in adding another option here (nor that it solves the actual problem; however by searching the options it might be found in theory).
(In reply to Heiko Tietze from comment #14) > (In reply to Mike Kaganski from comment #13) > > properties of the document... document elements rendered. > That's a very narrow interpretation. Don't see much harm in adding another > option here (nor that it solves the actual problem; however by searching the > options it might be found in theory). You are seeking to revolutionise the whole thing. Check what the dialog says: 'Compatibility options for "name_of_current_document"'. The title is not, for example, 'Available UI actions for DOCX files'. https://help.libreoffice.org/latest/en-US/text/shared/optionen/01041000.html "Specifies compatibility settings for text documents. These options help in fine-tuning LibreOffice when importing Microsoft Word documents." "Some of the settings defined here are only valid for the current document and must be defined separately for each document."
(In reply to Buovjaga from comment #15) > 'Compatibility options for "name_of_current_document"' Good point. The only reasonable alternative is Load/Save > General maybe as a list of compatibility options next to the default file format. Way too complicated though. And perhaps we better resolve the issue as NOTABUG.