Regression after commit b41a780d139ec6ca5a5514db972ccf0e50058dfc (tdf#166401:
support custom placeholder prompt text, 2026-08-17), where a placeholder that
authored no prompt stopped writing text and got a bare <a:p/> instead.
On a slide an empty presentation object reports no text through UNO anyway, so
the paragraph the export wrote for such a placeholder never had a run. It
carried the properties, and those are the formatting. In PowerPoint 2016 the
original title showed white at 22pt, indented 56.5pt; the round-tripped one
showed bold black at 17pt, indented 18pt.
Write the paragraph the way a shape with no text already does: the paragraph
properties, the run properties in endParaRPr, and no run. The prompt still
stays out of the file. That branch of DrawingML::WriteText is now a method of
its own, called from both places.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I034a4e14f388c90872069d32b303c6c143c1814c
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10768
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit e2859f5b23f53281d80cbad4c56db1764aaf1406)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211538
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A hyperlink in Impress or Draw can carry a name, the Hyperlink
dialog's Name field: the description a screen reader announces, and
what PDF export writes as the link annotation's Contents. Saving the
document and loading it again lost it, and a tooltip carried by a
PPTX never arrived at all, so the link fell back to describing itself
by its own visible text.
Commit 8bf8873f30 (tdf#161583
drawinglayer,editeng,svx,sd: add "Name" to SvxURLField ...,
2025-03-06) gave SvxURLField the name and wired the export path to
it, but no filter. It is not reachable over UNO either, and both
filters go through UNO, so neither had anywhere to put it.
Give the URL field a Name property, and read and write it in both
filters: office:name in ODF, and the tooltip of a:hlinkClick in
OOXML. On import that tooltip becomes the name rather than
Representation, which TextRun overwrites with the link's text; a
shape's own hyperlink goes through the same import context and is
unchanged. A Draw or Impress hyperlink now survives both round trips,
as a Writer one already did.
Inserting a field into shape text does not reach
SvxUnoTextField::CreateFieldData: SvxUnoTextBase builds the stored
field with SvxFieldData::Create, which needs the name too, or it is
dropped again on the way in.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I43d44d55ab460547bbed8acd04d8938a4ee9a615
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12270
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit f6218048f057a229eea7f15c198d850ceedd95dc)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211048
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Do not export transient Scott's-rule width as cx:binSize for automatic
histograms. An explicit binSize is imported as fixed-width
binning, so ODS-to-XLSX roundtrip changed FrequencyType from automatic
to fixed width.
Leave cx:binning without binSize or binCount for automatic mode and add
a regression test verifying that FrequencyType remains automatic after
XLSX export and reload.
Signed-off-by: Devansh Varshney <varshney.devansh614@gmail.com>
Change-Id: Icac1a0a032213dd5a6d5581a72d7453e8147d391
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7985
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 9b4ab82c920ae20bc82f6d68031b1f853dbc65c6)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209217
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A date/time placeholder saved to PPTX held our own display string
"<date/time>" as literal text with no <a:fld> at all, so PowerPoint showed
that string where the original showed a date. DrawingML::GetFieldValue has
no case for the field kind a header/footer date carries, "DateTime", and
with no type name nothing writes the field.
Name the type that leaves the format to the reading application, datetime:
the field carries no format of its own, the page holds it. PowerPoint writes
datetimeFigureOut in such a placeholder, an alias of datetime1 - MS-OI29500
part 1, 21.1.2.2.4 (fld) - which would pin a formatless field to MM/DD/YYYY;
that alias is read on import as the datetime1 it stands for, so a slide's own
date field keeps its format across a round-trip. Every other datetime* type
was understood; the one PowerPoint itself writes was being dropped.
The page's own DateTimeFormat is out of reach where the type is chosen, so
a footer set to show a time is written as a date. PowerPoint has no
per-page format to fall back on either way, and a date beats the literal
string this replaces.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Icbd9ac57ed7b2311d5f6570fffad1cd78e4d6bf7
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9192
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 145a37d84dd3b22023c46b6be8577008f36a48b9)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210141
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A placeholder clipped to an outline carries it as custom geometry, which an
image shape has nowhere to keep, so the outline was dropped on load and the save
wrote a plain rectangle over it. Read it into GraphicClipPolyPolygon, and write
it back from there.
The two directions are not equally capable. Import reads paths of literal
coordinates: one driven by guides or formulas, and an arc, both need the
custom-shape machinery. A quadratic curve is read, converting exactly to the
cubic the model keeps. A path that states no w and h is not read either - such
coordinates are absolute EMU rather than a space to scale from, and no file
authored that way turned up to check the reading against. Export writes whatever
polygon the model holds, so that direction loses nothing - a geometry the import
gave up on was never stored. A curve that closes a contour states no end point
of its own, and the point the contour started from answers for it.
A path that states fill="none" states that it paints nothing, and PowerPoint
leaves it out of the clip: a picture clipped by two paths shows through the
plain one and not through the nofill one, while the same file with that one
attribute removed - or with stroke="0" in its place - shows through both. So
such a path is read past, while the shading variants and stroke="0" are not:
those say how an area is painted, not whether there is one.
Several paths become one polygon by area, not by concatenation: the contours of
one path are filled by the even-odd rule, so two of them overlapping leave a
hole, while paths are filled one after another and the shape covers what they
cover together. Concatenating them instead cut a hole wherever two paths
overlap, which the file does not describe and PowerPoint does not draw.
A shape's own custom geometry now replaces the one it inherits, the way a preset
geometry already did. Saving states the outline on the slide as well as on its
layout, so reading that back gave the slide placeholder its own geometry beside
the inherited one, and two geometries at once are not one this reads - the
placeholder came back unclipped while PowerPoint showed the same file correctly.
The outline reaches the drawing the commit before this one added, so a
placeholder read from a file shows what sits behind the parts it does not cover.
It survives a round-trip through ODF as well, where the property already travels
as coext:graphic-clip-poly, with nothing to carry until now.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I87bd21e68bcea648c8c9151b6af5439578f1c2cf
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9303
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 04bbb74a24bad4ae54f257b6b028f3fd48955272)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210123
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A slide layout is imported as a master page, and the shown text was only set
off a master, so an authored prompt was stored but never displayed or written
back; the export emitted Impress's own localized resource instead. Set it on
a master too, and accept the graphic kind in RestoreDefaultText, which keeps
the object an empty presentation object. Now that the two are
distinguishable, a placeholder that authored no prompt writes no text - its
text body keeps the properties a reader needs, and holds an empty paragraph.
A slide's own placeholder asks its master for that prompt before falling back
to the resource string, so the two no longer disagree about what is really
one placeholder.
This is what degraded in commit 73f1e76b1760d4e936aa22627623c922dcda964b
(cool#15754: Fix PPTX round-trip of empty picture placeholders, 2026-05-21):
mapping a layout <p:ph type="pic"/> to a real presentation service is what
made it reach that text reset, where the previous OutlinerShape mapping had
kept the authored prompt.
Implemented a TODO from commit 67ba6ccd5a
(tdf#140912, tdf#159219: fix import of graphic placeholder with custom
prompt, 2024-01-17). That commit deferred this because marking the object
empty after setting the text crashed the PPTX export; going through
RestoreDefaultText, which does exactly that, no longer does. Its other
objection stands: ODF stores no placeholder prompt, so a save to ODP still
drops it.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I1b6f3e38cb24ac737d3de6258559090596817bad
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9046
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit b41a780d139ec6ca5a5514db972ccf0e50058dfc)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210008
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The export needs to write pt-elements for content text nodes with the
original modelId to data.xml. However, the shape has not this modelId
but the modelId of the associated pt-element of type=pres. Thus this
element is searched for in getMasterXShapeForPoint(). The error was, to
examine msPresentationLayoutName. That name is created by the author of
the SmartArt template and is arbitrary. And indeed, a name textNode
exists only twice in the over hundred predefined SmartArt templates. So
remove this test, it prevents to find the shape.
After removing the above mentioned test, an error in WriteText() in
the export becomes visible. The export of a SmartArt diagram calls
WriteText() with bBodyPr=false. With that no a:bodyPr element is
written at all. But for the CT_TextBody it is specified in OOXML, that
the bodyPr child element is mandatory. Thus we need to write an empty
element in this case. Without it, the file markup is invalid and
MS Office requests to repair the document.
Change-Id: I9cdf5e882b415ca1d13718d6c1e47ebb1d2c7018
Signed-off-by: Regina Henschel <rb.henschel@t-online.de>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4396
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 533dccff298edc397a9c0fc564ba4d31b8c27432)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206994
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
It appears that the ownerIdx attribute of <cx:series> is used to indicate
that series share data. At least that seems to be the case with pareto
charts, which have both a clustered column and a pareto line series. Going
on that assumption, implement parsing/export of ownerIdx, and don't write
a dataId tag when ownerIdx is present. That fixes round-tripping of
pareto charts, at least based on what I've seen.
Signed-off-by: Kurt Nordback <kurt.nordback@collabora.com>
Change-Id: Ie948d2e5992b778462e34e1ef90681631c867332
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5900
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 8c37a25ffb7711f69de978045b4e3dc8d52759da)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209240
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Read underflow and overflow attributes from the histogram chart
type properties.
Export the same properties back to <cx:binning> so chart roundtrip
preserves optional edge bins.
Signed-off-by: Devansh Varshney <varshney.devansh614@gmail.com>
Change-Id: I963febac4987da23dce2571928982973f7ea67d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207153
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A custom shape that has no matching OOXML preset is exported as
<a:custGeom>. Until now that path baked every coordinate to a fixed
number and wrote empty <a:avLst> and <a:ahLst>, so the shape lost its
adjustment values and adjust handles: it became frozen and could no
longer be edited by its control points after saving to docx/pptx/xlsx.
Convert the shape's ODF "Equations" to DrawingML guide formulas by
walking the parsed expression tree (FunctionParser::parseFunction). At
that level the original structure is intact, which lets the export:
- emit <a:gdLst> guides for the equations, keeping width/height symbolic
("w"/"h") so the geometry scales correctly on resize;
- express the trigonometric functions (sin/cos/tan): the angle-conversion
idiom (X*pi/180 or pi*X/10800000) is recognised and reconciled to
OOXML's 60000ths of a degree, for both trig arguments and standalone
angle values such as arc parameters;
- declare the referenced adjustment values in <a:avLst> ("adj1", ...) so
the guides stay driven by the shape's handles;
- emit an <a:ahXY> handle for each ODF handle that drives an adjustment
value, referencing the matching adjustment guide;
- reference an equation from a path coordinate (or handle) by the token
that holds its value.
svx gains two small ExpressionNode accessors (getChild/getIndex) so the
expression tree can be walked from the export filter.
Equations or handles that cannot be expressed yet (raw-radians angles
without the pi/const idiom, atan2/cat2/sat2, ellipse, polar handles) fall
back to resolved coordinates, as before.
Also update the now-outdated comment in ShapeExport that claimed ODF
equations cannot be converted to DrawingML. Adds a test on a symbol shape
(tdf#142603) and a circular arrow (tdf#157289 trig guides), and updates
testFlipAndRotateCustomShape / testEquationGuidesExport for the new
parametric output.
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: I21cf73df018417fcfe9c2f9ecd185c0ac29a198d
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4464
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 40967878aeaee989216b6e0cfd6cf81af4a8b1d8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206685
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
ODF import applied the histogram template before series data existed, so
bins were not rebuilt on reload. Apply it again after series import.
For XLSX import, preserve generated histogram bin labels during axis
conversion instead of replacing them with generic category labels.
For XLSX export, write the direct values-y source range for new
histograms instead of generating an _xlchart.v1.N alias without a
guaranteed matching workbook definedName.
(cherry picked from commit d346a0edcaa200720b8ce5716a84427b5fce10d8)
Signed-off-by: Devansh Varshney <varshney.devansh614@gmail.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3302
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Change-Id: I6c9d2aa5c70e0340331cde159499f3c4992828a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205843
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Currently the Graphics from imported and unchanged Diagrams
is held in uno::Any structures (look for DomMapFlag like
OOXDataImageRels/OOXDrawingImageRels) in the form of their
binary data. It gets deleted when the Diagram is touched,
and written to a new rels DomTree when the Diagram was not
changed.
The problem is that if multiple Diagrams exist and/or the
identical Graphic is used somewhere else these Graphics
are written double (or more) since before this change they
were written always.
This change now directly remembers the used XGraphic in the
uno::Any, so no extra space for the binary data is needed.
These are then used for export if necessary.
In the to be created rels the RelIDs have to be identical
since the original DomTrees for model and/or replacement
graphic gets written. This *could* be adapted to new
RelIDs but would be complicated, not easy and is not
needed.
The export uses more common methods that I had to slightly
adapt to add a XGraphic to the media part of the target
file, these already are capable of detecting existing
graphics. These now return a new relative path to the
media part that then gets used in writing the DomTree of
the created rels file.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: Iebbfe08d495d67b17eeaaadc76233e096df85727
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1915
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
(cherry picked from commit 5429358ead879f3d9f350c0ff05193813e6f5119)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206020
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Calc imported Diagrams due to using mainly DrawingLayer
oox import code, but export, even of the unchanged
DomTrees, was missing (just never done). Thus in
versions before this being a Diagram was lost, it
just always was converted to a GroupHierarchy containing
the Shapes that were part of the Diagram.
Added to read the Diagram's name at Import at all for Calc
oox import, set and used now at the created Diagram.
Added to secure/save the DomTrees for the imported
ReplacementGraphic when importing oxx Calc, that was just
also never done, so it could not be exported as unchanged/
original data (and was not, so that was never noticed).
Added complete export of oox Diagram to Calc. This includes
unchanged versions, but also changed/added versions. This
may need more work, but own turn-around works already.
This mainly uses the same ExportContent, but that needed
some adaptions.
Doing this I also changed the ShapeImport of Calc to use
a single oox::drawingml::ShapeExport, before it created
a separate temporary one for every Shape that was imported.
Also added the checkMinimalDataDoms check to Calc oox
export that is already used in the other apps. As always,
there are huge differences in oox im/export for Calc
compared to the other apps, e.g. a completely different
Group ImportContext is used compared to Impress and I have
no idea why that is done.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: Ib7c1b73f7f72599f6054d0cf9203f46980eec5cf
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1887
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
(cherry picked from commit b1fbe49401e5e4dbe62ff25580ec7252c0376e88)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206019
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Much-improved Writer oox roundtrip. It now checks if export
is possible as Diagram at all. It is capable of re-creating
ModelData and ReplacementGraphics. Cross-checked with ppt/oox
roundtrip, too.
Original Writer import held the DomTrees in the GrabBag of the
GroupObject, but by default converted content to a single graphic
shape containing a Metafile. This of course contradicts that
part of the new DiagramModel is in the Shapes - adjusted now.
I see no plausible reason to by default do that in the future
when we want to do more with Diagrams. Nonetheless that stuff
is still there if AdvancedDiagramFeatures is not enabled to
stay compatible until we can activate the feature.
Needed to adapt the ShapeImport for ReplacementGraphic for Writer,
it is (why?) different in oox from Impress import. Added needed
stuff like import of ModelIDs.
The export of ReplacementGraphic in Writer also is different,
needed to adapt to behave more like Impress export when Diagram
creates that.
Unified usage of useAdvancedDiagramFeatures to one place, adapted.
This allows fast changes (e.g. to use ExperimentalMode if needed)
or removal.
Change-Id: If8b73029615e8c9e5d6d93db26449bdfe6e3ef97
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/990
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
(cherry picked from commit f2f9961505ea7278e6aba84ab06fdced401a7851)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204739
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
The OOXML standard defines <c:showLeaderLines> and <c:leaderLines>
as valid children of <c:dLbls> only for pie and doughnut chart types.
The export code wrote these elements unconditionally for all chart
types, including bar charts. Excel crashes when it encounters these
elements inside a barChart series dLbls.
For non-pie/doughnut charts, the c15:showLeaderLines extension
(from the Office 2013 chart extensions namespace) is the correct
mechanism to express leader lines. The code already had logic to
write this extension for non-pie charts, but it was written in
addition to the invalid standard elements rather than instead of
them.
Fix by guarding <c:showLeaderLines> and <c:leaderLines> behind a
pie/doughnut check, and writing only the c15 extension for all
other chart types.
Change-Id: I652927b8d29de159a3bda10461bc220affe93dd9
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/778
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 9a52b0c1633108022e58605f6732ad81160a9bb1)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204677
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Bug document: forum-mso-de-138303.pptx
The chartex export code always writes xdr namespace regardless of
document type. Use appropriate namespace for document type.
Additionally do not write <c:date1904/> which belongs
to older non chartex chartSpace due to which the file was failing
to load in powerpoint.
Additionally write XML_nvPr for pptx as officetron
complains about the schema if this is absent for the
mentioned document.
Change-Id: I22e6e1641412c43c19c354dd9d763fb40fb367ba
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/194
Reviewed-by: Balázs Varga <balazs.varga@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit a14b9a514234bf5f676a83e29a80a1b9bb67020c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204673
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The gapWidth tag specifies spacing for bar/column-like charts. In old-style
charts, it's given in the type group. In chartex, it is an attribute of the
<cx:catScaling> child element of <cx:axis>. This code thus includes some
structural changes to allow for reading the value in the axis processing
and storing it in the PropertySet associated with a type group (XChartType).
Change-Id: I21bdf3b511269c34c225873ee66fbaf29a7cb0ea
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/718
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit bb1d3ba56f5b17d0979addac95a3973278d2f46b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204149
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Aron Budea