Differenciate when gradient is defined in the text element or in its parents

Add unit tests

Change-Id: I85b09f72fbb1a3c8d2fa7350b4396b5bf924277f
Reviewed-on: https://gerrit.libreoffice.org/22131Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
Reviewed-by: Xisco Faulí <anistenis@gmail.com>

When image was rotated towards 90 degree the ixscale and iyscale
went towards infinity. That caused problems in fragment shader
areaScaleFastFragmentShader. The problem was with calculation
of destination width and height which didn't take rotation
into account correctly. This commit takes this calculation
from WinSalGraphicsImpl::drawTransformedBitmap.

Change-Id: I30f14a1ecda21ef167e58eda8e2fcef00bdfa2b7
Reviewed-on: https://gerrit.libreoffice.org/22289Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>

Change-Id: Ia108d3d4db2a2f05d306da55a59520e9471bb336

OOXML export will need an SHA-256 hash of the certificate, introducing
a css::security::XCertificate2 just for this would be probably an
overkill. The same will have to be done in the mscrypto backend in the
near future.

Change-Id: Id2df06416a713927edd60e1253ff8e1c09dd706a

Again, just to help the exporter not loose information.

Change-Id: Icc729d6a58321695fa59e009a328fca56d5ef514

This is redundant, but it's needed to survive an export -> import ->
export flow, and at the end required in the OOXML result.

Change-Id: I0779950b6464b4e15f4da452c163cddbc3d03a3d

Change-Id: I43762aa8b572651676d8cac4848d4c6d478cf850

19ec3c5e "firebird compat issue with macosx
10.11 was fixed by sberg some time ago" forgot to turn this back on when
reverting 9af1331c "For now, firebird doe snot
[sic] build on macosx 10.11."

(But no, firebird still does not build out of the box on Mac OS X 10.11, one
still needs to pass into the build a non-broken SHELL that does not filter away
DYLD_* env vars.)

Change-Id: I17321893a08d1f2a129ee14bf4f4453ff64ad2ad

Change-Id: I78f28906c3ceae323b608018f929c66358e9aa39

Change-Id: I8f2a2910993609dec91e63074a5b9195a2352bb5

Change-Id: Ib35b5d2f352606208471262cdc69da136e88275f

Change-Id: Iad6bb5ba62d114ca760c4215aa8eec872c5d181b

Change-Id: Ie9bbce6892fe1dcf55e23028e68037f996d7c71f

Necessary for unit testing.

Change-Id: I8db8b4c469864a915a00f8d8c4932634d74f11a7

It is consumed by the saveAs() itself, and when provided, the document
identity changes to the provided pUrl - meaning that '.uno:ModifiedStatus' is
triggered as with the "Save As..." in the UI.

This mode must not be used when saving to PNG or PDF.

Change-Id: I11b5aa814476a8dcab9eac5202bd052828ebbd96

The LOK does not have to be fully initialized, eg. during the unit tests,
don't use the interaction handler in such a case.

Change-Id: I11bb8db37c92b05e2c1ad06e1a6632db7fb0ea60

The same extern declaration is already in alloc_impl.hxx which the
source file includes earlier.

Change-Id: Idacadc8cf938d88892c99b1af3723c52fcae5298

todo: get rid of the rest of the getStyleContext foo
in favour of additional createStyleContext entries.

This appears to now render fine on f23 and f24.

upstream gtk now has a foreign drawing demo in gtk-demo. Stuff we are trying to
do here can be found in a cleaner single-version state there. And additional
demos can be added to keep a reference of how to do this crap up-to-date.

Change-Id: I5ae1a52a2cacc6d8178ed1af30a12536ba828050

Change-Id: I7b23442b34c7f2dcc2c44c33613fb66e6eb1b14b

to simplify the normal control flow

Change-Id: If325ec0507a51d8e2d3340fc5b628bb75a078a44

Change-Id: I3274106d4459532145aaa9222df0e9d715cf59fc

Change-Id: Ic8d8c7df54bd9debea3b9601d9c8d67b0412b5ab

Change-Id: I0164e546b0ee0b40acc7b9253d3c0ecded97280c

Our own importer is happy about the export result already, but MSO is
more picky, and mandates the correct content types for both
_xmlsignatures/origin.sigs and the individual signature streams.

With this, MSO can open the signed file again (while previously it just
declared the file corrupted), though it still declares the signature
invalid.

Change-Id: I199ad96bb91e7ce03fdf1f10f9500db4e05bb5c1

commit 764752f5
"better import xlsx heights" left some unused code

Change-Id: I1bc0210f65a1e0c3cb16f86145b874cbca53f151
Signed-off-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
Reviewed-on: https://gerrit.libreoffice.org/22013Reviewed-by: Justin Luth <justin_luth@sil.org>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

The problem was that the final export lacked the "#" prefix in the
same-document reference names. Fix this by doing what the ODF export
does: don't let the signature informations (data model) contain the "#",
just prepend it right before writing the name out.

This way it won't matter if the source of the name is an import (which
doesn't keep the "#") or a new signature (which did, previously), we'll
always write exactly one "#".

Change-Id: I18b6a5ba55b7e79ace537b7ecf575a7abc71e281

Change-Id: Ia24a1b64d4adfc0db537704779ca25cfd86cac8f

The root cause (and that still needs fixing) is that the OOXML signature
export fails to start same-document references with a "#" character.
OTOH, even if that happens, it's better to throw uno::RuntimeException
in UriBindingHelper::OpenInputStream() to avoid std::terminate().

Change-Id: I9c9c211de36fb0aeb2c33f62b094c9f4d9c85b3d

With this, _xmlsignatures/_rels/origin.sigs.rels and
_xmlsignatures/origin.sigs is written to the destination file.

Change-Id: I8d63a182e7cf05ed20195f88c90fba2a9a05379e

Project: dictionaries  86e206b136520e4e4952637851f05d104af53715

Updated pt_PT dictionary to version 16.1.3.4

Change-Id: Iceff55cf9d09817f8f857b687983fddfbffb5c56

Change-Id: I311eb27e3d287f3ef409cb54f19a152793f940d9

Change-Id: I0931ae0edfb45c5d4c67f545a1a5e513c8210e88

and start the process of moving the parsing code to one central file

Change-Id: If6d8def37ec8c8415c22d39f9d8b7a09ec423873

Change-Id: I74595786754381fef8105e3acfeb0f693bdbea83

Change-Id: Ic6464cd4d2c4fdb302f6337719ad937c0d3f8135

Change-Id: Ic1b0e13a8d77154fa780f6804ee36b5a5d9c7334

Change-Id: I8f70d6bde7018d5b4455f95373f1b7d5dbc4d76e

Change-Id: I8e4cf6fa936bc94db3f8a865731d00878354ad99

Change-Id: I5378478500a18b2d7156b7047867bc53f6513b45

Change-Id: Ic2f83fd4ff83795a77dd9b97b98e2635e5c447c0