this finally makes fpicker usable

Change-Id: Iedf7ed8de04947ffbc0e88348c95f2a937a8e69e

Change-Id: I1fb29b673e5cb474de7230407b7924844b1460e0

Change-Id: I0a195de54a8631c2218f6704ca564c0c9f06becf

Change-Id: I1b9dee1a8cd4034f64c2c1b843cee1863a5dc1d9

Change-Id: I0d75ef9f5584935d05a0526a626145e00761efd9

Change-Id: I9cd6b0b393024957c3dec1bd7e381db62f711a24

Change-Id: I1b77d7a1c8a4a3581554fb5c481b7d9039497ced

Change-Id: Ieb3fb6bb9afa8cddbfd7f14ddfb36faebd524701

Change-Id: Ib79837ff08cabf8a27b6d154529399a5965ab148

Change-Id: I01b9f897abda67b12ed6f05844dca05dabb185a2

also kill KDE5SalDisplay with fire, it is not used anywhere
anymore

Change-Id: I4fe439b01322a6e3a809cf518e32d844c303daca

Change-Id: I3bb5d45f3337fbe26d80acb1fac7a433de904546

Change-Id: I1004ccba52fb23549dd85c20068da5c62d7bc964

Change-Id: I174a4a01f2191d935ea069a0e04b5c88f4bf8193

Change-Id: Ic18add9e1e0a6a7e4480df17885670a0796f074a

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

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here
and a bit of fallout management.

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

Many OpenType features are required features that are applied to certain
context determined by the layout engine, or should always be on. There
is no value in presenting these features to the user and they just
clutter the dialog for fonts that usually have many of such features
(e.g. Arabic or Indic fonts).

Change-Id: Idc3d7d3a9eb1c4f693ea6fdf9f26f0264b910f91
Reviewed-on: https://gerrit.libreoffice.org/55951
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

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

This should have been part of e0e21f27.

Change-Id: I5942b9a907f876ff7173971b27f72b8a6c97f8dc

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

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

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

Using SwTableFormatCmp in loops with SwTableLine::ChgFrameFormat, where
the latter may delete the old format of a frame, may invalidate the pOld
of a SwTableFormatCmp, and lead to use-after-free. To avoid this, let's
register SwTableFormatCmp as the old format writer listener.

Also use unique_ptr in vectors to simplify memory management.

Change-Id: I5ac93f4c3ae549b79a41220bda880386dd529c36
Reviewed-on: https://gerrit.libreoffice.org/55653
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

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

Change-Id: I85e364da59ce70ddd97fdae9bc03a4ea76b007fc
Reviewed-on: https://gerrit.libreoffice.org/55263Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

Sources such as
http://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/
or https://en.wikipedia.org/wiki/Double-checked_locking suggest that
it wasn't possible to reliably do a portable double-checked initialization
before C++11. It may be true that for all platforms we support those
memory barriers are in fact not needed (which seems to be the assumption
behind OSL_DOUBLE_CHECKED_LOCKING_MEMORY_BARRIER being empty), and
looking at the generated assembly here on x86-64 seems to confirm that, but
in the worst case then this is a more chatty and standard way of writing
a no-op.

I don't want to use threadsafe statics or std::call_once() because
ScGlobal::Clear() does cleanup, which would be non-trivial to do with these,
and also some functions may not necessarily always force
creation of the singleton when touching the pointer, so it can't be easily
hidden behind a single function call.

The need to explicitly use load() with delete (thus preventing DELETEZ)
looks like a Clang bug to me.

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

Change-Id: I36fcdf88c3e037b9db60f24cef3508aa9791bb35

Change-Id: I4eacbf689989d20142c04dc8fe586d0054c46350
Reviewed-on: https://gerrit.libreoffice.org/55962
Tested-by: Jenkins
Reviewed-by: Tamás Bunth <btomi96@gmail.com>

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

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

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

Change-Id: I77c4c8feb12d7ed6ee4b4eaa6132a91f4e655fbc
Reviewed-on: https://gerrit.libreoffice.org/55967
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

Project: help  bedb482f8d914e9319c711df1c665e636fd856be

Fix typos

Change-Id: Idf4ffe077bd71dc8170a20df93d714e581ef02b2
Reviewed-on: https://gerrit.libreoffice.org/55963
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Change-Id: Ibf4de00b63579aff9faf4cae657824a81c1c80dc
Reviewed-on: https://gerrit.libreoffice.org/55976
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

Change-Id: I9b79528e90426ee63dff22765ee8cfe717aa8d30
Reviewed-on: https://gerrit.libreoffice.org/55972
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

When importing PDF as images, we store the
PDF stream in the GfxLink. For large PDFs
storing a copy of the full PDF with each
page is overkill. For example a 10MB PDF
with 200 pages will consume 2GB of memory!

Change-Id: I99913514cf5c562683080bc817668095bee69427
Reviewed-on: https://gerrit.libreoffice.org/55571
Tested-by: Jenkins
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>

Change-Id: I01eff9b5d921787ff0c251ab8467912144577705

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

a problem (I assume) since...

commit d7d5fa52
Date:   Tue May 22 10:49:36 2018 +0200

    sw_redlinehide: trivial conversions in reffld.cxx

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