Change-Id: I5ab147c8b737396db6371b9d92e7f19955ed7f28

Change-Id: I16d5772b0f8455518866cb03729e9bab95be8087

Change-Id: I983a24964f71967f1c0fdbde6dde0524d8c3456c

Change-Id: Ib3dacf63db01649992c7fe7571b54f964202fc3b

Change-Id: I5be4cfb951100d36054e409043cb9becbe52338d

Change-Id: Ibeace7ce7621033cf04e3186c212bbb4a27492a1

Change-Id: Iaab5763d4fbde431bac6f7ecbf4527ad889b6891

Change-Id: I0244f12f1ee2e61ac577222a14b011aee5ddbd54

Change-Id: I2801f54cecf9c8b7d43f8e1c1699cfd7fdd918e3

Change-Id: I5fca36f79aa98606770c77dad5b757288bd47842

Change-Id: I63e2f5055a87593708f672341b5849554b4db6fb

Change-Id: I5350322e5c957127fe125e633b31b2492410995e

Change-Id: If1b2bfe308caa2bce92e73d2c5c86ee273faed93

Change-Id: I4c4294b7fb1cb537ba3ae3e6e7e747a3333b7469

Clang (at least the one from newest Xcode 7 Beta) warn both that
fResult "is used uninitialized whenever 'if' condition is false" *and*
that the very same "condition is always true".

Change-Id: I9e2424e7323046edbfe1af3c9f960df49e0809dd

Change-Id: I1b05edc954125e5bdeed05b5fdce1430f8eaba26

Change-Id: I0e3d6f00a79bc33e1db1329df217e7e867dfd511

Change-Id: I4c06290f09e5bfecd2c1de896e19cb5036a3a0e9

Change-Id: I1ba5583d9121b541b6b76588f1334980abe3836e

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

Change-Id: I69f45dd2d7426ecd99dca7e80e98e95c3e52d4a0

Since the gradient frame backgrounds were added in LO 4.1, we export
this:

 fo:background-color="transparent" draw:fill="solid"

Which doesn't make a whole lot of sense as this is really a "none" fill,
and now with the backward compatibility stuff in the style import code
we get the pool default color added when setting the BackTransparent
property, and with the draw:fill="solid" it becomes visible and the
background color is now Sky Blue 1.

So try to detect draw:fill="solid" without draw:fill-color attribute
and contradicting transparent legacy attribute and nerf it.  This way
we also export draw:fill="none" again, although still with a bogus
draw:fill-color but that shouldn't cause any harm.

Change-Id: I1c2bea46ba7d9a3f042b875df0ca12c7f6037909

... frame/paragraph backgrounds.

If a style is set to have draw:fill="solid" and a derived style to
draw:fill="none" then the derived one must have
fo:background-color="transparent" to override the parent for old
consumers like LO <= 4.3/AOO <= 4.1 that don't understand draw:fill.

Change-Id: I5b56c7ace927338239195c6bfcfef1950544c8d2

The problem is that if the FillStyle is NONE, setting only
ParaBackTransparent but not ParaBackColor does absolutely nothing.

This means that if a parent style sets a background color, then a
derived style cannot override it to be transparent.

Cause is that getSvxBrushItemFromSourceSet() defaults to setting a
0xFF transparency on the SvxBrushItem.

There is still a problem that getSvxBrushItemFromSourceSet() sets the
pool default item's color and that is also exported to ODF again as
draw:fill-color, but together with draw:fill="none" it should not cause
harm, at least for consumers that prefer draw:fill attributes like
LO >= 4.4.

(regression from 7d9bb549)

Change-Id: I5312901166a0e6f0cf02369b173dc8498e4113ed

Change-Id: I736964e0ae1419de212a7b608377804c764443e7

Flat ODF Import does not use SwReader but uses
SwXMLImport::startDocument() and SwXMLImport::endDocument() to set up
the document, so make sure those set the import relevant SwDoc flags.

Change-Id: Ife3e58eeebd73ad895fe328662822b847cf9bfec

coding conventions.

Change-Id: I36c11a979f7f003bfdfff766940a7832fd19e906

Change-Id: I5befe9deac917a28e80ed193b67ff29b5ba35149

Change-Id: Iff5ef2a5b2315b19cf8f0e84a08c776c3c97e0ae

For example, "B2:" or ":B2" were accepted as valid range, with the
missing part set to A1, which resulted in a A1:B2 range.

An omitted sheet specifier always results in a valid relative sheet,
hence that flag is set, so testing flags for non-null before the final
result is available isn't sufficient.

Additionally this revealed a flaw in handling of external references
when loading documents if the original file name differs from the
resulting real file name due to relative paths.

Actually now the displayed file name matches the real file name when
such a document was loaded, where before the original file name was
displayed.

Probably such references didn't even work before if the reference
spanned more than one sheet, which is a rather rare case for external
references.

Change-Id: I38035f2e4b3a11c0280457498cf62b02f882d2a1

Silence the glibc compile warning and actually handle a wrong
return value.

Change-Id: Icdbc8e655d4b8ad20699dfd0abdbf3405a49f898

Change-Id: I4c8e2e62943171a001036ea46fbfc83f92a2b1d8

Project: help  550b03030e494f8c0fd1161cbdeea3d8e5b954e5

Fix typo

Change-Id: I1620c3507722d8aeef11d0480f07bc104b9a7f95
Reviewed-on: https://gerrit.libreoffice.org/18032Reviewed-by: Olivier Hallot <olivier.hallot@edx.srv.br>
Tested-by: Olivier Hallot <olivier.hallot@edx.srv.br>

...which had apparently been unused ever since the function's introduction in
86ef4422 "INTEGRATION: CWS onlineupdate3," even
though the function's code had always been careful to clip the value to
m_aAddButtons.size() (which was now detected by clang-tidy's
clang-analyzer-deadcode.DeadStores)

Change-Id: Ic3542aaef04d059125d997cdc5e199d5edb1184a

This reverts commit ed6209f5, plus follow-up
18a2a642 "unit test that parsing range fragments
should fail."

Breaks CppunitTest_sc_subsequent_filters_test

Change-Id: Ic4663d79bf4bc017094bc37779f74f30630d79bd

Change-Id: If361620f18a6e8ff433feb8819eeb27b39652529

Just invert the scrollbar the same way gtk+ does by checking the
button positions and adjust the drawing style accordingly.

Change-Id: I3475c33e074c1509a73da618a4efa44dc61a1a77

Change-Id: I848b5a8834212fce1089fb3ef2186424a1e7a11e

Change-Id: I14c7e2245e1333a7cc3c372b29f4a3b679169209

Change-Id: I89f27286386809059e193004bfa0acecf692b99d