Change-Id: Iccf4b7156677c6db7e675b2c7a6926d8395d025a

Change-Id: I844901f38ec1d93f4183e0678741fecdc7636139

So we can use UTF-8 input to test.

Change-Id: Ie56d43226c8cc8a5bf10317961fa0a91d8acfcf0

Change-Id: Ia555369ae5dd530e5c0fdb4122071eff262059f1
Reviewed-on: https://gerrit.libreoffice.org/61418
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

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

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

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

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

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

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

Change-Id: Ic491b7f63726abe25acb61c619c15967e496094d
Reviewed-on: https://gerrit.libreoffice.org/61422Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>

when the menu is too tall to fit and the active entry is sufficiently
far down the menu that the problem gets triggered.

i.e. https://gitlab.gnome.org/GNOME/gtk/issues/94

as a workaround set wrap to 1, which is good enough to make
GtkComboBox take an alternative path to the one which sets
the problematic rect-anchor-dy value and the menu will at least
appear

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

Change-Id: I0dc2594371f6d11e6ba1f02de7d70bdde3af9957
Reviewed-on: https://gerrit.libreoffice.org/61409
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

Change-Id: I86e1fba17402d0a5f06d7942cf0733b0f2c924ba
Reviewed-on: https://gerrit.libreoffice.org/61276
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>
Tested-by: Heiko Tietze <tietze.heiko@gmail.com>

which only recent versions of MSVC (from 15.8.6) seem to spot.
It resulted in PythonTest_sw_python failures with "vector
iterators incompatible" assertion on the
    dest != maDestructedListeners.end()
check

ever since
    commit 4a290888
    Date:   Mon Oct 1 14:31:00 2018 +0200
    SvtBroadcaster unify the normal and PrepareForDestruction paths

Although this code appears to always have been wrong, it is just
that it is being hit much more often now.

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

What happened is:

- the paragraph was split into two lines, at the correct position

- but then the first line checked how wide the tab portion can be, and
  there it concluded that it has a lot of space, so the tab portion was
  1418 twips wide, instead of the expected "almost zero" 69

The root of the problem was that first the text break was determined
using the TabOverMargin rules (more horizontal space), but later a check
validated the result ignoring the TabOverMargin flag (less horizontal
space). Fix this inconsistency by using GetLineWidth() in
SwTextPortion::Format_() instead of manual calculation.

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

Change-Id: Ibc0dc42f3df8c5a4acc1ccece5a4ef63bd04fd39
Reviewed-on: https://gerrit.libreoffice.org/61405
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

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

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

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

We want to store the alpha channel in BitmapColor. To achieve this
we can repurpose bIndex attribute for alpha. Generally we don't
need bIndex at all as we can infer if we use index colors or not
from the context (using palette or not)

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

* Update helpcontent2 from branch 'master'
  - Uppercase function MUNIT
    
    Change-Id: Ife835065f29789785d5382081c2ebecb576e34dd
    Reviewed-on: https://gerrit.libreoffice.org/61407
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

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

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

Change-Id: I0fe6a0b8987fb3c3229c5aabcbf056cfb365650c
Reviewed-on: https://gerrit.libreoffice.org/61373
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>

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

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

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

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

In this case a generic ImportInfo property set is created in
XmlFilterAdaptor::importImpl(), so the XMLRedlineImportHelper
is responsible for setting this.

Change-Id: I6ec7ab2bab3ee10a585af88effb74f465e4bbae1

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

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

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

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

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

instead of hand-coded hash table

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

error: ‘sprintf’ may write a terminating nul past the end of the destination

(Why does GCC8 complain about this now and not before?)

Change-Id: I62cd9dec02d313b5aff1afc4cadf38ca1909ffb1
Reviewed-on: https://gerrit.libreoffice.org/61381
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

A mix of clang-format and manual.

Change-Id: Ice3d96d1400329fc7386e2d4544c69641658600f

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

Change-Id: I006a16cfc83e5b03408a2e772e752bb210901686
Reviewed-on: https://gerrit.libreoffice.org/61380
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>