When there was no modification to the document, and .uno:DefaultBullet was
sent, we have got an invalidtion of the entire document.

It seems that Invalidate() was not supposed to be called in the Validate()
call, and instead, we should rely on what the Validate() invalidates :-)

Change-Id: Ia65df90e4ff34078b59c1b2eb1ce1faac790b40d

Returns a json mapping of the available fonts to their possible font
sizes

Change-Id: I80c0bdd79e3ef2d814f64b8d38143d6c2b9ca720

This method returns a JSON mapping of the posible values for the given
command (e.g. .uno:StyleApply, etc).

returns:
{commandName: "cmdName", commandValues: {json_of_cmd_values}}
I've fixed the unit test this time

Change-Id: I30b0fba8ba1db33dd79f4b46026d293b9ea72402

We needed a better way to test LOK methods that are not app specific,
but are defined in /desktop/source/lib/init.cxx. So the decalaration
needs to be visible.

I also moved the `getStyles` test in the new test file

Change-Id: I98d97dc17a66e72732ca7bd848c131610790f48e

Change-Id: I866a44fcb71044d27a9bf06e2f55ca2e4135c23b

This method returns a JSON mapping of style families to a list of styles
from the corresponding family.
Will be used to know and apply styles in tiledrendering.

Change-Id: I0aa395c40b9573920ade44255f97c077475ae5f1

1. For tiled rendering, don't invalidate the whole page when hiding it
2. Don't invalidate when showing a page because we've just hidden the
previous one
3. No need for invalidation when setting visible layers

Change-Id: I858401b22c95093c58ec00896fe92b766fddb6de
Reviewed-on: https://gerrit.libreoffice.org/17452Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>

It is necessary the thread name for debugging LOKit threads.

Change-Id: I713595eb1319234ff90a6eddebcac5ebad912b04

Change-Id: I3965966f0d3fe65389e8834d67452ac56f9df2d6

Change-Id: I80cd2975f17bb7fa57fa669873ef1dd8f3595a11

Change-Id: I2b86f79e83b3facf3e54009d3e7c9b7667b5b377

Change-Id: I4f33679332998f87b7bf1ad7c32aea64897dcaa6
(cherry picked from commit 0590fe94)

Change-Id: Ifdba1eaf4cec448fe3284015c36ea7fd1b3440b0

Change-Id: I4030781b76ba4954174b3fab2ffb8e8e93a02bcd

Change-Id: I0e3d7340f664e7d34ae3161d57430250933d6ff1

pre-load all C++ component library.

Change-Id: I95637b628c5a6340afce09b2d2033127c6f8f504

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

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

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

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
(cherry picked from commit 56238d58)
Reviewed-on: https://gerrit.libreoffice.org/18035Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Regression from commit 7d9bb549
(Related: #i124638# Second step of DrawingLayer FillAttributes...,
2014-06-02), the problem was that the new
CTF_PM_REPEAT_OFFSET_X..CTF_PM_FILLTRANSNAME range's values overlapped with the
existing CTF_PM_HEADERHEIGHT..CTF_PM_HEADERGRAPHICURL range's values, so
when the new code in XMLPageMasterExportPropMapper::ContextFilter()
tried to tweak header repeat offset properties, it actually disabled
HeaderBackGraphicURL instead.

(cherry picked from commit 3b40329f)

Conflicts:
	sc/qa/unit/subsequent_export-test.cxx

Change-Id: I9c2700fa71a4ef2a813ec671049ee9d98171b57e
Reviewed-on: https://gerrit.libreoffice.org/18163Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Andras Timar <andras.timar@collabora.com>

save/load basic script so that when executing password protected
the user defined types can be rebuilt

supports array and nested types

New identifier B_USERTYPE for save/open macro with user defined types
No version bump but saves binary format now to current_version

a unit test in sc macros-test.cxx

full round trip on password protected document (ie. use binary storage)
master --(0)--> master --(1)--> libreoffice 4.4 --(2)--> master --(3)--> master
(0) in master, User type supported, big module supported
(1) in libreoffice 4.4, user type not supported, big module supported, no loss of code
(2) in master, user type not supported, big module not found, no loss of code
it is OK as libreoffice 4.4 saves to LegacyVersion (see sbxmod.cxx changes)
(3) in master, User type supported, big module supported (all is restored)
it is OK as module was saved with CURRENT_VERSION (see sbxmod.cxx changes)

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

Change-Id: I51a0596049a43cbc80f914f3d8491c2125c8109e
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/18158Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Idd7ec17eed51f79ead56349bb644945826d0a695

Change-Id: I9375f84affdaef30d9b1ded31525e6b7b8709cbc
(cherry picked from commit 7d4c77e3)
Reviewed-on: https://gerrit.libreoffice.org/18149Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>

Change-Id: I677f47f6b60271dc56c9d3d123cf982c00866eb9
Reviewed-on: https://gerrit.libreoffice.org/18136Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
Tested-by: Maxim Monastirsky <momonasmon@gmail.com>

SAL_DETAIL_ENABLE_LOG_INFO is always defined, as "true" or "false". It
is SAL_LOG_INFO that is defined or not, and can be used to avoid
unnecessary non-trivial code that the compiler might not be able to
optimise away.

Change-Id: I9903faab64b39fee86bff3b085cdce3614b0d921
(cherry picked from commit d23a1f4d)

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
(cherry picked from commit 68efa6f5)
Reviewed-on: https://gerrit.libreoffice.org/18040Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

... 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
(cherry picked from commit 25c50a71)
Reviewed-on: https://gerrit.libreoffice.org/18039Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

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
(cherry picked from commit f38f0180)
Reviewed-on: https://gerrit.libreoffice.org/18038Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

getSvxBrushItemFromSourceSet() is called once for each property of a
frame style that is set, and the "solid" fill-style is set by first
applying the BackColorRGB and then BackTransparency property.  So there
is an intermediate state that has fill-style NONE but a XFillColorItem
set - don't reset the color to white in that case!

Apparently writerfilter generally relies on the current reset-to-AUTO
implementation (loads of test failures), so for now limit the fix for
when we know that a frame style is imported from ODF.

(regression from 3d399b0e)

(cherry picked from commit 79fb61ef)

tdf#92379: sw: unit test for frame style background color

(cherry picked from commit 982537d7)

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

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
(cherry picked from commit 27a02d17)
Reviewed-on: https://gerrit.libreoffice.org/18036Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Since commit 65a66d41 the
sd_exports_test crashes on Windows in UniscribeLayout because
it uses a ImplFontEntry that has been removed from the font cache.

Tweak the refcount in WinLayout so it will be valid.

Change-Id: Ic4bf984ea9fd70de9fa95ca964ae12d95d47d5bf
(cherry picked from commit 34700400)
Reviewed-on: https://gerrit.libreoffice.org/18121Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

It says there's access to uninitialized variable on that line,
so propbably the loop is running over.

Change-Id: I0226f82b20a6fbbc79af5bbb46af09830c3bc25a
(cherry picked from commit eba9a6c4)
Reviewed-on: https://gerrit.libreoffice.org/18107Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I609c8c4f4e843601361b61f55e0325ad99db3c23
(cherry picked from commit dc1be62d)
Reviewed-on: https://gerrit.libreoffice.org/18115Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>

Change-Id: Ie1df87c7eb9d391d0fa4a579f744051a1f1b2ae1
(cherry picked from commit 07823502)
Reviewed-on: https://gerrit.libreoffice.org/18114Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>

Change-Id: I9c4c2f0fe2d892615b3c70e08da0cab6da13338a
(cherry picked from commit 2aadad1e)
Reviewed-on: https://gerrit.libreoffice.org/18113Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>

Change-Id: I0c5c4784713376e0762bfbd197640f8d31b65562
(cherry picked from commit 1847753a)
Reviewed-on: https://gerrit.libreoffice.org/18112Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>

Can't call a function that as a side effect prints to std::cerr in
SAL_INFO. It will be called even if the log area doesn't match
$SAL_LOG. Just use only SAL_INFO and no plain std::cerr output. It's
fine to output a string with embedded newlines in SAL_INFO.

Also drop the debug output line with the glyph start positions, it was
less than useful.

Change-Id: I9fb5ed068aae1b835e20cf1ec1097bcd55deb05d
(cherry picked from commit 15943416)