From c3f096c7630994450625307091a0e6009fb02bc4 Mon Sep 17 00:00:00 2001 From: Eike Rathke Date: Mon, 17 Oct 2016 21:01:13 +0200 Subject: Resolves: tdf#102357 export correct locale attribution, not just country So all XMLPropertyHandler derived XMLCharLanguageHdl, XMLCharScriptHdl, XMLCharCountryHdl and XMLCharRfcLanguageTagHdl are actually called. Broken since commit 21661ebfbec9ea162582bbc7ab46607eb9095f1a Date: Wed Aug 21 19:16:23 2013 -0400 fdo#60740: Populate auto styles from edit cells without using UNO API. Change-Id: If0523752a4dea4e18d3d86ca5a2735fbcf39c3e3 --- sc/source/filter/xml/xmlexprt.cxx | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/sc/source/filter/xml/xmlexprt.cxx b/sc/source/filter/xml/xmlexprt.cxx index c9aeb29fa3dc..bfd1efdee41a 100644 --- a/sc/source/filter/xml/xmlexprt.cxx +++ b/sc/source/filter/xml/xmlexprt.cxx @@ -1218,7 +1218,34 @@ const SvxFieldData* toXMLPropertyStates( if (!static_cast(p)->QueryValue(aAny, pEntry->mnFlag)) continue; - rPropStates.push_back(XMLPropertyState(nIndex, aAny)); + // Export multiple entries. + sal_Int32 nIndexLanguage, nIndexCountry, nIndexScript, nIndexTag; + switch (p->Which()) + { + case EE_CHAR_LANGUAGE: + nIndexLanguage = xMapper->GetEntryIndex( XML_NAMESPACE_FO, "language", 0); + nIndexCountry = xMapper->GetEntryIndex( XML_NAMESPACE_FO, "country", 0); + nIndexScript = xMapper->GetEntryIndex( XML_NAMESPACE_FO, "script", 0); + nIndexTag = xMapper->GetEntryIndex( XML_NAMESPACE_STYLE, "rfc-language-tag", 0); + break; + case EE_CHAR_LANGUAGE_CJK: + nIndexLanguage = xMapper->GetEntryIndex( XML_NAMESPACE_STYLE, "language-asian", 0); + nIndexCountry = xMapper->GetEntryIndex( XML_NAMESPACE_STYLE, "country-asian", 0); + nIndexScript = xMapper->GetEntryIndex( XML_NAMESPACE_STYLE, "script-asian", 0); + nIndexTag = xMapper->GetEntryIndex( XML_NAMESPACE_STYLE, "rfc-language-tag-asian", 0); + break; + case EE_CHAR_LANGUAGE_CTL: + nIndexLanguage = xMapper->GetEntryIndex( XML_NAMESPACE_STYLE, "language-complex", 0); + nIndexCountry = xMapper->GetEntryIndex( XML_NAMESPACE_STYLE, "country-complex", 0); + nIndexScript = xMapper->GetEntryIndex( XML_NAMESPACE_STYLE, "script-complex", 0); + nIndexTag = xMapper->GetEntryIndex( XML_NAMESPACE_STYLE, "rfc-language-tag-complex", 0); + break; + } + assert( nIndexLanguage >= 0 && nIndexCountry >= 0 && nIndexScript >= 0 && nIndexTag >= 0); + rPropStates.push_back( XMLPropertyState( nIndexLanguage, aAny)); + rPropStates.push_back( XMLPropertyState( nIndexCountry, aAny)); + rPropStates.push_back( XMLPropertyState( nIndexScript, aAny)); + rPropStates.push_back( XMLPropertyState( nIndexTag, aAny)); } break; default: -- cgit ption value='distro/collabora/co-24.04.8'>distro/collabora/co-24.04.8 LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/RepositoryFixes.mk
AgeCommit message (Collapse)Author
2018-11-29Rename Mac OS X to official name macOS in comments and documentationBartosz Kosiorek
Change-Id: I651b7f202fa52ff5f5357a11aa72c43eb7dc7f95 Reviewed-on: https://gerrit.libreoffice.org/64102 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2018-11-21tdf#112536 related: make soffice.bin a proper console application on WinMike Kaganski
Being a GUI application on Windows (with related flag in the executable header - see https://blogs.msdn.microsoft.com/oldnewthing/20090101-00/?p=19643/), OS would detect the subsystem before launching the application, and won't attach the parent console or redirected output handles from it to the application. Also, different hacks to reattach the GUI application to the console later are unreliable on different Windows versions, and work improperly (the output goes to the console after the launch command has already returned, which is wrong in batch files). This makes it extremily difficult to do CLI operations with LibreOffice on Windows, with error codes/warnings/messages/output missing or going to wrong consoles. Making an executable for CUI subsystem, on the other hand, makes Windows to allocate a console before starting it when the program is run by itself. This makes the console window to appear on screen unconditionally, even if it's hidden later when the program has started. This flashing is undesirable. But we use a wrapper executable on Windows, called soffice.exe, which is what actually launched by user, and which runs soffice.bin. This allows us to make soffice.bin the proper console application, and thus make it capable to behave properly in CLI scenarios, while avoid the console flashing when run from the soffice.exe (which would suppress the console creation using DETACHED_PROCESS creation flag to CreateProcessW). Also creating a new wrapper for console (soffice.com) allows to use command lines which omit explicit executable extension (no ".bin"), like this: "C:\Program Files\LibreOffice\program\soffice" --help which allows to continue using multiple available help resources unchanged, since .com extension is tried prior to .exe by Windows' cmd.exe. Change-Id: I089d0f30f860da6cfc781b4383f6598a08a4d238 Reviewed-on: https://gerrit.libreoffice.org/63572 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-04-12Revert "Remove dead HSQLDB driver"Sophia Schröder
We cannot silently convert user data or their used file formats and then await them to accept it or reinstall an older version. Let us make a soft change instead of an hard (heart) break and avoid us to been attacked with fire and forks from our users. This reverts commit 8d381ae8d6c742a7e15bf7ad9e07b65f81728ef6. Change-Id: Ia153640935e355771acb85cf652f8fe4c21fafbb Reviewed-on: https://gerrit.libreoffice.org/52731 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tamás Bunth <btomi96@gmail.com>
2018-04-10Remove dead HSQLDB driverTamas Bunth
Change-Id: Id4cfb69079f0150c9cca2626c16df7fab441d916 Reviewed-on: https://gerrit.libreoffice.org/52611 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tamás Bunth <btomi96@gmail.com>
2017-02-10Remove MinGW supportStephan Bergmann
In OOo times, there'd originally been efforts to allow building on Windows with MinGW. Later, in LO times, this has been shifted to an attempt of cross- compiling for Windows on Linux. That attempt can be considered abandoned, and the relevant code rotting. Due to this heritage, there are now three kinds of MinGW-specific code in LO: * Code from the original OOo native Windows effort that is no longer relevant for the LO cross-compilation effort, but has never been removed properly. * Code from the original OOo native Windows effort that is re-purposed for the LO cross-compilation effort. * Code that has been added specifially for the LO cross-compilation effort. All three kinds of code are removed. (An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing --with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.) Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568 Reviewed-on: https://gerrit.libreoffice.org/34127 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2015-11-27gengal script calling gengal.bin is not needed on MacStephan Bergmann
Change-Id: If965ab126be497a7b2af227a843aeb746901def2