The problem was that the whole Subject info was returned from
X.509 certs if they did not start with one of "CN", "OU", "O", "E"
Instead of extending this list with random keys, pass the type of cert
and only return the whole Subject info if it's an OpenGPG one, and
process the info unconditionally if it's X.509 like before the OpenGPG
integration
Change-Id: I1aa5d7285e48b0f4a769a073cdfb7732e482792c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92675
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
... and provide a compatibility mechanism for supported service
names, as the typo was long standing since the beginning and
existing extensions may rely on it.
Co-authored-by: Andrea Gelmini <andrea.gelmini@gelma.net>
Change-Id: I289ec8a17b131bd013dd4b69327aed41e488d4f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92938
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
The implementation is a combination of what "bottom" and "from-top"
already provided.
Change-Id: Id7bac8cbcccbadcca377fe9946a21ccb3e368913
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93086
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Before, code was test-compressing every single bitmap coming along.
Let's buffer those SvMemStreams, and keep the last 15 around in
case the same image comes along again.
Change-Id: Ic8da32725ea46b01bd6beacc389abf8f52845d36
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93058
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
When it comes to vertical positioning of anchored sw objects, one can
say the position should be "1cm from the top of the page". But measuring
from the bottom of something was not possible.
Add API for this to help working with documents from Word, which
supports the feature.
There is no duplicated C++ enum in sw/ for vertical relative
orientation, so no "doc model" changes are needed for this in sw/.
Change-Id: I3199d3e794bda2f21f92ce3bb7c3c6f04d284db2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93065
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
912217285b fixed the
root cause of tdf#131554 and
69b83dc2d3 is no longer needed
The unittest still passes
Change-Id: I7c723b0c3cc2b56022978bbeb8bf6b3f6f93f1c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93063
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
...in typelib_typedescription_register, in case they are already being
referenced from elsewhere. Instead, only move from *ppNewDescription to
pTDR->pType those members that were not yet initialized in the latter.
Change-Id: I7620219d137f8dd7f24a0f4a04eda30669b6c5a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93062
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It's not exactly clear why, but as a side effect, this makes a crash in
uno::Reference::release() go away in the --enable-macosx-sandbox case.
But it helps readability as well, so why not.
The root cause is probabably either a compiler bug or the old code
depends on a longer lifetime of the temporaries involved in the function
call, but that's not clear to me.
Change-Id: I5f987129d3301d30ebf732757a4f1ba4bdbb8d52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93040
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
I need that for another upcoming commit.
Change-Id: If7e567c731e454070bf8ad9efb5c2f28ff9049e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93031
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
to the slightly higher namespace, to make it easy and more readable to
use directly in a for-loop-range expression.
And make it return a reference rather than a pointer, since it is never
allowed to be nullptr.
Change-Id: I15d0b32493ef65cfc601b247c272b318f1eadfd8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93049
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Same as RAND() and RANDBETWEEN() but not recalculating on every
change, just the normal expression recalculation.
Change-Id: I8ba7099125e487a78bd3d91db8b666c2f36b22fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92994
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
Keeping position of OLE objects anchored to text
as a character.
Co-developer: Tibor Nagy (NISZ)
Change-Id: I9699250ae5c418f9994ea2a7a3b102681b042214
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91983
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Implemented highlight color in grouped shapes. It was missing
completely.
Co-Author: Balázs Regényi
Change-Id: I51207d01a205fbb24abc51c0d69042d6747570a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91619
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Regression from commit d37096f59e
(Related: tdf#124600 sw anchored object allow overlap: add layout,
2019-09-19), we assumed that the anchor frame always has draw objects,
but that may not be the case.
That happens when dragging a to-character anchored object around, before
the object is added to its anchor.
Change-Id: I1271a6e498553838c3851864b7965a1ba28de663
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92989
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
...broken with ef513fd4b0 "remove unnecessary use
of OString::getStr"
Change-Id: I85f5ccb6c5114ea5e3eab43a3c1821292cf4e994
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92993
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
order of filled net and normal area charts.
The data series of filled net and normal area charts are drawn in
reversed order in LibreOffice but not in Microsoft Office.
Default value is true to keep current behavior.
Change-Id: I07adac814597b756878d74610d028f07327f7214
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/83897
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga991@gmail.com>
Multiple SvxFillAttrBox objects having the same ID 'fillattr' caused
the problem in online making it hard to distinguish for different function
Change-Id: Ic5a29ea75fb442d7e495761faf4a10d6ab212829
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92977
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Multilevel lists are more flexible in case of DOCX. There is
supported custom format for any level in DOCX unlike in LO
and ODT where we are limited only with prefix and suffix
for hardcoded list levels separated by dot. At the same time
DOCX can have lists not only "1.2.3.4", but "1/2/3/4" or even
"1!2>3)4" and such format can vary on each list level.
Here is basic implementation for list format as a core feature
for all documents and old way (prefix-suffix + ".") is left
as fallback.
Practically its usage is currently implemented only in DOCX
import/export.
Some RTF/OOXML unittests were redesigned: since we are not creating
prefix/suffix for these formats conditions should be checked in
a different way.
Change-Id: I1ec58bcc5874d4fa19aee6a1f42bf1671d853b14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92106
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
This is a follow up commit to cf13fe3e fix with some
mostly cosmetic changes. General idea of list overrides
is not modified.
Change-Id: I35937449bd563eacceb3753e62b9ff7245f12b89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92739
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
It doesn't really matter, but the assumption is that functions
without entries take at least one and only scalar value arguments.
Change-Id: I6a4cb882c86c50a0c63ddd5fc6a3b885fab32ea3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92990
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
'make test-install -o build' fails without this when
--enable-macosx-sandbox is used. It is harmless in other cases.
Change-Id: Ic62a2c7729402cf45172ccc12fa83b46bee31e78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92985
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Now, I don't know for sure that E000 is from
Office 2013, since I don't know where the document
came from and I don't have 2013 readily available.
However, I tried round-tripping the unit
test in Office 2016 and it gave the version
number 0x2000.
Change-Id: Ib02f9440de34225affcb2ccbfd96ed89c717085e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92764
Tested-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
