... and callers in SwCursorShell / SwEditShell.

Change-Id: Iffe4ca7893b97df8bd07f25c9e0e1dc908011e3f

Change-Id: I6db8421a52f7a9bece5ebb95b377dd3bb0a39af4

IsFirstOfNumRule() needs a layout so it can check the correct
SwNodeNum.

Change-Id: Ic6bd9adc909d7c325f5e450fd9e53a15f68e7a63

Change-Id: I192a9743300a77bc463319789064abd89d046b0a

Answer depends on layout.

Change-Id: Ibc7bddfa1b04630ddcfcfa429fbb507347073ce2

... if the numbering is per-chapter, because only with a hidden layout
can the footnotes be numbered properly per-hidden-chapter.

Change-Id: I32732b7b8eec0adcbf4349aac3c87492802e38b6

... and UpdateAllFootnote() in the FTNNUM_CHAPTER case; the former is
particularly nasty since the hidden-chapter may effectively start
before and/or end after the "normal" chapter.

Change-Id: Ifd73dec28011c47c8b23319cb7d3bf16c84f0cfd

Change-Id: I31677211d0aa5637e0cce0034e29b9db724c791b

SwEditShell::IsOutlineCopyable(), IsOutlineMovable(),
IsProtectedOutlinePara(), GetCurrentParaOutlineLevel() all filter.

Change-Id: Ie5fb181e21d4bf606482bec9cb108dbd70f4209e

Filter merged outline nodes.

Change-Id: I959dd4bfd2e6b279b8476ffed6b3e6e70651ed49

Have SwNode::FindOutlineNodeOfLevel() check if the outline node is
merged away in the layout.

Change-Id: I2da0bf8afe993f1bb60f488a015a33b5e15af217

Change-Id: I1d1f4604c580fe4dd764cfb908cd18657ea54255

Adapt SwDoc::GotoOutline(), SwCursorShell::GotoNextOutline(),
SwCursorShell::GotoPrevOutline() to skip over outline nodes that are
merged away in the layout.

Change-Id: Id6f6bb93177753ed21a438c89dc6d90098e11455

Add sw::IsParaPropsNode() to check if the node's numbering attributes are
effective in the given layout.

Add IDocumentOutlineNodes::isOutlineInLayout() to expose this to UI code.

Adapt IDocumentOutlineNodes::getOutlineText() to produce the merged text
of the outline paragraph as seen in the layout.

Also adapt EnhancedPDFExport and SwFieldRefPage to interface changes.

Change-Id: I6fa95150ff0c5dc5eb4f366d218e8f0c4d4bb7ab

Change-Id: I34e823bc9f57924851a70e04c295b1d2c6e11ab4

The SwOutlineContent::GetPos() returns the outline position in the
document model / IDocumentOutlineNodesAccess; rename it to make that
more clear.

Also it's already possible to have gaps in the list entries by setting
the outline level so that inner levels are filtered; the
SwContentTree::ExecCommand() doesn't appear to handle this properly,
it needs some tweaks to skip over the outline nodes that don't have list
entries.

The GetYPos() does not contain the outline index, it contains the list
entry index.

Change-Id: Ifae0b9648ce61bb9aa470172ef989b2532370138

Update both of the SwNodeNums.

Change-Id: Iba8aa6cda460099f4a1086d6aaa08ac98c78f097

There is no obvious case where such a fallback would be needed, but it
does introduce a bug with a delete redline inside a hidden section:
on Show, when moving the nodes into the body content,
FindPrvNxtFrameNode() will return nullptr because there are no frames
inside the hidden section, but then this fallback will cause it to
erroneously create a frame.

Change-Id: I2328a6f213fdec95857b6e4446e1a8504c17f599

Call the same function as SwNodeNum::NotifyNode().

Change-Id: If2edc5fb9364e97715d4750f3a45c3c918edfebf

Change-Id: Ibe2afae869b1999772fa6132e35a1e951fffddd2

... always the same as pParaPropsNode.

Change-Id: I1fb225d147ec3558615ad16ec49f873db7f1628f

... by calling AddToListRLHidden/RemoveFromListRLHidden.

Do this here because it has all the necessary information.

Change-Id: Iac2640b7493267b187e66b1d464c79fe90642afe

... so assert that somewhere.

Change-Id: I928c55ffa57ec037e9406618d20b454e11dd80d4

Change-Id: I62ebdb92ee384905bba9ef3865fcdb306775baf2

Disable the NumRule/DocumentListsItemManager manipulations on the
second tree; only the "main" tree does that.

Change-Id: I0da8ced53f8d55758e3c02fd24b9253bbf603b38

... so it can be used when redlines are hidden in the layout.

Change-Id: I6cb2bca2fb8ba3913bbf6633996341b52639fe41

Change-Id: I5ee0928bb5ce490b52005eb3f97b56ceb81db062

... to StartOfSection/EndOfSection, which corresponds more closely to
where they actually move the cursor, in SwNodes::GoStartOfSection.

SwCursorShell::SttEndDoc does what one would expect from these.

Change-Id: I5005e3ebf230c903a4e63dcdda93892a8658e096

If there's a insert redline inside a footnote whose anchor is in a
delete redline, the nested redline will be copied by the first
iteration of the loop in SetRedlineFlags() and then deleted in the
second iteration, while handling the outer delete redline.

This causes the redline immediately following the outer delete
redline to be skipped in the 2nd iteration.

Change-Id: Iba5c3a7b0d6d8a0d76a6ab6c7066cc4b059edb75

... so the numbers are repainted, both in the document body and in
the footnotes.

Change-Id: I4164f1bace1b984a841f520f4832a324b811ab3f

Needed for FTNNUM_CHAPTER and FTNNUM_DOC, as well as end-notes.

It should be enough to update from the start node until the end.

Change-Id: I47414f93b9ad29bc4ab4ee0fc25ae40fae160427

Add layout parameter to SwFormatFootnote::GetViewNumStr().

Change-Id: Iff9c9ff31d1793b66ba7e3ebdfa5cfe413324471

Add a separate footnote number to SwFormatFootnote for the case when
the layout hides redlines.

If the footnote is in a delete redline, the value will be an arbitrary
number, let's use the same number as the last visible footnote for
simplicity.

Change-Id: Ic7fff9d1bb2c90f5ad811b859c6501a193b7ae70

The number is pretty useless: none of the callers know what the proper
auto-counted number is going to be, so they either pass in the number
that the footnote already has, or 0.

It is particularly funny if the SwPaM is actually a range containing
multiple footnotes; fortunately such a call is apparently not possible
currently.

Just remove the parameter and use the existing footnote number directly.

Change-Id: I45dee999b8b0b630eff4347a563ccca2869f84cc

If it is merged, it doesn't have GetDep().

Change-Id: I5a362c03fe7fcb0a6246aef0a0ac2824c48ede36

It doesn't have a layout, of course.

Change-Id: Iec4809ec4a14e1fa9852d09619a8b344419b29e7

This never called Rst() in the loops because the m_nPosition wasn't updated.

Change-Id: I5a9cf47d9fe6d92bb7fccf255acbbd22f04b7f47

... check, which should accept the past-the-last-char index, because
as the comments say it returns the hard attributes of the SwTextNode
as well, so it should work for empty paragraphs too.

(similar fix was done in getCharacterAttributes() in IA2)

Change-Id: I01e1a8f66f103b63584e88ce785ac2044c5db2b9

It doesn't actually work with a similar logic to the other iterators,
because it iterates ByEnd but forwards, so the hints and the extents
don't come in a matching order.

To prevent complicating this further, replace it with a new
implementation that does only what the one client expects, and put it
directly in SwTextFormatter replacing the previous integer iterator
m_nHintEndIndex, so that it is created only once.

Change-Id: I144bfcf7e837a4fb0e7ec279edfba4732d0ae897

Was using the wrong node when iterating; also the tricky case of empty
or without-end hints at the start of an extent was wrong.

MergedAttrIter also shouldn't include wihout-end hints and non-empty
hints at the end of an extent.

Change-Id: Ia0776c1d3043cbd6d76fa04905b4937ebba53398