summaryrefslogtreecommitdiff
path: root/sw/source/core/layout/tabfrm.cxx
AgeCommit message (Collapse)AuthorFilesLines
2 daysconvert some more long -> tools::LongNoel1-1/+1
grepping for stuff in template params this time Change-Id: Ia37bfd85480b3a72c3c465489581d56ad8dde851 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104855 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
10 daysuse tools::Long in swNoel1-60/+60
Change-Id: I44be72b3a9b14823ec37a3c799cffb4fb4d6e1de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104527 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-13static_cast after dynamic_castNoel1-4/+2
Change-Id: If1194bd3364fef8b2d0c26c22854745d0fb7b412 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104223 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-14loplugin:simplifybool moreNoel Grandin1-2/+2
look for expressions like !(a && !b) which can be expanded out Change-Id: I72515a9638762b050f9a258c08da39ebfa2ef8e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100579 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-07tdf#130639 sw layout: fix table positionLászló Németh1-0/+8
at fallback "switch off repeating header" by removing temporary page break immediately. Follow-up of commit f7e071a00542c414a7e9d7bcf4434d908f225e59 (tdf#88496 DOCX: disable long repeating table header). Change-Id: I3ae62456fd50f3f3fa25bfea5326a8eb9bef01c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100245 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-01loplugin:flatten in sw/core/layoutNoel Grandin1-96/+96
Change-Id: I67fd1a269d960174b88c57da4a0588f5d9252660 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99885 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-31tdf#134965 sw: avoid RemoveFollowFlowLine() SNAFUMichael Stahl1-0/+1
A follow-flow-line SwRowFrame is deleted in RemoveFollowFlowLine() while it is being iterated in stack frame #18. 0 SwRowFrame::~SwRowFrame() (this=0xaa035b0, __in_chrg=<optimized out>) at sw/source/core/layout/tabfrm.cxx:3807 1 SwFrame::DestroyFrame(SwFrame*) (pFrame=0xaa035b0) at sw/source/core/layout/ssfrm.cxx:389 2 SwTabFrame::RemoveFollowFlowLine() (this=0x9c16790) at sw/source/core/layout/tabfrm.cxx:945 3 SwTabFrame::MakeAll(OutputDevice*) (this=0x9c16790, pRenderContext=0x72afaf0) at sw/source/core/layout/tabfrm.cxx:2203 4 SwFrame::PrepareMake(OutputDevice*) (this=0x9c16790, pRenderContext=0x72afaf0) at sw/source/core/layout/calcmove.cxx:370 5 SwFrame::Calc(OutputDevice*) const (this=0x9c16790, pRenderContext=0x72afaf0) at sw/source/core/layout/trvlfrm.cxx:1791 6 SwFrame::PrepareMake(OutputDevice*) (this=0x925b740, pRenderContext=0x72afaf0) at sw/source/core/layout/calcmove.cxx:248 7 SwFrame::Calc(OutputDevice*) const (this=0x925b740, pRenderContext=0x72afaf0) at sw/source/core/layout/trvlfrm.cxx:1791 8 SwFrame::PrepareMake(OutputDevice*) (this=0x925b8e0, pRenderContext=0x72afaf0) at sw/source/core/layout/calcmove.cxx:248 9 SwFrame::Calc(OutputDevice*) const (this=0x925b8e0, pRenderContext=0x72afaf0) at sw/source/core/layout/trvlfrm.cxx:1791 10 SwFrame::PrepareMake(OutputDevice*) (this=0x925ba70, pRenderContext=0x72afaf0) at sw/source/core/layout/calcmove.cxx:248 11 SwFrame::Calc(OutputDevice*) const (this=0x925ba70, pRenderContext=0x72afaf0) at sw/source/core/layout/trvlfrm.cxx:1791 12 SwFrame::MakePos() (this=0x925bc20) at sw/source/core/layout/calcmove.cxx:552 13 SwTextFrame::MakePos() (this=0x925bc20) at sw/source/core/text/frmform.cxx:339 14 SwContentFrame::MakeAll(OutputDevice*) (this=0x925bc20) at sw/source/core/layout/calcmove.cxx:1408 15 SwFrame::PrepareMake(OutputDevice*) (this=0x925bc20, pRenderContext=0x72afaf0) at sw/source/core/layout/calcmove.cxx:370 16 SwFrame::Calc(OutputDevice*) const (this=0x925bc20, pRenderContext=0x72afaf0) at sw/source/core/layout/trvlfrm.cxx:1791 17 SwContentFrame::CalcLowers(SwLayoutFrame&, SwLayoutFrame const&, long, bool) (rLay=..., rDontLeave=..., nBottom=168478, bSkipRowSpanCells=true) at sw/source/core/layout/tabfrm.cxx:1521 18 lcl_RecalcRow(SwRowFrame&, long) (rRow=..., nBottom=168478) at sw/source/core/layout/tabfrm.cxx:1651 19 SwTabFrame::MakeAll(OutputDevice*) (this=0x93ec7e0, pRenderContext=0x72afaf0) at sw/source/core/layout/tabfrm.cxx:2421 20 SwFrame::PrepareMake(OutputDevice*) (this=0x3df3cc0, pRenderContext=0x72afaf0) at sw/source/core/layout/calcmove.cxx:316 21 SwFrame::Calc(OutputDevice*) const (this=0x3df3cc0, pRenderContext=0x72afaf0) at sw/source/core/layout/trvlfrm.cxx:1791 22 GetFrameOfModify(SwRootFrame const*, SwModify const&, SwFrameType, SwPosition const*, std::pair<Point, bool> const*) (pLayout=0x72aa850, rMod=..., nFrameType=(SwFrameType::Txt | SwFrameType::NoTxt), pPos=0x71f35e0, pViewPosAndCalcFrame=0x7ffc99f591a0) at sw/source/core/layout/frmtool.cxx:3697 23 SwContentNode::getLayoutFrame(SwRootFrame const*, SwPosition const*, std::pair<Point, bool> const*) const (this=0x6fcfb50, _pRoot=0x72aa850, pPos=0x71f35e0, pViewPosAndCalcFrame=0x7ffc99f591a0) at sw/source/core/docnode/node.cxx:1194 24 SwCursorShell::GetCurrFrame(bool) const (this=0x72a9730, bCalcFrame=true) at sw/source/core/crsr/crsrsh.cxx:2455 25 SwFEShell::GetAnyCurRect(CurRectType, Point const*, com::sun::star::uno::Reference<com::sun::star::embed::XEmbeddedObject> const&) const (this=0x72a9730, eType=CurRectType::PageCalc, pPt=0x0, xObj=empty uno::Reference) at sw/source/core/frmedt/fews.cxx:113 26 SwView::StateStatusLine(SfxItemSet&) (this=0x72af430, rSet=SfxItemSet of pool 0x6fa3d50 with parent 0x0 and Which ranges: [(10000, 10000), (10221, 10221), (10223, 10225), (11064, 11065), (21182, 21182), (21185, 21185), (21189, 21189)] = {...}) at sw/source/uibase/uiview/view2.cxx:1517 Not obvious why this changed with calling MakeFrames() instead of SwNodes::CopyNodes(bNewFrames=true) or how to best prevent it; adding another FrameDeleteGuard avoids the crash at least. (regression from 166b5010b402a41b192b1659093a25acf9065fd9) Change-Id: Ifd5a0c93064c9536429dda30a2c4ebc7a31b7e7d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99870 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-07-17sw: layout: fix missing invalidation of text frames in tablesMichael Stahl1-0/+18
... when the position of the SwTabFrame changes. The table is initially formatted on page 1, where one of its cells overlaps flys anchored in the footer, so the SwTextFrame in it contains SwFlyPortions. As the table doesn't fit on page 1, the SwTabFrame moves forward to page 2; lcl_RecalcTable() is called a bit later to invalidate pos and size of everything in the table. However, it turns out that that's not enough, when SwTextFrame::Format() is called it doesn't do anything because no part of the text has actually been invalidated via InvalidateRange_(). If the SwTextFrame were moved on its own (not via table), then SwContentFrame::MakeAll() would call Prepare(PrepareHint::FramePositionChanged) which calls ClearPara(). The SwTabFrame is moved via SwFlowFrame::PasteTree(), which calls SwTextFrame::Init() if it moves a text frame directly but does nothing for tables. So let's try to fix this similar to commit 068c133ac41c97652909b88c432e3b73010efc3e by calling Prepare(PrepareHint::FramePositionChanged) on every moved text frame if the position actually changes, like SwContentFrame::MakeAll() does; not sure what performance impact this has. (apparently regression from cc5916cd314a27b0cc99560ab887480026630a95 - whatever that means in this case, no idea how it worked before) Note: the problem only reproduces on libreoffice-6-3 branch because libreoffice-6-4 and later have another layout change from commit 3cccdabf19a99fd3f657985c1822436d7679df2b that needs reverting Change-Id: I65d3e367d56b8799e1ed32172fbbc0249c2852eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98925 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-06-30tdf#134277 sw table: fix lagging shape at page breakBakos Attila1-4/+8
Shapes anchored to characters in table cells didn't follow their cells at page break, resulting lonely shapes at the end of the previous page. Co-authored-by: Attila Bánhegyi (NISZ) Change-Id: I2149ef58696a8f5dc6f41959060d2d57f938d025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97209 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-06-13crashtesting: null deref in SwCellFrame::GetLayoutRowSpanCaolán McNamara1-1/+2
seen with swtextframe_connectfootnote_heap_use_after_free.sample Change-Id: I98da2e67065c5890d74e5f33ffc01329ff75f185 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96257 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-06-10loplugin:buriedassign in swNoel Grandin1-4/+6
limited this only fixing assignments inside "if" statements, since other things are harder to change Change-Id: If3188a3e3d5fcd94123211c97fee097ece5e2797 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95990 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-03Revert "tdf#105478 sw layout: treat minHeight as "do not split row""Justin Luth1-15/+1
This reverts LO7.0 commit aa5dc0b48cd4db6883c9b52c68b16170c9c81d1f, in order to prevent regressions like tdf#133441. Change-Id: Id08f5277621703e1577fc9db917841b8b7c0bda5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95180 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-05-20NFC sw layout: optimize assignment of bAllowSplitOfRowJustin Luth1-6/+3
1.) Remove unnecessary test for !bDontSplit, since by definition, bTableRowKeep requires !bDontSplit const bool bDontSplit const bool bTableRowKeep = !bDontSplit && ... const bool bAllowSplitOfRow = bTableRowKeep && ... 2.) Put the trivial !bPrevInd test first and so potentially avoid the non-trivial lookup of AreAllRowsKeepWithNext(pFirstNonHeadlineRow) 3.) bAllowSplitOfRow by definition contains the two requirements of !bDontSplit and !pIndPrev, so pull out and test earlier - potentially avoiding further tests. This also emphasizes its similarity to bEmulateTableKeep. Change-Id: I41cb72aa03371eacfdb68d63dc3df21f85e755bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93635 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-05-19tdf#132642 sw layout: try2 emulate table kept-with-next not splittingJustin Luth1-14/+14
This adjusts my LO 5.2 code for tdf#91083 that tried to emulate the table's keep-with-next property which doesn't have a matching counterpart in MS formats. I always confused myself trying to understand what my year-long coding attempt was trying to do. This seems much understandable, and efficient. The big clue was that it affected non-MS formats - which was unintended. Change-Id: I7886e52430cb34799e25f7fcf73500e28bbe2a55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93443 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-05-11tdf#105478 sw layout: treat minHeight as "do not split row"Justin Luth1-1/+15
Already, if minHeight is greater than the content of the row, then the row will "stay intact" and not split just because there is space for part of it on the preceeding page. However, if the content is greater than minHeight, it can split anywhere and moveBwd - since LO 5.3. At least for MS compatibility, this needs to not be split. But others agreed to change this for ODT as well, especially since this matches pre-5.3 behaviour, and will help at design-time for MS interoperability, as well as making minHeight consistent for the two different scenarios. Change-Id: Id15c44da2e7c38f6d552ffe32f92ab1c6b3c3349 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93414 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-05-06sw layout: remove useless historical timelog commentsJustin Luth1-6/+0
While there can be value in seeing bug numbers to figure out why certain code was added, these comments seem to have no value, but are just a timelog of when a formatting change was made. Change-Id: I47ccef9c7e4cd5c76aeec46867424dd8c9d05e13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93441 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-04-23pass SvxBrushItem around by unique_ptrNoel Grandin1-1/+1
we never create an object that is actually shared, so this is wasted Note1: in IMPL_LINK_NOARG(SwEditRegionDlg, OkHdl, weld::Button&, void) there was a comparison if( aBrush != pRepr->GetBackground() || ... which I removed Note2: In bool SwDoc::GetBoxAttr( const SwCursor& rCursor, std::shared_ptr<SfxPoolItem>& rToFill ) which had a condition else if( rToFill != xBack ) I changed to compare contents Change-Id: Idd769f44917c5ccc7e9f4bfbaddf12f9cd4151cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92791 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-04tdf#123116 sw layout: don't "page-break" before oversized rowJustin Luth1-7/+2
followup to LO 7.0 commit b271cc46851c61ddef20dc869bf339c857f76b18 THIS PATCH INTENTIONALLY BREAKS COMPATIBILITY WITH MSO. In the rather rare case of a table row that is larger than the page, but is nevertheless set to not allow splitting, historically this oversized row has started on a new page and disappeared into the bottom of the page. The commit mentioned above allowed the row to spill over onto the next page, but kept the "page break" feature for maximum compatibility and interoperability with MSWord. However, all of that seems completely senseless, so the most natural thing for the document to do would be to completely ignore the do-not-split-row setting and let everything flow naturally, without leaving a potentially large gap in order to start on a new page. Just let the oversized row stay attached to the prior row. The cases are rare enough that interoperability isn't important. In any case, for .doc documents authored by LibreOffice, Word is still going to try to squeeze it all on one page anyway, so even if we do leave a gap and start a new page, there will still be a difference. Now that compatibilityMode=15 for new .docx files, MSO almost perfectly matches the behaviour prior to this patch, so this is the one case where users might raise a complaint. The prior patch was committed first just to prove that we could fallback to a more compatible state in case this radical departure from the norm is unacceptable. Change-Id: I47c78526d4c4fda2c48e38fb64788bafbc06f2c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90131 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-03-24tdf#131282 sw layout: fix shifted down table next to a fly frameMiklos Vajna1-2/+7
Regression from commit fd7749fddc5a767461dfced55369af48e5a6d561 (sw: fix handling of table vs fly overlaps in the AddVerticalFlyOffsets case, 2020-02-14), the problem was that the rectangle of the fly frame included spacing when overlapping was checked. Given that this code was explicitly added for Word compat purposes, change it to ignore spacing. You can see that Word doesn't care about spacing: increase the left margin of e.g. the pie chart in the bugdoc to some large value and the table is still not shifted down. Writer shifted the table down as the small spacing was already enough to detect an overlap: debug:21457:21457: SwTabFrame::CalcFlyOffsets: aTabRange is 896 -> 3698 debug:21457:21457: SwTabFrame::CalcFlyOffsets: aFlyRange is 3650 -> 6290 If we don't include that ~3 px spacing, then we don't overlap, similar to Word. Change-Id: I154c211bb0700d132fd168f49c1bbfb29e8caeb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90939 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-12tdf#123116 sw layout: allow rows larger than page to split anywayJustin Luth1-2/+21
Even if the row is set to not allow splitting across pages, ignore that setting if the row is too big to fit on a single page. Don't worry too much about compatibility, because there is no sensible reason why anyone would have hidden content like this intentionally. An oversized row has always moved to start a new page. While that may not strictly be necessary anymore, to approximate a bit of backward compatibility, continue to do that. MS Word will do the same... Word, prior to 2013, always tries to keep the whole row on one page. In 2013 (compatibleMode == 15), native documents will be treated like this patch. So, although this patch throws away senseless compatibility with existing documents, it is interoperable with anything authored by Word >= 2013. Word 2013/2016 also opens .odt files this way. HOWEVER, LO authored .docx files do not set compatibleMode=15, so Word will treat them the old way - hiding all the content on a single page. Change-Id: I306e22230ed6fe21f6b66700ffd7615678859f5d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90005 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-02speedup sw build a littleNoel Grandin1-0/+1
from 11m46 to 11m21 Used ClangBuildAnalyzer to find headers that took a long time to parse (in total, across all modules). (*) moved the boost stuff out of sw/inc/docary into a new header. (*) make sw/inc/ndtxt no longer include doc.hxx Change-Id: Ia1d4ebddb4ddd4ec4ffbc011f4a5e24a42b46d3f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89808 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-02sw: layout: fix wrongly positioned table rows in --convert-to pdfMichael Stahl1-0/+12
If the document is loaded via UI, the first layout action is triggered from resizing the Window and the table is positioned properly on the first try. If the document is loaded via --convert-to, only getRendererCount() formats the content of the table, and the table is positioned 3 times but its first row is only positioned 2 times. The first time the table id="56" is positioned, the previous table id="50" is at correct Y 5988 but its content isn't formatted yet, so its height is almost 0 (just table's border etc.), so the table ends up at y = 6271. The second time the table id="56" is positioned, the previous table id="50" is at wrong Y 7937 and its content is valid, so its height is 1203, so the table ends up at y = 9140. The third time the table id="56" is positioned, the previous table id="50" is at correct Y 5988 and its content is valid, so its height is 1203, so the table ends up at correct y = 7191 ... but the first SwRowFrame remains at y = 9140 and is never repositioned, and the lower rows are cut off (invisible). Change SwTabFrame::MakeAll() so that a MakePos() that moves the table itself does not leave the first SwRowFrame's position valid, which should ensure that all rows are repositioned. (And work around C++'s particularly unhelpful type system.) This happens since the earliest version checked, OOo 3.3. Change-Id: If3dfe1ffcb81e03aa4f4bffcf33a237f0c92bd08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89735 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-02-14sw: fix handling of table vs fly overlaps in the AddVerticalFlyOffsets caseMiklos Vajna1-2/+28
When a table overlaps with a fly frame, Writer creates a fly portion inside the relevant cell frame (increasing its height), and Word shifts the table down. Both are valid approaches, but the rendering result is different in case the table has a border. So keep the default unchanged, but in case the AddVerticalFlyOffsets compat flag (set by the Word importers) is set, avoid the overlap the Word way. Note that the table frame uses the full width (available in the body) even for e.g. 50% width tables, so check for the overlap using the print area, which does not always overlap. Finally, don't always require a valid frame area definition from the fly frame: - the mentioned i#46807 bugdoc currently doesn't need that check - the fly frame area definition becomes valid only after already positioning the table, leading to an overlap Keep that check for the non-compat case, though. Change-Id: I9202050befebf2efdbb5395ded6fcb52b378d8e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88724 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-01-17tdf#88496 DOCX: disable long repeating table headerLászló Németh1-3/+4
if the pages could contain only that, hiding the non-repeating table rows. This behavior is similar to MSO. See also commit 110781a3a27dffe9e6690839bdce993796a08331 (tdf#58944 DOCX import: workaround for hidden table headers). Change-Id: I646be45c6d2c5fe9e1df0badeee4583097dc79f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86928 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2020-01-06Removed redundant semicolonsAndrea Gelmini1-1/+1
Change-Id: Ife14b8c3f7d121deb390deb5f405dd42d3016acf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86156 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-11convert PrepareHint to scoped enumNoel Grandin1-6/+6
Change-Id: Ia7c987dc59f335d76ee874c1bb51707cb55ff41e Reviewed-on: https://gerrit.libreoffice.org/84922 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-11convert SwFrameSize to scoped enumNoel Grandin1-8/+8
Change-Id: I7e1e641ff180035c7dcefdcfdd185eadbae32142 Reviewed-on: https://gerrit.libreoffice.org/84850 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-04tdf#128611 sw: improve rotated text layout in table cellsMiklos Vajna1-0/+19
The problem was that in case a table with 1 row and 2 cells has rotated text in the A1 cell, then the row height is 0, so we aggressively try to break up the text into multiple lines. Then the A2 cell adds more content, so the row height is increased, but the A1 cell is not re-layouted to make use of the increased amount of vertical space. A similar (but working) situation is vertical alignment of cell content, there adding more content to A2 re-formats A1. Fix the problem in a similar way: track if a text frame contains at least one rotated portion, and throw away the portions of the text frame at the end of SwCellFrame::Format(), after vertical alignment is handled. Change-Id: I65383bb1af486771dc671dca3d8bbf1831ba94ff Reviewed-on: https://gerrit.libreoffice.org/84433 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-11-27tdf#108642 remove dynamic_castNoel Grandin1-4/+12
use virtual method instead. Takes the opening time from 10.5s to 9.2s for me. Change-Id: I015c05b112dd7e8b7ea3ef722e082d25a3062cce Reviewed-on: https://gerrit.libreoffice.org/83847 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-18loplugin:virtualdead unused param in SwFlowFrame::ShouldBwdMovedNoel Grandin1-3/+3
Change-Id: Ife69fe8c9023682278c02d037d35d15bd015f127 Reviewed-on: https://gerrit.libreoffice.org/81014 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-02tdf#124601 sw FollowTextFlow: fix vert pos of objects outside the current cellMiklos Vajna1-1/+11
There were two problems here: 1) CalcHeightWithFlys() considered all follow-text-flow objects when determining the cell size, while wrap-through objects should never influence the layout of text (i.e. when they conflict, the second should have priority). 2) Once the cell had correct height, the oscillaction described in the SwFlyFreeFrame::CheckClip() comment started. Such a position update was already disabled for headers, but footers have exactly the same problem. In the case of the bugdoc, we jumped between 14618 and 14744 twips, till finally layout loop control kicked in. [ FollowTextFlow is meant to be same behavior as Word's layoutInCell shape property, so this is expected to improve rendering of existing documents. It's not likely that any user would opt in for FollowTextFlow to have the old close-but-not-exactly-matching behavior. ] Change-Id: I6b3b672fc82c6c67dbbdd35c349613fe4cda610d Reviewed-on: https://gerrit.libreoffice.org/79980 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-10-01Avoid redundant IsAtEnd: NextItem returns nullptr iif iterator is at endMike Kaganski1-9/+7
To keep the check efficient, split NextItem to inline and Impl parts Change-Id: Id5877a3c5bed73aac9c39c655b106a715cf888ea Reviewed-on: https://gerrit.libreoffice.org/79894 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-08-09Fix typosAndrea Gelmini1-1/+1
"its really" Change-Id: Ic0b41597c83be6c1c66b9cdf6ccbf80b0c2bc9ef Reviewed-on: https://gerrit.libreoffice.org/77204 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-07Fix typosAndrea Gelmini1-4/+4
Change-Id: Ie48d61e07ce44a3022b92cd295527b65532a64e7 Reviewed-on: https://gerrit.libreoffice.org/76773 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-01tdf#126138 sw: disambiguate SwTabFrame::FindLastContent()Michael Stahl1-11/+15
Most callers don't actually care about the SwContentFrame but want its upper; introduce FindLastContentOrTable() for those. Last frame can be a SwTabFrame quite simply if you delete the trailing paragraph with Ctrl+Shift+Del from the last cell of nested table. Change-Id: Ieab9e1ff2a5fa7b75d84dfc3cc4d17c867751b0c Reviewed-on: https://gerrit.libreoffice.org/76759 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-08-01tdf#126138 sw: invalid static_cast in SwTabFrame::FindLastContent()Michael Stahl1-1/+11
Change-Id: I64412f32f1be78a647710e96f0a92cd78921d784 Reviewed-on: https://gerrit.libreoffice.org/76755 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-07-02sw: remove hacky liveness check in lcl_RecalcRow()Michael Stahl1-41/+15
Crashtesting didn't find any assert there so now revert most of commit e4400f4c4e267f8528df3a7d5a09623c888bd10c. Change-Id: I6e990b76af0d047b50115cb019a352f1a04a65ed Reviewed-on: https://gerrit.libreoffice.org/74954 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-06-27sw: avoid deleting the iterated SwRowFrame on tdf104188-4.odtMichael Stahl1-12/+14
The change in commit 1e6dec4b4313212a3bdc6bb06155fd65e795368b was not enough to fix this problem. SwContentFrame::CalcLowers() may move a SwTextFrame to the previous page; in that case Calc() on the upper is a bad idea because it may then call RemoveFollowFlowLine() and delete the SwRowFrame that is being iterated. There is one other (unknown) bugdoc with this problem, let's hope it's fixed as well... (regression from commit 18765b9fa739337d2d891513f6e2fb7c3ce23b50) Change-Id: I3c55a0d7ef0350a482fb150d3e96c3b34853400d Reviewed-on: https://gerrit.libreoffice.org/74793 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-06-21sw: fix SwUiWriterTest::testTdf114306_2Michael Stahl1-5/+5
sw/qa/extras/uiwriter/uiwriter.cxx:5908:SwUiWriterTest::testTdf114306_2 equality assertion failed - Expected: 4 - Actual : 5 Mysteriously this doesn't happen on master when running make sw.check but reproduces with make CppunitTest_sw_uiwriter CPPUNIT_TEST_NAME="testTdf114306_2" The problem is that the early-returns in SwTabFrame::RemoveFollowFlowLine() are too late: the SetFollowFlowLine( false ); was already executed and henceforth the SwTabFrame thinks it doesn't have a follow-flow-line, so it will never be merged again and new follow-flow-line may be created. (test fail is regression from 1e6dec4b4313212a3bdc6bb06155fd65e795368b) Change-Id: Ic5a2ef4219f212c8b4d34fd47d3d67f32de45f8e Reviewed-on: https://gerrit.libreoffice.org/74500 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-06-21sw: prepare for revert of hacky liveness checkMichael Stahl1-0/+1
This problem should hopefully be fixed with commit 1e6dec4b4313212a3bdc6bb06155fd65e795368b. Change-Id: Iebc223d1968350905869421a8a3a6ca2df0b8069 Reviewed-on: https://gerrit.libreoffice.org/74501 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-06-20Fix typoAndrea Gelmini1-1/+1
Change-Id: I41d3f505a398974fa4b27eae1538a58f2871a4dd Reviewed-on: https://gerrit.libreoffice.org/74390 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-06-19sw: improve translation of comments in tabfrm.cxxMichael Stahl1-59/+60
Change-Id: I17eda9a9cb0425983fe6d23ee2c5b5db4a221b5e Reviewed-on: https://gerrit.libreoffice.org/74346 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-06-19sw: convert that to assert()Michael Stahl1-1/+1
Change-Id: I126c2565720770ca0fca9fef69a1690cc0bca948 Reviewed-on: https://gerrit.libreoffice.org/74345 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-06-05tdf#125685 sw: disregard footnotes in follow table on table splitMichael Stahl1-1/+34
The first problem here is that the table isn't fully formatted; it fails with: warn:legacy.osl:22975:22975:sw/source/core/layout/tabfrm.cxx:2639: debug assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by fix i44910 The situation is that there is a big table split across pages; the first line of the table would fit onto the previous page so its follow frame moves backward and then the table frame tries to split again. During SwTabFrame::Split(), all the frames in the table are formatted, and at that point a footnote that was on the next page is moved to this page. A nested table frame also splits, such that it fits inside the page... but then the split of the outer table fails by 5 twips, because the moved footnote has reduced the space available for the outer table. The footnote is anchored in the inner table's follow frame, which would be moved to the next page anyway, taking the footnote with it. Fix this in lcl_RecalcSplitLine() by checking for footnotes that are anchored in the follow frame of the top-level table being split, and adding their height to the available space on the page. Fixing the first problem avoids the crash as well; the crash happens since 18765b9fa739337d2d891513f6e2fb7c3ce23b50 and it's rather hard to avoid it in a situation where formatting starts at the end and recurses into an unformatted table preceding it, which isn't supposed to happen. Change-Id: I85286583c1c4930468a1c283afc98504cd35bb71 Reviewed-on: https://gerrit.libreoffice.org/73465 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-05-23tdf#119109 sw: fix SwTableFrame follow chain formattingMichael Stahl1-0/+3
The remaining problem is that with the previous commit, the layout stops at some point and everything is crammed into the next-to-last page, with the following symptom: warn:legacy.osl:7667:7667:sw/source/core/layout/tabfrm.cxx:2642: debug assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by fix i44910 This is apparently because of some very funny recursion that goes in circles until it formats some part of the "outer" table again. 0 SwTabFrame::MakeAll(OutputDevice*) (this=0x82b0280) at tabfrm.cxx:2642 ^ mpUpper -> 928 - top-level SwTabFrame and m_pFollow of 905 1 SwFrame::PrepareMake(OutputDevice*) (this=0x82b0280) at calcmove.cxx:372 2 SwFrame::Calc(OutputDevice*) const (this=0x82b0280) at trvlfrm.cxx:1790 3 SwFrame::PrepareMake(OutputDevice*) (this=0x6c06ba0) at calcmove.cxx:247 4 SwFrame::Calc(OutputDevice*) const (this=0x6c06ba0) at trvlfrm.cxx:1790 5 SwFrame::PrepareMake(OutputDevice*) (this=0x82aebf0) at calcmove.cxx:247 6 SwFrame::Calc(OutputDevice*) const (this=0x82aebf0) at trvlfrm.cxx:1790 7 SwFrame::PrepareMake(OutputDevice*) (this=0x6d674e0) at calcmove.cxx:247 8 SwFrame::Calc(OutputDevice*) const (this=0x6d674e0) at trvlfrm.cxx:1790 ^ m_pFollow->mpNext -> 332 - again! it's now m_pFollow->mpNext 9 SwTabFrame::MakeAll(OutputDevice*) (this=0x6d64570) at tabfrm.cxx:2544 ^ 303 - nested SwTabFrame, used to precede 332 but has now split and its m_pFollow precedes 332 10 SwFrame::PrepareMake(OutputDevice*) (this=0x6d674e0) at calcmove.cxx:313 11 SwFrame::Calc(OutputDevice*) const (this=0x6d674e0) at trvlfrm.cxx:1790 ^ 332 - SwTextFrame originally inside 991, but moved under top-level SwTabFrame 928 at this point 12 SwContentFrame::CalcLowers(SwLayoutFrame*, SwLayoutFrame const*, long, bool) (pLay=0x6dccbf0, pDontLeave=0x6ed6e30, nBottom=9223372036854775807, bSkipRowSpanCells=true) at tabfrm.cxx:1479 ^ m_pLower -> 991 - SwRowFrame 13 lcl_RecalcRow(SwRowFrame*, long) (pRow=0x6dccbf0, nBottom=9223372036854775807) at tabfrm.cxx:1614 14 lcl_RecalcTable(SwTabFrame&, SwLayoutFrame*, SwLayNotify&) (rTab=..., pFirstRow=0x6dccbf0, rNotify=...) at tabfrm.cxx:1691 15 SwTabFrame::MakeAll(OutputDevice*) (this=0x6ed6e30) at tabfrm.cxx:2082 ^ m_pFollow -> 905 - top-level SwTabFrame 16 SwTabFrame::MakeAll(OutputDevice*) (this=0x381d3e0) at tabfrm.cxx:2504 17 SwFrame::PrepareMake(OutputDevice*) (this=0x381d3e0) at calcmove.cxx:372 18 SwFrame::Calc(OutputDevice*) const (this=0x381d3e0) at trvlfrm.cxx:1790 ^ 866 - top-level SwTabFrame 19 SwLayAction::FormatLayoutTab(SwTabFrame*, bool) (this=0x7fff95aa3f20, pTab=0x381d3e0, bAddRect=true) at layact.cxx:1483 20 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7fff95aa3f20, pLay=0x6cfedc0, bAddRect=true) at layact.cxx:1375 21 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7fff95aa3f20, pLay=0x6e23fd0, bAddRect=true) at layact.cxx:1380 The first attempt was to add a TextFrameLockGuard around the pFrame->MakeAll() call in PrepareMake(), with corresponding test in SwTabFrame::MakeAll() ... but a similar problem still occurred, just now on page 18 instead of page 12. Another idea is to prevent PrepareMake() from formatting the SwTableFrame's follow *again*; it was already formatted by SwTabFrame::MakeAll() anyway, just before it calls pNxt->Calc(). With this, we get 23 pages for the bugdoc, same as before that commit: (regression from 18765b9fa739337d2d891513f6e2fb7c3ce23b50) Change-Id: I71e3f92b5f19b800626a008527fa75d08641e8de Reviewed-on: https://gerrit.libreoffice.org/72799 Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> Tested-by: Michael Stahl <Michael.Stahl@cib.de>
2019-05-14tdf#42949 Fix IWYU warnings in sw/source/core/inc/[t-w]*Gabor Kelemen1-0/+1
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I7cd9837360e244741bfa22b4693fd221241daf12 Reviewed-on: https://gerrit.libreoffice.org/71833 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-05-09tdf#124675 sw: fix crash when moving SwTextFrame in table to prev pageMichael Stahl1-1/+1
The problem is that the SwTabFrame and SwRowFrame that are being iterated are deleted: 7 SwFrame::DestroyFrame(SwFrame*) (pFrame=0x79052c0) at sw/source/core/layout/ssfrm.cxx:386 8 SwTabFrame::RemoveFollowFlowLine() (this=0x5bf07d0) at sw/source/core/layout/tabfrm.cxx:907 9 SwTabFrame::MakeAll(OutputDevice*) (this=0x5bf07d0) at sw/source/core/layout/tabfrm.cxx:1839 10 SwFrame::PrepareMake(OutputDevice*) (this=0x5bf07d0) at sw/source/core/layout/calcmove.cxx:344 11 SwFrame::Calc(OutputDevice*) const (this=0x5bf07d0) at sw/source/core/layout/trvlfrm.cxx:1790 12 SwFrame::PrepareMake(OutputDevice*) (this=0x603a570) at sw/source/core/layout/calcmove.cxx:247 13 SwFrame::Calc(OutputDevice*) const (this=0x603a570) at sw/source/core/layout/trvlfrm.cxx:1790 14 SwFrame::PrepareMake(OutputDevice*) (this=0x5daf120) at sw/source/core/layout/calcmove.cxx:247 15 SwFrame::Calc(OutputDevice*) const (this=0x5daf120) at sw/source/core/layout/trvlfrm.cxx:1790 16 SwFrame::PrepareMake(OutputDevice*) (this=0x6005ca0) at sw/source/core/layout/calcmove.cxx:247 17 SwFrame::Calc(OutputDevice*) const (this=0x6005ca0) at sw/source/core/layout/trvlfrm.cxx:1790 18 SwFrame::MakePos() (this=0x6094330) at sw/source/core/layout/calcmove.cxx:490 19 SwTextFrame::MakePos() (this=0x6094330) at sw/source/core/text/frmform.cxx:343 20 SwContentFrame::MakeAll(OutputDevice*) (this=0x6094330) at sw/source/core/layout/calcmove.cxx:1346 21 SwFrame::OptPrepareMake() (this=0x6094330) at sw/source/core/layout/calcmove.cxx:368 22 SwFrame::OptCalc() const (this=0x6094330) at sw/source/core/inc/frame.hxx:1060 23 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x8a349c0, bAddRect=false) at sw/source/core/layout/layact.cxx:1362 24 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x79052c0, bAddRect=false) at sw/source/core/layout/layact.cxx:1357 25 SwLayAction::FormatLayoutTab(SwTabFrame*, bool) (this=0x7ffc6da48350, pTab=0x7a9c300, bAddRect=false) at sw/source/core/layout/layact.cxx:1569 26 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x7c30300, bAddRect=true) at sw/source/core/layout/layact.cxx:1354 27 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x79e1780, bAddRect=true) at sw/source/core/layout/layact.cxx:1357 28 SwLayAction::InternalAction(OutputDevice*) (this=0x7ffc6da48350) at sw/source/core/layout/layact.cxx:546 They are deleted because the last SwTextFrame was moved via MoveBwd() to the previous page, and is formatted there. (regression from commit 18765b9fa739337d2d891513f6e2fb7c3ce23b50) Prevent this via: * delete-guard for the SwRowFrame - causing RemoveFollowFlowLine() to return early (also, let it return false, so the Join() isn't even called, although that doesn't make a difference in practice because of the next item:) * join-guard for the SwTabFrame - otherwise tabfrm.cxx:2199 will Join() it anyway This means that when the page with the follow-frame is done formatting, the empty SwTabFrame with no SwTextFrame in it will remain. Fortunately this is not a problem, because due to the moving, the previous page will be invalid and layact.cxx:613 will iterate to the previous page and format it again; then tabfrm:2199 of the master SwTabFrame will detect that the follow SwTabFrame is empty and Join() it. Change-Id: I2cca89d63b81e7d4909319fa4feab2f5d67a6ff3 Reviewed-on: https://gerrit.libreoffice.org/71996 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-05-08tdf#116501 fix freezing at embedded text tablesLászló Németh1-1/+3
by disabling their in-row splitting using loop control. Change-Id: Ibd93213fa0ce45458ce188de20da982e4abc17c5 Reviewed-on: https://gerrit.libreoffice.org/71920 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-04-25WIP: Further preparations for deeper Item changesArmin Le Grand1-2/+2
(1) Migrated all still existing binary load/save stuff in SfxPoolItem to legacy files. Isolated from Item implementations. Adapted all usages. No more methods Create/Store needed, also GetVersion removed (2) Removed operator= for SfxPoolItem. Adapted all usages. Goal ist to handle Items more as Objects ('Object-Oriented') in the sense to move/handle instances, not to copy one instance over another one (which is more and more problematic with hard to copy content as UNO API stuff or similar). This lead to much more usages of std::shared_ptr which correlates well with future plans fr Items (see dev branch). Next logic step will be to also remove copy constructor Linux build and corrections done Fixed Writer test and removed unused defines Fixed another unused m,acro Started to unify the AutoFormat stuff Changes to OUString constructor usages, tests completely No idea why, but SfxStringItem constructor which takes a OUString& now insists of not getting ::OUString's handed in - changed all 'SfxStringItem.*OUString.*".*"' accordingly Change-Id: Ibed7358b18fb019994a7490332b9d797a6694c29 Reviewed-on: https://gerrit.libreoffice.org/71075 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2019-03-19tdf#42949 Fix IWYU warnings in sw/source/core/inc/[a-f]*Gabor Kelemen1-0/+2
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I6c3ae806cbb4a00381e39414ff8c8fede5bf1733 Reviewed-on: https://gerrit.libreoffice.org/69150 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>