Age | Commit message (Collapse) | Author |
|
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 199f0edc93e25ff8144f16599184049573154232.
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 fa694a21b806ed7837c1337ec49a4b299c478393 (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/2372
Reviewed-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/2330
Reviewed-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/2383
Reviewed-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/2345
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
|
|
Change-Id: Ic548b8b0b4a9111f24fe0036bb50abaef03f4a2f
Reviewed-on: https://gerrit.libreoffice.org/2382
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
|
|
Change-Id: Idb8efc3f900172dea2ded6b7aa39e0b6f8fe49b7
|
|
Change-Id: Ifb38336863979890f1bc3de779d82454b4a5c185
|
|
Change-Id: I203ad92e8a006d1f262203852f05108706a90ee4
|
|
Project: help 6e3f40c9ca05ba234fac04074f594530f2e89e75
|
|
Change-Id: I5f008ba23c7f55a53d2b39cb235b27208b7743c5
|
|
Change-Id: Id76b57a1ef2edbb05f1d22a624caad077275ac74
|
|
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>
|
|
Change-Id: Iaa8ee970042c5260eb3d1199bf31f6495c449f40
Reviewed-on: https://gerrit.libreoffice.org/2370
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
|
|
Change-Id: I22150c0247ec98bd0e764a439a15ceaa7f42b029
|
|
Change-Id: I854fd87a21fc63a5c274b38831589b3d76379e25
|
|
Change-Id: I77433ff3926b6f8e2968b30451acf8acbbb4deb3
|
|
Change-Id: Icae65a8bf48f76801c536607055be066be0bd49f
|
|
Change-Id: I834b3cf0b5a46627ff0b532e27a73deeaefe7c47
Reviewed-on: https://gerrit.libreoffice.org/2376
Reviewed-by: Miklos Vajna <vmiklos@suse.cz>
Tested-by: Miklos Vajna <vmiklos@suse.cz>
|