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/8901
Reviewed-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
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
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/8839
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
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/8879
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
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
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
1. Fix regression 8659d189ec - rect. gradients no longer do grayscale
In commit 8659d189ec 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 954d7ad4ea - grayscale applied at wrong time
In commit 954d7ad4ea 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/8908
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
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
It seems to do more harm than good. Using the default avoids some yet
not found bug in vcl (or somewhere) and fixes the rendering of some
complex SmartArt test documents. (As long as the use of delayed
rendering for "graphics" in svx is also disabled.)
Change-Id: I0ed4b25278101bdd995ce90e8fb65f65ca644ebe
