Hi, Recently I introduced enum SvtSaveOptions::ODFSaneDefaultVersion, SvtSaveOptions::GetODFSaneDefaultVersion() and SvXMLExport::getSaneDefaultVersion() to determine the actual ODF version of the current file written, see https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=dd8c23522f9123bdf02c366e2abb7b1439028848;hp=009762b05131760144dbd2af8900ee2b84077564 https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=de6f1651326da9cc44b137779e5d3131cab5133e;hp=dd8c23522f9123bdf02c366e2abb7b1439028848 A running ODFVER_LATEST of SvtSaveOptions::ODFDefaultVersion is fine for configuration purposes, but not for determining how (i.e. in which namespace) to store a feature. For example if ODF 1.3 will add an attribute for a feature we requested, we still need to save it in the loext: namespace for all ODF versions <1.3, but ODFVER_LATEST will always mean "the latest and greatest" so it is not possible to use it to determine which version is actually written. For a possible use of ODFSaneDefaultVersion see http://opengrok.libreoffice.org/xref/core/xmloff/source/style/xmlnumfe.cxx#672 I bet there are some similar cases lurking where ODF 1.3 would define a namespace where we are currently unconditionally (or using a wrong condition) writing the loext namespace. Please, if you know of such places adapt them to write the proper namespace depending on the current ODFSaneDefaultVersion. Thanks Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/ Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Attachment:
pgpTGR3nWftBF.pgp
Description: PGP signature