This test is already disabled on non-Linux, but it fails in case there
is no display to use. For now just disable it in that case.

Change-Id: I29c52e803a1fca5f2bdeeb655c573ad8fef622e8

Instead, act as if it was true on all platforms. Don't do XOR clipping on any
platform. Simpler code is better code, and XOR tricks are generally very much
out of fashion these days, I have been told. Didn't seem to have any visible
ill effects on Linux at least.

Change-Id: I6192006c77a4a81363ec7b3292f72d512d5e9b53
Reviewed-on: https://gerrit.libreoffice.org/8901Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>

MSVC 2010 LTO triggers some bug in painting Writer documents;
unfortunately it's not possible to put a VCVER check in there to enable
LTO by default only for MSVC2012 because the compiler detection actually
uses the ENABLE_LTO value.

Change-Id: I29ecdd552d8a8bbd673a844e6bf0c938a98825c2

Change-Id: I7262f0114f3bde17d81e14e0813cc7906e73fceb

We didn't have EMF+ rendering testcases so far, let's see if it works
out to render into a bitmap and then just assert pixel position colors
there. It's better than nothing for missing shapes at least.

Change-Id: I2d1c63fef1127f69af7156ed6c99553845f77c9f

Change-Id: Ic720aa7b30bbe56d67e0b65f3e047ad3ae521a97

Compared to 4c8d29f4, we do not have to
provide 0 to mark the end.

Change-Id: I3b9a3de61df48caf271cb06b27cf9cfa174dc4ed

OAuth2Handler is from libcmis

Change-Id: Ia1986d6df7ab45580c66b4e536c5882af41f357f

Problem Description:
- In LibreOffice, the index field flag '\f' was not
  getting preserved after roundtrip as there was no
  support for it.
- '\f' field flag is used for Specific Entry Type.
  ex. In our case it is "Syn"

Implementation:
- Provided import & export support for Index field flag '\f'
  and added UT for the same.

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

Change-Id: I9d6e9df0b686c61597aaa0e194ab321445671a20

Change-Id: Icd3b57c4ae3dd79f4e57b72f9b241f15060322cf

This has been removed because it was unused.

Change-Id: If8fdf87cec1cd5fb5ee1924396643b152e6f3431

Change-Id: I1b846e79c2fdd718b7c67f39cb67ca2916520cb3

Change-Id: Ifd6a9897e3ebf978968efed79a478fa72cebe51a

Change-Id: I7cdc9b13fe950222521cb937e928da27ee55e866

Change-Id: If60a02f42a64ac60fb5be1072bf34efcbfa3cc6b

Change-Id: Ie3cfd1427dfe668c4cf682efa1f728dea764d277

Change-Id: I4d4780bdd8491c00140babc7651fc80a711bcf20

GetNextGlyphs could only deal with 1 glyph at the time
and was recalculing a lot of thing while iterating on the glyphs

This is not just a performance issue.. the notiong of keeping
per run glyphs information will be useful to re-establish the
proper support of glyphs display positionning by SetDXArray()
which today is completely ignored, in favor or letting
CoreText spread the extra free space itself.

Change-Id: Ib267c3e490619b650d4149f4b15b5758802942ba
Reviewed-on: https://gerrit.libreoffice.org/8879Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>

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

Change-Id: Ife3e8e4b339b3e2cba3bc81e14f616d75c4f5ed0

Change-Id: Icf3cc0ece477a1370d6dbf609e6b121075b3b999

DrawGradient should check to see if the polygon is a rectangle before
adding the gradient to the metafile. If it's a rectangle, we are
currently unnecessarily adding XGRAD_SEQ_(BEGIN|END) comment records.

Change-Id: I38aef322469f45403ed105d971d7e1d1441ba6a0

OutputDevice::DrawGradient doesn't check to see if it's meant to be
drawing a grayscale gradient when it adds it into the OutputDevice
metafile. Now fixed.

Change-Id: I83cb5255c01901e33ca1f751e91e8a77292663e6

Change-Id: I160a760a13c8e5140d6df295a9dffd05cf5e7b81

The bounding rectangle actually comes from the polygon. Therefore, it's
not needed. Removed from the following functions in OutputDevice, et al

+ ClipAndDrawGradient
+ XORClipAndDrawGradient
+ ClipAndDrawGradientMetafile

Change-Id: I4a87edcddb8895871982f0448854e1c0854124bc

Change-Id: I937d83e8c219bb1b672ec0b8b40204d9b20c8317

Change-Id: I9eff260046a08890629b41188082f196d547c734

Change-Id: I955e0dd7253c19ef7d6dad1c663bbcfd27d2b511

Change-Id: Ibd42c70edbd8a5ca5eba34bcb92e801c8dc97ba0

Change-Id: I637e84ae7fa82f687eb3f05b3e24e236f0ba8e3c

Change-Id: I75a88c9fffb3d2d5c6c12e6df89ba85a8eb92d34

Change-Id: Ifeeed4216275f944e61579408c77ae38945e60fa

Change-Id: I17a9c275743208dcb90075b0cdbd40caae3ab642

1. Fix regression 8659d189 - rect. gradients no longer do grayscale

In commit 8659d189 I swapped the passing
parameters going to ImplComplexGradient and ImplLinearGradient from
aGradient (the copy) to rGradient (the original which didn't have the
grayscale applied).

2. Fix regression 954d7ad4 - grayscale applied at wrong time

In commit 954d7ad4 grayscale was applied
in DrawGradient (Rectangle &rRect...) after the gradient was written to
the metafile. I was attempting to bring it into line with what
DrawGradient (PolyPolygon &rPolyPoly...) does. However, it remains to be
seen if that's actually doing the right thing - so best to revert this
as in all likelihood I may have caused a regression with grayscaled
gradients

Change-Id: Id94549b3366adb8fcf3cddc59d30029579430a30
Reviewed-on: https://gerrit.libreoffice.org/8908Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>

...unused ever since at least fd069bee "initial
import."

Change-Id: I6ec792b68ce6b13b1cf074d9719a23daf3356e66

...left over after 66e45400 "aDataAvailableLink
in SfxMedium was never called."

Change-Id: If2cfcc27f2b26ea3c950c2da1c673df940d94773

some more investigation into why bare language
autocorrect files are accepted needed but this
is a reasonably safe backportable to 4-2 fix

Change-Id: Ia294219e3c9d98710c6727238cedc15b040b408d

Before, all selection was recklessly replaced when you clicked something
else than a scaling handle (or the like).
It caused bug 69157.

But now, you can still drag the frame by gripping the interior one.
Btw, that the timer did not correctly start was because of the return
statement in the prior state.
Signed-off-by: Lennard Wasserthal <Wasserthal@nefkom.net>

Conflicts:
	sw/source/core/uibase/docvw/edtwin.cxx

Change-Id: I5e02cfb2d5fe9cdb9fd7f50d0c961dcc418fadd6

Change-Id: Id9e29dcaab64b0244b5c53abb48ac27253a11917