[Libreoffice-commits] core.git: Branch 'libreoffice-6-0' - 3 commits - editeng/source sw/source
Michael Stahl
mstahl at redhat.com
Mon Dec 18 12:50:09 UTC 2017
editeng/source/editeng/impedit4.cxx | 23 ++++++++++++-----------
sw/source/core/doc/DocumentRedlineManager.cxx | 4 ----
sw/source/core/layout/trvlfrm.cxx | 5 ++++-
3 files changed, 16 insertions(+), 16 deletions(-)
New commits:
commit b8ba995f079add002ab9606168d31d5386993160
Author: Michael Stahl <mstahl at redhat.com>
Date: Thu Dec 14 14:17:03 2017 +0100
editeng: fix RTF export of colors
SfxItemPool may contain null pointers and return them from GetItem2(),
even if non-null pointers follow, so have to use GetItemCount2() here.
This later asserts when it can't find the items in aColorList.
(cherry picked from commit 30504139af039d524ca0fd7158fc21ed38db2d9f)
editeng: RTF export: another buggy GetItem2() loop, for fonts
(cherry picked from commit 8ce353279caa84944971f22ec536433030e5d9c7)
editeng: error: "remove_const_t" is not a member of "std"
Manual type inference was an interesting oxymoronic curiosity that
can probably only exist in C++, but it turns out our baseline
compilers don't even support it yet.
(cherry picked from commit 700e1e7fda6f0a415adbbd5bb190efa5c7435c4f)
Change-Id: I976c95387b4c45e5a4371254f130df6b24370eaa
Reviewed-on: https://gerrit.libreoffice.org/46469
Tested-by: Jenkins <ci at libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm at redhat.com>
Tested-by: Caolán McNamara <caolanm at redhat.com>
diff --git a/editeng/source/editeng/impedit4.cxx b/editeng/source/editeng/impedit4.cxx
index f315141e9719..4b09582b99d1 100644
--- a/editeng/source/editeng/impedit4.cxx
+++ b/editeng/source/editeng/impedit4.cxx
@@ -315,10 +315,15 @@ ErrCode ImpEditEngine::WriteRTF( SvStream& rOutput, EditSelection aSel )
else if ( nScriptType == 2 )
nWhich = EE_CHAR_FONTINFO_CTL;
- sal_uInt32 i = 0;
- const SvxFontItem* pFontItem = static_cast<const SvxFontItem*>(aEditDoc.GetItemPool().GetItem2( nWhich, i ));
- while ( pFontItem )
+ auto const nFonts(aEditDoc.GetItemPool().GetItemCount2(nWhich));
+ for (sal_uInt32 i = 0; i < nFonts; ++i)
{
+ SvxFontItem const*const pFontItem = static_cast<const SvxFontItem*>(
+ aEditDoc.GetItemPool().GetItem2(nWhich, i));
+ if (!pFontItem)
+ {
+ continue;
+ }
bool bAlreadyExist = false;
sal_uLong nTestMax = nScriptType ? aFontTable.size() : 1;
for ( sal_uLong nTest = 0; !bAlreadyExist && ( nTest < nTestMax ); nTest++ )
@@ -328,8 +333,6 @@ ErrCode ImpEditEngine::WriteRTF( SvStream& rOutput, EditSelection aSel )
if ( !bAlreadyExist )
aFontTable.push_back( new SvxFontItem( *pFontItem ) );
-
- pFontItem = static_cast<const SvxFontItem*>(aEditDoc.GetItemPool().GetItem2( nWhich, ++i ));
}
}
@@ -392,16 +395,14 @@ ErrCode ImpEditEngine::WriteRTF( SvStream& rOutput, EditSelection aSel )
{
aColorList.push_back(rDefault.GetValue());
}
- sal_uInt32 i = 0;
- SvxColorItem const* pColorItem = aEditDoc.GetItemPool().GetItem2( EE_CHAR_COLOR, i);
- while ( pColorItem )
+ auto const nColors(aEditDoc.GetItemPool().GetItemCount2(EE_CHAR_COLOR));
+ for (sal_uInt32 i = 0; i < nColors; ++i)
{
- ++i;
- if ( pColorItem->GetValue() != COL_AUTO )
+ SvxColorItem const*const pColorItem(aEditDoc.GetItemPool().GetItem2(EE_CHAR_COLOR, i));
+ if (pColorItem && pColorItem->GetValue() != COL_AUTO) // may be null!
{
aColorList.push_back(pColorItem->GetValue());
}
- pColorItem = aEditDoc.GetItemPool().GetItem2(EE_CHAR_COLOR, i);
}
rOutput.WriteChar( '{' ).WriteCharPtr( OOO_STRING_SVTOOLS_RTF_COLORTBL );
commit a1e377aff16ea7c4d434ab60d7ed946c82514684
Author: Michael Stahl <mstahl at redhat.com>
Date: Fri Dec 15 17:07:01 2017 +0100
tdf#100635 sw: fix layout crash caused by field expansion ...
... triggering recursive layout-in-layout where a SwTextFrame
that's being formatted is deleted inside some other frame's
SwTextNode::GetFormatted().
The offending field is a SwAuthorityField that's located in a
fly-frame with FLY_AT_PAGE anchor.
SwPageFrame::GetContentPosition() is only called by field expansion
code, so this shouldn't have an effect on layout.
It already has a fall-back for the case when the frame has invalid
flags, so handle the situation when the SwLineLayout has been
deleted from the SwCache due to overflow the same way,
which prevents the recursive formatting.
Change-Id: I90437edb5692dc2bdec7ad03964588942bde05be
(cherry picked from commit b77881366b17230908f441dfa27afcafc4374708)
Reviewed-on: https://gerrit.libreoffice.org/46569
Tested-by: Jenkins <ci at libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm at redhat.com>
Tested-by: Caolán McNamara <caolanm at redhat.com>
diff --git a/sw/source/core/layout/trvlfrm.cxx b/sw/source/core/layout/trvlfrm.cxx
index 1225e6f65f41..2b9cd10d1111 100644
--- a/sw/source/core/layout/trvlfrm.cxx
+++ b/sw/source/core/layout/trvlfrm.cxx
@@ -1433,9 +1433,12 @@ void SwPageFrame::GetContentPosition( const Point &rPt, SwPosition &rPos ) const
else if ( aAct.X() > aRect.Right() )
aAct.X() = aRect.Right();
- if( !pAct->isFrameAreaDefinitionValid() )
+ if (!pAct->isFrameAreaDefinitionValid() ||
+ (pAct->IsTextFrame() && !static_cast<SwTextFrame const*>(pAct)->HasPara()))
{
// ContentFrame not formatted -> always on node-beginning
+ // tdf#100635 also if the SwTextFrame would require reformatting,
+ // which is unwanted in case this is called from text formatting code
SwContentNode* pCNd = const_cast<SwContentNode*>(pAct->GetNode());
OSL_ENSURE( pCNd, "Where is my ContentNode?" );
rPos.nNode = *pCNd;
commit 33efb8806ea16bcc140f084503ef1c9e49a844f8
Author: Michael Stahl <mstahl at redhat.com>
Date: Wed Dec 6 22:28:05 2017 +0100
ofz#4518 sw: why do we need to set IgnoreDeleteRedlines
This mysterious IgnoreDeleteRedlines flag was set in this particular
case of a new DELETE redline inside or equal to an existing INSERT
redline since initial import.
Why it's needed is documented nowhere.
If it is needed, then i'm assuming it's only needed to prevent
deleting redlines that are actually in the pNewRedl range;
it makes no sense to prevent deletion of redlines inside a footnote
when that footnote is deleted, because there is no valid
position left for such redlines.
The problem here is that in the range that is deleted there is a
footnote and there is another redline inside the footnote text
and that has its positions corrected rather ridiculously by
DelBookmarks() because DeleteRedline() ignored it due to the flag.
Remove the call to MaybeNotifyRedlineModification(), to fix a
SwTiledRenderingTest::testRedlineUpdateCallback failure,
assuming that it is only called to compensate for the flag
being set, seeing as this is the only such call in AppendRedline.
Change-Id: I0f266213b8525f7bee06ee0d56290f4524bf0d85
Reviewed-on: https://gerrit.libreoffice.org/46016
Tested-by: Jenkins <ci at libreoffice.org>
Reviewed-by: Michael Stahl <mstahl at redhat.com>
(cherry picked from commit 0999ac11796d2f2c7439df8c5f65d73119716a7d)
Reviewed-on: https://gerrit.libreoffice.org/46513
Reviewed-by: Caolán McNamara <caolanm at redhat.com>
Tested-by: Caolán McNamara <caolanm at redhat.com>
diff --git a/sw/source/core/doc/DocumentRedlineManager.cxx b/sw/source/core/doc/DocumentRedlineManager.cxx
index 5fc5ada08205..6aad179ab11e 100644
--- a/sw/source/core/doc/DocumentRedlineManager.cxx
+++ b/sw/source/core/doc/DocumentRedlineManager.cxx
@@ -1224,8 +1224,6 @@ DocumentRedlineManager::AppendRedline(SwRangeRedline* pNewRedl, bool const bCall
case SwComparePosition::Inside:
if( bCallDelete )
{
- meRedlineFlags |= RedlineFlags::IgnoreDeleteRedlines;
-
// DeleteAndJoin does not yield the
// desired result if there is no paragraph to
// join with, i.e. at the end of the document.
@@ -1247,8 +1245,6 @@ DocumentRedlineManager::AppendRedline(SwRangeRedline* pNewRedl, bool const bCall
}
delete pNewRedl;
pNewRedl = nullptr;
- if (eCmpPos == SwComparePosition::Inside)
- MaybeNotifyRedlineModification(pRedl, &m_rDoc);
break;
case SwComparePosition::Outside:
More information about the Libreoffice-commits
mailing list