Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: Idf473f029c2e38efe817c38d4cb00bdd09648d36
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128052
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I7a462b821f286411d759b5259461fcdbf1741859
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117955
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
In some functions author forgot that addCommaBeforeField()
can add additional two characters.
I didn't change cases where more bytes than needed are requested.
Additional change is that in debug mode there is a marker at the
end of allocated buffer - we check that after every write to
detect overflow. No need to request more space for a marker as
we always allocate "needed size * 2".
Change-Id: I28066797b0ba833e408b0a731abc01b7fd989da3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126535
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Change-Id: I694585a1a540bfefc0e59bd58d8033a96ca35acb
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123003
|
|
They in practice are, since they are just integers, but SwRect
had explicit implementations of some functions that technically
prevented SwRect from being considered trivially copyable, even
though they were identical to default implementations.
Change-Id: Ib5086dcd5279f3b4c0c530535c91524671cc6656
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122128
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
(*) tweak buffer in SfxLokHelper::notifyInvalidation to be a bit larger,
so we avoid the cost of a resize©
(*) use our optimised OString concatentation instead of going via
std::stringstream
(*) pass down a pointer to rectangle, instead of a string. later we will
use this to avoid doing the stringify until later
Change-Id: Ia3e3042bc919d9b9cb80e47a93704eb236438605
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119994
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120072
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(cherry picked from commit 417f881d20cafe88a02b64894ba4483875fb9460)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122123
|
|
Add the char encoding handler when calling xmlOutputBufferCreateIO
so that special chars are handled correctly. Previously we just
set nullptr.
Change-Id: I7ef44130869625cc4662bf168550a3f987390287
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117355
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 9ef167c38495a67639366357833041b33be3f978)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121098
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
With previous implementation the ARC, ARCTO and CHORD were
not displayed if the corners of rectangle was switched.
With this patch the shapes are always displayed correctly.
Change-Id: Ie8ac7af812298c0b96c3b5af417117784f128ce1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115757
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
(cherry picked from commit 39369c6e67dffe04acc4abb678c1a94526237fd8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115524
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I5638b1b02afcdd57b16b60d83d3d15da45866060
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107066
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114767
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
When client side tries to show the "Macro Security Warning"
message dialog, it fails to parse the JSON objects
Change-Id: Id73c291ddd9cf739d63d69f06094eacb7b43a2f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108287
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
Change-Id: I730d99cc9aa519f07d6b1c436d749f2c0b044bfd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107151
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107349
Tested-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: Icaa64a493598dc4bb8f2d6d076ad4300e2e4dde6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112976
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113156
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
It is wrong to iterate over UTF-16 code units one by one. We have
OUString::iterateCodePoints() to iterate over Unicode code points.
The two UTF-16 code units of a surrogate pair (for a non-BMP code
point) should not be encoded separately to UTF-8 bytes. It is the code
point that should be encoded (to four bytes).
Change-Id: Ica4341308deb6618c9c2da8dcee8a11ef4e8238d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109318
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109474
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Before colors could be only converted to string rrggbb. Now also supports RRGGBB. It can also be converted back into a color.
Change-Id: Ifb89d554b434c243c4f0956ee680ec23de823339
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106224
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It preserves the points, but not the flags. Work this around
by temporarily converting to B2DPolygon, where it works.
Change-Id: I120264fbc4c7c508386f23a06435891199565aae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106188
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I0f66d02e67388cc4d21c5e96bf84b6848e8de63a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105721
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: Ie1adad9228c4eadbe0d314c0dc27057e84cd721a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106037
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Just don't rely on details of Point implementation.
Change-Id: I0cd0d6b7cacbf2751803a854d78e4b099ccf197f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105978
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
no need for such a thing to be "nullable", just default it to zero,
as one would be expect for such a type.
Change-Id: Ic8b78ca3288355c90820135b9ced2c865ff7606e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105970
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...more likely to pick an appropriate version for the involved integer types,
esp. after the recent long -> tools::Long changes
Change-Id: Ia91259ca35aaf74b0e907de6831fc926f30057f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105949
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I890d19f5e2177294dc1175c90c98b964347f9e85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105751
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaca11d6279e17cf6301ef35d416829377c0ec964
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105841
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This reverts commit 1397a1c8e4995b0dd336478e564880fe8ad91d1d.
Reason for revert: Some discussion required
Change-Id: Id39ee8260790e0722c5bf8338b0b76ca34da83d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105539
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9f1b386ddb4d7d5377151c54baee207b2444c7d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105541
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
which was introduced in
commit adf0738d2dbfa742d0e9ef130954fb4638a8e90d
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed Jan 3 14:25:15 2018 +0200
long->sal_Int32 in BigInt
presumably to make the conversion easier.
Instead just fix the call-sites to select a better
conversion, BigInt only returns 32-bits of precision
anyway.
Change-Id: I2e4354bcfded01763fe3312a715ef37800297876
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105602
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Color.hxx has now documentation ( even if it is quite obvious if you know RGB standar ).
Color.hxx has been reordered in more coherent order, but kept format.
Some changes on Color.hxx dynamics.
Color.hxx starmath colors list
Now colors are managed by starmathdatabse.
The path is open for simple addition of colors, there are no more infinite switches with color tokens here and there.
To add a color, just put it in Color.hxx and register it in starmathdatabse.cxx. Do not forget to change array size in starmathdatabase.hxx.
Now mathml supports RGB colors in #RRGGBB format ( import and export ).
New colors have been added. Only the HTML Css1 are available via UI.
New colors will be added. I intend to finish Css2 and dvipsnames ( latex colors ) on posterior patches.
RGBA command has been unlocked for compatibility reasons. However will be displayed as RGB.
Added color #RRGGBB.
Improved qa color test on mathml to test RGB on mathml.
TODO for someone on the UI team:
- Add a color picker.
- If it is a color with name:
- It will add in the code "color " + starmathdatabase::Identify_Color_DVIPSNAMES( colorvalue ).pIdent +" "
- If not:
- It will add in the code "color " + starmathdatabase::Identify_Color_DVIPSNAMES( colorvalue ).pIdent +" "+ colorvalue.getRed() +" "+ colorvalue.getGreen() +" "+ colorvalue.getBlue() +" "
- Note that those will habe eType with value TRGB or TRGBA.
Change-Id: I47af37bd191b3099e8e6e08e7a5fb1a8a227bbf2
Change-Id: If971473ddcc34739439818dba9a62ca3494a4473
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105526
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This is only for the 64-bit windows platform.
I don't see the point in messing with the 32-bit platforms, they are
(a) become more and more rare
(b) unlikely to even have enough available process memory to load extremely large calc spreadsheets
The primary problem we are addressing here is bringing
Windows-64bit up to same capability as Linux-64bit when it
comes to handling very large spreadsheets,
which is caused by things like tools::Rectangle using "long",
which means that all the work done to make Libreoffice on 64-bit
Linux capable of loading large spreadsheets is useless on Windows,
where long is 32-bit.
The operator<< for tools::Rectangle needs to be inside
the tools namespace because of an interaction with the cppunit
printing template stuff that I don't understand.
SalPoint changed to use sal_Int32, since it needs to be
the same definition as the Windows POINT structure.
Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
A 0-byte ("empty") pptx file is obviously junk input, so it's not
surprising if the catch-all generic_Text filter is chosen to open it in
Writer at the end.
But we can do better: if we really get an empty file URL with an
extension we can recognize, that we can fake the filter type / filter
name, so the empty "presentation" opens in Impress, and also a re-save
works as expected.
This builds on top of commit 8a201be240b6d408d15166be7ffc576b9e123634
(fdo#68903 Import .tsv and .xls plain text files in Calc by default,
2013-10-27), just the new way works for all supported file extensions
and also with filters which would not handle empty input (e.g. pptx
refuses the import if the ZIP storage is broken).
Change-Id: Ie01650a5eb6ca42c35e090133965467b621bb526
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104939
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I88a77f4b07e5aaccc42e6fb6e5bd0366f57381a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104899
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
grepping for stuff in template params this time
Change-Id: Ia37bfd85480b3a72c3c465489581d56ad8dde851
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104855
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
partly to flush some use of "long" out the codebase,
but also to make it obvious which units are being used
for angle values.
Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
first step to switching long to a 64-bit type on 64-bit windows
Change-Id: I640d807426dfe713c7a8984ef560575f8288dbeb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104516
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9d5fe8d61286c2fe167d4733c36e1fc3976d0b43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104446
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: If7fbb25037343e18081a8ee7064840d75e9a45a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104010
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I439b9f456ac0bfaa3eb9bf17472053bd4787e828
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103840
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
As per afb62b0e96e9bf91ec99857cc16ddb094bcaa3be swing the actual
check into a separate file and make only that file be compiled
with the specific flag.
Change-Id: If848a041fc3a26cfaa79f945d63f6c43f8cf3772
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103497
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
As per afb62b0e96e9bf91ec99857cc16ddb094bcaa3be swing the actual
check into a separate file and make only that file be compiled
with the specific flag.
Change-Id: I7f75453f21271f38e0099bdf6b40f9138d8b4cff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103496
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
At the moment test_cpu_runtime_detection_AVX2.cxx is compiled with
-mavx2 to allow it to use the intrinsics; however the compiler jumps
at the chance to use newer instructions outside the actual test;
in my case using AVX in the string manipulation in addTestsToSuite
when my CPU doesn't actually have AVX.
Swing the actual check into a separate file and only compile that
with the extra flag.
We probably need the same change for the SSE* checks as well.
Change-Id: I1683231932fff264a87c96ac95ac1d24b921163a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103075
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I17cbc1c8474880024921f476aa602d61978da868
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102851
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
+ remove sal_Char check on compilerplugins
Change-Id: I0f7da14e620f0c3d031d038aa8345ba4080fb3e9
Change-Id: Ia6dba4f27b47bc9e0c89159182ad80a5aee17166
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102499
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...and in turn add OUString::operator = and OUString::operator +=
overloads that take a std::u16string_view. Without making the ctors explicit,
the operator overloads would have caused ambiguities when called with raw
sal_Unicode pointers/non-const arrays, as those can convert to both OUString and
to std::u16string_view.
But the std::u16string_view operator overloads will generally be useful when
changing OUStringLiteral similarly to 4b9e440c51be3e40326bc90c33ae69885bfb51e4
"Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which
point many existing uses of OUStringLiteral will be replaced with uses of
std::u16string_view.
Implementing this change turned up a need for an operator = overload for
OUStringNumber, which has thus been added. No such need turned up for a
corresponding operator += overload, but which can easily be added when the need
arises.
It also revealed that the operator == overloads between an OUString and a raw
sal_Unicode pointer/non-const array were implemented rather inefficiently,
creating a temporary OUString from the raw argument. Those have been improved.
Preceding commits have already taken care of many dubious or simply unnecessary
implicit uses of the now-explicit OUString ctors. This commit makes explicit
the few remaining reasonable uses. (And in some cases needed to change variable
initialization syntax from using parentheses to using curly braces, to avoid the
most vexing parse issue. And needed to explicitly add OUString ctors from
char16 const[2] string literal lvalues in a conditional expression in
writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary
because MSVC apparently still insists on doing array-to-pointer decay there.)
All of this only affects LIBO_INTERNAL_ONLY.
Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It passed "make check" on Linux
Change-Id: I4db1681869907f050ea224ed24dcb7469a50eb20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101792
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
O[U]StringView had an odd mixture of uses. For one, it was used like
std::[u16]string_view, for which directly using the latter std types is clearly
the better alternative. For another, it was used in concatenation sequences,
when neither of the two leading terms were of our rtl string-related types.
For that second use case introduce O[U]String::Concat (as std::[u16]string_view
can obviously not be used, those not being one of our rtl string-related types).
Also, O[U]StringLiteral is occasionally used for this, but the planned changes
outlined in the 33ecd0d5c4fff9511a8436513936a3f7044a775a "Change OUStringLiteral
from char[] to char16_t[]" commit message will make that no longer work, so
O[U]String::Concat will be the preferred solution in such use cases going
forward, too.
O[U]StringView was also occasionally used to include O[U]StringBuffer values in
concatenation sequences, for which a more obvious alternative is to make
O[U]StringBuffer participate directly in the ToStringHelper/O[U]StringConcat
machinery.
Change-Id: I1f0e8d836796c9ae01c45f32c518be5f52976622
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101586
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
tackle some read-only vars.
Mark some of them const to make it obvious they are not really used, and
to make the constantparam plugin see more data.
Change-Id: Ia25927745866746aa1aa9d5affd5857ad9f9ee24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100895
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6e5c07f4e63b949afb8c259d623a0711a86db021
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100188
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I31d44c0a1791c58c0fc348fb2ec42fe2e2ec4323
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100003
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...that are helpfully deleted in C++20, as now implemented at least by VS 2019
16.6.4 when using --with-latest-c++
Change-Id: Iaf80f793e73fc90768bb146c9cf3d300d6747c8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99170
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
Change-Id: I2f22d455d2a936a85750eaab1fda215ebb6d9d48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98182
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I832fbcde277a87ab873ce3477a6886c7002e24ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97709
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie9d4761747f7e97f63f34394b5a8b9f0bb287a0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97528
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|