tdf#133459 Fix import of fields with user defined number formats

commit 59ace23c367f83491a37e844d16f7d716eff6346 ("tdf#101710 Fix
invalid style:data-style-name attribute") had a side effect of
exporting user defined number formats under <office:styles> instead
of under <office:automatic-styles> (which is valid, and what Calc
does since forever). As it turned out, this didn't work well for
fields:

- For fields inside headers or footers, their number format wasn't
imported at all. The reason here is that fields use the
XMLTextImportHelper::GetDataStyleKey method to resolve data styles,
and that method checks only automatic styles. Actually it resolves
also styles from <office:styles>, because SvXMLImport::SetAutoStyles
has a special code that merges styles from <office:styles> into
automatic styles during content.xml reading. The problem is that
headers and footers have their contents stored inside styles.xml,
and no merging happens at this stage (unless it's a flat odf file).
One way to solve this could be to explicitly check for styles from
<office:styles> in XMLTextImportHelper::GetDataStyleKey (e.g. see
previous gerrit patchsets, or XMLTableStyleContext::GetNumberFormat)
I chose to simply modify the condition in SvXMLImport::SetAutoStyles,
so that merging happens anyway.

- Fields whose format resolution depends on the merging of
SvXMLImport::SetAutoStyles, did import the number format itself,
but not its language setting. This can be in one of three ways:
(a) Fields in the document and the header, when both use the same
format. In this case the format is stored once in styles.xml, so
at least the consumer from content.xml depends on merging.
(b) Field in the document with a user defined format - a regression
of the above commit. Now stored in styles.xml under <office:styles>
instead of in content.xml under <office:automatic-styles>.
(c) Field in a header with a user defined format - depends
on merging as a result of the above fix.

The reason here is that the merging isn't done with the original
SvXMLNumFormatContext objects, but with a newly created fake ones,
which only have the format id correct (with the assumption that
those formats already imported, and calling code could just find
them by the id). The problem is that the fields code uses
XMLTextImportHelper::GetDataStyleKey to get the language setting
from style objects, and set the IsFixedLanguage property according
to it, while we know that those fake objects don't have the
language correctly set. Try to fix that problem by setting the
correct language on those fake objects.

Change-Id: Ibb362df019921e040708d3bda83bf155535ec7af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95612
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>

1 files changed, 2 insertions, 0 deletions

diff --git a/include/xmloff/xmlnumfi.hxx b/include/xmloff/xmlnumfi.hxx
index 21eac93a3cd9..b337fad36832 100644
--- a/include/xmloff/xmlnumfi.hxx
+++ b/include/xmloff/xmlnumfi.hxx
@@ -91,6 +91,7 @@ public:
     SvXMLNumImpData* getData() { return pData.get(); }
 
     const SvXMLTokenMap&    GetStylesElemTokenMap();
+    LanguageType            GetLanguageForKey(sal_Int32 nKey);
 
 //  sal_uInt32  GetKeyForName( const OUString& rName );
 };
@@ -164,6 +165,7 @@ public:
                                     const OUString& rLName,
                                     const css::uno::Reference< css::xml::sax::XAttributeList>& xAttrList,
                                     const sal_Int32 nKey,
+                                    LanguageType nLang,
                                     SvXMLStylesContext& rStyles );
     virtual     ~SvXMLNumFormatContext() override;