Age | Commit message (Collapse) | Author |
|
it's not enough to compare != end(), you also need to compare the key
against the iterator result
Change-Id: Ide5f151ba2297a35e5546f47fbc3c53cbe5ab533
Reviewed-on: https://gerrit.libreoffice.org/62014
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1df70b7dff5ebb6048f7fc618789faa15ca5d422
Reviewed-on: https://gerrit.libreoffice.org/61967
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...to avoid -Werror,-Wshadow from Clang trunk with
<https://reviews.llvm.org/D52400> "Improve -Wshadow warnings with enumerators",
warning about shadowing of BORDER_TOP/LEFT/BOTTOM/RIGHT in enum BorderPosition
in writerfilter/source/dmapper/PropertyMap.hxx.
Also, BorderPosition can apparently be made a private member of BorderHandler,
which gives extra confidence that any other uses of BORDER_TOP/LEFT/BOTTOM/RIGHT
across writerfilter/source/dmapper/ indeed meant to reference the other enum
BorderPosition.
And change BorderHandler::lcl_sprm to return early in default case, to avoid
having to come up with some new BorderPosition sentinel value to represent
"invalid pos".
Change-Id: I31e535326627cec25a17b99485bf7cf56f4c66d3
Reviewed-on: https://gerrit.libreoffice.org/61896
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I409eb644bdf519e097c87911b90f83c5ecd913ee
Reviewed-on: https://gerrit.libreoffice.org/61853
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
redundant get() call on smart pointer
Change-Id: Icb5a03bbc15e79a30d3d135a507d22914d15c2bd
Reviewed-on: https://gerrit.libreoffice.org/61837
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
tighten up the handling of binary operators
Change-Id: I262ec57bf7142fa094d240738150a94d83fd15ee
Reviewed-on: https://gerrit.libreoffice.org/61777
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
5d0c83fd4cf91083805f60f49e4fafd3d6ac73d4 follow-up
Change-Id: I3611172944072ac009c7c5191cbe05ec9600fd1d
Reviewed-on: https://gerrit.libreoffice.org/61847
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I7abd715b6bb71d6e2e01939c4cf849d94eb6a103
Reviewed-on: https://gerrit.libreoffice.org/61843
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
error: accessing an element of the container does not require a call to
'data()'; did you mean to use 'operator[]'?
Change-Id: I022745aa84b80124f342ce6c596d51b4d904f012
Reviewed-on: https://gerrit.libreoffice.org/61820
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iadab935efff35e1e8e5d70878414da1ed2f0fbf9
Reviewed-on: https://gerrit.libreoffice.org/61795
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
And fix
ScXMLCachedRowAttrAccess::Cache
which was never setting its mnTab field, and hence would never
be hit.
And fix oox::xls::CellBlockBuffer, which was never setting mnCurrRow.
Change-Id: I2c46aa050b9ebe3c2dc2e52579555f97945dd61c
Reviewed-on: https://gerrit.libreoffice.org/61772
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
message is "calling a base constructor other than the copy constructor"
these constructors are not in use, so just remove them
Change-Id: Ic8cede1eb153a6ae97fd1ca9c96ca8c1f43e3399
Reviewed-on: https://gerrit.libreoffice.org/61784
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Although this follows a very different code path, copy the ww8
import idea of "consuming" the bookmark of a BOOK_FIELD.
This is particularly important for textcontrols, especially
since LO keeps duplicating bookmarks as it adds another
bookmark for the field name at each save.
Existing unit tests that this matches are fdo53985.docx and
tdf111964.docx. I expected more, but apparently most fields
don't contain or represent any bookmarks.
This patch is for import only. A followup patch stops
the creation of duplicate bookmarks during export.
Change-Id: I1e11980e52dc523393fd6d621191228d676e9a17
Reviewed-on: https://gerrit.libreoffice.org/61615
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Repeating table headers consisted of more than 10 table rows
switch off table header repetition during DOCX table import
to fix non-visible table content and broken tables.
Repeating header lines are not visible in MSO, if there is no space for them.
OOXML (and ODF) standards don't specify this exception, and unfortunately,
it's easy to create tables with invisible repeating headers in MSO, resulting
OOXML files with non-standardized layout. To show the same or a similar layout
in LibreOffice (instead of a broken table with invisible content), we use a
reasonable 10-row limit to apply header repetition, as a workaround.
Later it's still possible to switch on header repetition or create a
better compatible repeating table header in Writer for (pretty unlikely) tables
with really repeating headers consisted of more than 10 table rows.
Note: This workaround could help to create standard and more portable OOXML
files in a mixed environment.
Change-Id: I17fbc0173ec1c4f188a46227b99dde5726530da3
Reviewed-on: https://gerrit.libreoffice.org/60689
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I04c5ba277d5b3398c07de6ae66713d977636088d
Reviewed-on: https://gerrit.libreoffice.org/61347
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
despite the documentation that states it must be a positive value,
the actual implmentation honors a negative number (as opposed to
treating it as a zero, or an absolute).
Change-Id: Ie38369ecdf5353b73572dd3533c2efe41adda290
Reviewed-on: https://gerrit.libreoffice.org/59401
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: I9a763eacf8887230ba5d88ac69cb13d0cfb1a7ee
Reviewed-on: https://gerrit.libreoffice.org/61274
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I7db0c27ff2213210ed4b46ebbadc1a2f74a18257
Reviewed-on: https://gerrit.libreoffice.org/61249
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...and the column width must not be negative.
The previous column logic ensured that the total width was
larger than the reference by adding a fake buffer
and then subtracted the difference from the final column.
In the case of a zero-width final column, it could become negative.
The current logic ensures that the total width is less than
the reference width, and then adds the difference
(which should be a smaller difference now) to the final column.
Regression potential - early columns that need every single twip
of bonus space might not fit anymore. On the other hand,
ending columns might be fixed...
Change-Id: Ie75d455e8ed62dbec5a1b9c901417df8d842ace8
Reviewed-on: https://gerrit.libreoffice.org/59400
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
This mostly affects explicitly defaulted functions that had recently been user-
declared to silence new GCC trunk -Wdeprecated-copy. It is not entirely clear
to me what the best approach is overall, see my mail
<http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20181001/245321.html>
"Re: r343285 - [cxx2a] P0641R2: (Some) type mismatches on defaulted functions
only", but lets just explicitly delete those functions for now.
Change-Id: If8c72f612f67a8feb8b03c2fb988c807e704ef03
Reviewed-on: https://gerrit.libreoffice.org/61259
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Use range-based loop or replace with STL functions.
Change-Id: Ie1e169f9d2d44e188180164bd1f93af43740425d
Reviewed-on: https://gerrit.libreoffice.org/61141
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5f9ef043d76c55f2c761fd08a2bc1dae66b675c8
Reviewed-on: https://gerrit.libreoffice.org/61073
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
If the tblBorder does not exist, or if first row's
left-border has a different sized border than the
overall table settings, use the cell's lineWidth
value to determine the the spacing needed.
The potential regression here is the spacing given to
the cells. However, the current calculation is totally
wrong (it needs to be based on per-cell, not on some
table-level default) and so it was "wrong" a different
way before. The unit test shows this visually.
Plus, MS Office version are inconsistent in handling this
unit test. The latest versions base the position on the
*last* row and not the first row.
The key reason for making this change is to support a
table that doesn't have a table default, needed to
fix tdf#92026.
Change-Id: I319513a2f5550c1527dc564fb8b3806d1251a0c2
Reviewed-on: https://gerrit.libreoffice.org/60988
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: Icfe120db02a70d43e4120d1f4cbb2704640d3990
Reviewed-on: https://gerrit.libreoffice.org/59470
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
implemeent a reduction approach, which is good at finding virtual
methods that only themselves or their virtual partners.
The accessibility GetVisArea stuff is dead since
commit 891e41fac81fbd8d5cdb277b26639abfd25a7143
Date: Wed Apr 4 11:23:22 2018 +0200
dead code in AccessibleTextHelper_Impl::UpdateVisibleChildren
Change-Id: I78d9d8bca585ecec8394f2c3fe2baa93db0e58f5
Reviewed-on: https://gerrit.libreoffice.org/60912
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
"new" borderlines (from 2012, 2014) defined in
offapi/com/sun/star/table/BorderLineStyle.idl
where no supported in export yet!!! Sad.
const short FINE_DASHED = 14; (rtf)
const short DOUBLE_THIN = 15; (rtf/doc/docx)
const short DASH_DOT = 16; (rtf/docx)
const short DASH_DOT_DOT = 17; (rtf/docx)
Change-Id: I07fee08e17171db4baec489864fc47da107cee75
Reviewed-on: https://gerrit.libreoffice.org/60992
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Deciding when to and when not to deduplicate repeated direct formatting
of paragraph / character properties is stricky, this bug is about a case
when deduplication should happen and did not, since commit
1970a686273c5d4fc1eeb4430283e37085d9f647 (tdf#113408 RTF import style
dedup: separate paragraph and character handling, 2017-10-31).
Especially that deduplication works in both directions: it should remove
properties which are duplicated and also should insert explicit default
values for not repeated properties.
Fix the problem by making the getDefaultSPRM() aware of the context
(which style type it deals with), and then by making sure that only
default properties relevant for the given style type are inserted.
Change-Id: I35b6599cc47fa51b8754fd921c61a3b31a283547
Reviewed-on: https://gerrit.libreoffice.org/60946
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I22ba2c8aec235e34cd7835b8a0a716bf3057db7a
Reviewed-on: https://gerrit.libreoffice.org/60837
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
on Win32, waiting only for \r\n instead of \n in RemoveLastParagraph().
Change-Id: I8921a6a72e8397ed04edb9f339ba3f0bf5bbb98b
Reviewed-on: https://gerrit.libreoffice.org/60865
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
by ignoring isolated tblHeader settings, according to the standard.
(OOXML 17.4.49 tblHeader (Repeat Table Row on Every New Page)
"...if this row [with tblHeader property] is not contiguously connected
with the first row of the table (that is, if this table row is not
either the first row, or all rows between this row and the first row
are not marked as header rows) then this property shall be ignored.")
Note: with this fix, in a mixed environment, LibreOffice is able to
fix the known problems of MS Word 2013/2016 by removing the isolated
tblHeaders during DOCX import/export (such problems in MSO: missing
repeating headers in a few pages or in the whole table, despite the
correct settings; and non-modifiable repeat header row property in
the table settings).
Change-Id: I73e8394a75b77c937a4bac37d99ff747ad95a06e
Reviewed-on: https://gerrit.libreoffice.org/60765
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
According to the OOXML standard, <w:cr> (carriage return –
Unicode character 000D) is equivalent to a break
with null type and clear attributes, so we handle it as
a <w:br/>, instead of endOfParagraph, fixing
losing table paragraphs and tables containing <w:cr/>.
Note: It seems, MSO cannot handle carriage return characters
in table cells correctly. It shows squares (unknown
characters) without line break there. Copying this text to
a non-table paragraph in MSO, we get the correct layout with
line breaks. Copying this text with carriage return characters
back to a table cell, we get squares again. With this LO fix,
it will be possible to fix the bad tables edited by MS Word
by using LO, because LibreOffice import/export converts all
<w:cr>s to <w:br>s (as before, but now without destroying
the structure of the tables).
Change-Id: Iee42f71e9a00531353582e7127c2c212ea0890d0
Reviewed-on: https://gerrit.libreoffice.org/60585
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Ia0a19736dfd4500bb17b04c072710f8ee8744031
Reviewed-on: https://gerrit.libreoffice.org/60526
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...warning about (for now only) functions and variables with external linkage
that likely don't need it.
The problems with moving entities into unnamed namespacs and breaking ADL
(as alluded to in comments in compilerplugins/clang/external.cxx) are
illustrated by the fact that while
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
returns 1, both moving just the struct S2 into an nunnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
namespace { struct S2: S1 { int f() { return 1; } }; }
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
as well as moving just the function f overload into an unnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
namespace { int f(S2 s) { return s.f(); } }
}
int main() { return f(N::S2()); }
would each change the program to return 0 instead.
Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
Reviewed-on: https://gerrit.libreoffice.org/60539
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ibe380e1fb35d9defc478d459a988f9f6df13bf35
Reviewed-on: https://gerrit.libreoffice.org/60427
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic2d901ca0dbc2d6fa96611d260c1572da8a783c0
Reviewed-on: https://gerrit.libreoffice.org/60398
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
partial revert to fix tdf#119589
Although it was working fine for DOC/DOCX formats, ODT doesn't
save the working document's defaults to the file. Instead it just
writes the application's built-in docdefaults, and just
throws away the current working state. Unbelievable.
But changing this results in invalid ODF syntax, so not trivial.
So, it wasn't working to change the format from DOCX to ODT.
Since this patch was just "future-looking" and didn't immediately
solve a particular problem, I'm just reverting part of it, so
that parentless styles once again copy the default settings.
This means that table-style settings cannot override system defaults
since it cannot know whether the style specified that value, or
if it just got a copy of the defaults. (Just becuase the style
matches the docDefaults doesn't necessarily mean that it
inherited them - unless it is parentless...)
Change-Id: I61dd7866b42f79d91645ee65ff84b734ed2a53cf
Reviewed-on: https://gerrit.libreoffice.org/60366
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: Ifb7e6ad6f5ffe71c3c5bb7cca9cb3b27bff7943a
Reviewed-on: https://gerrit.libreoffice.org/60308
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Idd435b3a4d081f6d3af26ff8add69ad4af50db57
warning: calling a base constructor other than the copy constructor
Reviewed-on: https://gerrit.libreoffice.org/60239
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I09cb2e8f4af7d34c32accf2590695799d0613d62
Reviewed-on: https://gerrit.libreoffice.org/60070
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I41c965512085cc56c06fb735d8ef86aaf3ecdbe9
Reviewed-on: https://gerrit.libreoffice.org/60071
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
If the inherited properties define a non-auto color, then
a specified COL_AUTO needs to be returned in order to
override the inherited color.
This affects three areas. Character fill, Paragraph fill,
and table cell fill. The unit tests cover all three areas.
This patch depends on the commits for tdf#91292
Change-Id: I1a043d2224b164c6c411ce2e46d899212f2b7f3d
Reviewed-on: https://gerrit.libreoffice.org/59313
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: Iebcaea7b08c5284946d83b6b6b9ed26b218025d4
Reviewed-on: https://gerrit.libreoffice.org/59992
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
17.4.25 insideV (Table Cell Inside Vertical Edges Border)
This element specifies the border which shall be displayed on
all interior vertical edges of the current group of table cells.
[Note: Although individual table cells have no concept
of n internal edge, which would render this property useless
in most cases, it is used to determine the cell borders to
apply to a specific group of cells as part of table
conditional formatting in a table style, for example, the
inside vertical edges on the set of cells in the header row.
end note]
So, I interpret this as insideV/H having meaning only within table
styles, and not when directly applied to a cell. The only
documents I've seen with insideV/H directly applied to a cell seem to
have been created by LO - which dumps them everywhere, redundantly.
Change-Id: Ie76e9af6845cc87b0b847050b031e57d95b1a31b
Reviewed-on: https://gerrit.libreoffice.org/59674
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
or InComment. The first footnote does not get special treatment in
autospacing either, so no exception needs to be made for it like in
autospacing, unlike many other "firsts".
The unit test is simply preventative. I'm a bit surprised,
but the section isn't even marked as "IsFirstSection" until after
the comment and footnote paragraphs are finished. That seems a bit
odd to me, since they are in the FirstSection after all.
Change-Id: Ib0107c969bf624e44f0c78b936bf9531fd25bfc2
Reviewed-on: https://gerrit.libreoffice.org/59858
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
which also resolves a regression from tdf#113258.
The previous code segments were being spread out all over
the place. It all consolidates nicely in finishParagraph,
and the code is much easier to read using the new
GetAnyProperty function.
Plus there were regressions creeping in.
The mere presense of the Autospacing property normally, but
not necessarily means that it is on. Verify that it is enabled,
and update grabbag if autoSpacing changes.
Additionally, support was added for a zero top margin for
the first paragraph of the document.
This will be too hard to backport since it depends on
150c12fc0fba2c2f4b08b4298678ee49676ebae0 from tdf#72560
and the many code fixes related to GetPropertyFromStyleSheets.
Change-Id: Iaf1600fffea54e9800e215e89cad40006d5bcdda
Reviewed-on: https://gerrit.libreoffice.org/59705
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
|
|
regression from 5c6bce38a01b21403a603acd3148cf3bbb4c685f
(tdf#104354 DOCX import: fix paragraph auto spacing in tables).
Change-Id: I486d155eb4463599ab922837fd2f4347b48e0851
Reviewed-on: https://gerrit.libreoffice.org/58818
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
pulled in from OOo project as a single call being passed nCell = 0.
Change-Id: I90899e9b5270d809dbdc37915a5ec31fc43f1f22
Reviewed-on: https://gerrit.libreoffice.org/59673
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: Icc820a47ac891c358883f9c01224f676c58fdd11
Reviewed-on: https://gerrit.libreoffice.org/59744
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Since anchored objects can contain paragraphs, considering all
of them to be "firstParagraphs" would generally be considered
an incorrect result. Browsing through the existing uses of
IsFirstPara.*InSection I didn't see any that looked like
it should be considered true if IsInShape.
Since this is the kind of gotcha that that the programmer
should be aware of, add it directly into the function instead
of requiring each use to have an additional qualification.
The following ooxml unit tests match these conditions, but
only one was fixed - the rest were unaffected since they just
avoided adding/removing dummy paragraphs.
fdo79540.docx - 5
tblppr-shape.docx - 5
ooo47778-3.odt- 5
ooo47778-4.odt- 5
textbox-rounded-corners.docx - 7
n780563.docx - 8
missing-path.docx - 10
floating-tables-anchor.docx - 10
tdf117805.odt - 11 (fixed - prevented extra section paragraphs)
Change-Id: I841475e214c194a673321c1229d9254dd07205f8
Reviewed-on: https://gerrit.libreoffice.org/59659
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
ECMA-376-1:2016 states that w:dir is functionally equivalent to LRE/RLE+PDF
pair around the enclosed runs. So this patch does just that.
Change-Id: Ibf9775338cc38a3bbc38a42a33fc64ae787b478f
Reviewed-on: https://gerrit.libreoffice.org/59643
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|