Summary: | Writer allows to insert comments in footnotes in DOCX, but loses them | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Nadie Nada Nunca <nadie.nada.nunca> |
Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | ||
Severity: | minor | CC: | aron.budea, buzea.bogdan, heiko.tietze, kelemeng, sdc.blanco |
Priority: | low | ||
Version: | 7.6.0.2 rc | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=86188 https://bugs.documentfoundation.org/show_bug.cgi?id=160672 |
||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 103164, 106179, 112916 |
Description
Nadie Nada Nunca
2023-09-24 01:14:50 UTC
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. |