this patch only tweaks a few things around the edges. The bulk of the
cost is down in the chart2 module where it creates ticks and labels.
Change-Id: If73a16d2f0a7511f07eff379a9b5c1b38ef96786
Reviewed-on: https://gerrit.libreoffice.org/51931
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Because Excel does not know a Boolean number format, BOOLEAN is
saved to Excel as
"TRUE";"TRUE";"FALSE"
with implicit conditions [>0] and [<0]. This when loaded has no
boolean property. Then saved to ODF it is loaded as
[>0]"TRUE";[<0]"TRUE";"FALSE"
with explicit conditions, which has identical meaning.
Convert both equivalent format codes to proper BOOLEAN when
reading. Locale dependent representations are treated the same,
e.g. "WAHR";"WAHR";"FALSCH"
Change-Id: I49383d71fce972fdd7ad9b19ce3bc150d02aba62
Reviewed-on: https://gerrit.libreoffice.org/50642
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
using
git grep -lwP "Color\s*\(\s*(COL_\w+)\s*\)"
| xargs perl -pi -e "s/Color\s*\(\s*(COL_\w+)\s*\)//g"
and then some manual fixup where the resulting expression no longer
compiled
Change-Id: I0e268d78611c3be40bba9f60ecfdc087a36c0df4
Reviewed-on: https://gerrit.libreoffice.org/50372
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
ODF 1.2 has added some mandatory requirements for protection-key hashes
which did not exist in ODF 1.1.
This affects sections and indexes in ODT documents, as well as
spreadsheets and sheets in ODS documents.
1. Accept the following hashed passwords:
* UTF16 LE/BE encoded StarOffice-SHA1, OOo legacy and allowed by ODF 1.1
* UTF8 encoded proper SHA1, as required by ODF 1.2
* UTF8 encoded SHA256, as required by ODF 1.2
- specified either with the wrong URL used in the ODF 1.2 spec
or the correct URL from the W3C spec, see OFFICE-3702
* Excel+SHA1 double-hash, only in Calc, see OFFICE-2112
2. Round-trip any of the above as-is
* for SHA256 only write the URL from the ODF 1.2 spec
3. Generate only UTF16 LE encoded SHA1 for now, so that older LO
releases can still verify the password
* some time in the future, switch to generating some valid ODF 1.2 hash
More changes are necessary in Calc, which can actually preserve
different hashes for the same passwords in its runtime data model,
whereas Writer just has a single buffer without even any metadata.
For the Calc unit tests we need one document per hash because the
protection-key attribute can be set on the entire spreadsheet, which
is an unique element in the document.
There are further uses of SvlPasswordHelper for change-tracking passwords,
but apparently those are stored in settings.xml, so ODF has no
requirements for them, so let's leave that as it is.
Change-Id: Icb720b14ae9c0d9c04d2e082769ae2b74e3af8aa
Reviewed-on: https://gerrit.libreoffice.org/49352
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Automatic rewrite (of loplugin:cstylecast and loplugin:unnecessaryparen) after
cab0427cad "Enable loplugin:cstylecast for some
more cases" and a409d32e7f "More
loplugin:cstylecast"
Change-Id: Ib3355159dd08333e1b7a8d091caf2069cdcc7862
Reviewed-on: https://gerrit.libreoffice.org/48317
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: I71e3b2c9b4c68183288f43999d242e95ae13584d
The only place is is used is ConvertAndPutItems.
Which only loops over EE_PARA* which ids.
But the only things which define slotid<->whichid mappings are XATTR*,
SDATTR*, SCHATTR*.
Which means that this code ConvertAndPutItems is dead, and that is the
last place using GetTrueSlotId.
Change-Id: I3037c25c2c15087572abacc9642970936824678d
Reviewed-on: https://gerrit.libreoffice.org/47377
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This way, it is possible to have all the strings translated in dialogs even
when different users use different languages. [It was already possible
to have different languages previously, but not everything in the dialog has
switched - like the buttons at the bottom of the dialogs etc.]
Change-Id: I29a5ae6d31a370eec60397884200b684ec1bf5b9
Reviewed-on: https://gerrit.libreoffice.org/46417
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/46979
Tested-by: Jenkins <ci@libreoffice.org>
if ui is set to track the locale automatically and the current locale
has no match in installed resources but has a match in the list of
languages that libreoffice was compiled to contain
so e.g. de_AT locale shouldn't trigger the installation of anything if
langpack-de is already installed and yue_HK shouldn't trigger install
of anything cause that not supported (at time of writing) for libreoffice
put Fedora/RHEL/Ubuntu naming schemes in here.
I moved the lang code from svl to svtools so I could use the restart dialog
to prompt to restart after the langpack is installed, but packagekit's blocking
mode seems to be no longer blocking and control returns immediately which is a
change since the last time I played with this stuff, so drop the restart thing
for now. The lack of a blocking modal also makes the "run this on idle when there's
a toplevel window up and running" a bit futile, but lets keep that for now anyway.
caolanm->rene: I know you'd disable this anyway, so Debian is left out, there's
also config key Office/Common/PackageKit/EnableLangpackInstallation to disable
this too.
Change-Id: Ice731be539850338ccdd8af87839e0b4d83f01e7
Reviewed-on: https://gerrit.libreoffice.org/46856
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
merge the droplong and convertuintptr into one new plugin.
Limit the analysis to looking at var decl's, since that seems to be
safest proposition, even if that too needs some careful analysis.
Change-Id: Id005baaf05cfb157ce44a06a1c81f08559a07d1f
Reviewed-on: https://gerrit.libreoffice.org/46851
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This way we can't forget an sKeyword element and need to care only
about the exceptions. Adds a slight penalty for German in that it
has 25 keywords initialized twice, but..
Change-Id: I99ba228ef8b1517a32ce98a9c79cfbe2b1d0b340
Reviewed-on: https://gerrit.libreoffice.org/46575
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
... as especially the keywords are controlled by the current state (locale) of
the ImpSvNumberformatScan instance and *not* a property of SvNumberformat. Add
a clarifying descriptive comment as well, and outline it's only for the unit
tests anyway..
Change-Id: I732918026bf9ffc25db11033d5f10bc2f51e3505
Reviewed-on: https://gerrit.libreoffice.org/46426
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
instead of one mutex for all instances. We still keep the global mutex
for some operations because there are some shared global data
structures.
Change-Id: Ic1106baa23d4ade18dbd732ad74979f3996f326b
Reviewed-on: https://gerrit.libreoffice.org/46304
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
... in GetPreviewStringGuess() that is used in Calc TEXT()
spreadsheet function, if the format code didn't resolve as English
or the format code needs to be (re)parsed otherwise as locale
dependent.
Also SvNumberFormatterServiceObj::convertNumberToPreviewString()
(XNumberFormatPreviewer::convertNumberToPreviewString()) if
bAllowEnglish==true.
Change-Id: I7c4b1a610d2bcb20fe0f0ae06efc81f998cae048
Noel Grandin