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

this time the missing cells are on the left

Change-Id: I55a5aa60c8d06b25b0c48b3f6a683694adca8e6a

only allow for Calc functions NETWORKDAYS.INTL, WORKDAY.INTL
for compatibilty with Excel

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

Change-Id: I44f1969a227a811cdb740b387e30cf10994360b9
Reviewed-on: https://gerrit.libreoffice.org/15445Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>

Regression from commit 1f77a5e8
(n#203704 fix RTF export table output for subtables, 2012-02-08), the
problem is that RtfAttributeOutput::StartTableRow() has two callers
depending on if it's the first or a later row, but the m_bTableRowEnded
flag storing if that method is called is only set in one case.

Fix the problem by moving the update of the flag to the method itself.

Change-Id: Ieae1fb53f9528fc74d037d2fd783b3979b17cab8

Change-Id: I456669f15a659e144fc6ecad053cd0b929859424

Change-Id: Iedaddf11604b13c7db1d2b588a5f205f691ea2b4
Reviewed-on: https://gerrit.libreoffice.org/15440Tested-by: David Tardon <dtardon@redhat.com>
Reviewed-by: David Tardon <dtardon@redhat.com>

Change-Id: Iba9f6923e2e7cfefe980a97d7c1cd35e01f437fa

Change-Id: Iec781bdbbf216cb14c9ba5be5955123273d7699c

Change-Id: I14f5e9abe63954141f1711115f884db68282d94c

Change-Id: I3c0d7560d9a47123ca98f72c0319fcee97894913

This also renames member variables with the m prefix, drops
a couple of private functions which were called only for
lazy construction, and stops persisting in futile const-ness.

Change-Id: Ia4d1aded294f6b22a25a7cf40eb37418d45c9f0b
Reviewed-on: https://gerrit.libreoffice.org/15359Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Idf747fb895c15e8df96a6ced06cf9f0df5d35e39

Change-Id: I9ad1aa651b6971526dd924630fe5606b7632f2dc

Change-Id: Id9fad922622881d29664d2149b74c98742a4e88d

Change-Id: I2f9d151449d5f58cd553f28b98c2aabfbb204dd6

Change-Id: If1cdc67535b11d9309503b14ffad2aa3718661c6

Change-Id: I22a5b9fa29d465a21e682279e6e88d37bd8adf93

Change-Id: I29d29e06a17167e9fc2d3caf40084e80274dae72
Reviewed-on: https://gerrit.libreoffice.org/15419Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>

Change-Id: I9fad024e4b5c8a4ca272f2387df07351198cf5dc

Previously SvxHyphenZoneItem was serialized to some custom RTF extension
that even our own RTF import ignores since LO 3.5.

Change-Id: Ia99d9750ad0b1a07105eeef2bee07e6fdbfe7876

Change-Id: I2a1d0e194af6eb5fb865d3ed26712eed09a3b28f

Change-Id: Id0f0c7d692410cf5e1477c5180e7cfb8e7b0f52b
Reviewed-on: https://gerrit.libreoffice.org/15345Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: I84a2581429b1453a5e2ba896402dc6b687cad0c4
Reviewed-on: https://gerrit.libreoffice.org/15379Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Yousuf Philips <philipz85@hotmail.com>