This came in with 3ecdcbae and is
apparently wrong.

Change-Id: Ic048d20c728aca2f8c97a90ede74d77e51b16e1c

So if we have an INVALID_ATTR event in the queue and receive
INVALID_CONTENT, drop the attr and replace it with invalid-content

And anyway filter out the RSID change event from hitting the
a11y queue, humans don't care that this changed, it's just noise

Change-Id: I4842f217153fc90aa1dce75c3445053004c74536

Change-Id: I0c2a2301de1b0de71fc6724ff2af73fbf6b406ef

Move unoidl functionality into a module of its own, as a prerequisite to use it
in codemaker etc.  (This is intended to ultimately remove modules store and
registry, modulo backwards compatibility constraints.)

Change-Id: If5274cbd3a595951e6cf7a9664bc542f01833f38

Change-Id: Id7b5e421f8ff9d6db923a1fb01b1071f75a6842d

Change-Id: I794b34c1864f619d91f0b105ba08a4f607abd291

Change-Id: I17f68196edeb685fb8d3f95616be1199fd5f1de2

Change-Id: Icb3044f1dc8b8a816cc93c9764908532a9cdcec4

Change-Id: Ib655b1177ffb4609bd7c50d54a818de659f284f3

Change-Id: I7e12a4ddd68ffb2c2b1cd1730a8ab17c79311fb2

Change-Id: I006230e190eb4e35f72c598c0016f7a7aa27cc7d

Change-Id: Iaced34a334e216ac2f4df783d76fb3003051e3b5

Change-Id: I7687af837d116ef7ec444049d941f3ca337aca03

Change-Id: Ib7721d6b97b2d5f11f9f6dd05f5bc236c09c4f42

Change-Id: I2bb9d4598d31462f9b661ed076046eb643c0a9e5

Change-Id: I74232178bb8c8a528d03274fbc8c1c9573874421

Change-Id: Id90ffae1f38b69005ead8bef9fadc54833813184

Change-Id: I198238f52b232dab4dc1d39fff70eb2dda2ddcfd

Change-Id: I4f5edb370a77e9d364e2b1df1271f20f99cef193

Change-Id: I58ed1ba6992b413aad9aa39f77623371a3e7972e

Change-Id: I9e26a6a32a70275174c83d109256dde5c718e42b

Change-Id: Ia75627e720f1edf7dba8aeb4684cdc0e3bfebb33

Change-Id: I3d0f0320fff1e9b6609bac152ff27552d58d928f

Change-Id: Ibe4c7753c1494cc665f52cefcc65875fd75fe051

Change-Id: Ib5ac31222fb9007336e49b872719c4515d51d5ad

Change-Id: Iee64a80118e927bfa66d24edb34187f7f7551533

Change-Id: Iff0150f99336c9650c9d9a9aaf34d0badf32c562

Change-Id: If2b1df2e71f6f206bff0951205490283e481c199

Change-Id: I6619cb27b1e49eb4ee7a91ad5e6f09f2b617e514

Change-Id: Ifba88d55c6fa9f86d46b2460aca9d62e0d47fee7

Change-Id: I98019eabc170b638275531036012cf8812e7f43c

Change-Id: I47280399bd9e0757365db8f4f1930efd0a340424

Change-Id: I2d6cf0afad4d5237b44e21be051f6f593a12830d

This reverts commit 199f0edc.

the problematic emf+ file with embedded wmf suffered from different problem
so I reverted this fix as it is not needed

Change-Id: I5005961e1b618af949dc978a7ac560fc9eca3e65

This rewrites commit fa694a21 (fix of
fdo#55931), and fixes it a better way.

Change-Id: I9ac0c78294e6a9c510c12b22547564b736416131

Printing to stderr is not at all any faster or more direct in an Android app
than just using the Android standard logging API.

Note that in a normal Android app, stdout and stderr are not connected
anywhere. (Just like in "GUI" subsystem (as opposed to "console") Windows
programs, heh.) It is our own code in sal/android/lo-bootstrap.c that
redirects stdout and stderr to pipes which we set up and which are read in a
separate thread that we start. The lines read are then, surprise, passed on to
__android_log_print(). Thus writes to stdout or stderr in "normal" LibreOffice
code aren't lost.

But in code that is by definition Android-specific it makes little sense to
use stdout and stderr.

(Much of the affected logging in this change is in NativeActivity-related #if
0'ed code, sure, so won't actually be reached.)

Change-Id: I409114f36f3e535bb144b4bde0d378110b3336a1

The View size is available only after the view has been connected to the
activity, it seems, so move the Bitmap creation to onDraw().

Note that the code in SvpSalFrame::SvpSalFrame() in vcl/headless/svpframe.cxx
still hardcodes another (!) size, 800x600. This affcects the size of the
desktop-style "top-level window" displayed by the android/experimental/desktop
app. I didn't yet figure out the right way to pass the actual view size to the
SvpSalFrame. And there is also a hardcoded third (!) size, 1280x750, in
AndroidSalInstance::GetWorkArea(), although I don't know what that affects, if
anything.

Change-Id: I042bf764cd66efa7069c36601170b90d57fa174c

Change-Id: I113f7bf3fd4194011efe83b1776ca42ad489f652

When editing the Visio OLE object, there is a "preview" file generated,
which is apparently an EMF file (strangely initially inserting the Visio
object seems to result in a totally unproblematic WMF file).
The EMF file apparently has almost its entire content stored in
MetaCommentAction of type "EMF_PLUS", which is thrown away when writing
the file again.

Change-Id: I77a08454da673c1825aaa8421606737e7e8bc82c