Markus did half of this, and I simply carried the torch.
Change-Id: Icd3ee1e4b5bd562faee06dfd9dce52a4bed49a71
Reviewed-on: https://gerrit.libreoffice.org/22943
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
For reasons beyond human understanding, the many-tentacled horror that
openssl calls its build system puts headers in "inc32" directory on
Windows and "include" on other platforms in 1.0.2g.
Change-Id: If03c80f5a31bb6e378cd187051b020579af7f7bd
... not into the source one as that will likely fail with EXDEV if
source and target are on different mounts => osl_File_E_EXIST.
This broke the xmlsecurity test SigningTest::testOOXMLAppend().
Change-Id: I07ada1d5564fd72a059d588e127a5906a499aca4
i.e. the position provided is the location where the popover is to be drawn,
not the bounds of the thing to be pointed to, so adapt them so gtk will point
to the desired place.
e.g. the slide names/numbers in the presentation slide view sidebar
Change-Id: I8c87d5dba32e27f9e627b3282f34d87a8ee460ca
We can't "break symlinks after extracting tarball" because they populate
that dir during the build now. So instead cripple mklink.pl to
copy instead of link. (Configure no-symlinks simply skips the symlink
step instead of copying, so that appears useless)
Change-Id: Ib30b2c1b8b3de72511d09c478297a7a5a4bc691e
Reviewed-on: https://gerrit.libreoffice.org/21880
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
using autorelease here leads to “just leaking” because there's no autorelease pool for thread
besides, make sure that released fields do not contain used•to•be•a•valid•pointer value
Change-Id: Id6cb37643230f64dbe9f6128f52236f04d0c88e4
Reviewed-on: https://gerrit.libreoffice.org/22981
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
... signatures.
ExportSignatureContentTypes() was already a "remove all, and then re-add
necessary entries" operation, so just make sure we still call it for
zero signatures and it'll do the right thing.
Change-Id: If9182b39ac6d8f2cf66f33a02d9ddcab170ba5ea
The signature relation refers to _xmlsignatures/origin.sigs, but
that's not written when all signatures are removed.
Change-Id: I5ee1c8849962cba4b338e6f43243bcf89aedad36
... signatures are removed.
With this, the _xmlsignatures/ sub-storage inside the document is empty
when all signatures are removed.
Change-Id: I391bd1d3b6fdb724952a7158a043b1e602d532a9
EnableAdjustHeight(true) lead to the side effect that when clearing the
range of a pivot table during import, formulas in the same rows were
recalculated with then empty data. Through xSheetOp->clearContents() in
PivotTable::finalizeImport() of
sc/source/filter/oox/pivottablebuffer.cxx
In the case of the bugdoc attached to tdf#98389 that lead to all
VLOOKUP() calls resulting in #N/A errors because an empty string was
looked up.
Change-Id: Ie629ce871d255cc871671165c4da974f21041cec
Attachment 123203 of tdf#98389 has external references of the form
[1]Data!$1:$1048576
which effectively address the entire cell range of sheet Data and
allocating a matrix for a billion cells attempted to allocate 8GB+xGB of
memory which the system said no-no ...
Some brave soul along the road once decided that a check on the number
of elements wasn't needed anymore and dared to remove it during
refactoring.. This change reintroduces the check and adds it also to
other places that try to instanciate or resize a matrix.
When allocation of a matrix for an external range reference fails it is
checked whether the request is for such nasty entire rows or entire
columns ranges and if so tries to shrink the range to the actual data
area used, which at least in this case helps and works.
Additionally it fixes a long standing bug in the cached area to array
mapping which caused the cache to not be hit but instead the matrix was
aquired over and over again for the same range, causing a serious
performance bottle neck specifically for VLOOKUP and related functions
where the same external range is used in a lot of cells.
Change-Id: I35f67b48e665bf1cc8d672325c32b889f2e05c57
