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
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
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/2372
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
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
In case of RTL, we want bullet text e.g. “1. ,1)” to be reversed
e.g. “.1,(1”, so we need to check only paragraph’s writing direction
and pass that direction to DrawingText().
and fix drawing position calculation logic.
Change-Id: I303dc1b04ae5e66b1b5d25a40794be308f36668b
Reviewed-on: https://gerrit.libreoffice.org/2348
Reviewed-by: Ahmad Harthi <aalharthi@kacst.edu.sa>
Tested-by: Ahmad Harthi <aalharthi@kacst.edu.sa>
resolve fdo#53594 : Import RTF file but ole are not well positioned in
table/cells
If the OLE object is in a container, don't try to import it as
OLE object (use the \objdata element) but use the \result element which
is the appareance of the object (it's a picture).
Change-Id: Id97b36ce89beae02885cf82383321c14b58f2ea5
Reviewed-on: https://gerrit.libreoffice.org/2243
Reviewed-by: Miklos Vajna <vmiklos@suse.cz>
Tested-by: Miklos Vajna <vmiklos@suse.cz>
Stop ImplLayoutArgs::ImplLayoutArgs() to perform
ubidi algo on text by setting TEXT_LAYOUT_BIDI_STRONG flag.
Change-Id: I7222517c1db6649eef0c0d9c11cbbbed1fc6bb04
Reviewed-on: https://gerrit.libreoffice.org/2076
Reviewed-by: Ahmad Harthi <aalharthi@kacst.edu.sa>
Tested-by: Ahmad Harthi <aalharthi@kacst.edu.sa>
