had to change the structure of the plugin considerably, was too messy to
structure it to do the calculations on a per-function basis

Change-Id: I4edee7735f726101105c607368124a08dba21086
Reviewed-on: https://gerrit.libreoffice.org/40516Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Ifdd86590f4258c84006f7ca94ea06058e600db1e

Change-Id: I608b818063f3ac66c6b36f9f8d221a54bfe1be24

Change-Id: I273847d01a457bf79a9b9182b370ffb58284c952
Reviewed-on: https://gerrit.libreoffice.org/40498Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>

Though meFieldUnit appears to not be used anywhere, but ...

Change-Id: I99e8392e4a773ba00868904e0f2ff5fdbc4bc47d
Reviewed-on: https://gerrit.libreoffice.org/40521Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>

Change-Id: I578d89cb732bf3e75b83ee6c65d0320659b5c3f8
Reviewed-on: https://gerrit.libreoffice.org/40514Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>

Change-Id: I9e542f6e131de1a05dd54a84a260453ea2edcb62

Change-Id: I62e021b2ec7ac9df122389fd128f7a7770317a43

Change-Id: I55896eb939a864c3437e3f3c5b13c272966e4b85

Change-Id: I59da77da208e5360b43ad2c18389e7a0ff7b84d2
Reviewed-on: https://gerrit.libreoffice.org/40152Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Change-Id: Ica9c66fe09f7340f76f62e536527dc63b3735d90

Change-Id: I27b0b82ac5be631c0d47f486603e241026dcabd9

and then turning it back into the code again

Change-Id: Iae9cddb18a6bdad4b1ba8c2af81f3d29a7f26725

Change-Id: I986352cd2db4a9bd794ec25fbef9168be08a70ce

Change-Id: I0624690f8af05adb2466219a4e508e634c490ef1
Reviewed-on: https://gerrit.libreoffice.org/40436Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

that way we can avoid the super slow code path for filtered
rows when we only care about selected shapes

Change-Id: I175fa841e406dbbe7075296f2e0a0e79fa115fb7
Reviewed-on: https://gerrit.libreoffice.org/40496Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>

Change-Id: Ic55fa1ad336035275f05f2bd0d56a9c0166ab1d2

Change-Id: I621fcf7ceb27238ca86d2299dfb2b8ed03c270fd
Reviewed-on: https://gerrit.libreoffice.org/40509Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

commit fdfdea4d for tdf#82173
added that functionality for .docx, but since .rtf didn't support
character props for footnotes, it messed up other formatting.

start/EndCharacterGroup() fixes the reported bug.
runProps() adds the functionality for .rtf that was requested
for .docx in bug 82173.

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

Change-Id: I46272f8a0b35776b9d14f72b1720e951458ab208

Change-Id: I37e0ab40bd76c34a52751d10bc5857c357ad52e9
Reviewed-on: https://gerrit.libreoffice.org/40501Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>

These files had a consistent style before, let's keep them that way.

Change-Id: I8a05a8fbbc193373e0815f27d2cd9ff1272ba0eb

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

According to ECMA-376-1:2016 17.4.63, 17.18.87, etc, all table widths are
considered preferred, and actual table layout should be determined using an
algorithm described in 17.18.87. When w:tblLayout element is omitted, or
there is no explicit width information given, it is assumed that AutoFit Table
Layout should be used, i.e. using cells content to determine final widths of
table grid. In the description of the AutoFit Table Layout algorithm, it is
stated that the table width grows to hold data, but no more than page width.

As a first approach, this commit just sets table width to 100% when there's
no width data available. TODO is to implement the AutoFit Table Layout
algorithm properly.

Change-Id: I000c548eb152c70d2c6e053f4d2b1d16e8976c27
Reviewed-on: https://gerrit.libreoffice.org/40500Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

Change-Id: Ibb940c2a7098313dfa282734894b1abc1ac40bc2
Reviewed-on: https://gerrit.libreoffice.org/40489Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

seems I got one of the checks wrong, and was missing a bunch of stuff

Change-Id: I2c662fc4e735f8d6cbe56c6f82906a60a580331b
Reviewed-on: https://gerrit.libreoffice.org/40481Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Id80e939412ed05324300189949d47b3f33bb5116
Reviewed-on: https://gerrit.libreoffice.org/40263Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Change-Id: I23671f0cea592c92a05b34b3cf284a47a73962b1

Change-Id: I96f91105d32b18c29bd82eedcf2f93c54ad5f229

If nCnt = 0 the only thing that will happen is an infinite loop.

Change-Id: I23c5d0ff9d36fbfb3eabc93476fe3ca1c558f91c

Change-Id: I093c8fbf5bb181d8e530fe33805a16aea94cdd62

SwTextNode::EraseText() on the paragraph at the start of the
selection notifies the SwTextFrame:

0  in SwFrame::ImplInvalidateSize() (this=0x3088a20) at sw/source/core/layout/wsfrm.cxx:1568
1  in SwFrame::InvalidateSize() (this=0x3088a20) at sw/source/core/inc/frame.hxx:849
2  in SwTextFrame::InvalidateRange_(SwCharRange const&, long) (this=0x3088a20, aRange=..., nD=-62) at sw/source/core/text/txtfrm.cxx:741
3  in SwTextFrame::InvalidateRange(SwCharRange const&, long) (this=0x3088a20, aRange=..., nD=-62) at sw/source/core/text/txtfrm.cxx:708
4  in SwTextFrame::Modify(SfxPoolItem const*, SfxPoolItem const*) (this=0x3088a20, pOld=0x0, pNew=0x7ffc8da38c50) at sw/source/core/text/txtfrm.cxx:1005
5  in SwClient::SwClientNotify(SwModify const&, SfxHint const&) (this=0x3088a20, rHint=...) at sw/source/core/attr/calbck.cxx:67
6  in SwModify::CallSwClientNotify(SfxHint const&) const (this=0x2f05550, rHint=...) at sw/inc/calbck.hxx:355
7  in SwModify::ModifyBroadcast(SfxPoolItem const*, SfxPoolItem const*) (this=0x2f05550, pOldValue=0x0, pNewValue=0x7ffc8da38c50) at sw/inc/calbck.hxx:176
8  in SwModify::NotifyClients(SfxPoolItem const*, SfxPoolItem const*) (this=0x2f05550, pOldValue=0x0, pNewValue=0x7ffc8da38c50) at sw/source/core/attr/calbck.cxx:142
9  in SwTextNode::EraseText(SwIndex const&, int, SwInsertFlags) (this=0x2f05550, rIdx=SwIndex (offset 1), nCount=62, nMode=SwInsertFlags::DEFAULT) at sw/source/core/txtnode/ndtxt.cxx:2355
10 in SwUndoDelete::SaveContent(SwPosition const*, SwPosition const*, SwTextNode*, SwTextNode*) (this=0x3052950, pStt=0x7ffc8da390b8, pEnd=0x7ffc8da39100, pSttTextNd=0x2f05550, pEndTextNd=0x2faefe0) at sw/source/core/undo/undel.cxx:387

However, at this point the first page, which contains this paragraph, is
not visible; so the Action that is created in ViewShell::ImplEndAction()
will skip over the first page and start at the 2nd page, which is the
first visible one.

Now it happens that the last paragraph in the document has a page break
on it, and formatting it causes it to move forward (a new page to be
inserted and the empty 2nd page to be deleted).

Unfortunately it then decides to reset the mbValidSize flag on the
preceding SwTextFrame, assuming that it was set by its own moving
forward, and not already set before.

0  in ValidateSz(SwFrame*) (pFrame=0x3088a20) at sw/source/core/layout/calcmove.cxx:1082
1  in SwContentFrame::MakeAll(OutputDevice*) (this=0x308b4a0) at sw/source/core/layout/calcmove.cxx:1276
2  in SwFrame::PrepareMake(OutputDevice*) (this=0x308b4a0, pRenderContext=0x306f850) at sw/source/core/layout/calcmove.cxx:346
3  in SwFrame::Calc(OutputDevice*) const (this=0x308b4a0, pRenderContext=0x306f850) at sw/source/core/layout/trvlfrm.cxx:1760
4  in SwLayAction::IsShortCut(SwPageFrame*&) (this=0x7ffc8da394a0, prPage=@0x7ffc8da392b8: 0x7491e30) at sw/source/core/layout/layact.cxx:1085
5  in SwLayAction::InternalAction(OutputDevice*) (this=0x7ffc8da394a0, pRenderContext=0x306f850) at sw/source/core/layout/layact.cxx:490
6  in SwLayAction::Action(OutputDevice*) (this=0x7ffc8da394a0, pRenderContext=0x306f850) at sw/source/core/layout/layact.cxx:351
7  in SwViewShell::ImplEndAction(bool) (this=0x30829c0, bIdleEnd=false) at sw/source/core/view/viewsh.cxx:278
8  in SwViewShell::EndAction(bool) (this=0x30829c0, bIdleEnd=false) at sw/inc/viewsh.hxx:605
9  in SwCursorShell::EndAction(bool, bool) (this=0x30829c0, bIdleEnd=false, DoSetPosX=false) at sw/source/core/crsr/crsrsh.cxx:258
10 in SwActContext::~SwActContext() (this=0x7ffc8da396a0, __in_chrg=<optimized out>) at sw/source/core/edit/edws.cxx:159
11 in SwWrtShell::DelRight() (this=0x30829c0) at sw/source/uibase/wrtsh/delete.cxx:260

So at the end of the Action, the first page is still not valid, and
the SwTextFrame has mbValidPos = false, but it does have
mbValidSize = true.

Then when the SwCursorShell::UpdateCursor() calls
SwViewShell::MakeVisible(), which creates another Action, the
SwTextFrame is not formatted and its SwTextPortions do not match
the paragraph text content, which is the cause of the crash.

Change-Id: I6e8153c574469a94d190fda8bc3007d17a474c7f

getWordBoundary() can return bounds that do not include the starting
nPos, if there are ZWSP characters at the starting position.

This happens in the bugdoc of tdf#109081 where paragraph starts with 3
ZWSP and then 5 dashes, SwScanner is created from 0 to 1 and bounds are
3 to 8.

Change-Id: I5fc41b98568a7211fc7d5f29bb87840371a4c005

to getOleSourceRanges( renamed from getChartSourceRanges)
and optionally calculate source ranges to avoid code
duplication and do OLE detection as done in
CheckOle() which was working well before the commit
c55d5226.

Matching test cases (in uitest) coming up soon in another commit.

Change-Id: I64a12eef02afb488bed4bc8de1a18823c89128bb
Reviewed-on: https://gerrit.libreoffice.org/40278Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jean-Baptiste Faure <jbfaure@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

ScXMLDataPilotTableContext
ScXMLDPSourceSQLContext
ScXMLDPSourceTableContext
ScXMLDPSourceQueryContext
ScXMLSourceServiceContext
ScXMLDataPilotGrandTotalContext
ScXMLSourceCellRangeContext
ScXMLDataPilotFieldContext
ScXMLDataPilotFieldReferenceContext
ScXMLDataPilotLevelContext
ScXMLDataPilotDisplayInfoContext
ScXMLDataPilotSortInfoContext
ScXMLDataPilotLayoutInfoContext
ScXMLDataPilotSubTotalsContext
ScXMLDataPilotSubTotalContext
ScXMLDataPilotMembersContext
ScXMLDataPilotMemberContext
ScXMLDataPilotGroupsContext
ScXMLDataPilotGroupContext
ScXMLDataPilotGroupMemberContext
ScXMLDPFilterContext

Change-Id: Ie01ddb0f740a1b41a44e4abc9fe1bea3ab32cb12
Reviewed-on: https://gerrit.libreoffice.org/40326Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: Iedd529d4b5064beed3d2fd99cfe4e0312c024187

Change-Id: I955cf49fe5fa47fb38d2c8dacf4aadc8e3f7d651
Reviewed-on: https://gerrit.libreoffice.org/39317Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

This was the last incarnation of SfxItem binary stream serialization that is to
be eliminated after clipboard use is gone.

The "full" EditTextObject::operator==() in EditTextObjectImpl::operator==(),
and via ContentInfo::operator==() in SfxItemSet::operator==(), also compare the
SfxItemPool pointers which gets in the way here (not stored to stream hence
didn't matter and maybe the reason for not having switched EETextObjEqual() to
use operator==() back in the days).

Introduce *::Equals() functions that do not compare pool pointers and let
SfxItemSet::Equals() in that case not assume it would be operating on one pool
only.

Change-Id: Ifff939a92101c7f74695b676a45a7fdbb4f1d7f6
Reviewed-on: https://gerrit.libreoffice.org/40492Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>

Change-Id: I765c482a41e9681a1eb145c1833cc94f35a27db3

so it gets progressively slower

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