Age | Commit message (Collapse) | Author |
|
Change-Id: I3c94d68cb85adc2005a5a5e3b03a311732f782c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141617
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
it seems it's no longer needed
Change-Id: I346a12a150659ddde218a895d140c9087989d516
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141613
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
...where ScTypeStrData::LessCase(In)sensitive is implemented in terms of
ScGlobal::Get(Case)Collator().compareString. And that apparently implements
only a strict weak ordering (in the C++ Standard's meaning of the term) rather
than a strict total ordering (i.e., sorts different strings into equivalence
classes, e.g., ScGlobal::GetCollator().compareString("guet", "guͤt") returns 0).
With a randomizing debug-mode libc++, tests recently added to UITest_autofilter
failed for me with
> FAIL: test_tdf123095 (autofilterBugs.autofilter)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "sc/qa/uitest/autofilter/autofilterBugs.py", line 45, in test_tdf123095
> self.assertEqual(get_state_as_dict(xTreeList.getChild("0"))["Text"], "乙二醇(进口料件)")
> AssertionError: '乙二醇(进口料件)' != '乙二醇(进口料件)'
> - 乙二醇(进口料件)
> ? ^ ^
> + 乙二醇(进口料件)
> ? ^ ^
when _LIBCPP_DEBUG_RANDOMIZE_UNSPECIFIED_STABILITY_SEED is e.g. 140434132192856
and
> FAIL: test_tdf125363 (autofilterBugs.autofilter)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "sc/qa/uitest/autofilter/autofilterBugs.py", line 69, in test_tdf125363
> self.assertEqual(get_state_as_dict(xTreeList.getChild("0"))["Text"], "guet")
> AssertionError: 'guͤt' != 'guet'
> - guͤt
> ? ^
> + guet
> ? ^
when _LIBCPP_DEBUG_RANDOMIZE_UNSPECIFIED_STABILITY_SEED is e.g. 139927542230616.
(Those tests only required the !bCaseSens case to be stable_sort'ed, but it
looks plausible that the bCaseSens case would suffer from the same issue, so
lets stable_sort that one too.)
Change-Id: I860ae7b58f09c85da82fca99a2962f12d70d2202
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141548
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
the chart2 module likes cloning ScChart2DataSequence, which can take a
long time if we have lots of data, so share the data via shared_ptr
Change-Id: I4b0948610810c41a8569b97c58b2b52e8e3190f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141501
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This takes the time to apply the formating from "who knows how long" to about 500ms on my machine.
Change-Id: I202d023c58ea191bf080ef3a85068e8acab52dec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141463
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It's never included.
It passed "make check" on Linux.
Change-Id: I1a58f36b081d85ad18c2794120f3a343b30f0ac8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141476
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It's never included.
It passed "make check" on Linux.
Change-Id: Iadcc59130374ae318fff5dd1674d59c2906cedd6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141477
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This patch does the following changes to the Functions sidebar in Calc:
1) The function description now uses a TextView instead of a Label so that the text can now wrap. This is important because many descriptions are long and require more than a single line of text.
2) The minimum size of the description TextView is set to 6 lines of text. Because there's no easy way to set this minimum size (since it is inside a Slider control), then the following rule was applied.
- If the user resizes the slider to less than 6 rows (in this case, moves it down), the next time a new function is clicked the slider is positioned so that 6 lines of text become visible.
- Moving the slider up, thus giving more space to the description view is still allowed as prior to this patch.
Change-Id: I52dfa8bef52b645fdce379408e6b790f6e8e5dea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140507
Tested-by: Jenkins
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
if we have already optimal heights in the xml, because it is
not necessary and it takes a lot of time loading a file.
Citing here for completeness:
a) if there is no height attribute and the "use_optimal-row-height"
attribute is set then calculate the row height
b) if there is a height attribute just use it and do not recalculate.
Maybe TODO for later: optimize row height calculation more in sc
Change-Id: I9d964aad744970e5d36f239c0ce39ce98c00f273
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141204
Tested-by: Jenkins
Tested-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
Initialize code was not called when xlsx file was loaded
(line count is only stored in ods format).
Change-Id: I5b01f6079921af77ffd6da09ae5d5388b8beff1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141281
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
Change-Id: Ib6f1edebe26a69d3316a901e00d2bc6e0c66695f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141047
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I9874778ba79540cfde32bf59c3a63ebb72889dc7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141215
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This check was introduced in commit 4cd9e45a439b654c8e1ff7983fe7e4bd073b9c92
Author Yan Pashkovsky <yanp.bugz@gmail.com>
Date Fri Aug 12 23:39:30 2016 +0300
tdf#91305 fix sort calc
Then commit 63592999a067d76c896ed79204330e1a4b934c80
Author Eike Rathke <erack@redhat.com>
Date Thu Aug 18 17:16:50 2016 +0200
refine HasColHeader()/HasRowHeader() conditions, tdf#91305 related
made the "not only one column/row" case check the same.
Change-Id: I25ce867e1c64d7b89a617021de9a5e4f1c89d2a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141219
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I5cf4e16692d55f30cc06723a323b4cd0408aaab7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141216
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
And use an overloaded helper function with a better (?) unified name
to show that the result is not an O(U)String.
Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
... just to convert back to OUString in the end.
Change-Id: I727d5e4c03d1a49f64bd5ca3d64157a9149cd9ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141125
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The presence of an Auto_Close module prevents any
auto_close subroutines from running.
Interestingly, Word is different. It doesn't care at all
if such a module is present. (In fact, it uses that
module's main() as an AutoClose if there is no
Sub AutoClose.)
Change-Id: I83a80b7f016dcf2ad3b7fd931acacb6f788241a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141036
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
Option is out-dated and access via UI confusing
* UI access removed from Tools > Options > General (Impress, Calc)
resp. > Compatibility (Writer)
* Unit tests updated
* Tip-Of-The-Day cleaned-up
* remove UsePrtMetrics value
Change-Id: Ib645f6e1f648455e0536a437be14c2c6a7b25a49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139863
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Change-Id: Ic7126ac57f8cc06b37f3098603f0710602f0ab28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140998
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Changing row height showed the rows hidden
by AutoFilter, removing the result of the filtering.
Change-Id: Iecc8eb03ed563de126e7a376dad41a4ab2434f0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139883
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
i.e. ignore system theme so we get the same results on export to pdf
regardless of the theme (esp dark) and don't follow the system theme
when hosted with a writer/calc/impress document (do continue to use
system theme for StarBasic dialogs as seen in BasicIDE)
Didn't reuse 'NativeWidgetLook' for this because is currently defaults
off, while we currently do use the colors derived from the system theme
even when this is off, its really the NWF flag to render using the
platform theming engine
Change-Id: I816d7ebaf793e5eac7bd937d44c1db0371145199
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140942
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
It makes it consistent with SW, which is why I went ahead
with this without asking any questions.
Change-Id: Ibb8f4149bfb3bd785c35772d0ff399f60c0d1c72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140933
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
Freezing was done in LO 4.0.4 with 2013-05-09 10:55:44 UTC
Sameer Deshmukh commit 07a14c901025722bcc0a06c76e83c40985ca01a6
fdo#61060 - Freezing now marks spreadsheet as unsaved.
Now Unfreezing does the same thing.
TODO: should the same thing be done for splitting?
It will be available in LibreOffice 4.0.4.
Change-Id: I3d1d3563c5c62ccfe2dece64a26862db0380ec34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140932
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
The chain of fixes for #i119960# tdf#48621 tdf#125440 produced
code that is suboptimal and not robust enough against some further
corner cases, taking quoted field content where there shouldn't
be.
First, in ReadCsvLine() assume that if a generator is broken
enough to start a field quoted followed by containing an unescaped
embedded quote and there is no closing quote (i.e. immediately
before a field delimiter) until the line end then the generator
will not be clever enough to write embedded linefeeds either and
the field starting quote wasn't one but to be taken literally as
all other quotes until the now unquoted field end. In this case do
not read a subsequent source line for the current row.
Then, for individual fields of a row make a similar assumption, a
quote-started field has to end with a quote before a field
separator (or line end) or otherwise all quotes of that field are
literal data up to the next field separator.
This made it necessary to adapt two test cases of the garbage CSV
import test to produce different garbage than before.
Change-Id: I4424b65c87c7f9dcbe717a7e6cf207352cb613f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140850
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I6bec0af1c7fe109b81b5392c06f795eed03df061
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140716
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
In the content of Equals/notEquals, Eike said,
"This should not use collation (which should only be used
in sorting context) but ignore case transliteration instead."
"I'm undecided about replacing this (and the Between|NotBetween)
collator with transliteration. Locale sensitive collators have a
different comparison than transliteration
and order characters differently."
I also added a few code clean-ups.
Change-Id: I94f73d99b36f8995c4e80fd2f317f1b5bca4f165
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140676
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
This is intended to handle possibly unallocated columns similarly
to CreateColumnIfNotExists(), but unlike that one this one does not
allocate, if the column is not allocated then the default column
data is returned. This is intended for reading of columns.
Change-Id: Ic3b637eb3d16bac69ebc7ecd389973407db4f7fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140737
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
which makes it easier to know what each variant requires
to stay on it's happy path
Change-Id: I3275a2543573367714bc78092e882f6535507285
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140469
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
lcl_IncrementNumberInNamedRange() during copying a sheet didn't do
what it was supposed to do, it could generate names that would had
been cell references, and the loop it was called from could had
prematurely ended because it inserted into the set it was
iterating over; also the loop ended as soon as it encountered just
one dbrange that wasn't on the sheet that was copied. That never
worked as intended with more than just a very few names only on
the same sheet.
Additionally after the actual change loplugin:stringviewparam
forced me to pass a std::u16string_view parameter, for that some
adaptions had to be made.
Change-Id: Ib83d317c69d821e8e8a2f1cd6791da9616ed188d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140717
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
from
commit 690e4852809ea21b5fd909298c5fa2a053fa0458
Date: Mon Jan 31 09:02:33 2022 +0100
Fix copying range when it doesn't contain a number
OUString::lastIndexOf() eithers returns an index or -1, so adding 1 to
it, means that nLastIndex is __always__ >= 0.
Change-Id: I197f8c856a52534690d7a0d28e49cecf296dccb3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140704
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9fb70d1612dda3c20a683a050f550d1830dd1fc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140693
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
can save some cycles by treating it as a std::u16string_view
Change-Id: I704118b26cbfbebcc8a7f19ce11079ef5a544a84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140692
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Thanks Eike
Eike said "This should not use collation (which should only be used
in sorting context) but ignore case transliteration instead."
I had just copied ancient code from
commit 952c2b02c73b30b011306faf2f0d6f2b4a935955
Author: Eike Rathke on Date: Wed Mar 14 14:57:39 2001 +0000
use CollatorWrapper instead of International
Apparently that code should also be changed
in a follow-up commit.
Interestingly, a \x000 - \x008 etc must be isEqual(""),
so an attempt to ScGlobal::getCharClass().lowercase
all variables at the beginning and use regular OUString
comparisons didn't work.
Also, a "" startsWith and endsWith each string.
In Excel, a "" is also contained in every string,
but not (yet) in Calc.
Change-Id: I44a07c482d2d67a76a939ba2d593a003398d52c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140633
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
regression from
commit b52fd544b9c128d3e28de6355286f6480b618e93
Date: Tue Sep 20 15:48:38 2022 +0200
avoid some string refcounting with sheets with lots of conditional
formatting
Change-Id: If1414221aef0b227200cfb6ffb8e87abb48a90c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140589
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Respond to https://bugs.documentfoundation.org/show_bug.cgi?id=117764#c1
a) the function should be *available* on "clean" cells (removed after comment in gerrit)
b) answering "No", one would not edit the existing format, *but will edit a new format instead*
c) answering "Yes", one would edit the existing format
Change-Id: I8c578a59084c557939a853d4746efffbaf4e56e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140266
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Rename SCSTR_FILTER_TEXT_COLOR_COND to SCSTR_FILTER_FONT_COLOR_COND according to UI string changes (https://gerrit.libreoffice.org/c/core/+/137087).
Change-Id: I34a707e4924299fccbbb3dcd9580de100221a012
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139943
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
This is how Excel handles these.
At first I was afraid that this would upset LibreOffice users,
but then I realized that equals already is case insensitive,
so this change ought to be more consistent, and thus there should
be fewer outcrys.
Change-Id: Ia3de78d5888672ba8b774866d41ecd65293397c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140484
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
This reverts commit fd2ca9607431fc6ca49e37ab6fef228aa72da5f9,
since it causes a regression when copying a chart.
Change-Id: I5d40de6f46b4b3e68531257d27f9a81540a06da4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140427
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
soffice.bin: include/rtl/ustring.hxx:842: sal_Unicode rtl::OUString::operator[](sal_Int32) const: Assert ion `index >= 0 && static_cast<sal_uInt32>(index) < static_cast<sal_uInt32>(getLength())' failed.
when editing a paragraph (line) longer than the first, because the
string was always obtained from the first paragraph but the
position from the current selection.
Also match parentheses in the current paragraph, not somewhere
else in the first paragraph.. still we're matching only within one
paragraph.
Change-Id: I955fd371c1e248ce58735a5b61603bbce6c997db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140446
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Three invalid files are hitting this assert.
They had invalid XML, so I couldn't even
xmllint --format --recover content.xml
Removing the assert - it has outlived its usefulness.
Change-Id: I93d6d6e1d5ce53f9dd1ee46ce3881183993827c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140447
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
I.e. use "ugly" macros to make code more nice.
Change-Id: I053dd2313c140dbc6b25073d67155a1284c6b310
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140398
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Input data to this function is not required to be sorted, so implementing
this would mean sorting it in opencl, which is not exactly trivial and
not worth the effort. There also exist algorithms that find the median
without sorting an array, but they work by guessing it and looping until
their guess is right, so again, not worth the trouble. I'd say there's
nothing to be gained here from using opencl.
Change-Id: Ic6d6efdfc59b9058bdae50d07d8039db481dfb75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140397
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
These mostly exist in "old" and _new variants which are more or less
the same, sometimes there are minor differences. Keep just the _new
ones, everything still seems to work, all tests pass.
Change-Id: I903ea3f11bad6c5e1301febe03974469eb414368
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140396
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
As one of the code comments said the code used string hashes to represent
strings and this was a broken idea. But the basic idea of that is actually
valid, so just implement that properly and use it only for comparing
strings. See the code comment in opbase.cxx for technical details.
Change-Id: I113d6b4d5e1e78bbe2c05aafc0572605e2595ad8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140395
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This is what core does, it also extends the range (the casting to int
variant limited to the range of the int, which the core variant doesn't).
Change-Id: Ib93bc57b38c0927f9732742d116d0f40700a0abb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140394
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
It's that way in core too.
Change-Id: Ic1100ed637a310b8073256b95a261023b32df827
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140373
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
They are listed in the SC_OPCODE_START_BIN_OP group, but AND(A1:A30)
is fine.
Change-Id: I397d1f8dc6bff450116dd46b6b1da7ffe447efb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140372
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
It's actually not said anywhere in the otherwise extensive opencl
debug output.
Change-Id: I978239d045436c05457b1c0e3e00b672889b9279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140371
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Basically copied from core.
Change-Id: Ic46e6ed77d1e75fcd4dfb8c641a8f592d577cab0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140370
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
as_double interprets the binary representation, it is not a cast.
Change-Id: I3034a36b84fbf458b8818af1e2255b532d21d229
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140369
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|