Bug 137883 - Confusing terminology for DOCX save (Transitional versus Word 2007-365)
Summary: Confusing terminology for DOCX save (Transitional versus Word 2007-365)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.6.0
Keywords: difficultyBeginner, easyHack, filter:docx, skillDesign, topicUI
Depends on:
Blocks: DOCX
  Show dependency treegraph
 
Reported: 2020-10-30 17:18 UTC by Telesto
Modified: 2023-03-03 16:50 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-10-30 17:18:29 UTC
Description:
https://ask.libreoffice.org/en/question/273402/save-as-office-open-xml-text/

The LO Save As dialog shows for saving an Microsoft OOXML document either "Office Open XML Text (Transitional) (.docx)" or the more commonly used "Word 2007-365 (.docx)". Assuming the "Word 2007-365 (.docx)" is a Transitional "formatted" document "compatible" with what MS Office produces I would think the "Office Open XML Text (Transitional) (.docx)" should actually be the Strick format and for that say "Office Open XML Text (Strict) (.docx)". That would be in line with the MS Office Save As options where the Strict format is also refereed to as "Office Open XML-document (Strict) (.docx)"" vs Transitional "Word Document (*.docx)". So is that in LO a typo that needs to be fixed?

Steps to Reproduce:
Read above

Actual Results:
No clue

Expected Results:
Maybe a rename if needed


Reproducible: Always


User Profile Reset: No



Additional Info:
7.1
Comment 1 Telesto 2020-10-30 17:20:32 UTC
No expert on this matter.. only read a comment on a forum pointing to the ask report in question.. so only creating an report here.

There is at least some terminology issue here somewhere
Comment 2 V Stuart Foote 2020-10-30 17:39:59 UTC
Miklos and Samuel worked on this for bug 131936, but IIRC the OOXML Transitional was precursor based on the earlier published standard, but is not maintained against O365/Office 2019 "strict OOXML".  IIUC they remain different filter/formatting specifications.
Comment 3 Heiko Tietze 2020-11-10 12:56:57 UTC
Don't see need for UX input. Average MSO user has no idea about transitional, strict, ooxml, standards...
Comment 4 Dieter 2022-02-07 15:53:23 UTC
Hello Telesto, a new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Comment 5 QA Administrators 2022-08-07 03:31:23 UTC Comment hidden (noise)
Comment 6 Telesto 2022-08-07 07:55:37 UTC
Nothing changed here
Version: 7.5.0.0.alpha0+ / LibreOffice Community
Build ID: c1c8ce3b0f1037bca4d500af2f39363cd9d38db6
CPU threads: 8; OS: Mac OS X 12.3.1; UI render: Skia/Metal; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded
Comment 7 QA Administrators 2022-08-08 03:48:39 UTC Comment hidden (noise)
Comment 8 Michael Stahl (allotropia) 2023-02-01 11:02:43 UTC
this is very confusing.

There are currently 5 editions of ECMA-376, latest is from 2021.
* 1st edition allegedly corresponds to Word 2007
* 2nd edition allegedly corresponds to ISO 29500:2008
* it's unclear what changed in later editions; there is:
  Annex M.  Differences Between ECMA-376:2016 and ECMA-376:2006
  but that's relative to 1st edition.

then there is ISO29500:2008, which apparently is the only version of that,
but it specifies a "transitional" and a "strict" flavor.

our filter called "Word 2007-365" actually means "ECMA-376 1st edition":
it exports files that Word 2007 can read, as well as later versions (apparently?).

the filter called "Office Open XML Text (Transitional)" actually means "ISO 29500:2008 transitional":
it exports files that Word 2010 and later can read, but not Word 2007.

(we don't have a "strict" filter because it doesn't really matter, and we export a bunch of extensions that for compat with newer Word versions unconditionally with both filters; these extensions are definitely not in ISO but i haven't checked if ECMA-376 added anything past 2nd edition.)

until i looked this stuff up now, i always thought that the "Word 2007-365" filter selects the "newer"/"more features" variant, but it turns out that it is the other way around! (see bug 148952)

perhaps it would be better to name one filter "Word 2007" and the other one "Word 2010-365"
Comment 9 Heiko Tietze 2023-02-01 12:04:18 UTC
(In reply to Michael Stahl (allotropia) from comment #8)
> perhaps it would be better to name one filter "Word 2007" and the other one
> "Word 2010-365"

Sounds reasonable. And easyhackable... (search for the label in *.xcu).
Comment 10 Michael Stahl (allotropia) 2023-02-02 08:57:00 UTC
in other news: i've renamed the related confusing constant:

https://git.libreoffice.org/core/commit/2c0c95af13662f37e7f217e0bd0fc87ebde36f1b

tdf#107841 oox: rename ambiguous and confusing ECMA_DIALECT

there were more comments on the other bug which i think are more relevant here:

> Miklos Vajna 2023-02-01 09:10:40 CET

> My expectation would be that these days we could flip the default to the non-ECMA one, since Word 2007 was EOL in 2017.

> Gabor Kelemen (allotropia) 2023-02-01 22:32:55 CET

That is happening since 7.0 for new documents, see:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=f25985c55541cbbc9a4fc79e660592d3d0485196

so in my view we should NOT do workarounds to please Word 2007. Those situations are bugs.

> Michael Stahl (allotropia) 2023-02-02 09:51:00 CET

ah yes that's another aspect: it doesn't make sense to export ECMA-376 1st edition for Word 2007 and then set compatibilityMode=15 - if we use the old format for Word 2007 then use compatibilityMode=12 and if we use the "current" format then use compatibilityMode=15.
Comment 11 Commit Notification 2023-02-20 12:07:47 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/e66ddcd4b66923bc835bd7c5f5c784a809a420a2

tdf#137883 sw: DOCX export: compatibilityMode=12 for ECMA 376 1st ed.

It will be available in 7.6.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.
Comment 12 Commit Notification 2023-02-20 12:08:49 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ed0476b0625c4361df5ff040a6661a9634588cea

tdf#137883 filter: rename DOCX filters to be less confusing

It will be available in 7.6.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.
Comment 13 Commit Notification 2023-02-20 12:08:52 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a44380768059e4efe7b29f5b57b54a20540faa0c

tdf#137883 officecfg: ModuleDependendFilterOrder move Word 2010 ...

It will be available in 7.6.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.
Comment 14 Michael Stahl (allotropia) 2023-02-20 12:30:14 UTC
okay due to the confusion with the other bug i've fixed this now as far as Writer is concerned.

but the same issue exists with Calc/Impress XLSX/PPTX filters, so the easy-hackers might want to work on these.
Comment 15 Commit Notification 2023-02-20 19:54:44 UTC
Olivier Hallot committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/help/commit/336d8e277daa429fe5c271d7e5169e179dd4aaf9

tdf#137883 Rename docx filter to be less confusing - Help part
Comment 16 Tex2002ans 2023-03-03 07:37:35 UTC
Michael + Olivier, just a small typo in the latest patches.

Accidentally used a HYPHEN instead of an EN DASH:

- Word 2010-365 Document
- Word 2010–365 Document

1st one is current.

2nd one is correct + will match the other Word filetypes in the dropdown ("Word 97–2003").
Comment 17 Commit Notification 2023-03-03 16:50:25 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/7391942099d4a76639c1aa8e559643b2702da2b7

tdf#137883 filter: use en-dash instead of hyphen in UINames

It will be available in 7.6.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.