Fix ignoring large twips values like MSO does (cp#1000087)

which was introduced in 10b4da63e3143108ba75891e9e98fdaa2f7953ab.

Since 1e47614cdb84b018a22a334dad0cdd9f0f53892c, only
convertTwipToMM100Unsigned() ignores large values, which presumably
was not the intention. At least commit message suggests so.

So, move the check back to convertTwipToMM100().

(cherry picked from commit 4d1621136c464b462a598571ecdcfe2ae119d8c7)

Conflicts:
	writerfilter/source/dmapper/ConversionHelper.cxx

Change-Id: I17040f1987e24789b9de39a837d9f7ecaed520fb
Reviewed-on: https://gerrit.libreoffice.org/10193
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
resolved fdo#80195 act on implicitly propagated error, if any

Change-Id: I1d5a55a14fc3e25edc2cddec5b53ed2afa96bd3e
(cherry picked from commit 1093b900b43d819c9a730ef6435fed0f3687a085)
Reviewed-on: https://gerrit.libreoffice.org/10198
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
fdo#80201: msfilter: fix infinite loop during export

(regression from 6c5557c60f97778fd732c01f054553356ce7f258)

(cherry picked from commit 86b9f03c3f754f7b753893ff2772f6b17bf3de3c)
Signed-off-by: Michael Stahl <mstahl@redhat.com>

Change-Id: I75bfafbc7343aaddbbc5c7433e28b5d4154177dc
Related: #i125226# don't try to access known-bad DDE servers

(cherry picked from commit 88de6a59d9d7933b86fdcba733277aa4fbd5e132)

Conflicts:
	sfx2/source/appl/impldde.cxx

Change-Id: If4dcd49cfe15188d06e4e06cd8e58cdcc66ed5a4
(cherry picked from commit b16f164650f8345e51bf0b0c73bf9c8eee775bc2)

Related: #i125226# some macro preferences are directly...

applicable to DDE servers

(cherry picked from commit 2c835e761e1e9ddb6794895e6f3538b918160dd1)

Conflicts:
	sfx2/source/appl/impldde.cxx

Change-Id: Ic16b3df34ac1b003a8a5cabab15ea655d05bdd18

Related: #i125226# typo fix

(cherry picked from commit 727ea069c6342e01a50c8b068ec302574b251cbd)

Conflicts:
	sfx2/source/appl/impldde.cxx

Change-Id: I8db53b7e8529d05e660a2d69e669b44c9045712c
(cherry picked from commit 13b68e24db26374ca17572de9abb429edeac32e9)

Related: #i125226# disallow absolute and relative paths for DDE servers

(cherry picked from commit 6b64ada6e3a902ac4b44fe49476514d49138d4d4)

Conflicts:
	sfx2/source/appl/impldde.cxx

Change-Id: I127add375a127dbbd0eaf12a10884e2636f1a332
(cherry picked from commit d1fc47793c1efbe9ff5271656283211647dd0b33)
Reviewed-on: https://gerrit.libreoffice.org/10202
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
fdo#80462: Don't always increment the start row position.

Sometimes someone might attempt to sort only a single row.

Change-Id: Ie29d4cf7ec0bd3a5c945997083368b6ef6074268
(cherry picked from commit 5902dcf0995cdd0a6c1dbd1f9c21b0b2b3f5609f)
Reviewed-on: https://gerrit.libreoffice.org/10260
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
fdo#81214 - tolerate exceptions thrown inside XFastParser callbacks.

Not an ideal solution; ideally we should not throw the exceptions,
and stop the parser as soon as something bad like this happens; but
hopefully exception throwing is reasonable exceptional.

Change-Id: If619592533b2929c671e2b03eb8a83480bd92c54
Reviewed-on: https://gerrit.libreoffice.org/10289
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
sd: stop calling graphics styles "Image Styles"

(regression from a71a562a9958fc58a5fb914bcf7f8056a353f618)

Change-Id: Ie3a44a80c720f59831bc2b1da91792fb8aa24d62
(cherry picked from commit b55b96589f7fe0b2f426c2472da7174ab95aab87)
Reviewed-on: https://gerrit.libreoffice.org/10307
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
fdo#81284 Don't write to zero length files

Change-Id: I4eddcda3977f43b39abdaa8d9089ff661092361c
Reviewed-on: https://gerrit.libreoffice.org/10310
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
Resolves: fdo#52226 swap in graphics on .docx and .rtf export

(cherry picked from commit 9dd5caac62083f7162d83319284df68ee83e3777)

Conflicts:
	sw/source/filter/ww8/docxattributeoutput.cxx
	sw/source/filter/ww8/rtfattributeoutput.cxx
	sw/source/filter/ww8/wrtww8gr.cxx

Change-Id: Ie818b382c0b17760c720ff2f2c73a3697989f97e
Reviewed-on: https://gerrit.libreoffice.org/10296
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
Related: fdo#52226 ensure graphics are swapped in on DrawingML::WriteImage

I imagine it would be best that the Graphics were delivered pre-swapped in by
higher levels in case there are second level caches or more complex caching
systemed wrapped around it, so warn about it in debug mode but give it a
last-ditch shot anyway. i.e. while the .docx problem should be fixed there
is a report of a very similar .xlsx problem

Change-Id: Ie40ee10fe5cba8ff9c321f47b83e33ee2c1425fd
(cherry picked from commit 6e580f3f53ae2de086a08c8ba1958b67874eb9c5)
Reviewed-on: https://gerrit.libreoffice.org/10300
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
fdo#78554 - SVG: Text from SVG no longer displayed in LibreOffice

regression of 3b7472b284131c09d91b69f26d5d26d54648f939

Change-Id: I95a30acbf4b2684dda9684f5b51b887356a940e1
Reviewed-on: https://gerrit.libreoffice.org/10304
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
fdo#80498: vcl: Revert "fdo#74124: Scale the pictures before calling ...

... ImplDrawAlpha()."

This reverts commit 3cf3700b7a903e88f5296076c40ae854bce91cdc.

It may look nicer but is unusably slow when scrolling in Writer.

(same as master commit ee36fc7add892690c95a969530ecdcfc1bc9decc)

Conflicts:
	vcl/source/gdi/outdev2.cxx

Change-Id: Ieb3d0b9dedeb3f1688eb30668e59750f3b569d9b
Reviewed-on: https://gerrit.libreoffice.org/10205
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
fdo#81173 abi#3623 RTF import: missing null pointer check

(cherry picked from commit 08fb25ab7941c52d4eed0435a45a38b03aff588c)
Signed-off-by: Michael Stahl <mstahl@redhat.com>

Change-Id: I5861e5fec0d822f42dfeb994500a818a968e69fb
bnc#862510: Improve handling of OOXML gradients

OOXML gradients can have an arbitrary number of "stops". LibreOffice gradients
have just a start and end colour, plus an optional uniformly coloured border
(on the "start" side). In addition, LibreOffice has the "axial" gradient mode,
which means the gradient is reflected in the middle.

It is thus obviously impossible in general to losslessly map OOXML gradients
to LibreOffice ones. But let's try a bit harder than earlier to get visually
more similar result, in at least some simple sample cases.

We look for the widest gradient segment and use that for the start and end
colours of the LibreOffice gradient.

Also, map an OOXML gradient to an axial LibreOffice gradient only if it is
symmetrical. Also, use the border property when suitable. In general, look for
the widest OOXML gradient segment (once a segment corresponding to the
LibreOffice gradient border, if any, has been accounted for) and use that as
the LibreOffice gradient.

Possibly some perceptionally better heuristic should be used... Like, if we
have a three-segment gradient, with a wide gradient segment between two
visually very similar colours (for example, two shades of red), and a narrower
segment ending with a visually very different colour (for example, yellow), it
probably would be best to represent that in LibreOffice as a gradient from the
first red shade to yellow, instead of as a gradient between the two shades of
red. Or even, if a first or last gradient segment is between very similar
colours, equalize those start and end colours, thus using a border colour in
LibreOffice instead. The possibilities for bikeshedding are endless.

I am sure there are instances where the old code (by accident?) produced
visually more pleasing results... But hopefully this works more pleasingly and
consistently in a larger number of cases.

Change-Id: If153e986ad943454307e3ba718479d5ac4cdc7ab
Reviewed-on: https://gerrit.libreoffice.org/10359
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
Do not prefer bandRow over firstCol/lastCol, nor the same with bandCol.

Change-Id: I0c573d721212c870e9ecc99ba5e8494073e09aaf
(cherry picked from commit 5d2f12a44d2af3e42e0c3a17ff556f5ada27b1b8)
Reviewed-on: https://gerrit.libreoffice.org/10330
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
bnc#887225: OOXML import: Correctly apply table style for lastRow.

nMaxColumn and nMaxRow are indexes, so use size() - 1.

Change-Id: I20055e55cf2464710fe553fb8067bad13a339084
(cherry picked from commit 47645734c350f244b4a5642a709132ca1b7dc75d)
Reviewed-on: https://gerrit.libreoffice.org/10329
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
resolved fdo#81294 store correct sheet number during range names update

Change-Id: Ic4c858efa6e7c1a65357ac79f01e6c08f464ae3f
(cherry picked from commit 4011b74eb7650a0eeb99d3acebb9ef60b0fcaab9)
Reviewed-on: https://gerrit.libreoffice.org/10376
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Tested-by: Kohei Yoshida <libreoffice@kohei.us>
use rtl::math::round here to get the same number on 32/64bit platforms

This fixes sd_import_tests where 100*0.35 was 34 on 32bit platform.

Change-Id: I45705326e91892beb814bd94e074b0a652709768
(cherry picked from commit ba6da9545764f2545313ba085ed4a096165180fd)
Reviewed-on: https://gerrit.libreoffice.org/10382
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
fdo#78598 avoid use of invalidated pointers

Change-Id: Ib81f79da696b5e8002f5a2ddcf160903231dc3f1
(cherry picked from commit 6b127d40c7d57745bc602d9ff7914392f9d3b92b)
Reviewed-on: https://gerrit.libreoffice.org/10421
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>