There are special properties to create a "horizontal rule" shape
that apparently set some specific defaults; this prevents the
shape being imported as a big fat rectangle over the document.

Change-Id: I402376d7306e870ad895beaa657750cbf3290d98

The document has a \pict with {\sp{\sn shapeType}{\sv 1}}, i.e. it's
actually a rectangle shape; Word seems to ignore the picture data in
this case, so try to do the same.  Also consolidate the shape creation
in a new function RTFSdrImport::initShape().

(regression from ba9b63d8)

Change-Id: Iec94852ddc4c1ca3d8284119e6f1818a8dbb4149

Change-Id: Ic820daa58574fb37a737b632ba6c58d31ccb8114

Change-Id: Ia43a4ba643b3a3f5e362204de141eae0f73ad0db

These produce a lot of noise, and do not indicate a real bug.

Change-Id: I355f6788af92529804cef2567ee2f8b3e4a1e807

Change-Id: I393e8a23bf69802e7879fe668708dca4f743bd4e

to current field as it could be unavailable caused by its change and a followed
removal from the document by e.g. a conditional hide of a section

(cherry picked from commit 58f0d79a20c3b9683c2d6a4be5dde14fe7688e01)
(cherry picked from commit 619fb83a3bc6d372632d382eaa1eb94fb9a8e8e9)

Conflicts:
	sw/source/ui/fldui/fldvar.cxx

Change-Id: I3f37b97ca8245c1996790622dd25437906b080db

CreateTitleTextObject will call indirectly ImpPageChange which
triggers tools::EventMultiplexerEvent::EID_PAGE_ORDER and so
in outlview.cxx without ignore page changes level in action
the outliner is filled in from the slide contents in
FillOutliner clearing the outliner contents and filling it
fresh, but..

a) this hack tower is not prepared for all the outliner
iterators to become invalid
b) the contents of this title object is empty, because
it was just created, and we didn't get a chance to fill
in its text.

This all works for typing vs pasting because the KeyInput
uses the OutlineViewPageChangesGuard guard which sets the
ignore pages changes bit.

So, given that OutlineView::UpdateDocument expects
the iterators of the outliner to be valid during
the lifetime of the method lock the full method with
the OutlineViewPageChangesGuard guard

Change-Id: Iecbf37d54f5f0c5a181be5f27832f769a3d2e389

Change-Id: If2efab82c0adc2f3dc52733c335693565c350bfa

Reviewed on:
	https://gerrit.libreoffice.org/10272

Change-Id: I696c152f9c053b745ab753a8899cc447eba8d1f8

Change-Id: I27600820acb4a432840ef9bc7220fc3d4bb6a273

This fixes sd_import_tests where 100*0.35 was 34 on 32bit platform.

Change-Id: I45705326e91892beb814bd94e074b0a652709768

	Issue :
	- Direct Formatting for non-first Table cells was not getting preserved.
	- In issue file, a table with multiple cells have Line Sapcing = 1.5 lines.
	  But LO was importing only First Table cell with Line Spacing = 1.5 lines
	  whereas for remaining cells LO was applying Line Spacing = Single.
	  LO was overriding value from styles.xml
	- Issue was due to at line : http://opengrok.libreoffice.org/xref/core/writerfilter/source/dmapper/DomainMapper.cxx#399
	  here LO sets only a boolean value for all cells and
	  here : http://opengrok.libreoffice.org/xref/core/writerfilter/source/dmapper/DomainMapperTableHandler.cxx#769
          we set DirectFormatting to False.
	  So we have processed only one cell, hence for remaining cells Direct Formatting is not getting applied.
	- So in order to have Direct Formatting for multiple Table Cells, we need to preserve Direct Fomatting property
	  for respective cells.
	  And with present code structure it is not happening as there is only a bool variable we are considering.

	Implementation :
	- Saved Direct Formatting information in DomainMapper itself.
	- Hence when DomainMapperTableHandler::endTableGetCellProperties() gets called,
	  Table cells already have correct value stored in it.
	  We no more need to erase Default Formatting as Default formatting is not
	  present instead it's actual values are now available.
        - This has conditionally reverted : https://gerrit.libreoffice.org/#/c/9560/

Change-Id: Ie1c82069cd84e9662f33e734bda3ef69c5169e83
Reviewed-on: https://gerrit.libreoffice.org/10216Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: I888f107c61037162439ad2d1ba99ad8185532f71

Change-Id: I2a4066c66894e0bd9c349a7c5b8db3a8398451d2

Change-Id: Ie33e6b9038d6c18482c2ba7aa47f62d23973ab08

Change-Id: Ibe9fedb3602d6c8ddbc007b214969c9960ba10b1

Change-Id: If91ed85a56c597f9aecbd5e469af4af83d256cfb

Change-Id: Ic4c858efa6e7c1a65357ac79f01e6c08f464ae3f

Change-Id: I9b1736bea65a582fb5214521472028835aec28ee

... which was introduced at 21103976.

Change-Id: If0f634b29e1891574267edf8cc07b24d07a9406c
Reviewed-on: https://gerrit.libreoffice.org/10363Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Doing it the other way round truncates the values

Change-Id: Ieb14c9d1b9dde496eac24737aced7c8da8ce1346

Calling Undo() here removes revision entries which also removes formula
cell instances stored in the entries.  The problem is that the
XclExpChTrCellContent instances store pointers to these formula instances
for later use, and removing the entries at this location causes deleted
formula instances to get accessed which in turn causes segfault.

Since all revision entries get deleted when the temp change track instance
gets deleted at the end of the revision export, not deleting the entries
here will not cause memory leaks.

Change-Id: I85f8064945a841b684e4fc4a97c3f9bb6a2de353

Change-Id: I4caeaf3565255ab141fc4951f1bd149a7af6bb8f

Change-Id: Iaf4ccc8949fb823a7bd3329c0164443220573b03

If the lock file still exists when running this test, LOK will fail
resulting in "documentLoad failed: unknown load failure"
(the actual error is that the lock file dialog cannot be confirmed
 by the user in headless mode, resulting in loading failure, however
 this is then hidden by multiple layers of exception redirection
 in sfx2).

Change-Id: I025ea6187c3d17805f25ab6f756eae9646f2c7c8

This allows for easier visual comparisons (i.e. currently the test
would be failing for some tiles).

Change-Id: I5b174375b57ffe0edd2700fdec411a83669e4a34

Change-Id: Ie8772de1d5b56b994c951ada09ee54afffceeb4f

Change-Id: I3972fb23557f61ce3dbe0e671ed4c3f434a98f8b

Change-Id: Ic1e6ecea3ba3ba4ed07760557b04bc07bd963532

Change-Id: Ieffd1fe52d6167d84ada5ebb11686f20d6dce8fa

Change-Id: Ib3c26cf90a26db31a3d145beeecc877ef57ab249

before:
$ time make -sr CppunitTest_sw_ooxmlexport
real    4m5.728s

after:
$ time make -sr CppunitTest_sw_ooxmlexport
real    3m24.446s

and the new CppunitTest_sw_ooxmlfieldexport can run in parallel.

Change-Id: I5a1d121f51e2d09a1c2126a33484e956c5c706a8

Change-Id: Ibf16b9651988358c30d649dd937813329d0f64ec

Change-Id: I95af4c2750c01e3e48f6708306b25f774c29e592

Change-Id: I1566a20166e77ac1e00db9ba19b92c68ad14e2df
Reviewed-on: https://gerrit.libreoffice.org/10366Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: I494cc676f384edbac9f64c1bc02b14cf7973d0d8

... if it has multiple columns.

See wwSectionManager::InsertSegments() for the related binary import
code which already did this.

Change-Id: I919f585bd864db748cd349e01789ec7805f031a1

Change-Id: Ifc538d8a51a333e79cec0312ab8cf4541abba7af

even on a short spreadsheet scrolling up and down leaves
the first/last row (depending on the direction of scroll)
unchanged until the scrolling stops.

http://people.freedesktop.org/~mst/calc_4.2_scrolling.webm

On larger document there are rendering artifacts during scrolling which go away
after scrolling for me and mstahl, but a bunch of people can show us piles of
horribly broken spreadsheets after scrolling, esp wheel scrolling

Revert "fdo#75026: Sometimes we need to update grid view...

while not being active."

This reverts commit 52cc88d6.

Revert "fdo#68961: Check visible range during scrolling, and re-paint if necessary."

This reverts commit e36c8a67.

Revert "Repaint grid view when the visible area changes."

This reverts commit b54c1a53.

Conflicts:
	sc/source/ui/app/scmod.cxx

Revert "Update visible ranges when updating the scroll bars."

This reverts commit 391a57ef.

Change-Id: Ie170308cba18a9a74c7c72daf07dfa0a4ef7bd13
Reviewed-on: https://gerrit.libreoffice.org/10350Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Tested-by: Kohei Yoshida <libreoffice@kohei.us>