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

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

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

Need to use "" for call.hxx include

Change-Id: I9a30f3d3cfab83076f9ad22a5b637f8f4fc7c432

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

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

test xTextPortionEnumerationAccess before trying to use it
bt:
0x00007fffca9201e6 in SwEditShell::CollectAdvancedClassification (this=this@entry=0x55555790c710) at /home/user/libreoffice/sw/source/core/edit/edfcol.cxx:804
804	        uno::Reference<container::XEnumeration> xTextPortions = xTextPortionEnumerationAccess->createEnumeration();
0  0x00007fffca9201e6 in SwEditShell::CollectAdvancedClassification() (this=this@entry=0x55555790c710) at /home/user/libreoffice/sw/source/core/edit/edfcol.cxx:804
1  0x00007fffca927e8c in SwEditShell::ClassifyDocPerHighestParagraphClass() (this=0x55555790c710) at /home/user/libreoffice/sw/source/core/edit/edfcol.cxx:1722

Regression from b480d5e4

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

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

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

because of addToUnoRc and addToConfigmgrIni which use push_front
(and no easy way to change this), I couldn't use vectors

+ use for range loops

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

Change-Id: Ib02986e5b3d54d65982836e22ebcb70eb7a0e7b3
Reviewed-on: https://gerrit.libreoffice.org/44216Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

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

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

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

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

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

Change-Id: Icd33bbe415f321a82a52364aa93ba6cf4a28507f

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

The problem is that we don't render ShapesWithWrapping.odt
the same as Word does:

https://beta.opendocumentformat.org/rendercompare/upload/223/86/191/1

The first shape in the file is anchored "as-char" and has no
style:vertical-rel or style:vertical-pos attribute affecting it.

If Word would write either style:vertical-rel="baseline" or
style:vertical-pos="top" explicitly, the rendering in LO would
be the same.

So the problem is that, for drawing shapes (note, text frames are
images, embedded objects handled differently), LO's default
vertical alignment is different, it is hard-coded in
SwShapeDescriptor_Impl::GetVOrient() as
SwFormatVertOrient(0, text::VertOrientation::NONE, text::RelOrientation::FRAME)

This effectively positions as-char shapes *below* the baseline,
which, while technically allowed, isn't really a good default.

So fix this by making the default alignment dependent on the anchor
type, so that as-char shapes sit on top of the baseline.

The ODF filter sets the anchor type before inserting the shape in
XMLTextShapeImportHelper::addShape(), however as it turns out the
various MSO filters insert the shape before setting the anchor,
which means the new default in SwXShape has an unwanted effect
on them, as inserting the shape causes the default to be created.

This requires changes to VML import to always set the VertOrient
property, and to RTF import to set the anchor type before inserting.

The DrawingML import is unaffected as it already sets VertOrient
for every non-as-char shape.

The testDmlTextshape "dml-textshape.docx" test still fails, but it
turns out that the change in alignment for this test document is
a bugfix, as it now has the same vertical alignment as in Word,
so adapt the test.

Change-Id: Ifcabd96a037515f7803f5474ec995f968b3b4de1

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

reported spike in load time, so still necessary I guess

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

annoyingly was getting different order on oss-fuzz vs normal case
making things hard to reproduce

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

allow SDK 11.1 alongside 11.0

Change-Id: I0ad3c47ebccfac90fe7ae9101781c91a0fcd5fba

Updated settings to new xcode

Change-Id: I04eed7eaaf02dda69b4dbce7376b883478b78d27

compiling with bitcode slows builds process

Change-Id: Icee263652d31f3a7a6e92a91ef5320a804d0bef1

Removed compile of dummyLO, meaining full link is performed
(to test LOkit_open)
Removed faulty properties in property view scene

Change-Id: I980cadaf98d40f3e497ee6aa69cb6166fa1b87f7

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

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

Change-Id: Iaba95e2cfb6b34ab3ad04f96dd2c8e2c12115d95

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

Change-Id: I722ba0ab1e056904c55b4ad6cdec6f26fa3b723d

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

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

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

Change-Id: I931f0d95cad0a63d344c84d89ba7c80f14be8ec9

...between "error: unannotated fall-through between switch labels
[-Werror,-Wimplicit-fallthrough]" (in some builds, for the original code) and
"error: fallthrough annotation in unreachable code
[-Werror,-Wimplicit-fallthrough]" (in other builds, after adding
SAL_FALLTHROUGH).

Change-Id: I75bbefd69c81f43f22117f8ad110237de24e18af

CellStoreEvent remembered the original ScColumn* and corresponding
ScColumn::mnBlkCountFormula, hence after inserting a column to the
left the quick check of ScColumn::HasFormulaCell() whether there
are any formula cells worked on the swapped in column (originally
the one to the right) that happens to be empty in the scenario.
Things worked correctly by accident if the next column to the
right already contained a formula cell.

Regression from

    commit e57a5905
    Date:   Sat Jul 16 20:01:48 2016 -0400

Change-Id: If993856ceee657736f516a81c293506041a6b7eb

Change-Id: I004bcba518ead9c149f1671d62aa94986a38945d

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

Change-Id: I96636cbff097af77bc0ccd669b6a973c282f7360