Change-Id: I5619e26e5afbe8e6532204feb60b87f6a7875ee0

Change-Id: I8233f6409d75bff23738e121efcdbd340035da9d

Get the app bundle directory from Xcode's SCRIPT_OUTPUT_FILE_0.

Copy .rdb, registry, .res files, set up the various rc files.

Don't list a bunch of .component files on the command line, surely
that is not sane.

Change-Id: I6fb8bd4bea8d5afd30900daa1b916defb894e78c

That they do is a leftover hack from before we started using the
DISABLE_DYNLOADING thing on Android, it isn't actually necessary any
more. Earlier when the UNO components were actually dynamic libraries
on Android (too, as on desktop OSes), they *had* to have names
starting with "lib" or they would be silently skipped when
packaging.

Change-Id: I11a4689f316e1ffb640a5c3110c63296d2833a84

Change-Id: Ib59f9cf7c60796fd091de64fabdd6c10a3fec5e5

Change-Id: I7259358c917ef9e7cc93d8f6886c9a935887183b

There was quite come confusion as to where Xcode wants the Run Script
phase (= our gbuild mechanism) to put the executable. I think I got it
right now. Xcode can be quite scary as soon as you do anything out of
the ordinary. (But then, what isn't.)

Change-Id: I22bbdfaef88174815bff66d6c7241f4ba2360246

Change-Id: I34e06bdb24ece278c928c6cbba8b01a38c86ff85

Change-Id: I5a29ca056af443643bfef823d0a064c5d834d24f

Change-Id: I94cea45c0e9d2890160a97d1ef198ae3f4f140d4

Change-Id: I6b1d524a7771678758c5cd8d0ef46cb03aba7655

Change-Id: I4c8edfc0ee0390d595c43e384bf6e5f595a7b84f

Change-Id: I8dc055336d1577475282198528a57efc60508cef

It used to call getenv("SAL_LOG") just once and assume it never changed.

Sure, I don't expect that LO code will start changing SAL_LOG back and forth
all the time. But it is definitely useful in our Android (and iOS) apps to be
able to call for instance putenv("SAL_LOG=+WARN+INFO") as early as possible,
before explicitly using any LO code.

That used to work earlier, but not any more with the getEnvironmentVariable()
thing, as the new logging mechanism gets called while initialising some static
globals (i.e. before out app code had even started), and that then caused the
one and only call to getenv("SAL_LOG").

This meant that we didn't get any debugging logging from SAL_INFO and friends
in the Android app(s) any more.

Change-Id: I932facff4118e5f016c95a4c1461e871184d3fc6

Project: dictionaries  a84489515d2207b1c34646be7d6f532b84a37439

Change-Id: I14e851a74955ff4053026e7fb664759cbf24c86a

Change-Id: If855e5fafb8f1291d69d5e50fdaa9ef165071293

Change-Id: Ide96d7f052ee4c8f56b33629ae48c6425a8ca19f

This reverts commit 119483d9b0af6b4830733161fcf56cea10ed01d7.

Change-Id: I715975dfa93d736cb537076feab4afe6b75c162a

No idea how to reproduce it; pSwView is checked before use except here.
(possibly regression from 2f9f480b)

Change-Id: Ia7667e879a6944e084a45c06133efc1ac2d8b3c0

Change-Id: Ic563204c1a1a64d315e3e73dff30b6a6d05cfd87

Change-Id: I55fa2570decd52e978747e589887f2fe972812c8

Change-Id: I92bff38304959237042b9a0078be25948d642b25

Change-Id: I5753a822e9f18d1afa831ece6134e030f88ad47f

Test disabled as it currently fails.

Change-Id: I33ea3c95357fd7fdb9deaba30372567cfb69ebd6

Let's use the orginal patch from https://gerrit.libreoffice.org/#/c/1479/
There is difference, visible e.g. by 'make help testtools'

Change-Id: Iaf929ed1d315f038eb29fca1b4ba37e2143c6294

...to avoid reading the bitmaps more than once.

Change-Id: I7577f5df96a5a28f1ac1f800867af5eee298663e

The case where it broke was a bitmap that is very wide (3000 pixels), but not
too tall - and the small height satisfied the aPosAry.mnDestHeight >
3*mnOutHeight condition.

Such workarounds that are triggered only in very rare cases are a bad idea in
general, unless there is a unit test.  I've tested with the document from
i#75264, and it works for me - there were some improvements in the bitmap
scaling, hopefully the root cause is fixed by that, or maybe I just have more
memory; who knows.

Change-Id: I4b7a749378ef35469db78dfc680fc77f87bc4382

Change-Id: I1d3986675ceb7a2748a77b736beb8a654a514e0d

Change-Id: I33d13cfece22c080e2204d7df10d3e9414b507b7

Change-Id: I21a45159f6b27aa7beff5ec07530b14480675729

The nX / nY is correct for clipping operation, but not for base; visible with
WALLPAPER_TOPRIGHT style.

Change-Id: I8de92b68b822a156bc376201e97ce458d1a6ba08

Change-Id: I52b67c82f69059a7d2babf1b49e59f27062cc02c