Change-Id: I4302d0d767a1bf50fd34a78e9aa0ad6d6b0c7a22

Change-Id: Ibebcd1c1ebfea0ecdf9d90b6f8bcc8ceb87df456

Change-Id: I95b4358f0d4311e8f427c8de18863049fb718d9b
Reviewed-on: https://gerrit.libreoffice.org/30731Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>

Change-Id: I12f9f5edc4929264627ba949ebf95abd369778c6

A ZIP storage was unconditionally assumed when calling
showDocumentContentSignatures() for "originally" read-only documents,
i.e. in case the file itself is read-only at a filesystem level.

Change-Id: Iba69000fc396afaf5ab34699e811b5d2c216e2bb
Reviewed-on: https://gerrit.libreoffice.org/30758Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

This was the last problem to be able to counter-sign Acrobat-created PDF
1.6 signatures unlimited number of times.

Change-Id: I24ab80c8516b6fe9c08d57c08907bec70384dc28
Reviewed-on: https://gerrit.libreoffice.org/30757Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

The problem: an object stream provies obj#1 and obj#2, then an
incremental updates provides an updated obj#1'. Then we look up obj#2,
parse the stored objects on-demand, so at the end when later we look up
the first object, we find obj#1, not obj#1'.

An easy workaround would be to never update already existing objects
from object streams, but that would break when an incremental update
provides an object stream.

Fix the problem by parsing stored objects right after tokenizing the
object stream, and not later, on-demand, when we no longer have the
context what objects should be ignored.

This is needed (but not enough) to correctly append a signature at the
end of a PDF file that has both object streams and incremental updates.

Change-Id: I3c1fae5ac26804c8e8cc1984511f43cfa881c97b

Change-Id: Ia07f4ff7b243708304186c840135ec1180621fa5

Change-Id: I4ef86a56780cf9ea8fe244a5347a79099bc05979

Change-Id: I355e9507692e770063a91d05efd3ebc3e2671d57

Pass an XAdES flag to a couple more functions and adapt to that.

Factor out writeDigestMethod() and writeSignedProperties() from
OOXMLSecExporter::Impl to DocumentSignatureHelper and use them in an
additional place.

Write xd:UnsignedProperties with EncapsulatedX509Certificate. Probably
much more work needed.

Change-Id: I2a0cd1db6dd487b9c7ba256ad29473de3d271cd8

to b1164b07 "loplugin:constantparam in sd"

Change-Id: I5e03c9ab19af630cdc536fddcb2f39815084b714

For a default column, now ScAttrArray does not store the default
format. So the case of default pattern from 0 to MAXROW is represented
as nCount = 0 and pData = nullptr in ScAttrArray.

A new ScAttrArray object (aNextColAttrArray) is introduced as a member
of ScTable. This is used to store the formatting of *unallocated*
columns (whose indices are from aCol.size() to MAXCOL).

In next patches for this bug, I plan to refactor table*.cxx functions
related to formatting such that :

1) In formatting setter functions, if colspan of the input range
   spans the colrange(aCol.size() to MAXCOL) then instead of
   allocating columns, apply that formatting to aNextColAttrArray.

2) In formatting getter (const) functions, if requested colspan has some
   intersection with the colrange(aCol.size() to MAXCOL) then use the
   formatting info stored in aNextColAttrArray to calculate the formatting
   of the input range.

3) In general setter (non-const) functions if we really need to allocate
   new columns (example, when data is entered), use the formatting info
   stored in aNextColAttrArray to create pAttrArray of the new column.

Change-Id: Ieb56f853209b396d92fdb2c27e39361703576423
Reviewed-on: https://gerrit.libreoffice.org/27828Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

Blacklisted intel driver for graphics card Intel(R) HD Graphics 4000 for Windows 8.
With this card LibreOffice won't start.

Change-Id: I3f4e04da7b4d61bddb1e755771b6a9538b596c51
Signed-off-by: Marina Latini <marina@studiostorti.com>
Reviewed-on: https://gerrit.libreoffice.org/30754Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>

Change-Id: I44fcadbf34677887853324e15cc46388f6f55448

because the start move by wm conflicts with the manual efforts
to position the toolbar.

the move by wm was done to get wayland to move the toolbars, but
(gnome#768128) supporting docking toolbars under wayland is futile
as far as I can see

Change-Id: I502d4617efaf1eb686469e100224e56104ad650d
Reviewed-on: https://gerrit.libreoffice.org/30751Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Why should clicking on a frame/image in a header act any differently from
a one insde the text body?

(The only time frames (or any kind of fly) required a double click occured
when switching from inside a header to a body-fly or from inside the body
to a h/f-fly. This patch removes that oddball corner-case.)

Now all frames are handled with a single click and there will not be
an impact on double-clicking anymore.

regression caused by 7e2f98d0 and its
prior commit which say:
> Header/Footer: fixed click on frames over the header/footer area.
> The main problem here was due to the click to show the separator when
> there is no header or footer under the frame. That code was just exiting
> MouseButtonDown too early, which isn't good.

> Now, double-click actually selects a frame anchored in header/footer.

confirmed that single-clicking on frames over the header/footer section
still shows the header blue-line.
Change-Id: I4770cfe7898202929742743931e22de8bf233b03
Reviewed-on: https://gerrit.libreoffice.org/30693Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

This is especially needed, as we don't bother compressing updated
objects into sections on signing, we simply use a separate section for
each updated object.

Work towards supporting xref streams and incremental updates at the same
time.

Change-Id: Ie9759edbba816991615fafc6602cdd440141b989

and account for the libreofficekit changes

This reverts commit 50e9065c.
that did in turn revert 4ae8c3c2.

Change-Id: Ie02d8743b3608120ed63bfe2a014fa4139577b01

cause of the reported regression, it seems extradinary that this
would cause that, but it seems to be the case and I have no interest
in debugging the undebuggable scheduler.

This reverts commit 180a0eac.

Change-Id: I282a438159b9862034ba9fe4acdf87bf859b0465

This can happen when the group calculation is disabled and falls
back to non-group calculations.  And we only care about the first
entry in case of non-group calculation of grouped cells.

Change-Id: I545980acf8e35b4d0504aa2a77f86bdc85799e29
Reviewed-on: https://gerrit.libreoffice.org/30738Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Tested-by: Kohei Yoshida <libreoffice@kohei.us>

the linux build / libreofficekit also uses those and needs to be told
about this change as well.

This reverts commit 4ae8c3c2.

Change-Id: Ib0d2dac42814c9daf752f0421922fb093507eb7c

Change-Id: I0c0a8a540eccc022c405659f53da73bd87eced18

Change-Id: If42bf5757e2010fccc7061ccffda76048b2e0dda

android studio/sdk manager doesn't provide a default way to install
multiple versions of the NDK, so typically only the latest one will be
available. Don't make configure error out in this case, but print a
warning instead.

Change-Id: I6af9a3f088daf7d12ebd9910286d7f44d264014a

Replace double code by function calls (dialog libraries handling)

Change-Id: I17fc700e47a258b281214fe29e075bc782fb6acd

Project: help  02139162f541bb56ddbaf0a2d6142256a0454372

digital signatures: briefly document OOXML/PDF signing effort

It may be unexpected for users to see that OOXML files are always only
partially signed.

Change-Id: Ie7c6c553580a4eb38ed72c8a50b75f4b7902613f

Change-Id: Ifaf0f45b12d983d556ca4c7e0b4a57c47ff38597
Reviewed-on: https://gerrit.libreoffice.org/30737Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Id7d7bb572466bcc803ac424cd8ddb64205a1c273

Change-Id: I0eb2b9986840b1bd5bc892da23c56205047bc120

Change-Id: I6ec274c6c546f60c23fe639002d751f0a9f11d33

Change-Id: If7fb37a3656b55f7820698a59b8f1d8d8b14d594

...seen a failure of JunitTest_sc_unoapi_3 with

> checking: [sc.ScDDELinkObj::com::sun::star::util::XRefreshable] is iface: [com.sun.star.util.XRefreshable] testcode: [ifc.util._XRefreshable]
> LOG> Execute: refresh()
> LOG> starting required method: addRefreshListener()
> LOG> Execute: addRefreshListener()
> Method addRefreshListener() finished with state OK
> LOG> addRefreshListener(): COMPLETED.OK
> warn:unotools.misc:30768:84:unotools/source/misc/mediadescriptor.cxx:690: caught Exception "" while opening <file:///data/lo/core/sc/qa/unoapi/testdocuments/ScDDELinksObj.ods>
> warn:filter.config:30768:84:filter/source/config/cache/typedetection.cxx:455: caught Exception "Could not open stream for <file:///data/lo/core/sc/qa/unoapi/testdocuments/ScDDELinksObj.ods>" while querying type of <file:///data/lo/core/sc/qa/unoapi/testdocuments/ScDDELinksObj.ods>
> Method refresh() finished with state FAILED

and it appears that all of sc.ScDDELinkObj, sc.ScDDELinksObj, and
sc.ScIndexEnumeration_DDELinksEnumeration try to open that file (necessarily for
writing?), and the first two are in JunitTest_sc_unoapi_3 (so are executed
sequentially), but the last one is in JunitTest_sc_unoapi_4 (so may be executed
in parallel with the others), so that may be the reason for such sporadic
failure.  Easiest workaround appears to be to move the third test into the same
JunitTest as the other two...

Change-Id: Iefb94cf657bdc9c1eac92dd49ee6257eb5e80905

Change-Id: I917cdf6e8d3ebfa7c9e4a52ca61adc5b8707ecfc
Reviewed-on: https://gerrit.libreoffice.org/30447Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>

With this our xref stream output is close enough to Acrobat so that the
existing signature verifier runs without any problems.

Change-Id: I6eca7966890365759c269b465e4bf4d86d335219

Change-Id: I7e77fcf2d120845b436b7d6220025fd5b339aafa

...as that, somewhat surprisingly, causes 'make MODULE.all' do additional
targets that a plain top-level 'make' would never do.  See discussion in mail
thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2016-November/075797.html>
"[Libreoffice-commits] core.git: Branch 'feature/dialog-screenshots' [...]".

Change-Id: I460f3c91cf00d3398c61833fdcd5eaebdc87fbf2

Its last user was
writerfilter::dmapper::DomainMapperTableHandler::getTable(), removed in
commit 6ea66657 (loplugin:unusedmethods
writerfilter, 2015-07-20).

Change-Id: Ibaf536d4dd8f01f4413c3cec033db7438501e58c