Commit 046e954595 (Try to revert to use
of file_iterator from boost on Windows, 2023-10-31) had introduced a
problem that pdfparse::PDFReader::read couldn't create file_iterator
for files already opened with write access: mmap_file_iterator ctor
on Windows used single FILE_SHARE_READ as dwSharedMode parameter for
CreateFileA WinAPI; and that failed, when the file was already opened
using GENERIC_WRITE in dwDesiredAccess - which happens when opening
stream in TypeDetection::impl_detectTypeFlatAndDeep.
Fix this by patching boosts' mmap_file_iterator constructor to use
FILE_SHARE_READ | FILE_SHARE_WRITE, like we do in osl_openFile.
But there was a pre-existing problem of using char-based CreateFileA
API, which disallows opening any files with names not representable
in current Windows codepage. Such hybrid PDF files would still fail
creation of the file_iterator, and open as PDF.
Fix that by further patching boost to have wstring-based constructors
for file_iterator and mmap_file_iterator on Windows, which would call
CreateFileW.
Change-Id: Ib190bc090636159ade390b3dd120957d06d7b89b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160218
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Supposedly, at this day and age, it is OK to use non-ascii file names.
Specifically, this is intended to allow such names for bugdocs, which
allows simpler testing of problems with handling those.
An alternative would be to rename bugdocs at runtime; but that still
requires that the target filesystem supports such names, so...
Change-Id: I25da2402f311d59c5777c4cd302147d6965dea5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160217
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
* Update helpcontent2 from branch 'master'
to cd2824ba5ee24accdeffea3518bd89cc194ed189
- Document new SF Dataset service
Change-Id: I4e6a792f2cbcbf826f51f5d62e6dad855d4a0bf0
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/160035
Tested-by: Jenkins
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
Two bugs are fixed with this commit:
1. when rows in a dataset are read in chunks,
one record is skipped errorneously between
every two successive chunks.
2. In updatable datasets, the updatable fields
need to be identified. This is done at
dataset creation.
Before: the IsDefinitelyWritable criterion was
used, valid for Firebird, not for HSQL
After: the IsWritable criterion is used,
valid for both.
The correction in Basic is valid as well for Python.
Documentation is unchanged.
Change-Id: I990c02aaa8a93123a7e669b1294605fa19780167
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160163
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
Tested-by: Jenkins
Configure the gradle build to show detailed warnings
about the use of deprecated API, instead of just
> Task :compileStrippedUIEditingDebugJavaWithJavac
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
With this in place, 78 specific warnings about the use
of deprecated API are now shown in the build output,
which can be addressed at some point.
Change-Id: I9f3b484b6dfad1fc57895efa7d3426b625030ee7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160198
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Clicking on the right of the floating table on the page 1 resulted
in a cursor position on page 2 instead of a position inside the floating
table on page 1.
What happens is that the anchor text frame on page 1 is wide enough to
contain the mouse click position, but then "before the first character
of the paragraph" is on page 2, so a page 1 click results in a page 2
cursor position, which is unexpected.
Fix the problem by first ignoring which dummy anchor frames (all
non-last ones) in SwLayoutFrame, so
SwLayoutFrame::GetModelPositionForViewPoint() in
SwPageFrame::GetModelPositionForViewPoint() fails for the perfect match
case, and then later looking for split flys explicitly, so the corrected
case finds the split fly on the page.
I imagine this is not only useful for mouse clicks, but it's also good
for everything else that uses GetModelPositionForViewPoint(), e.g.
keyboard page-down.
Change-Id: I761b211c1b5468d9d8996c59a32ac9be5b83a777
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160194
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The paths generated for curved connectors are basically incompatible
between LibreOffice and OOXML. Thus it was not possible to render curved
connectors the same way as MS Office. The patch adds an OOXML compatible
method for calculating the path. The new method results in a different
svg:d attribute when saved in ODF, but needs no change to ODF.
The patch introduces the boolean connector property 'EdgeOOXMLCurve' to
switch between the two methods. The property value is determined from
the svg:d attribute in case of import from ODF. In case of missing
svg:d attribute the property value is set to 'true', because Word
currently does not write a svg:d attribute when it exports to ODF.
The property value is set to 'true' for import of connectors on a
drawing canvas in docx. Default value for new connectors is 'false'.
The new property has no UI, but can be used via macro.
Currently the new method is used for import of curved connectors on
drawing canvas in docx documents.
Change-Id: I53d99f44febe4d74c2b611f5fdb9de86628c4519
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159708
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Previously the ooxml import added a new page style when the first
header or footer was detected. Since then we gained support to add
first page header/footer in an existing page style so we don't need
to import it like that anymore.
This changes the import code so that the old complication to add
"First Page" page style is removed and it always just uses the
"Standard" page style for all 3 cases: first, left and right headers
and footers.
This also adjusts the existing tests to align with this change.
Change-Id: Ibf69597e6990499ac520ea9e323a5f73f429800b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157860
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
and rename it to ScItemPoolCache,
since its only use is to handle ScPatternAttr objects
Change-Id: I68a2dd5f47fcf902f9df552e1a1767d5061d85d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160162
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
When the PageDesc is copied from one document to another, we
don't make sure the stashed FrameFormat(s) are also properly
copied to the new document (which can happen at copy/paste). This
can cause a crash if the stashed FrameFormats are accessed or
destructed after the original document is destroyed.
This fixes the issue so that when we detect the PageDesc belong
to different documents, the stashed FrameFormats are copied just
like the non-stashed FrameFormats (used for headers and footers).
Change-Id: I948068dba4d39bb47c3725dfa8491c53c5833c7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160065
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
In Notes mode, these templates have a preview of 4/3 ratio. Change them
in 16/9 like the slides
Unification of preview and notes position and size
Change-Id: Ie088b2226e438476cf421f6351c3bd617e7e6bbf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159876
Tested-by: Jenkins
Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
The implementation was not aware of the used functionality
in the used call to SdrPageView::DrawLayer: The given
OutputDevice is *not* intended to hand over a new render
target, it's used to allow the mechanism(s) to *identify*
one of multiple possibe registered render targets (which are
usually OutputDevice/SystemWindow). It is even the default
to call these method(s) with a nullptr which means to repaint
all registered OutputDevices/SystemWindows. This is no
tooling intended to repaint parts of a View to 'any'
OutputDevice.
This is not very obvious and there are already other places
in the office that do that wrong and never got cleaned-up,
therefore also being fallbacks to not just let those cases
fail, but at least paint something (and give you a warning).
The caveat is that these fallbacks (e.g. in
SdrPageView::DrawLayer) have to use temporary SdrPaintWindow/
SdrPageWindow instances to make the paint work. Especially
when a temporary SdrPageWindow is used an evtl. existing
VC/VOC/OC structure will not be used and with it also not
the existing primitive decompositions.
I thought about bigger changes in PageView/PaintView/
PageWindow/PaintWindow area to sort that out, but this is
- despite being utterly necessary - too expensive for now,
keep a note about this needed change for the future.
For now I will just use an already (also for this purpose
already existing) 'compromize' that will do it for now.
Change-Id: I8c7ccee1deb0d69aad1d2145a7ac2039aca685b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160155
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Move Title-Slide master page at first place to get it from Master page
Side panel
Move picture from background of master page to image at the back
Other updates:
- remove unused fonts
- remove English text "number"
Change-Id: I8e6567ec3661ebce8ccd08f97d3661b1994c3ee7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159691
Tested-by: Jenkins
Reviewed-by: Stéphane Guillou <stephane.guillou@libreoffice.org>
Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
On first master page, move picture from page background to an object at
the background
Change-Id: I0f288396f63230fc0fe524b3e30f6d1fc4d7ef11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159808
Tested-by: Jenkins
Reviewed-by: Stéphane Guillou <stephane.guillou@libreoffice.org>
Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
The crash was caused by removal of a paragraph break (pointed to by a
PaM returned by pDelPam->GetNext()), that resulted in merge of the node
pDelPam pointed to, with the previous node. The destructin of the node
made pDelPam dangle. In debug builds, an assertion failed in destructor
of SwContentIndexReg. I.e., since the code always called DeleteAndJoin
on pDelPam->GetNext(), the processing went from second-to-last deletion
towards the begin of the document, and the last deletion (represented
by pDelPam) was handled last, when GetNext call wrapped.
This change makes sure that the order is strict, from last to first.
Change-Id: I5cb7fe2f06d4138d3c445eeca8220f0a87a82626
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160158
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
So far, the build ID in liboSettings.gradle, and
therefore in the about dialog in Android Viewer
was not reliably updated in incremental builds.
For example, after a full build, then
git commit --allow-empty -m "Dummy"
make
, the build ID would still refer to the commit
from the full build, not the new dummy commit.
Since `instdir/program/versionrc` on Linux
and `instdir/program/version.ini` on Windows
gets updated properly, add an optional make
dependency on these files, using a wildcard.
Change-Id: If3b1d4d811a5e4316a26bb17f246b66858dcf80f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160157
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
...with value begin of type GtkPackType: Could not parse enum: 'begin'
To reproduce this:
- launch Writer
- menu Format
- choose Columns...
Change-Id: I591d925f1375ffbc5583ea8f6a4470a6721174c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160141
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
So far, the versionName for the LibreOffice APK/app bundle
included the build ID and vendor, was e.g.
"24.2.0.0.alpha1+/2972af9045a5/The Document Foundation".
That versionName would be split again to extract the build ID
and vendor to display them in the about dialog.
No longer include build ID and vendor in the `versionName`,
but use separate build config variables, similar to what
is done for the privacy policy.
This slightly simplifies the code for the about dialog.
But more importantly, the previous `versionName` scheme
would make it impossible to automate the F-Droid update
of the app, because the scheme is not compatible with
the expectations of F-Droid's update mechanism, see the
F-Droid merge request to update LibreOffice Viewer to 7.6.3 [1]
for more details, in particular the (eventually not merged)
commit [2] mentioning what manual steps would still be needed
when trying to semi-automate the update at least.
[1] https://gitlab.com/fdroid/fdroiddata/-/merge_requests/14080
[2] https://gitlab.com/fdroid/fdroiddata/-/merge_requests/14080/diffs?commit_id=bfc062a358dc574326a29f08e01c0e80cadd80cb
Change-Id: Ibede06d13095d8e83dcc88ee09a8a610d6a9de0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160150
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Similar to
Change-Id: Iaa78f5a6020bea4ed80a1b41d3b23cc8d313813c
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Nov 30 12:00:52 2023 +0100
android: Simplify version info handling for about dialog
, also simplify the handling of the vendor info text by
retrieving the text from the string resource right away.
Change-Id: I7d56b1814454be2bc8d13e01265f0a0db6d865be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160147
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
* Don't set and retrieve the placeholder text in/from
the TexView in the about dialog, but use the string
resource directly.
* Add the HTML code directly in the string resource,
rather than having to fiddle with that in the Java
code.
With this in place, only the version name and the
commit hash need to be replaced.
Since there is no placeholder text in the text view,
it's also no longer necessary to explicitly set an
empty string in case of an exception.
Change-Id: Iaa78f5a6020bea4ed80a1b41d3b23cc8d313813c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160146
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Add the build dir (`android/source/build`) to the
directories to be removed when cleaning.
Previously, this was't cleaned, which could be seen
e.g. by the fact that a fresh build would result in
this warning being shown
> Task :compileStrippedUIEditingDebugJavaWithJavac
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
while a
make android.clean
make android
after a full build wouldn't.
Change-Id: I00a4f8b1fda9fbefb3b8f806b1997eceded117fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160145
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
With GNU gdb (Debian 13.2-1) 13.2, I noticed this trace on console when using --backtrace
Warning: 'set logging on', an alias for the command 'set logging enabled', is deprecated.
Use 'set logging enabled on'.
Change-Id: Ic03911ea94aff57dee8f594744147302ef01a1ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160143
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
The comment is saying the opposite of what the code is doing.
Change-Id: I16cc44b56f90f622cedb87b9107d17b940665896
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160144
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@libreoffice.org>
This is a prerequisite for updating the compile and target
SDK versions to API level 34, which requires and AGP minimum
version of 8.1.1.
Change-Id: I27d12ec3c9bc3dac8a5df18459a57f1a1e990197
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160085
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As described in more detail in
commit 45fbfbfeae
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Mar 27 17:04:37 2020 +0100
tdf#131622 android: Extract native libs again
, extracting native libraries was necessary for the NSS
library to be able to load modules like `libnssckbi.so`
at runtime. Without this, opening password-protected
files would fail.
However, this has in the meanwhile been addressed
differently in the following commit (probably in the
context of the online-based/Collabora Online app), so
extracting libs is no longer needed:
commit 16a7f98f99
Author: Mert Tumer <mert.tumer@collabora.com>
Date: Wed Sep 30 17:14:59 2020 +0300
Fix libnssckbi not found error on Android
This error causes Android App to be unable to
open Password-protected documents.
Change-Id: Iacbacb1c780025752e2447db325b075c58947818
Signed-off-by: Mert Tumer <mert.tumer@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103658
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Therefore, no longer extract the libraries, which also addresses
addresses this warning shown during the build:
> Task :processStrippedUIEditingDebugMainManifest
.../android/source/AndroidManifest.xml:16:9-41 Warning:
android:extractNativeLibs should not be specified in this source AndroidManifest.xml file. See https://d.android.com/guide/topics/manifest/application-element#extractNativeLibs for more information.
The AGP Upgrade Assistant can remove the attribute from the AndroidManifest.xml file and update the build file accordingly. See https://d.android.com/studio/build/agp-upgrade-assistant for more information.
Change-Id: I867beea0bce8398806375048e87a152e1348d016
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160079
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
For the layout containing the Calc address/formula bar,
explicitly set a background color that matches the theme.
Otherwise, those text views would be using white font on
white background when using dark theme, making the text
unreadable.
Change-Id: I5fdf9e04f8bb331ca6a57bf3046a7ebb9ccb0d1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160078
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Using "colorBackgroundFloating" requires API level 23 [1],
but our current minimum API level is 16 (when building with
NDK 23).
Therefore, define an own color `background_floating` instead
and use the correspodning color values from the material theme
(`background_floating_material_{dark,light}` depending on whether
dark/night mode is enabled or not.
This makes the app work again in a quick test with an x86 AVD
with API level 16 instead of crashing on startup.
Change-Id: I7b8378b42e9fc7430ec4ed263d4cb8b42027a930
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160077
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Instead of using a TextView and setting `?attr/colorButtonNormal`
for the background color, just use a button right away, which also
makes sure that the proper button color is used and avoids
using `colorButtonNormal` only available from API level 21 on. [1]
Also drop the extra `LinearLayout` parent that was only containing
this one TextView.
While at it, drop an unused import.
[1] https://developer.android.com/reference/android/R.attr#colorButtonNormal
Change-Id: Ie2f7e2646d20f4051fb2513fb8fd72572ce19217
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160076
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Similar to how
Change-Id I2061878067d21dcd743ad6ca8d1018db323755d6
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Nov 28 14:22:54 2023 +0100
tdf#124480 android: Use themed color for more icons
did for the icons in the toolbars, use the themed color for
the directory icon in the start activity as well.
While at it, switch to using the same shade of gray that
the toolbar icons also use.
And rename the icon to drop the "_grey" suffix, since this
is now themed and no longer using a hard-coded color.
Change-Id: I9fcf51b712a01aab3b9754bcfbd817c89171a64f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160075
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As already mentioned in
Change-Id I2061878067d21dcd743ad6ca8d1018db323755d6
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Nov 28 14:22:54 2023 +0100
tdf#124480 android: Use themed color for more icons
, do this:
> Given the icons are no longer hard-coded to be black,
> the files with a "_black" suffix will be renamed in
> a follow-up commit. (Separate commit to keep the
> diff clearer.)
Change-Id: Ie2d3433934569dc97530a35d88bda01802af96b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160074
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
These icons used in the toolbars were previously using a
hard-coded fill color.
Most of them were using black, but `ic_line` and `ic_rect`
used in the "Insert" tab of the bottom toolbar, were
previously using a lighter gray than the other items in there
for no apparent reason.
Switch all of them to use the themed `toolbar_foreground`
color that other icons are also using.
Together with
Change-Id Ic699fd1cecc607bd5e748648113336fe045e72b1
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Nov 28 13:13:12 2023 +0100
tdf#124480 android: Override icon color for dark theme
, this makes these icons use a light color when using
the dark system theme.
Given the icons are no longer hard-coded to be black,
the files with a "_black" suffix will be renamed in
a follow-up commit. (Separate commit to keep the
diff clearer.)
Change-Id: I2061878067d21dcd743ad6ca8d1018db323755d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160073
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Add a `values-night/colors.xml` that can be used to
override the colors specified in `values/colors.xml`
specifically for the dark theme.
Specify a light color for `toolbar_foreground`,
which is the color used for (most) toolbar icons,
both for the top-level as well as the bottom
toolbar.
This makes most icons show up in proper contrast
when using dark mode. Others are not making use of
the color defined here and will have to be looked
into separately.
Change-Id: Ic699fd1cecc607bd5e748648113336fe045e72b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160070
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Instead of hard-coding the background color
for the 2 toolbars shown at the bottom
(`toolbar_bottom` and the color picker), use
"colorPrimary" from the theme.
Stop overriding "colorPrimary" in
`LibreOfficeTheme.Toolbar`, which would otherwise
result in a hard-coded white color being used again.
This makes those toolbars show up in a darker color
when dark theme is enabled.
Stop hard-coding the font color of the items in
the "Style" tab in the bottom toolbar to black, but
use the primary font color instead, so a light color
is automatically used when using the dark theme.
Change-Id: Ib09ca47e8695903cdfa9f4eb100dc88ecae652a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160069
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Support dark theme by inheriting from the
corresponding "AppCompat.DayNight" themes rather than
forcing the use of a light theme by using the
"AppCompat.Light" variants, s.a. [1].
With this in place, the app will automatically use a
dark theme for the Android UI controls when that's
enabled in the Android system settings.
Toolbars and menus mostly look as expected.
The bottom toolbar will be handled separately.
Icons will also have to be adapted in a follow-up
step to provide for better contrast, since they're
currently designed for light mode/white background.
[1] https://developer.android.com/develop/ui/views/theming/darktheme#themes-styles
Change-Id: Ia08edcc9d22b93caa67b146dcf90ee5fd02ee550
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160068
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This ensures these 2 toolbars will also use the correct color
in dark mode once support for that is added in a subsequent
commit.
Change-Id: Idcea5096c4e4bdf8ddc6b28df0fc6df05074980b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160066
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
