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/14732
Reviewed-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
Same as in ScDocument::SetString() as changed with
c79bdd062f, do it similar in
ScDocument::SetValue()
Change-Id: I7c666b176062c81a8a74cb49f345408c1060d973
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/14992
Reviewed-by: Thorsten Behrens <thb@documentfoundation.org>
Tested-by: Thorsten Behrens <thb@documentfoundation.org>
Part of Code Review:
https://reviews.freebsd.org/D2055
Author: Don Lewis (truckman at FreeBSD)
(cherry picked from commit ecebe457c968bfd30a99a435210b0bdbb117faef)
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
