Bug 149658 - Support OOXML Strict Format in "Save as" GUI and "convert-to" CLI
Summary: Support OOXML Strict Format in "Save as" GUI and "convert-to" CLI
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: lowest enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:ooxml
Depends on: OOXML-Import-Strict
Blocks: MSO-Formats
  Show dependency treegraph
 
Reported: 2022-06-21 12:52 UTC by assk
Modified: 2022-09-06 12:27 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description assk 2022-06-21 12:52:00 UTC
Description:
Hi

The OOXML standard is divided in two different conformance classes: "Transitional" and "Strict".

Currently you only support Transitional conformance class in the "Save as" GUI and the "convert-to" CLI.

Available filters in LibreOffice: https://cgit.freedesktop.org/libreoffice/core/tree/filter/source/config/fragments/filters

To properly support OOXML you should differentiate between Transitional and Strict file formats despite their file extensions are the same aspects such as namespaces, conformance class and specific features are not the same.

Actual Results:
LibreOffice does not support OOXML Strict standard.

Expected Results:
Support of OOXML Strict standard.


Reproducible: Always


User Profile Reset: No



Additional Info:
None.
Comment 1 Timur 2022-09-06 11:01:10 UTC
Hi Regina and Mike, please comment on this one.
Comment 2 Mike Kaganski 2022-09-06 11:17:04 UTC
I would consider this very low-priority.
OOXML support in LibreOffice is *external file format* support, and its existence is not to support every bit of the standard, but to enable interoperability.

Supporting the subset that is used by that format's reference implementation (MS Office) *as the default*, and that does not introduce any interoperability problems by itself, is quite adequate for the goal of that format support.

If someone has enough motivation to do the heavy lifting of implementing the strict subset, then why not.
Comment 3 Regina Henschel 2022-09-06 11:29:23 UTC
I think, as long as LibreOffice has severe problems in reading OOXML strict, it should not try to write in OOXML strict, see bug 83571. Otherwise it gives a bad experience for the user, when the file is different after save and reload.

So I would except this as enhancement request, but with low priority.