...(where destructors can be constexpr), making
21584b304b "make OUString(OUStringLiteral)
constructor constexpr" and 983c1146ac "actually
make OString(OStringLiteral) constructor constexpr" actually useful and
eventually removing the need for O[U]StringConstExpr again
Change-Id: I55520c1d928758f61e92336206e0f14b6f12a711
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148978
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
For them to be available also when shapes are selected.
This commit alone shouldn't cause any change in behavior.
Change-Id: Ic038618fe8b450ef2c93a19efb2e27c41f6de0f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149047
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
It turns out that the m_bFootnoteNum flag is no guarantee that there is
a SwFootnoteNumPortion, because if it has no width, it will be deleted
in SwLineLayout::CalcLine(); the flag indicates that this is the frame
which would contain the SwFootnoteNumPortion, which appears to be
checked in SwTextFrame::Prepare().
(regression from commit 92f7d3bfedc71bb0a91cf77b0263633c9d0f8d14)
Change-Id: I2f3ff70e6c2bb3379068b285cdd5fd52bc7cecf8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149053
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
CppunitTest_sw_ooxmlexport8's testN816593 failed in the
SW_FORCE_FLY_SPLIT=1 case because the re-import of the document merged
two tables into one.
The problem starts earlier, we didn't import the table with a <w:tblpPr>
as a floating table, but we should.
Fix the problem by never going via m_aPendingFloatingTables in the
SW_FORCE_FLY_SPLIT=1 case, since that was only a workaround for layout
limitations. This conditionally reverts commit
78d1f1c283 (fdo#68607 bnc#816593
DomainMapperTableHandler: don't always start a frame, 2013-09-03).
Also add a SwModelTestBase::FlySplitGuard, so it's just a one-liner
change to test the SW_FORCE_FLY_SPLIT=1 case from cppunit. The goal is
to have this on by default once it's mature enough.
Change-Id: I9d94a49f7a0c27dd43e8fd388867c65d6d25f2e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149044
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Refactory
Cause
Currency must be added in the MRU list in SvxCurrencyToolBoxControl::execute
method.
Unfortunately in this point the only information available is the number format.
It is not possibile to infer currency from number format (e.g: both USD and
AUD use symbol $).
Encapsulating currency data
In order to solve the problem currency data is enacpsulated in a SvxCurrencyData
struct. Added a vector of SvxCurrencyData to SvxCurrencyToolBoxControl.
Static and non static call
Former static SvxCurrencyToolBoxControl::GetCurrencySymbols has been
preserved, as it is called by SvxNumberFormatShell.
A new GetCurrencySymbols is used by the control.
To avoid code duplication, both functions call a static private function
inner_GetCurrencySymbols.
MRU Currencies
MRU currencies are stored in another member vector m_mru_curencies:
During currencies vector population (inner_GetCurrencySymbols) a space is reserved
on top of vector for mru currencies.
A new method addMruCurrency updates m_currencies. This method is called in
SvxCurrencyToolBoxControl::execute
Change-Id: I6f86179efd1839e31b089e0086b6ddbdda358f31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148896
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
If the inpt matches one of the constants exactly, the result is the
name of that constant. If the input matches some combination of
constant values that are single bits, the result is the sequence of
the names of those constants joined with plus signs.
For instance, if the IDL has:
constants Constants {
const byte BIT0 = 1;
const byte BIT1 = 2;
const byte BIT2 = 4;
const byte BIT3 = 8;
}
The result of Constants::to_string(5) is "BIT0+BIT2", and the result
of Constants::to_string(17) is "17".
I am sure there are corner cases that aren't handled as would be
intuitive, especially with types that include unsigned values.
Correspondingly, the semantics of the generated to_string() functions
is not formally defined.
Also add a unit test for the new functionality.
Change-Id: I14aa826d0989ac6dfe97dd5c09119b1601c65643
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148995
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
If there's a paragraph scoped tab default distance defined,
use that as the default tab distance in the SvxRuler instead
of the document wide setting.
Change-Id: I9b0e7d0db0b25aee08bd27948b2e462b4a4ee496
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148060
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir@collabora.com>
The bugdoc has 2 rows: the 2nd row was split and the master row went to
page 1 and the follow row went to page 2. Word positioned the entire row
to page 2.
The problem seems to be that the layout code wants a "deadline" (so it
can grow the frame to that bottom position), but the deadline depends on
the height: split flys need to fit the body frame, then they can have a
vertical offset (resulting in an overlap between the bottom margin area
& the fly frame), in case the fly frame is still inside the page area.
This means that this deadline depends on the body height, the fly top
and the fly height at the same time. (Or in other words: the overlap is
only allowed if the fly would fit the body frame, but an additional
vertical offset pushes it to the bottom margin area, with an unchanged
height.)
Solve this fly height <-> deadline circular dependency by first checking
against the page size, using the current fly height; and then against
the body height, using the assumed / future fly height (assuming that
the fly will grow so its new height will match the deadline). This
results in a construct where usually you can't grow outside the body
area, but in some limited cases you can (till you only use the bottom
margin area), but only in case you grow your top position as well, which
is Word-compatible, but quite unusual at other places in Writer.
With this, the original tdf#61594 bugdoc gets rendered correctly, once
you opt in with SW_FORCE_FLY_SPLIT=1.
Change-Id: I016df1bad79f4b09abc7e2b4fe9ea613355e3794
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149039
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Add an uno command that changes the theme to the one specified in the
first parameter
Change-Id: Ia0fef2ca698415e07f1943cf80ab667fb5c37238
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148942
Tested-by: Jenkins
Reviewed-by: Paris Oplopoios <parisoplop@gmail.com>
* Update helpcontent2 from branch 'master'
to a0ef2acc2d24501a7373ab7ba03ddc9473814b54
- one character is found without plus in regular expression
reported by Kamil Landa
Change-Id: I53f11b8ccd89340d2545e3c26edd8abee8cf5e9a
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/149005
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Adds export of ParaTabStopDefaultDistance property into defTabSz.
Also adds a unit test that checks pptx roundtrip of the property.
Change-Id: I5be9ea88b15e3e8cab25af79488983a71b96dae1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148539
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
* Update helpcontent2 from branch 'master'
to 4453c0b2edae4934f87594d5974783c4a1a5ea54
- convert paragraphs with role="heading" & childelements to → h<level>
and also drop the language that was changed to implied previously/defaults to
en-US unless specified.
This change doesn't affect translations, only the content of the
paragraph/headings is extracted.
done with:
perl -CSD -pi -e 'BEGIN {$base = qr/role="heading"|level="(?<level>\d+)"|(?<id>id="[^"]+")/;} s#<paragraph(((\s+($base)){3})|(\s+($base|xml-lang="en-US")){4})>(?<body>.*?)</paragraph>#<h$+{level} $+{id}>$+{body}</h$+{level}>#g'
and manually undoing the one that uses <sup>in body that's not valid
according to the dtd in the h tags.
Change-Id: Ibd4aed3157ed168cd5005161575672a392e59202
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/148797
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
* Update helpcontent2 from branch 'master'
to 77cb682cd1b004e7247560e60f603a4bb0565b8d
- convert plain paragraphs with role="heading" → h<level>
i.e. without child elements and also drop the language that was changed
to implied in the dtd previously/defaults to en-US unless specified.
This change doesn't affect translations, only the content of the
paragraph/headings is extracted.
done with:
perl -CSD -pi -e 'BEGIN {$base = qr/role="heading"|level="(?<level>\d+)"|(?<id>id="[^"]+")/;} s#<paragraph(((\s+($base)){3})|(\s+($base|xml-lang="en-US")){4})>(?<body>[^<]+)</paragraph>#<h$+{level} $+{id}>$+{body}</h$+{level}>#g'
(all permutations re order of attributes, and xml-lang="en-US" being
optional / implied)
Change-Id: I365a2bb983a3969af9390753fce7b7f3597c7b8b
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/148795
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>