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>

Change-Id: I1a35da4b23b9ff8efa8f500eaf18e4c259cc0177

we know that nStartPara is EE_PARA_NOT_FOUND so rOutliner.GetAbsPos must have
returned that, but we don't know the circumstances that lead to that yet.

Change-Id: I53a488317d154b4a3c050248b8737da0a611ca43

Change-Id: I7aa4a9bf72732db95a67cee368f3a83a0d71bb9c

We should probably introduce an API to allow selecting notes instead, however
the default mode is to open whichever view we had open last for a given
document -- whereas for nowwe probably always want to render the slides.

Change-Id: I26540613d1a510f23e5abfc8fee2ad743c180f34

Currently the only way to change the PageKind is via the UI controls
(i.e. via ExecCtrl) -- however for tiled rendering we want to select
the PageKind directly.

Change-Id: I3a3fa8f8cefaa0e0212832aef4026433fc596263

.. which more accurately reflects it's purpose

Change-Id: Ibb87a47a3d1f3e35ac2820f14c71adf3b227c961
Reviewed-on: https://gerrit.libreoffice.org/10283Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

All the temp files got the same names for the temp files which might
conflict when two tests try to get teh same temp file at the same time.
Additionally it makes the dbgutil check by Norbert for finding leaked
temp files useless.

Change-Id: I692107f7705787c360247785b8d95daf4199c2a6