Change-Id: Iaa082d85ef95c58da14013c80cb06a2e1112d4ef

This is similar to 3d7e168a, but for RTF
(Word default is 0, Writer is something larger).

Change-Id: Ibb429eed5d3c1d09777db88ba2a98503c8ed0ed8

Since commit f4f4a899, we send the external header of WMF images to the
importer, but that seems to be cause problems with this document. To be
on the safe side, revert this only for pictures inside textframes.

Change-Id: I7e443beb9ca4261abf3e3a1257270d6c70b85918

Change-Id: I6a1af0cd98ed832204d4485e135da6e56e575b4a

Change-Id: Ifc1d6b78f55e7f202f5cc391f1401de5b65ed395

This allows inline pictures on shapes later, plus matches what the
DOC/DOCX filter does.

Change-Id: I5da56ccf59a26cc9657925dec94fb58f97692bb8

Change-Id: Ief85da80e14078e1d5a0b2812a2959484717da76

Change-Id: Ib60ae077be6a179568e6ccd8454e572c22c35e7e

Change-Id: Ib4227a74232b1ba6ca48d037340c4a7441ab08e7

Change-Id: I958f6e80813a4e056b09225b16cea9ea2a3450ac

Change-Id: Ib9b06e843f3e44c3a1ec3c1a64335d2a6ebed810

Change-Id: I64995db8f9e913db5f4ab4e81359dd163bc29d15

Change-Id: I417a6d46dc72ee251b43e00836363b6ae07c2b4c

Change-Id: Ia840ae93a0582e96df8faa2507835dc4fbb7141d

Change-Id: I732bd280295097fe098d3175127eb4d8a026dc32

Change-Id: I579dd5fc6c71ac9dad2de622e9125b399f3e160e

Change-Id: I8ba88cf9b19612800beac5e200bbaeff6da32f97

Change-Id: I21aa786a9f214ba5137d35497318c4f088456845

Change-Id: I31c91bec6807b699333f646d758078ce5e69570d

Change-Id: I90ef759639c8b1410ec314fed4ff0fd877d8e224

Change-Id: Idd1f670dba9d88233a22b9f6ff084bf2ef41fb54

Change-Id: I99314136cac7f47a5adf8e0e29093ec9fbf4fd90

Change-Id: I8702c70eb2579781e2f524b2364191e1636370c5

Change-Id: I54db750b79f77ee964c31febe466f0eeee82b9d1
Reviewed-on: https://gerrit.libreoffice.org/917Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>

More type-safe way, instead of void* everywhere
void* instead of sal_Int8 for raw memory / multi-use buffers
Fixed more issues than I care to count, but at least:
 - updates to a DECIMAL were truncated to integer because DecimalDigits set to 0
   maybe/probably also NUMERIC
 - setObjectWithInfo(... DataType::LONGVARCHAR ...) was passed as AT_EXEC, but the buffer was already free()d by then -> crash or wrong data

Change-Id: I0e6791a05b96fb345bfe3f911386263e6cfedde9

Change-Id: Ifa9b93b2daf0bb448711eb1bd3ebab69febf4f9c

Change-Id: I6de4e86f09be74518c9980d1b2347217cdcc4e02

Change-Id: I70f92224e22e9a9a1283564b5b1be7bf1e0240d0

Change-Id: Id2e8ad5b6bed1c184de6dccf7fa43254099fb958

Change-Id: I50c64d5fcf1d642052be5edbe64dde2c03c1eba9

Change-Id: Icf6a71900d79377cde84c2307ce85a9b3c96a54f

This reverts commit dd6c4f4d "fdo#46102: Load
Java scripts with class loaders that actually find them."  That commit broke
support for macros embedded in documents (as
new java.net.URL("vnd.sun.star.tdoc:...") throws a MalformedURLExcetpion), and
it looks like that commit was not necessary after all -- or rather that what it
tried to work around must have been some other problem that has been fixed
meanwhile.  "It is unclear to me how the Java script provider shall ever have
found the script jars in the past" indicates that something must have been
fishy, and what I failed to notice back then is that createURL creates
java.net.URL instances with a UCBStreamHandler that does allow to obtain content
from weird-looking URLs.

Anyway, with that reverted, all three following scenarios work on both current
master (towards LO 3.7) and libreoffice-3-6 (towards LO 3.6.4); I haven't yet
come around to test on libreoffice-3-5:

1  Stock macros, "Tools - Macros - Run Macro... - LibreOffice Macros -
HelloWorld", running all of the four "helloworld.bsh", "helloworld.js",
"HelloWorldPyhton", and
"org.libreoffice.example.java_scripts.HelloWorld.printHW".

2  Per-document macros, loading test.odt attached to fdo#49517, then "Tools -
Macros - Run Macro... - test.odt - HelloWorld", running
"org.libreoffice.example.java_scripts.HelloWorld.printHW".

3  Extension macros, installing ScriptDispatch.oxt attached to fdo#46012 as
shared extension, then loading StartScriptDispatch.odt attached to fdo#46012 and
pressing the "Start Java via ScriptProvider" button.

Change-Id: I31cd16b3720ffeb1058722d4d1fdffb773f8a067

Change-Id: I6b26f2805d08d2eb1b28ade459d38a1c6895addf

Change-Id: I347672a2175cf7a0304cf5d6c0f8f3f6afa92cd4

Change-Id: I0ddc4d343882248d208c9f96366625bcbe6ac4f7

Change-Id: I702c044fdf510c67364f2fc32889ca394583edf6

Remove tabs too

Change-Id: I8f7b2148f95e5694ad17d1a1b98001f1c803ce7e

Change-Id: I1c571327f977a95fc4193567142e3897cbfc3e14

Change-Id: I6ac3940fb0b07d280998a56d5eaede0909f14bce

With ucbhelper::Content now requiring an XComponentContext during construction,
calling "unopkg add" with an .oxt that requires license acceptance would lead to
an assertion about a null XComponentContext, as doChecksForAddExtension calls
the XPackage's checkPrerequisites -> checkLicnese -> getTextFromURL, which
creates an ucbhelper::Content with getMyBackend()->getComponentContext(), but
early release of the "tmp" manager would already have caused disposing of that
backend, which clears m_xComponentContext.

I assume this problem had always been lurking silently in the code.

Change-Id: I9f59c612fe3831b2f6dd832ef2f0505b6590b8e0