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

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

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

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

I get the warning from such a case when loading an .xls written by
Excel 2013. I have no idea how common it is. I have no deeper
understanding of the code here. I just want to get rid of one more
unnecessary warning.

If nLevel > nCurLevel the code indeed probably will misbehave quite
badly (thanks to unsigned arithmetics).

Change-Id: I6cc5af454049e6ec054865535d2f7a54c6264613

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

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

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

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

Change-Id: I928ec885f445615fa1fb8a7cfb4ccc0015381d67
Reviewed-on: https://gerrit.libreoffice.org/40550Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>

Fix regression from e79ef12b
   tdf#107033 DOCX import: fix unexpected missing footnote separator.
Initially related to tdf#68787.

If HandleMarginsHeaderFooter was called twice, then it automatically
would have disabled the separator. Clearing the HasFtn/HasFtnSep flags
also shouldn't be run when in the footnote sections.

Change-Id: I00cbd1cbc8dc86edf426f852c59c3f943e373b13
Reviewed-on: https://gerrit.libreoffice.org/40551Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

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

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

Change-Id: I54f19f61161f3473cbdf2b1bfdc04e9354cc39a8

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

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

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

extend oncevar to any POD type

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

Change-Id: Ic8c652085c3132c0245c2629b71b0e2555d167cb

ScXMLConditionalFormatContext
ScXMLColorScaleFormatContext
ScXMLDataBarFormatContext
ScXMLIconSetFormatContext
ScXMLColorScaleFormatEntryContext
ScXMLFormattingEntryContext
ScXMLCondContext
ScXMLDateContext

Change-Id: If2980e87198b934b4f8e95a6278f4026c092896d
Reviewed-on: https://gerrit.libreoffice.org/40561Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

ScXMLCellRangeSourceContext
ScXMLDetectiveHighlightedContext
ScXMLDetectiveOperationContext
ScXMLCellTextParaContext
ScXMLCellTextSpanContext
ScXMLCellFieldSheetNameContext
ScXMLCellFieldDateContext
ScXMLCellFieldTitleContext
ScXMLCellFieldURLContext
ScXMLCellFieldSContext

Change-Id: I605e83064a7c0ec8dc0c78a93d2fec0ebdbce565
Reviewed-on: https://gerrit.libreoffice.org/40553Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: I51143ecfe4eb1584f13bd1590f927743de8fa91e
Reviewed-on: https://gerrit.libreoffice.org/40572Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: I08b1e73323a15dd977daba98946e7deec3967503
Reviewed-on: https://gerrit.libreoffice.org/40575Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Blocking actions are normal actions plus a modal dialog. So we need
to wait quite some time before considering the action as failed.

Change-Id: I76360b15f54abb1f957a1cddf5314359dfae2d25

Change-Id: I13b07b0a60fdb9fdf736431c6af87d2c2d123182

Change-Id: I447d48930d3321f5c3e1aab9f7b04299cc75f6bb

description of problem here:
https://lists.freedesktop.org/archives/libreoffice/2017-July/078168.html

There is no need for a explicit delete of operator!= .
C++ doesn't generate comparison operators for objects even if one
kind is defined (here operator==).

Change-Id: Ifb22b3f9baa5ca23a4b64800d601cec66dcf39e0
Reviewed-on: https://gerrit.libreoffice.org/40566Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>

Change-Id: Icb8ec00635e42ac8a52e3a9d5ac360f11bf6e645

Several bugs (AFAIK not filed into tdf bugzilla) fixed.

Remaining problems:

When some filter clauses go into WHERE and others in HAVING,
they are always logically ANDed (it cannot be any other way),
but that is not communicated to the user in the UI.

Some things left undone:

* DatabaseDataProvider (and its users?) needs to be updated
  to be HAVING-aware, too.

* Form-based filter (.uno:FormFilter) not HAVING-aware
  it reads the current filter in function
  svxform::FormController::setFilter
  in
  svx/source/form/formcontrollers.cxx
  That's one place that needs to be updated.
  The other place is the one that applies the filter.

Change-Id: I0e9d30a1927b6739a16ae7627e8d0dae8823b376

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

Change-Id: Ia94797159a617ff7c9c2d875e1f51892d5b698b2

- Base SvxCurrencyToolBoxControl on PopupWindowController,
  so we still allow tearoff, but without marking the window
  as self-decorated (unless actually teared-off).

- Add support for toggle state to PopupWindowController.

Change-Id: I60e004e6ada3efe092352cb93be5aae346073f83
Reviewed-on: https://gerrit.libreoffice.org/40557Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>

Group shape level vertical flip is not handled well. Recent handling
of group shape's transformation makes it hard to import this attribute,
but we can import the right text direction at least.

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

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

Project: help  4d6f86d203814a211eae9dfacd4baf195ca4ff1d

tdf#97745 housekeeping

Fix links in bookmarks.js
Better font size for Index and Contents
Fix CSS file

Change-Id: I42966be1d88b12393b6dd95adb2719baf76a025c
Reviewed-on: https://gerrit.libreoffice.org/40549Reviewed-by: Olivier Hallot <olivier.hallot@edx.srv.br>
Tested-by: Olivier Hallot <olivier.hallot@edx.srv.br>

Change-Id: I0f457e60da1ca765dfdb1458b9de629b0dbeccad
Reviewed-on: https://gerrit.libreoffice.org/40545Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

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

1. First quotation mark of \B command switch of TOC field command
  wasn't written when exporting.

2. Quotation mark wasn't ripped off when writerfilter parsing TOC
   field command.

3. FindInCommand accidently ripped that last character of the last
   command.

Change-Id: If283776048f3c8d896c466cf4d742e44b6d85e96
Reviewed-on: https://gerrit.libreoffice.org/38745Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Hung <marklh9@gmail.com>

The problem here is that the SplitNode() calls in SwRTFReader::Read()
destroy the order of the bookmarks, which causes an assert later
from the std::lower_bound() when a new mark is created.

The 2 marks that cause the problem are:
SwPosition (node 5, offset 0)
SwPosition (node 5, offset 0), SwPosition (node 5, offset 0)

During the 2 SplitNode calls, the second one is corrected by
ContentIdxStore and remains on 5, but the first one is not and
becomes:
SwPosition (node 7, offset 0)

ContentIdxStoreImpl::SaveBkmks() does different things when a
mark position is exactly on the parameter position: if it has
only one position, it is ignored, but if it has a second
position, then both its positions are corrected.

It is not possible to change the sort order so that marks with
one position are sorted behind marks with 2 positions, because
while SplitNode() corrects marks "backward", JoinNode() uses
ContentIdxStore to correct marks "forward"; hence manually sort
the marks.

Change-Id: If5b35f18bfd47ffe98c0f67e84d380ca801411a3

This was changed in d72aad21

Change-Id: Ie93f603c82669ca612fbf9635a62c50e63702a85