Change-Id: I198fb0193fed891c4dd8a8a92c29e36f6c4d48b9

	Issue :
	- Document contains a Section break(Next Page) with a drawing.
	- Section break is manullay adjusted before the drawing.
	  Hence in original document.xml it wsectPr comes as
	  a part of w:pPr of paragraph.
	- But in RT in document.xml, section break is written
	  by adding a dummy paragraph.
	- This is because <w:drawing> also contains a paragraph
	  and hence when encounters section property LO creates
	  a dummy paragraph and writes it in between runs.
	- This was causing the corruption.

	Implementation :
	- Added a member varaible m_bDMLAndVMLDrawingOpen.
	- It is set to true when it writes drawing.
	- It's value is checked in DocxAttributeOutput::EndParagraph()
	  If m_bDMLAndVMLDrawingOpen is true Do Not make
	  m_bParagraphOpened to false, as one more paragraph is still
	  open.
	- This will postpone the writing od Section property and will
	  be written inside w:pPr and no dummy paragraph will get
	  created.
	- Added Export Unit test case.

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

... as they can be disabled and thus are not there at install

Change-Id: I197b5053971d2721114b2ebc7b3c31db36c3f58e

We need to wait until all the affected cells get marked dirty at the
end of the deletion process.

Change-Id: I49618fcc386ec2209f5f0267d50257ecb8dd21d1

Change-Id: If8ed8b74b58efd948772376a14172b52ff588f82

Change-Id: I10bdfc3356bda66fefa59fa2c9f63f9231d8728e

Change-Id: I2447498cf92da91a7fb2d67ee041d603ae16fe25

Change-Id: I82a517a267cceaac4dd1030d45c67fc070e22def

Change-Id: Id8adb7517960a33f9900cb773b62b84db71e795a

Change-Id: I010c7c194bf0680a499077b6b364498a09542764

Change-Id: Ib79f0c525608d279eebe820bfc82e84dd3518c29

Change-Id: I35adb022f12c6833f4f29b2e8dad44394a2c4be5

The chart object can be destroyed after the context.

Change-Id: I5ae370638f296ea314ee11680e0a8d81a8fdbe69

Change-Id: I5bdf6c3b313a73126cb692e5101836f424a2fc08

Change-Id: Ifb068efb553ed24a7caf65dbab28726bdeced0e6

Change-Id: Ic038a1c95721d4e578face5deea0b8d8a4ab7304

Change-Id: Ib763efb268bc9165704185c2b588ed282121cfa0

With just the Oracle JRE installed, it is not possible to load the
"jvm.dll" directly, because the required MSVC runtime DLL is not
found (unless some other software happens to install it system-wide),
as described in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184978

There was a hack "do_msvcr71_magic" to manually load the runtime that
is bundled with Oracle JRE 6 and this generalizes that to work with the
MSVCR100.DLL that is bundled with Oracle JRE 7 as well.

An additional adaption of the virtual addresses in the file is done,
and it's a mystery whether it even worked before without that.

This issue was not user-visible before because LO releases 3.5 - 4.2
bundle the MSVCR100.DLL themselves.

Change-Id: If61565df80ff8a68472a76000ab5b10d6c78e11c

Change-Id: Ib4d7c2da71a6fa083fc1ed56f058c8dfbc6e58fb

Change-Id: I629b5f6e57c5d8368bafc544c1c23785ee209a1e

Change-Id: Iab50c52a132c90389992ef68c2d31df95a193ab9

Change-Id: Ia00d7e52de5edfce09c3a0a8aa4390e3e1582a01

"warning: suggest a space before ';' or explicit braces around empty body"

Change-Id: I71a55cc888d3480217621491ecace7d0af3dca6e
Reviewed-on: https://gerrit.libreoffice.org/9441Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>

Change-Id: I6c2cc90668a2158a0b5bf638ce520c8af7731f4e

The motivation is that this test takes time to execute (and we're
testing a limit here, so it's not easy to speed it up), though moving it
out of CppunitTest_sw_ooxmlexport is still possible (which is the
current critical path during a toplevel 'make').

Change-Id: Ibe6580f8aea1439f4feb281996f2f4bbd46ff4ce

The \vern output was never parsed, and Word uses the generator field, so
let us do the same. And with the standard generator string, if we ever
need to parse it, we already have a parser for it in the ODF filter.

Change-Id: I57f25a6414b2b753a23cf82b691e364d84e4bb44

Copy them to the same folder where the conversion output is written.

Change-Id: I38b93bf3fc427974cff7d6975151451a253b1cce

... to allow continuous typing.

Change-Id: I4717e72e422037a441e582004bc87689ea7bc455

Change-Id: Ibf0cb4c0fa951adcd0a7f185d7dd45b06913a40d

Change-Id: Icc2a4829b8a859756ed194f35df214f8bb55c7ae

Change-Id: I6acc7538fcbf8aa7a5e50ba72b27409252cffa15

Change-Id: Id57eb51b69e50be78f85d19a7b3623c1acdf6509

Change-Id: I102566a95b5b34daf60730ffef290913caf28eb2

Change-Id: I095f45b537690fe98bf385d99194db6319d7ac93

...as flagged by -fsanitize=undefined.  But is it really undefined?
[conv.double] "If the source value is between two adjacent destination values,
the result of the conversion is an implementation-defined choice of either of
those values."  So if the double is between std::numeric_limits<float>::max()
and std::numeric_limits<float>::infinity()...

Change-Id: I6389c8ac4a922991e240638d231dd2a39e173882

Change-Id: Iffe85763097829cb04b766314077b5f2a9b5b8d5

Change-Id: Ic1bae7fcebfaf35b62aecd86ed8b3a70fae3e4d3

As an InfoBar, so hopefully not annoying...

Change-Id: I5d4e79273edc03829fdab2d6d5a291576c954e4b

Change-Id: I0dbb2546f1e776ebf95b61c16ebedbce0ead4c7f