Change-Id: I21084eb053c04cb5be5de586ee506cc6e5d97b04

Change-Id: I3cda1a74695aefa34f2749b29af5409db83f2946

Change-Id: I7d40663162a907e2bc7280167e311e4d577c3863

Change-Id: Ied92054db1daabf7342cb6455bcf5edfc80bc6a1

Change-Id: If4faeb8e9b8344ac8b7bf6057c89ceaa503ebefe

Change-Id: I762383de76ecbabc867ebf3fc9128287421f9c6b

Change-Id: I97df89d60add869ea8277295580f880284f29358

Change-Id: Ic3f3f671098a173e05da26c53e3e50fafdf3fd1a

Change-Id: Ide059f320e45080278e0c1723c81b26c0bbad506

Change-Id: I67f6c6e433402ba610f39b7fa4ee50a8cb5295fe

Change-Id: I931eca79499c566e953abeca0b9ba451937e5a33

Change-Id: I9980b280236f858e6c88ef4ef0ba8cb9d2750b0e

Change-Id: Idfccaaf3443f15699f6fab38bd89f7874698d6c1

Change-Id: I54a3eed05702bdfe1e1c625df6463399f38e9180

Change-Id: I7591402f4cea59a41afe1ae010cf34ab8627c8e0

Change-Id: I277bdd76e79310992bbf645d9e215f4dbba47554

Change-Id: I846783ab4c4718eb82fa99458cdffd861b5bf03d

Change-Id: I4262b31978b9c932cc33b5442cf731f7f45cadc3

The rendering looks correct and I think the new code is correct but did
not understand why the assert was triggered now.

Change-Id: I3e08bc507a69de447f633cd1be9787f59348cffe

Change-Id: Ic3c83e670472a8882eddf8b4d29cf148a8e73d0d

Change-Id: I679b2a4597e37f1e902b85ea5239df0eec33fa8b

Change-Id: I50ffc3419938dbf3bfef2a83d8148e495ce649cf

Change-Id: I94758b6462c589b1f7eea9bac634e2f33646651b

Change-Id: Ic10025f8b27c87ae40f62cb04653cc8e6abc7fc1

Change-Id: I2968541be05aafbd39a161b48d840f7be66deee1

SvViewDataEntry is provided to the item when painting. If we send
the whole rect to the item, it can make better decisions when
painting. Extending or changing the method contract would be too
risky so send this information this way.

Change-Id: I985680a8d053990d992d77e4310853321c0de787

StyleManager is a new class responsible to handle document styles.
The current implementation has only the responsibility to provide
a implementation of StylePreviewReneder, but the idea is to move
all style related functionallity to this class (and relieve the
SfxObjectShell a bit). CommonStyleMAnager is the common impl.

StylePreviewRenderer is responsible to render a preview of a style.
As styles can be handled differently by each component it is
possible to provide component specific StylePreviewRendered, but
currently only the common one is implemented and used by sw.

Change-Id: Id271485f571a777a3e94f855d3c614a2efc14628

Change-Id: Ia29d45ed1fe41c986bf7d15d4da4557011544daa

... with style:background-transparency

(regression from 102bb87c)

Change-Id: Icead7a47c145eace51249896b6e05d65dfaa2f78

... bitmap backgrounds of frames.  OOo/LO versions <= 4.3 wrongly write
fo:background-color="transparent" style:background-transparency="100%"
for bitmap backgrounds, because of a stupid API implementation with
SvxBrushItem.  They overwrite that with draw:opacity="100%" on the child
element style:background-image, which we don't read if we see draw:fill
attributes, so ignore the background-transparency in that case.

(regression from 5aa360ca)

Change-Id: I4ca59d8932a8e5d034c35543a54528198ad7d51c

The emulation of legacy RES_BACKGROUND properties claims that (unless
fillstyle is NONE) all of them are direct values, which causes export of
legacy attributes like style:background-transparency without
corresponding non-legacy draw:opacity.

Especially problematic for style:background-transparency, which is set
to 100% if style is bitmap, which is the reasonable default for API
backward compatibility of BackColorTransparency, but wrong for ODF.

Change-Id: I1fa4fa5df45eb00cbfcd2e171b4862c4e195cc7d

Wrong type causes draw:opacity not to be exported from FillTransparence.

(regression from 6e61ecd0)

Change-Id: I478fc34dfb614f0433a6e28b0260379528b86680

as those are fake, just textfiles with dll extension that signtool
doesn't like.
Also made the text more descriptive "invalid" is ambiguous,
"invalid - merged lib" states the reason why the file is a dummy.

Change-Id: I31801fd0c3aa593549fac5e6275189e18bbc0010
Reviewed-on: https://gerrit.libreoffice.org/15444Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>

Change-Id: I5ab279a7d7af6829735b47ef5228f56dc77580c9
Reviewed-on: https://gerrit.libreoffice.org/15292Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

Change-Id: I7bc03f7ff3ec57317e7fbad4476874bac6c44877

Change-Id: I7cebaf1a2907f4beb10e128ea5d479df45c1e1c5

Change-Id: Ic7171f3b0c0931e476d8419257b33c760c6283a6

Change-Id: I93cd943f9b26e6e4bdc7c616e9fc7a46d07a9d91

Change-Id: I723e752ff4bab9e36b3f3a08fc1fe8d10511d774

Especially the 'using namespace std' is scary, now that we have
std::shared_ptr and boost::shared_ptr, too.

Change-Id: Ibb584281f1b9d56103ab5984473eb484157c12d5