Change-Id: I834eb4ecd0fa71caf6fa746901367fac8b538305

Change-Id: I680f6d79c27c83cf41edb8ba3acfcfc8dab26a76

Change-Id: I6c7c31befd61cbf0800a62c08e7395ddf78e4b30

Change-Id: Icdb619101a992a740c71545e669e138cb5dc63a6

Change-Id: Ic903d2429672159691fef58d0d7a15433c884250

Change-Id: I5c0372bce2564e58c78daf544cfcb106387c6894

Change-Id: I6dd7c7fbaf0d4b22abba0a7b1f5e37f0a46d0747

Change-Id: I0db5c02e9fbc09fe7d85e46f1434c86b5b5b4853

Change-Id: I61b960eecaeadaf12121596e181604318f951094

Change-Id: Ifab61517e0b2e721b85a3e2cc7d927198f1690c4

...that might depend on macro arguments and not really be redundant

Change-Id: If19de3835a4972add58965ea7c0936fad7ef6957

Change-Id: If0cb056d5a5e82bec1f4b863e40ec05b405280ac

Change-Id: I501ad421c283ec6a1f2629aa424f4d4c32228516

When a SwTxtFormatInfo is created to format a paragraph, pre-compute the
result of vcl::ScriptRun::next() and cache it for future calls to
OutputDevice::GetTextBreak() and GetTextWidth().

This requires adapting a bunch of methods to pass the additional
parameter, and some classes to backup and restore the cache when they
replace the text of the SwTxtFormatInfo.

There is some code in vcl OutputDevice::ImplPrepareLayoutArgs()
to modify the passed string and replace digits depending on
"meTextLanguage" member; try to set it to the correct value when
creating the layout cache (unfortunately it's not possible if the user
sets the CTL Numerals config to the non-default "Context" value).

Another issue is the check in OutputDevice::ImplLayout() if there is
a mpConversion member on the font; apparently this is used to translate
between different Symbol fonts, so not very important; just ignore the
cache in this case.

This reduces vcl::ScriptRun::next() from 11 to 0.36 billion callgrind
cycles when built with GCC 4.9.2 -m32 -Os (which is still 16% of the
formatting).

Change-Id: I61fb8530333f2e7a9199f767c00cf2181ba49951
Reviewed-on: https://gerrit.libreoffice.org/14732Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Such are fairly pointless to keep permanently in the code. Use a temporary
SAL_DEBUG if you need tracing output when you reach a certain lines while
hacking.

Change-Id: I13a898486731c6d2995e92e2c5dcd0d1429e47cc

Let's not make the mode space too complex. Do we really want to have to ponder
what it means to be console-only but not headless?

Make it so that turning on console-only mode also turns on headless mode (with
dialogsAreFatal turned on, too).

Change-Id: I630cb1bc605c1fb1787ace58180125509ef8789b

The "console only" mode, which apparently is intended to mean something
stronger than merely "headless" mode (?), is not checked much currently. But I
plan to start checking it to avoid doing things that make no sense when
running LO code through LibreOfficeKit.

(If overloading "console only" mode turns out to be a bad thing, we will have
to introduce a third degree of headlessness then, "LOKit mode".)

Change-Id: Id4cd16c4d68e2f1aba8a6b8fba83325b7262563a

Change-Id: Id1315a35f84fee2a7c7a42df489237c2e641a189

Change-Id: Ic75e73cf390872f4095d23a4388739330aeb1286

This crept in with commit 367d3c9b

Change-Id: Ia59d89b6d08b45478ce1c217c7e4004aa52aca06
Reviewed-on: https://gerrit.libreoffice.org/15042Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Yousuf Philips <philipz85@hotmail.com>

Change-Id: I656905cf6f0e3647824ff3836fcea93920251264

Change-Id: I3be9b1a57971286441d78e03130d0467ea2cc838

Change-Id: I6ff31e406d79361c07779f650de8d46cc78302ff
Reviewed-on: https://gerrit.libreoffice.org/15041Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>

Change-Id: Id33b72ef29e55a3446a3c628a33c21eabd01e662
Reviewed-on: https://gerrit.libreoffice.org/15039Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Change-Id: I3e218f947c863e03148934191e8859d449cc20de
Reviewed-on: https://gerrit.libreoffice.org/15038Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Same as in ScDocument::SetString() as changed with
c79bdd06, do it similar in
ScDocument::SetValue()

Change-Id: I7c666b176062c81a8a74cb49f345408c1060d973

Change-Id: I497a5bae4b08b46357415501ddbafc70585adfb0
Reviewed-on: https://gerrit.libreoffice.org/14920Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

Change-Id: Ifbab13cde089206a8d21aaca45c7aba2b182aa2d
Reviewed-on: https://gerrit.libreoffice.org/15035Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Change-Id: Ia2ce5a27a938997e39ce7603fdb836337a4c8589
Reviewed-on: https://gerrit.libreoffice.org/15034Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Change-Id: Ic9e42f2bbf29b87f901f995b6bd5e74e8bf13b16
Reviewed-on: https://gerrit.libreoffice.org/15033Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Change-Id: I6f0b90f7a76ddc69e158502af760466ab7ce2f91

tspan element only valid as child of text element
if exporting a selection use top left corner of bounding rect as top left corner of viewbox
export x coordinate of text position for text portions

Change-Id: I8b739085473aa4a48ff3bbbbe8c413c3cddbaebd
Reviewed-on: https://gerrit.libreoffice.org/14992Reviewed-by: Thorsten Behrens <thb@documentfoundation.org>
Tested-by: Thorsten Behrens <thb@documentfoundation.org>

Change-Id: Iea5209473632891b2015ac2df493e307972867e8

Change-Id: Ia3458ae91ea20aa3f5090f9b85a5030ddde81c3c

Change-Id: I8489b0341709d44bc62e5ddef49fe232998f3c80

Change-Id: I0594de8cc79626720f2f72062c39a6f2590dd64f

Part of Code Review:
https://reviews.freebsd.org/D2055

Author:		Don Lewis (truckman at FreeBSD)
(cherry picked from commit ecebe457)

Change-Id: Id0593e1c9af79084ae798f26a0be37c57d254227

Change-Id: I90798a036ba630456939d383e7e4288eb630cd86

the motivation is SwWrtShell::CalcAndSetScale

and the assert/crash triggered by

ooo58458-1.odt ooo84729-2.odt ooo75058-1.odt ooo123605-1.odt ooo102990-1.odt
fdo57249-1.odt fdo50880-1.odt fdo70223-5.odt ooo30052-2.odt ooo119280-1.odt
ooo79009-1.odt ooo58182-2.odt ooo59992-1.odt ooo123607-1.odt ooo89304-1.odt
ooo91578-5.odt ooo89303-1.odt ooo30052-1.odt fdo65664-3.odt ooo119941-1.odt
ooo55761-1.odt fdo57249-2.odt ooo83229-3.odt ooo84729-1.odt ooo102990-2.odt
ooo37749-1.sxw ooo38798-1.sxw ooo27909-1.sxw

getMapUnit activates the object which can cause chart object to load data from
the current document and appears to attempt to stop and resume pending layout
actions which can't be done if layout is underway, hence the assert from the
inner SwLayAction::SwLayAction triggered by the runstate while an SwLayAction::SwLayAction
is already active for counting the number of pdf output pages.

getMapUnit always returns the same result regardless of anything else and the
assumption is that we don't need to be in run state to setVisualSize on it

Change-Id: Ie75b159b140de223a56324b39699d703c3b40bb9