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

This can be observed when inserting the bugdoc from fdo#59405.
Apparently the "size" and "length" do not agree; ensure that the
"length" does not underflow.

Change-Id: Idfc68919859b8284c724831de21208e4392af328

The mnViewAspect member is otherwise only initialized if a
SOT_FORMATSTR_ID_OBJECTDESCRIPTOR thingy is in the clipboard, which only
happens if the clipboard source is OOo/LO.
When inserting an OLE object, the value MSOLE_CONTENT apparently results
in requesting the current size from the OLE object, which looks much
better than the square default.

Change-Id: I8c7fb80a8ae88272f1ecaf3a375bef5d917f2a5b

Change-Id: I98794721c21231800d7d28cbdd34dd300b69a9c2

Change-Id: I37099d15cd403f48ca1716414f2e79cc1213d8c8

Stale component files result in failure to load libraries in incremental
builds; because rebuilding these is fast just depend on the 2 Repository
makefiles that define the library file names.

Change-Id: Ia72a0460d3bb8bceb0e17334415ca3dde0401c24

Changed all occurrences of 'charcter' found by git grep. All of them
were used in comments only, so it should not break anything.

Change-Id: Ief2c00d929ae7972c55a4920fc0eaa8d6b18ab82
Reviewed-on: https://gerrit.libreoffice.org/2372Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

Change-Id: I7c9ebd01c16ff066008e53de865560ad78215bab
Reviewed-on: https://gerrit.libreoffice.org/2330Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>

but *sob*, it's not really that, because there's a dialog scale factor which is
per-language which adds a bit to it depending on the language, MAP_REALAPPFONT
is the unscaled variant.

but *head in hands*, it's not really that either because if the font was
considered "too narrow" then the average char width is recalculated in terms of
the average char height.

*clenches teeth*, add a approximate_char_width and use it directly. It can be
considered the rough equivalent of
pango_font_metrics_get_approximate_char_width albeit that it retains the same
crude 1/8 of the width of "aemnnxEM"

Change-Id: I4c135ca03467447dddf279ac0c187b13371acadb

Change-Id: I92cc8be5c6359e99b57967ae54e6814d07d0e47d

Change-Id: Ib841747b10a1d0cda54b2b05a813760d1a50a3fa

Change-Id: I1dd71baf48a0b5b62c73c9f8f071ff67520cc771
Reviewed-on: https://gerrit.libreoffice.org/2383Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

Change-Id: I4596d78620936770f3aca3207cdc19f71197eb75
Reviewed-on: https://gerrit.libreoffice.org/2345Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>

Change-Id: Ic548b8b0b4a9111f24fe0036bb50abaef03f4a2f
Reviewed-on: https://gerrit.libreoffice.org/2382Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>

Change-Id: Idb8efc3f900172dea2ded6b7aa39e0b6f8fe49b7