summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-02-21sw: layout: fix overlapped table rows in --convert-to pdffeature/cib_contract57lMichael Stahl
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 positioning goes wrong. Somehow the 2 rows of the table in the fly end up on the same Y position, because when the text frame in the 1st row is formatted and grows from 0 to 230, the already-valid position of the cell frame in the 2nd row is not invalidated. This happens since the earliest version checked, OOo 3.4 beta. This fix is somewhat similar to commit 068c133ac41c97652909b88c432e3b73010efc3e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129851 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit e7874c936dd1ff9b3423eb7477cbee2494535176) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129845 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> (cherry picked from commit 06bb600ce3445abe095b8011ec7e66b33badb4ef) Change-Id: I3259c440265cfe40dc7731cb4830bfe2487acf38
2022-02-21sw: fix layout loop on soffice --convert-to pdf ooo95698-1.odtMichael Stahl
For unknown reasons, this loops since commit 32902f66e7749b2d06d13f50416be5323a0c0ea9a "sw_redlinehide: make layout based Show/Hide mode the default" The problem is that when page 1 is layouted for the first time, it splits into 6 pages, and then the SwTabFrame 47 decides that it wants to move its follow flow line because it fits onto page 1. Then splitting the SwTabFrame again fails, but for this RemoveFollowFlowLine() was called a 2nd time and removed the one on page 3. The result is a layout with content on page 1, nothing on page 2, 3 and again content on page 4. This seems to reoccur every time page 1 is formatted. But the first RemoveFollowFlowLine() was wrong because CalcHeightOfFirstContentLine() returns 0 because lcl_CalcHeightOfFirstContentLine() didn't handle the case of SwSectionFrame containing SwTabFrame. This is similar to commit e024cad7c1365da6a198656c3ca0c32b28938e87 doing the same thing for text frames in section. Change-Id: I23fb4d1d56622039f461bb2d357a9c88db140605 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129800 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit b4271e028686d729189afc5e42a9c310f81144f3) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129828 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit 60811f97c753360393f52aa747837db15a722162)
2022-01-21Release 6.3.6.14Samuel Mehrbrodt
Change-Id: I3ea3698f6e8473dad3211a1b18788a9a49c039e7
2022-01-21tdf#141556 Fix 100% CPU usage in Writer idle loopLuke Deller
Do not interrupt the idle layout processing unnecessarily, because if it is continually interrupted before making enough progress then it will keep resuming at the same page, never finishing, constantly using CPU. This is achieved with two changes: - Revert "tdf#123583 use TaskStopwatch for Writer Idle loop" (commit 383032c50a3e3354f04200ce984a47ab9d2c5c67) which introduced a stopwatch timer to interrupt idle processing every 50ms. This reversion restores the previous behaviour where idle processing is interrupted only when there is an input event. - Filter out TIMER events so that they do not interrupt the idle loop; this fixes both tdf#123583 and tdf#141556 Conflicts: sw/source/core/inc/layact.hxx sw/source/core/layout/layact.cxx Change-Id: Ic989631e5f32199209d64b66b72059253fc0167a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113825 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 0fedac18214a6025401c4c426466a5166553e8ec) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114944 (cherry picked from commit b33148071ae6256845352f8625e58b1ab95be41c)
2022-01-18Update .gitreviewSamuel Mehrbrodt
Change-Id: I360c95365dbe553dc589a0a7da99189f1148a754
2022-01-18tdf#123583 use TaskStopwatch for Writer Idle loopJan-Marek Glogowski
I don't see much of a point in the extra CheckIdleEnd() function. We already check IsInterrupt() almost everywhere, so move that check in there. An other strange thing is the Idle job, which should just be interrupted by keyboard events (using SetInputType(, which this patch removes). Unlucky for me this code was there in the initial import. I can just say that othing obvious breaks... Change-Id: Ia5955d1eaf2ab612f2c4b63b0e458ed92507b75c Reviewed-on: https://gerrit.libreoffice.org/77040 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit 383032c50a3e3354f04200ce984a47ab9d2c5c67)
2022-01-18Drop bogus check from TimerTest::testStopwatchStephan Bergmann
(that had been added with 6e13585508ca3c9b66c6571ad1eb42bfcb66ef0b "Add a TaskStopwatch to interrupt idle loops"). For each StopwatchIdle, m_nIters counts the calls to Invoke before it calls Stop (which it calls based on tools::Time::GetSystemTicks calculations). But the number of such GetSystemTicks() spent in each Invoke is nondeterministic (it can e.g. be affected by the overall system load), so a2Idle may Stop prior to a1Idle and thus have a lower nIter2 than nIter1. Change-Id: I416eee9774c3605be25e9832b24dec7d9dcb00c2 Reviewed-on: https://gerrit.libreoffice.org/77561 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 92e42a0fde32e3f2dbe2c786a0e41547e4912b4b)
2022-01-18Add a TaskStopwatch to interrupt idle loopsJan-Marek Glogowski
If we have multiple pending Idles, they will interrupt / starve each other, because there will be an instant pending timeout for the next Idle. This patch introduces a time slice to tasks, so long running events can use a TaskStopwatch to do the real interrupt after running out of their time slice. Apart from the time, this breaks when AnyInput is available, except for the timer event. This class just helps to track the time, as the scheduler is coop, not preemptive. Change-Id: I9d0b4a5aa388ebdf496b355d100152d890224524 Reviewed-on: https://gerrit.libreoffice.org/75568 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit 6e13585508ca3c9b66c6571ad1eb42bfcb66ef0b)
2022-01-17tdf#116501 sw: layout: check for flys in SwTabFrame::ShouldBwdMoved()Michael Stahl
On loading, this hits loop control warn:legacy.osl:580715:580715:sw/source/core/layout/layact.cxx:543: LoopControl_1 in SwLayAction::InternalAction This is because there's a fly frame 404 anchored at the last text frame 353 on page 2 inside the nested table 347. ShouldBwdMoved() sees that there is space on the bottom of page 2 and hence the follow flow row joined, but then it immediately splits again in the same way as before due to the fly with WrapTextMode_NONE. But then the outer table's cell 273 (upper of 347) is invalidated again, hence the loop. Try to check for overlapping flys in SwTabFrame::ShouldBwdMoved() by reusing CalcFlyOffsets(), which is ... not quite ideal, but perhaps better than copy-pasting half of it to a new function. This should have less side effects than the previous fix, but a problem remains that clicking on the shape on bottom of page 2 causes the layout to go wonky, but that was also the case with previous fix. Note there's a check of SwLayouter::DoesRowContainMovedFwdFrame() there already, but that doesn't help because it will only detect when the fly itself was moved forward, but in this case the fly remains on the page. Also likely it wouldn't be a good idea to move a text frame forward if the only thing of it that fits on a page is an anchored fly (i.e. its follow has mnOffset=0) because that can be intentional. Change-Id: I0376f7dcb784c006990336233c97f5093aaccb77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117473 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit f1439db62eb36ef5fbc9111b87dc4e0f24b3cb86) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117602 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit 35a0bfa7bf52ca713ea8e57cd982d16723be920d)
2022-01-17sw: add BIRT layout test documentMichael Stahl
This nested table is an example that was broken by commit 91b2239783dc716bd71ce7962bfd7e341dfe4175 - if loaded with a wide window, it goes into layout loop; if loaded with a tall window size where page 2 is visible, strangely it doesn't loop. Change-Id: I5e73cfcd928ff1a321667c1a75b0ba7f348d4b77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117587 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit a41c71838d4662adf1ada9d46ec6e070cae7e695) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117603 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit 5e658c91a5d1e69e34384dd50ac8ada358ebd8ba)
2022-01-17Revert "tdf#116501 fix freezing at embedded text tables"Michael Stahl
This reverts commit 91b2239783dc716bd71ce7962bfd7e341dfe4175. This breaks documents that have many nested tables. For example Eclipse BIRT generates reports with tables nested 8 levels deep, they run into the counter in no time and, ironically, one goes into a layout loop because of this counter. Change-Id: I7451d01787903bbc60b305da3dc72f8259175e97 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117472 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit ee042a371e98cdcc59848f0b953f1ce545e18e31) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117601 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit 0f026c6e7186ef57e5806348a320f8383dfb7dc7)
2022-01-17tdf#142326: Adapt to "libstdc++: Implement LWG 1203 for rvalue iostreams"Stephan Bergmann
...for libstdc++ 11.2, similar to 1f3dddd6f21d91c429190ae314dadeec409f35f4 "Adapt to "libstdc++: Implement LWG 1203 for rvalue iostreams" for libstdc++ 12. The libstdc++ change referenced there has been backported to the releases/gcc-11 branch past the releases/gcc-11.1.0 tag (i.e., only towards libstdc++ 11.2) as <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ca7d2f2ec9142995179a5d832a946b50de05e659> "libstdc++: Implement LWG 1203 for rvalue iostreams". According to <https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html>, <https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html#abi.versioning.__GLIBCXX__>, and <https://gcc.gnu.org/develop.html#timeline>, the right __GLIBCXX__ value for libstdc++ 11.1 should be 20210427, but at least libstdc++-devel-11.1.1-1.fc34.x86_64 defines it as 20210428 while not including the above "libstdc++: Implement LWG 1203 for rvalue iostreams" commit, so use that value here. Change-Id: I4e2c6d6ad8156a83f5c4bc861e4a118271928a20 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115738 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins (cherry picked from commit 95e26d3dce4f5a3b2d010d5ca47b4e450905a100)
2022-01-17Adapt to "libstdc++: Implement LWG 1203 for rvalue iostreams"Stephan Bergmann
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=aa475c4ac80733f85ba47b109fc1900f05e810e2> towards GCC 12, so that now "the return type is the original rvalue stream type not its base class." (And which would thus have caused issues like > sfx2/source/control/bindings.cxx:1323:19: error: dynamic_cast from rvalue to reference type '::std::ostringstream &' (aka 'basic_ostringstream<char> &') > ? SAL_STREAM("File: " << pFile << " Line: " << nLine) : "")); > ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > include/sal/log.hxx:198:6: note: expanded from macro 'SAL_STREAM' > (dynamic_cast< ::std::ostringstream & >(::std::ostringstream() << stream).str()) > ^ > include/sal/log.hxx:341:20: note: expanded from macro 'SAL_INFO' > SAL_WHERE, stream) > ~~~~~~~~~~~^~~~~~~ > include/sal/log.hxx:155:68: note: expanded from macro 'SAL_DETAIL_LOG_STREAM' > SAL_DETAIL_LOG_STREAM_PRIVATE_(level, area, where, stream); \ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ > include/sal/log.hxx:133:45: note: expanded from macro 'SAL_DETAIL_LOG_STREAM_PRIVATE_' > ::sal::detail::StreamStart() << stream) == 1) \ > ^~~~~~ now. While the issue with old libstdc++ that originally prompted the dynamic_cast was > sfx2/source/control/bindings.cxx:1323:19: error: no member named 'str' in 'std::basic_ostream<char>' > ? SAL_STREAM("File: " << pFile << " Line: " << nLine) : "")); > ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > include/sal/log.hxx:194:40: note: expanded from macro 'SAL_STREAM' > (::std::ostringstream() << stream).str() > ^ > include/sal/log.hxx:336:20: note: expanded from macro 'SAL_INFO' > SAL_WHERE, stream) > ~~~~~~~~~~~^~~~~~~ > include/sal/log.hxx:155:68: note: expanded from macro 'SAL_DETAIL_LOG_STREAM' > SAL_DETAIL_LOG_STREAM_PRIVATE_(level, area, where, stream); \ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ > include/sal/log.hxx:133:45: note: expanded from macro 'SAL_DETAIL_LOG_STREAM_PRIVATE_' > ::sal::detail::StreamStart() << stream) == 1) \ > ^~~~~~ .) The libstdc++ macro _GLIBCXX_RELEASE is reportedly available since GCC 7.1. Change-Id: I1ee6eabb66355c1f28b9d305cbd85bac50d6b0e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115121 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 1f3dddd6f21d91c429190ae314dadeec409f35f4)
2022-01-17Fix gpgmepp build with glibcMike Kaganski
posix-io.c: In function '_gpgme_io_spawn': posix-io.c:492:23: error: void value not ignored as it ought to be 492 | while ((i = closefrom (fd)) && errno == EINTR) | ^ make[1]: *** [Makefile:964: posix-io.lo] Error 1 Change-Id: I0e7abc33200ca7436c72e925447e681fd241c6a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123260 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Jan Holesovsky <kendy@collabora.com>
2021-12-13Release 6.3.6.13Thorsten Behrens
Change-Id: I7de37f19b61472d9050a60f949cdc77b66294b2b
2021-12-10tdf#138518 sw: layout: fix assert on ooo43913-1.docMichael Stahl
Assertion `rAnchoredObjPage.GetPhyPageNum() == _nFromPageNum' failed. Because not only the fly's anchor frame moves forward in FormatAnchorFrameForCheckMoveFwd(), but also the fly itself, apparently because it's in a table: 0 SwAnchoredObject::SetPageFrame(SwPageFrame*) (this=0x5a1d3d8, _pNewPageFrame=0x8cfbeb0) at sw/source/core/layout/anchoredobject.cxx:162 1 SwPageFrame::MoveFly(SwFlyFrame*, SwPageFrame*) (this=0x8cbd8c0, pToMove=0x5a1d280, pDest=0x8cfbeb0) at sw/source/core/layout/flylay.cxx:985 2 lcl_ArrangeLowers(SwLayoutFrame*, tools::Long, bool) (pLay=0x8cf80c0, lYStart=179488, bInva=false) at sw/source/core/layout/tabfrm.cxx:5000 3 SwCellFrame::Format(OutputDevice*, SwBorderAttrs const*) (this=0x8cf80c0, pAttrs=0x8ce78c0) at sw/source/core/layout/tabfrm.cxx:5359 4 SwLayoutFrame::MakeAll(OutputDevice*) (this=0x8cf80c0) at sw/source/core/layout/calcmove.cxx:1036 5 SwFrame::PrepareMake(OutputDevice*) (this=0x8cf80c0, pRenderContext=0x5b7fcf0) at sw/source/core/layout/calcmove.cxx:375 6 SwFrame::Calc(OutputDevice*) const (this=0x8cf80c0, pRenderContext=0x5b7fcf0) at sw/source/core/layout/trvlfrm.cxx:1792 7 SwFrame::MakePos() (this=0x8cebdb0) at sw/source/core/layout/calcmove.cxx:627 8 SwTextFrame::MakePos() (this=0x8cebdb0) at sw/source/core/text/frmform.cxx:340 9 SwContentFrame::MakeAll(OutputDevice*) (this=0x8cebdb0) at sw/source/core/layout/calcmove.cxx:1412 10 SwFrame::PrepareMake(OutputDevice*) (this=0x8cebdb0, pRenderContext=0x5b7fcf0) at sw/source/core/layout/calcmove.cxx:286 11 SwFrame::Calc(OutputDevice*) const (this=0x8cebdb0, pRenderContext=0x5b7fcf0) at sw/source/core/layout/trvlfrm.cxx:1792 12 SwTextFrame::CalcFollow(o3tl::strong_int<int, Tag_TextFrameIndex>) (this=0x5ae2c60, nTextOfst=...) at sw/source/core/text/frmform.cxx:279 13 SwTextFrame::AdjustFollow_(SwTextFormatter&, o3tl::strong_int<int, Tag_TextFrameIndex>, o3tl::strong_int<int, Tag_TextFrameIndex>, unsigned char) (this=0x5ae2c60, rLine=..., nOffset=..., nEnd=..., nMode=1 '\001') at sw/source/core/text/frmform.cxx:611 14 SwTextFrame::FormatAdjust(SwTextFormatter&, WidowsAndOrphans&, o3tl::strong_int<int, Tag_TextFrameIndex>, bool) (this=0x5ae2c60, rLine=..., rFrameBreak=..., nStrLen=..., bDummy=false) at sw/source/core/text/frmform.cxx:1166 15 SwTextFrame::Format_(SwTextFormatter&, SwTextFormatInfo&, bool) (this=0x5ae2c60, rLine=..., rInf=..., bAdjust=false) at sw/source/core/text/frmform.cxx:1613 16 SwTextFrame::Format_(OutputDevice*, SwParaPortion*) (this=0x5ae2c60, pRenderContext=0x5b7fcf0, pPara=0x8d07490) at sw/source/core/text/frmform.cxx:1720 17 SwTextFrame::Format(OutputDevice*, SwBorderAttrs const*) (this=0x5ae2c60, pRenderContext=0x5b7fcf0) at sw/source/core/text/frmform.cxx:1910 18 SwContentFrame::MakeAll(OutputDevice*) (this=0x5ae2c60) at sw/source/core/layout/calcmove.cxx:1525 19 SwFrame::PrepareMake(OutputDevice*) (this=0x5ae2f80, pRenderContext=0x5b7fcf0) at sw/source/core/layout/calcmove.cxx:321 20 SwFrame::Calc(OutputDevice*) const (this=0x5ae2f80, pRenderContext=0x5b7fcf0) at sw/source/core/layout/trvlfrm.cxx:1792 21 SwObjectFormatterTextFrame::FormatAnchorFrameAndItsPrevs(SwTextFrame&) (_rAnchorTextFrame=...) at sw/source/core/layout/objectformattertxtfrm.cxx:905 22 SwObjectFormatterTextFrame::FormatAnchorFrameForCheckMoveFwd() (this=0x8ce5720) at sw/source/core/layout/objectformattertxtfrm.cxx:919 23 SwObjectFormatterTextFrame::DoFormatObjs() (this=0x8ce5720) at sw/source/core/layout/objectformattertxtfrm.cxx:368 24 SwObjectFormatter::FormatObjsAtFrame(SwFrame&, SwPageFrame const&, SwLayAction*) (_rAnchorFrame=..., _rPageFrame=..., _pLayAction=0x0) at sw/source/core/layout/objectformatter.cxx:160 25 SwContentFrame::CalcLowers(SwLayoutFrame&, SwLayoutFrame const&, long, bool) (rLay=..., rDontLeave=..., nBottom=192048, bSkipRowSpanCells=true) at sw/source/core/layout/tabfrm.cxx:1534 26 lcl_RecalcRow(SwRowFrame&, tools::Long) (rRow=..., nBottom=192048) at sw/source/core/layout/tabfrm.cxx:1653 27 SwTabFrame::MakeAll(OutputDevice*) (this=0x8cf5f80, pRenderContext=0x5b7fcf0) at sw/source/core/layout/tabfrm.cxx:2425 It looks like the _nFromPageNum is always from the SwObjectFormatter::mrPageFrame anyway because that's a precondition of the mpPgNumAndTypeOfAnchors->Collect() being called, so just rely on that to get the correct page. (regression from c799de145f7e289f31e3669646e5bd12814e6c5e) Change-Id: Ibdffb2121cffbc04320d17a29ab2e160dec4250b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115188 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 533a998e540b0f04068c876dde0e74adc3f79c93) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115201 Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 7eb12f8a09dd67168ba42058b99d8ab58a5c7b0a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115766 Tested-by: Michael Stahl <michael.stahl@allotropia.de>
2021-12-10tdf#138518 sw: layout: avoid moving flys forward prematurelyMichael Stahl
(regression from b9ef71476fd70bc13f50ebe80390e0730d1b7afb "tdf#134298 sw: layout: remove left-over page frame without content") When updating the 3rd ToX, the change to remove empty page frames causes one page frame to be deleted. On the subsequent layout, things generally move backward, but there are some fly-related hiccups; the first problem is visible on page 7. Commit eb85de8e6b61fb3fcb6c03ae0145f7fe5478bccf "sw: layout: if fly's anchor moves forward, move fly off SwPageFrame" helps quite a bit, but not completely; now the first problem happens on page 54, when SwTextFrame 1261 and its fly 3132 are formatted. Frame 1261 moves forward to page 55, and then SwObjectFormatterTextFrame::CheckMovedFwdCondition() returns true and so SwMovedFwdFramesByObjPos::Insert() is called to prevent frame 1261 from moving back to page 54. But the reason why it moved forward is that there are 3 flys on page 54 that are anchored on frames in the next-chain of 1261, namely 1275, 1283 and 1284; if these flys weren't on the page then 1261 would fit. While the move forward cannot be easily prevented in the situation, it's possible to avoid the entry into the SwMovedFwdFramesByObjPos map, by detecting that there are flys on the page that would should forward *before* the current one does. With this fix and the above mentioned commit to get the flys off the page, frame 1261 will eventually move back to page 54 again. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114478 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit c799de145f7e289f31e3669646e5bd12814e6c5e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114521 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> (cherry picked from commit 8feac9601cfe35ee0966776bab15d122206f154e) tdf#138518 sw: layout: unbreak fdo80206-1.doc The 7 flys on the para on page 3 create ~15 extra pages with one paragraph each. Argh! One of the bPageHasFlysAnchoredBelowThis checks was inverted. How dumb of me. (regression from c799de145f7e289f31e3669646e5bd12814e6c5e) Still doesn't look good but now it looks same as in 7.0. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115242 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins (cherry picked from commit 59d96acec8c4d9e472daa3e2c287b3a754e01817) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115206 Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit dcea18e66e61c6f411b9bf6498a0ffc374161484) Change-Id: I83e44d65a0b889a49a313b0cd8b08efce4c3afa7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115765 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-12-10sw: layout: if fly's anchor moves forward, move fly off SwPageFrameMichael Stahl
The problem is that on Show Changes->Hide Changes->Show Changes in a 311 page document, the fly "Grafik1" was initially on page 203 but ends up on page 204, with a fly-sized gap on page 194. In a 25 page cut down version of the bugdoc, on layout action 659 the fly's anchor SwTextFrame moves from page 21 to page 22, but the fly remains in the SwPageFrame's m_pSortedObjs, because it's not the anchor frame itself that moves but a distant previous frame, and page 21 goes valid. 0 SwFlowFrame::PasteTree(SwFrame*, SwLayoutFrame*, SwFrame*, SwFrame*) (pStart=0x57c9e30, pParent=0xba15c50, pSibling=0x5a0f920, pOldParent=0xb057690) at sw/source/core/layout/flowfrm.cxx:586 1 SwFlowFrame::MoveSubTree(SwLayoutFrame*, SwFrame*) (this=0x57c9f48, pParent=0xba15c50, pSibling=0x5a0f920) at sw/source/core/layout/flowfrm.cxx:677 2 SwFlowFrame::MoveFwd(bool, bool, bool) (this=0x57c9f48, bMakePage=true, bPageBreak=false, bMoveAlways=false) at sw/source/core/layout/flowfrm.cxx:2061 3 SwContentFrame::MakeAll(OutputDevice*) (this=0x57c9e30) at sw/source/core/layout/calcmove.cxx:1831 4 SwFrame::OptPrepareMake() (this=0x57c9e30) at sw/source/core/layout/calcmove.cxx:399 5 SwFrame::OptCalc() const (this=0x57c9e30) at sw/source/core/inc/frame.hxx:1065 6 SwLayAction::FormatContent_(SwContentFrame const*, SwPageFrame const*) (this=0x7ffec0191b30, pContent=0x57c9e30, pPage=0xb9a1fd0) at sw/source/core/layout/layact.cxx:1833 In subsequent layout actions the anchor frame moves forward one page at a time, until in action 665, when things get really interesting. On page 24, the anchor text frame 582 is formatted for the first time, and it moves the fly to page 24, after positioning it on the page. 2 SwPageFrame::MoveFly(SwFlyFrame*, SwPageFrame*) (this=0xb9a1fd0, pToMove=0x641d310, pDest=0x9125bb0) at sw/source/core/layout/flylay.cxx:972 3 SwFlyAtContentFrame::RegisterAtCorrectPage() (this=0x641d310) at sw/source/core/layout/flycnt.cxx:1432 4 SwAnchoredObject::SetVertPosOrientFrame(SwLayoutFrame const&) (this=0x641d468, _rVertPosOrientFrame=...) at sw/source/core/layout/anchoredobject.cxx:195 5 SwFlyAtContentFrame::MakeObjPos() (this=0x641d310) at sw/source/core/layout/flycnt.cxx:1466 6 SwFlyFreeFrame::MakeAll(OutputDevice*) (this=0x641d310) at sw/source/core/layout/flylay.cxx:223 7 SwFlyAtContentFrame::MakeAll(OutputDevice*) (this=0x641d310, pRenderContext=0x55b1f00) at sw/source/core/layout/flycnt.cxx:384 8 SwFrame::PrepareMake(OutputDevice*) (this=0x641d310, pRenderContext=0x55b1f00) at sw/source/core/layout/calcmove.cxx:375 9 SwFrame::Calc(OutputDevice*) const (this=0x641d310, pRenderContext=0x55b1f00) at sw/source/core/layout/trvlfrm.cxx:1791 10 SwFlyFrame::Calc(OutputDevice*) const (this=0x641d310, pRenderContext=0x55b1f00) at sw/source/core/layout/fly.cxx:2874 11 SwLayAction::FormatLayoutFly(SwFlyFrame*) (this=0x7ffec0191b30, pFly=0x641d310) at sw/source/core/layout/layact.cxx:1455 12 SwObjectFormatter::FormatObj_(SwAnchoredObject&) (this=0xa5c0d10, _rAnchoredObj=...) at sw/source/core/layout/objectformatter.cxx:286 13 SwObjectFormatterTextFrame::DoFormatObj(SwAnchoredObject&, bool) (this=0xa5c0d10, _rAnchoredObj=..., _bCheckForMovedFwd=false) at sw/source/core/layout/objectformattertxtfrm.cxx:135 14 SwObjectFormatter::FormatObjsAtFrame_(SwTextFrame*) (this=0xa5c0d10, _pMasterTextFrame=0x0) at sw/source/core/layout/objectformatter.cxx:408 15 SwObjectFormatterTextFrame::DoFormatObjs() (this=0xa5c0d10) at sw/source/core/layout/objectformattertxtfrm.cxx:337 16 SwObjectFormatter::FormatObjsAtFrame(SwFrame&, SwPageFrame const&, SwLayAction*) (_rAnchorFrame=..., _rPageFrame=..., _pLayAction=0x7ffec0191b30) at sw/source/core/layout/objectformatter.cxx:160 17 SwLayAction::FormatContent(SwPageFrame const*) (this=0x7ffec0191b30, pPage=0x9125bb0) at sw/source/core/layout/layact.cxx:1675 18 SwLayAction::InternalAction(OutputDevice*) (this=0x7ffec0191b30, pRenderContext=0x55b1f00) at sw/source/core/layout/layact.cxx:771 Nothing invalidates page 21 now that the fly is gone, and formatting on page 24 is kind of pointless now because everything from page 21 on is wrongly positioned. (It's possible to skip out of the main layout action loop via SetNextCycle()/IsAgain(), but at this point it's in layact:771 in the layout-all-the-visible-pages loop that follows the main loop, and that one can't be cancelled.) Then DoFormatObjs() is called on frame 582, and this calls FormatAnchorFrameForCheckMoveFwd(), which formats previous frame 581, splitting it and moving its follow along with 582 to page 25. Here SwMovedFwdFramesByObjPos::Insert() is called, and now the anchor text frame 582 cannot move back to page 24 because it's prevented by SwMovedFwdFramesByObjPos::FrameMovedFwdByObjPos(), but that was all based on the wrong assumption that the pages before 24 were completely formatted (this happens in action 670). Something later formats page 21 again, and so at the end there is a fly-sized hole at the bottom of page 24, with frame 582 at the top of page 25. It won't help to detect a situation where the fly is on a page previous to the page it's anchor frame is on in DoFormatObjs() because it was actually moved to the same page in a previous formatting of the anchor frame, in the same layout action. To fix this, try to detect in SwLayAction::FormatContent() if the anchor frame of any fly on the page has moved forward, and move those flys off the page; this is enough for the 25 page document. The 311 page document still has a hole on page 194 though; apparently the last content frame on the page is never reformatted, so invalidate its size. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114066 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit eb85de8e6b61fb3fcb6c03ae0145f7fe5478bccf) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114519 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> (cherry picked from commit 810f7e4e0b61ee7cb3a7d6a1b503782d7248a4b1) tdf#141945 sw: layout: check master frame when moving fly forward The problem is that in the finished layout the fly frames are positioned on the first page but are in SwPageFrame::m_pSortedObjs of the second page. Don't use FindPageFrameOfAnchor() because that looks up the follow-frame that contains the anchor position. This was unintentional; the idea was to get flys anchored in subsequent paragraphs out of the way. This situation where it's on a follow-frame of the same paragraph is more complicated and less obvious, so don't try to solve it now. (regression from eb85de8e6b61fb3fcb6c03ae0145f7fe5478bccf) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115100 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 30512746c182b52f37f9a818d4e206c98e715cb7) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115080 Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 41f68b652eb1ccdd4941e2270426461da8e66417) Change-Id: I232c6b305e8593bfecd885c36058777f3980f82f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115763 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-12-10tdf#138039 tdf#134298 sw: layout: fix overlap of fly and tableMichael Stahl
The layout is horribly borked, the fly anchored in the body-level paragraph messed with the preceding table: page id="1" top="284" width="11905" height="16837" bottom="17120" tab id="3" top="794" row id="4" top="17121" fly id="8" top="16725" txt id="7" top="1394" fly ptr="0x6ce5510" id="10" top="1302" SwTabFrame::CalcFlyOffsets() detects an overlap with the large fly, and since it has wrap NONE it resizes to below the large image. Then the SwTabFrame doesn't fit on the page, so it is split, but the split fails because nDistanceToUpperPrtBottom is -720 (negative); hence it is joined again. Meanwhile the fly was invalidated, so now CalcFlyOffsets() ignores it and the table shrinks again. Once the fly is positioned again, the process repeats from the start. Fix this in SwTabFrame::CalcFlyOffsets() by ignoring flys with wrap NONE that extend below the body of the document and are anchored in a frame in the next-chain of the table frame: these must move to the next page with their anchor frame. For the bugdoc this gives the same layout as LO 5.2. Reportedly this problem started to happen since commit 6f5024de2e1a5cc533527e45b33d9a415467c48d, but it's not obvious why. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105809 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 6b92d2e8522ecc98d2c5532f5076c20ae295168e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105940 Tested-by: Michael Stahl <michael.stahl@cib.de> Change-Id: Iafb8a6afcba634f11c5db73869313ded0fe13bbd
2021-12-10tdf#138785 sw: fix mis-positioned as-char flys when deleting empty pageMichael Stahl
When SwFrame::CheckPageDescs() deletes an empty page in the middle of the document, which happens during SetRedlineFlags() here, the SwFlyInContentFrame::maFrameArea is moved in lcl_MoveAllLowers(), but the SwFlyInContentFrame::m_aRefPoint stays unchanged. Because the formatting occurs only after the redline mode is reset, the position of the SwFlyInContentFrame when it is formatted is exactly the same as its (stale) m_aRefPoint, so the setting of (updated) maFrameArea is skipped in SwAsCharAnchoredObjectPosition::CalcPosition(), so the fly ends up a page above where it should be. So keep m_aRefPoint consistent with maFrameArea in lcl_MoveAllLowers(). (regression from b9ef71476fd70bc13f50ebe80390e0730d1b7afb) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114332 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit e656cf2a71e738c282abcd0d610e724b955f274a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114520 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> (cherry picked from commit c79b92edfb5e650fff76688998cf4f0bbd08d2a4) Change-Id: If1b421daa0d71718d89d9772f5c0d9e367e76845 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115764 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-12-10tdf#134298 sw: layout: remove left-over page frame without contentMichael Stahl
Once tdf#138039 is fixed, this bugdoc has an additional empty page 3. This is because it first goes to 3 pages, and then the SwTextFrame on page does a MoveBwd, leaving behind a page frame with just a body frame and nothing else. It turns out that SwRootFrame::RemoveSuperfluous() only removes empty frames at the end of the document, but here there's a non-empty frame following it. Also, this function doesn't handle cases like right/left page styles so it can't delete pages in the middle. SwFrame::CheckPageDescs() doesn't remove page frames that don't have content, it only removes those that have the intentionally-empty flag set. Extend CheckPageDescs() to also remove page frames that don't have content, and make sure it is called when SwContentFrame::Cut() removes the last content from a page frame (it will be called after all pages are valid in SwLayAction::InternalAction()). (Alternatively it might be possible to prevent the problem from occurring in SwTextFly::ForEach() by ignoring the fly so that the first paragraph never leaves page 1, but we didn't explore that.) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105810 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit b9ef71476fd70bc13f50ebe80390e0730d1b7afb) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114097 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Change-Id: I3a3f1efe6d7ed28e05dc159a86abc3d702cc272b
2021-12-10(related tdf#134298) sw: layout: avoid infinite loop in InternalAction()Michael Stahl
The condition IsInterrupt() && pPage && (m_nCheckPageNum != USHRT_MAX) isn't handled properly and the while loop will never terminate with the fix for tdf#134298 in several UITest_writer_tests*. If m_nCheckPageNum is set, then it must result in a call to CheckPageDescs() here; it's a member of SwLayAction so won't survive until the next idle layout invocation. There is a funny history of these loop conditions with commit 9eff9e699e17cc5a8a25895bd28dc8e4ceb8071e and cee296066ab780217395201ab84c2150c8840d25 so we can only hope this time we got it right... Change-Id: I91b63540bf4280296d747cb8e841594f8dd3b140 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105927 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 094ee3955ee81e1bc631d50cc216cbb17a777839) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114096 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-12-10nss: upgrade to release 3.73Michael Stahl
Fixes: CVE-2021-43527 Memory corruption via DER-encoded DSA and RSA-PSS signatures Change-Id: I5c3f169c57fc2763029b07ad7e325b2f53b7e28f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126218 Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-11-23Teach symstore more duplicated DLLsThorsten Behrens
Amending commit b4dfba947768834ffecc09056992019878711c8b with adding the copied DLLs here, too (symstore complains otherwise) Change-Id: If5cc155cf2fe11b0f97cd152993609fd2c835316 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120686 Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-11-23replace usage of blacklist with denylistThorsten Behrens
.. and a few cases of instead doing blacklist->excludelist where that made more sense. Background and motivation: https://tools.ietf.org/html/draft-knodel-terminology-02 [API CHANGE] officecfg::Office::Canvas::DeviceBlacklist -> DeviceDenylist [API CHANGE] officecfg::Office::Canvas::BlacklistCurrentDevice -> DenylistCurrentDevice [API CHANGE] officecfg::Office::Common::Misc::OpenCLBlackList -> OpenCLDenyList Change-Id: Ia35e25496bf0cc0692d5de4cb66bfc232d3a869e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98180 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2021-11-23symstore.sh: add vorbose modeJuergen Funk
Change-Id: I01f9827140810080c037108021ca70f2b906b05e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90083 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2021-11-23Optionally generate PDBs also for nssJuergen Funk
Enables pdb generation for symbol builds, for: - freebl3.dll - libeay32.dll - nspr4.dll - nss3.dll - nssckbi.dll - nssdbm3.dll - nssutil3.dll - plc4.dll - plds4.dll - smime3.dll - softokn3.dll - sqlite3.dll - ssl3.dll - ssleay32.dll Change-Id: I231fdc8e8ade7b7a8b85fc76536291e0546f2eac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88673 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2021-11-23Fix typosAndrea Gelmini
Change-Id: I2671a0faf78d8ece27aaa88082a60f19197e929f Reviewed-on: https://gerrit.libreoffice.org/85314 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2021-11-23symstore.sh: collect PDBs for *all* artifactsJuergen Funk
- a number of external library PDBs where missing - also the soffice.bin and unopkg.bin (renaming that to *.bin.pdb) Change-Id: Idafcce87bfefadfa669807a861efab76b4122c62 Reviewed-on: https://gerrit.libreoffice.org/83726 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2021-11-23symstore.sh: use logical operators for test statementsJuergen Funk
No need to spawn two subshells, test can do and/or logical ops itself. Change-Id: I2abba303383f9f0053515088d4fa32753a777a1d Reviewed-on: https://gerrit.libreoffice.org/83066 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2021-11-23Add comment and pdb-only switch to symstore.shJuergen Funk
Two new switches added: -c plus a comment for the transaction -n do not store the exe/dll on the symbol server Change-Id: I8c5db06909720707987970347e298be6d55ebc71 Reviewed-on: https://gerrit.libreoffice.org/82751 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2021-11-05Adapt to Bison 3.8 internal yyn -> yyrule renameStephan Bergmann
see <https://git.savannah.gnu.org/cgit/bison.git/commit/?id=f30067ed51f23802fc91761ede1506dfa72b2865> "glr2.cc: log the execution of deferred actions" including "Rename argument yyn as yyrule for clarity." YYBISON was defined as 1 rather than as a representation of the Bison version prior to <https://git.savannah.gnu.org/cgit/bison.git/commit/?id=21c147b6e5372563b7c4741deadaddb9354f4b09> "yacc.c: provide the Bison version as an integral macro", which shouldn't be a problem here. And YYBISON is apparently completely undefined with /usr/bin/bison on macOS. (The preceding comment always mentioned "yyi" and "yyrmap" in apparent mismatch with the actually used "yyn" and "yyr1" ever since c25ec0608a167bcf1d891043f02273761c351701 "initial import", so just leave it untouched.) Change-Id: I4f901407aa21ed4abec84e661d813ee7599f02f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122082 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-11-05Release 6.3.6.12Thorsten Behrens
Change-Id: Ie4c94f7f0f5000e0b6fd86a3b6d5af5bea4e8202
2021-11-01Disable PDF-to-PDF embedding on PDF export (hack), part IIIArmin Le Grand (Allotropia)
Corrected creation of PDF export for Bitmap/BitmapEx which needs a createObject call in createBitmapEmit in all cases where no embedded PDF is written Change-Id: Ic0da0139d99b273f61c0164ac3615e288986bc94
2021-07-07Disable PDF-to-PDF embedding on PDF export (hack), part IIArmin Le Grand (Allotropia)
Adapted 899a52b236b81a94367ec8bafdff891a67d818aa to use officecfg::Office::Common::VCL::AllowPdfToPdfEmbedding instead of LIBO_ALLOW_PDF_TO_PDF_EMBEDDING Change-Id: I42e3d9a474400ec488352c081620a9b31cde3562
2021-07-06Disable PDF-to-PDF embedding on PDF export (hack)Armin Le Grand (Allotropia)
Due to creating PDF formats recognized as errors for PDF readers using PDF1.5 I decided for a QuickFix to have a simple possibility to disaable that feature, depending on the flag LIBO_ALLOW_PDF_TO_PDF_EMBEDDING If (initially) not defined/set, PDF-to-PDF embedding will be replaced at export to use Jpeg/PixelData instead what is uncritical and creates valid PDF files. If defined/set, all will be unchanged. This opens a quick possibility to switch back if unexpected side effects should occur. Change-Id: I5aaf833b539cdea2bb3bf165cd25990e56efa847
2021-07-01avoid windres preprocessor quoting-messups with current cygwinChristian Lohmaier
apparently fresh installs of cygwin behave differently with the windres command's quoting and treats --preprocessor='cpp foo bar' as a single file "cpp foo bar" to run instead of running "cpp" with the arguments "foo" and "bar". (-D and -I options are passed to the preprocessor automatically, so no need to prefix those with --preprocessor-arg) Change-Id: I711e968206f0769ff07152ebb9572e8b71c30cec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114965 Tested-by: Jenkins Reviewed-by: Georgy Litvinov <git@litvinovg.pro> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117600 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-07-01Revert "avoid windres preprocessor quoting-messups with current cygwin"Armin Le Grand (Allotropia)
This reverts commit 731010a3124c92458be5c7c4839e8804d1c32463. Instead, try 15d36bdb2069cb531cabd9b3b9ffb0fb913a6bd0
2021-06-30avoid windres preprocessor quoting-messups with current cygwinChristian Lohmaier
apparently fresh installs of cygwin behave differently with the windres command's quoting and treats --preprocessor='cpp foo bar' as a single file "cpp foo bar" to run instead of running "cpp" with the arguments "foo" and "bar". (-D and -I options are passed to the preprocessor automatically, so no need to prefix those with --preprocessor-arg) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114965 Tested-by: Jenkins Reviewed-by: Georgy Litvinov <git@litvinovg.pro> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit 07f1ec0af02a9ab6c1bf6e6478092ee50495afa7) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114971 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 3589180bfa67bc2ef411a56c9e8bb161f6c59902) Change-Id: I711e968206f0769ff07152ebb9572e8b71c30cec
2021-06-30sw: layout: fix table split loop caused by RemoveFollowFlowLinePendingMichael Stahl
In no_view.odt, the table 1340 does RemoveFollowFlowLine(), then splits again, and by the time Split() returns, its flag m_bRemoveFollowFlowLinePending is set and so in the next SwTabFrame::MakeAll() it will do the same thing again, until eventually it hits layact.cxx:544: LoopControl_1 in SwLayAction::InternalAction The flag is set during lcl_RecalcSplitLine(), in SwContentFrame::Cut(), which operates under the assumption that there are no other cells in the follow flow line that may contain content frames. This only happens if "Verdana" and "Arial" fonts are available and not substituted with "DejaVu Sans" etc. (regression from c4af8b0f106f31b6e79a145bc4ab83bb6a55c808) Unfortunately this uncovers another pagination bug in testTdf88496 which was hidden by this flag being set from text frames that shouldn't exist anyway. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117851 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit a0cd270a99f43049fc099ddd463e57aa243d5b0e) Change-Id: I3cc82c13bfc06960b827aefc64f5b5b12520955a (cherry picked from commit d5c9e1b939d76748f30002e73982475856b68a16)
2021-05-17tdf#134582 sfx2: when storing, set Version on embedded object storageMichael Stahl
This previously wasn't needed because there was only one version for which it was checked (1.2) but since commit a541cd91951eca15e40764244b34c72b347f9f26 there's a second version so when loading an existing embedded object in one version and storing it in another, the Version must be updated so the attribute in META-INF/manifest.xml matches the one in content.xml. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98521 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 519d96fd8b83ef4c61576d87b58f97b7e6e6e3c6) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98459 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit a24a4cc1838e3a2d55261a8edf6cb63186f4c38f) (cherry picked from commit 2976392800739d38d5f84f1f8242701c526b29e1) Change-Id: Ic2fc303c6f6bc254050d531d578029377976ecb5
2021-05-17python3: fix segfault importing ctypesMichael Stahl
on this line: CFUNCTYPE(c_int)(lambda:None) python segfaults when compiled with GCC 11. │ 0x7f7e53a5d64c <PyCFuncPtr_new+220> call 0x7f7e53a5c3d0 <GenericPyCData_new> │ │ 0x7f7e53a5d651 <PyCFuncPtr_new+225> mov %rax,%r13 │ │ 0x7f7e53a5d654 <PyCFuncPtr_new+228> test %rax,%rax │ │ 0x7f7e53a5d657 <PyCFuncPtr_new+231> je 0x7f7e53a5d990 <PyCFuncPtr_new+1056> │ │ 0x7f7e53a5d65d <PyCFuncPtr_new+237> mov 0x88(%rsp),%rax │ │ 0x7f7e53a5d665 <PyCFuncPtr_new+245> movq %r15,%xmm0 │ │ 0x7f7e53a5d66a <PyCFuncPtr_new+250> movq %rax,%xmm1 │ │ 0x7f7e53a5d66f <PyCFuncPtr_new+255> addq $0x1,(%rax) │ │ 0x7f7e53a5d673 <PyCFuncPtr_new+259> mov 0x10(%r13),%rax │ │ 0x7f7e53a5d677 <PyCFuncPtr_new+263> punpcklqdq %xmm1,%xmm0 │ │ >0x7f7e53a5d67b <PyCFuncPtr_new+267> movaps %xmm0,0x60(%r13) (rr) p/x ($r13 + 0x60) % 16 $10 = 0x8 (rr) p &self->b_value $11 = (union value *) 0x7f7e53c0fea8 b_value contains "long double" which requires 16 byte alignment so the subsequent 2 pointers have to be 16 byte aligned, so gcc generates "movaps" instruction which requires 16 byte alignment, but they're 8 byte aligned. Change-Id: I8d57311c5dc0d33ab0f7beeb6fee91299bd3de67 (cherry picked from commit 6a38eafc17c7b1b8972e648db19dc841c3f9902e)
2021-05-14Missing include (for std::min)Stephan Bergmann
Change-Id: I44eebee0149d7e890aeff715dd7ae0005c45378d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109179 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit e24cc814b5b6e50967116cb3908e4bf56b7aee4b) (cherry picked from commit 2575182a0e106f61be4c5bd8a2ff60e069936424)
2021-05-14include cstddef for gcc11Jeff Law
Change-Id: I2f845ce9bb660ad6c1eea80ea81dd71add2c0db1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107191 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 8830cf86b146b1252ac37f351a23246088d569b0) (cherry picked from commit 8acc85c4f96313468147e8dff54255aa1c8be4ce)
2021-05-14gbuild: don't use -Wunused-macros with sccacheMichael Stahl
In at least soltools, jurt and gperf generated files, build with GCC and sccache 0.2.16-alpha.0 reports spurious -Werror=implicit-fallthrough= due to comments and these go away by configuring sccache with rewrite_includes_only = true. But his results in cc1: error: ‘-fdirectives-only’ is incompatible with ‘-Wunused-macros’ so disable that like for clang-with-icecream builds. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111716 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 6fb9f368c6824a8ff7bc5bc5cf66fc2df7d055b7) Change-Id: I6dec38e86aa6e22591d7a700a8daddf3fed88b16 (cherry picked from commit 11e39bcfac696752bbe64c6975ec4b87f3ca92b6)
2021-05-14odk: build examples with GCC with explicit -std=c++11Michael Stahl
GCC 11 defaults to -std=c++17, which doesn't support exception specifications any more. ddcc98fa50dd9d86a60dada4daa00f4d95ffe005 seems a bit large to backport. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115505 Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> (cherry picked from commit dff559024d271a69186b608615f4a7095cbee2a4) Change-Id: I74a182435b268be8fd7a9ff0be9f404122108b51
2021-05-14gbuild: work around GDB 10 bug with DWARF5 in split debug infoMichael Stahl
GCC 11 defaults to -gdwarf-5 and GDB can only read it if -gsplit-dwarf isn't used. Dwarf Error: wrong unit_type in compilation unit header (is DW_UT_split_compile (0x05), should be DW_UT_type (0x02)) [in module /workdir/CObject/desktop/source/app/main.dwo] https://sourceware.org/bugzilla/show_bug.cgi?id=27354 https://bugzilla.redhat.com/show_bug.cgi?id=1956475 Change-Id: Ie2ac7193a29a8f257cf6f1d711f9fa6941df48ad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115054 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit dc8c8a4aa20ddd3139a25d5c052cac9bae944cb8) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115193 Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 626ea4e62a3e5005fe9825923a1c0c5bdb61cc08) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115504 Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> (cherry picked from commit c2a882e896d9a1a2af3bc5652a2dd4a9b0e486ee)
2021-05-14external/libwpd: Missing include for size_tStephan Bergmann
...as now reported when building with recent trunk GCC/libstdc++ on Linux: > In file included from WPXContentListener.cpp:26: > In file included from ./WPXContentListener.h:29: > ./WPXTable.h:56:31: error: unknown type name 'size_t'; did you mean 'std::size_t'? > const WPXTableCell *getCell(size_t i, size_t j) > ^~~~~~ > std::size_t Change-Id: Ic20240f01c7b0305cb87ababf53a3aaf66072d61 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105324 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 8d378abf1de0a47517427c086da26588f846592a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115000 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 524cfb93d4033917ad20c718d538235078d068d5) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115503 Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> (cherry picked from commit fdbc4995522167cc64b6b9ec3f9d523c75e52511)
2021-05-14exteranl/coinmp: Fix build with recent GCC 11 trunkStephan Bergmann
It had started to fail for me now with > ~/gcc/trunk/inst/bin/g++ -DHAVE_CONFIG_H -I. -I. -O -MT CoinFinite.lo -MD -MP -MF .deps/CoinFinite.Tpo -c CoinFinite.cpp -fPIC -DPIC -o .libs/CoinFinite.o > CoinFinite.cpp: In function 'bool CoinFinite(double)': > CoinFinite.cpp:38:19: error: 'DBL_MAX' was not declared in this scope > 38 | return val != DBL_MAX && val != -DBL_MAX; > | ^~~~~~~ > CoinFinite.cpp:8:1: note: 'DBL_MAX' is defined in header '<cfloat>'; did you forget to '#include <cfloat>'? > 7 | #include "CoinUtilsConfig.h" > +++ |+#include <cfloat> > 8 | because of a missing -DCOINUTILS_BUILD. Which in turn was caused by workdir/UnpackedTarball/coinmp/CoinUtils/configure (see workdir/UnpackedTarball/coinmp/CoinUtils/config.log), which first tries to determine an ac_declaration that would apparently be a suitable declaration of `exit` without actually including <stdlib.h> in a C++ file. It settles on > configure:3551: ~/gcc/trunk/inst/bin/g++ -c -g -O2 conftest.cc >&5 > conftest.cc:15:17: warning: 'void std::exit(int)' has not been declared within 'std' > 15 | extern "C" void std::exit (int) throw (); using std::exit; > | ^~~ > <built-in>: note: only here as a 'friend' > configure:3557: $? = 0 (which generates a warning, but no error with the given g++ invocation). The determined ac_declaration value is then included in confdefs.h, causing the later > configure:4014: ~/gcc/trunk/inst/bin/g++ -o conftest -O3 -pipe -DNDEBUG -pedantic-errors -Wparentheses -Wreturn-type -Wcast-qual -Wall -Wpointer-arith -Wwrite-strings -Wconversion -Wno-unknown-pragmas -Wno-long-long -DCOINUTILS_BUILD -Wl,-z,origin -Wl,-rpath,\$$ORIGIN conftest.cc >&5 > conftest.cc:15:17: error: 'void std::exit(int)' has not been declared within 'std' > 15 | extern "C" void std::exit (int) throw (); using std::exit; > | ^~~ > <built-in>: note: only here as a 'friend' > configure:4020: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "CoinUtils" > | #define PACKAGE_TARNAME "coinutils" > | #define PACKAGE_VERSION "2.9.11" > | #define PACKAGE_STRING "CoinUtils 2.9.11" > | #define PACKAGE_BUGREPORT "http://projects.coin-or.org/CoinUtils" > | #define COINUTILS_VERSION "2.9.11" > | #define COINUTILS_VERSION_MAJOR 2 > | #define COINUTILS_VERSION_MINOR 9 > | #define COINUTILS_VERSION_RELEASE 11 > | #define COIN_COINUTILS_VERBOSITY 0 > | #define COIN_COINUTILS_CHECKLEVEL 0 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | > | int > | main () > | { > | int i=0; i++; > | ; > | return 0; > | } > configure:4045: WARNING: The flags CXXFLAGS="-O3 -pipe -DNDEBUG -pedantic-errors -Wparentheses -Wreturn-type -Wcast-qual -Wall -Wpointer-arith -Wwrite-strings -Wconversion -Wno-unknown-pragmas -Wno-long-long -DCOINUTILS_BUILD" do not work. I will now just try '-O', but you might want to set CXXFLAGS manually. to fail, because its g++ invocation including -pedantic-errors turns that > 'void std::exit(int)' has not been declared within 'std' warning into an error. There were similar build failures in the Cgl, > ~/gcc/trunk/inst/bin/g++ -DHAVE_CONFIG_H -I. -I. -I~/lo/core/workdir/UnpackedTarball/coinmp/CoinUtils/src -DCOIN_HAS_CLP -O -MT ClpCholeskyDense.lo -MD -MP -MF .deps/ClpCholeskyDense.Tpo -c ClpCholeskyDense.cpp -fPIC -DPIC -o .libs/ClpCholeskyDense.o > In file included from ClpCholeskyDense.cpp:11: > ClpHelperFunctions.hpp:16:4: error: #error "don't have header file for math" > 16 | # error "don't have header file for math" > | ^~~~~ > In file included from ClpCholeskyDense.cpp:11: > ClpHelperFunctions.hpp: In function 'double CoinSqrt(double)': > ClpHelperFunctions.hpp:81:13: error: 'sqrt' was not declared in this scope > 81 | return sqrt(x); > | ^~~~ and Clp, > ~/gcc/trunk/inst/bin/g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./.. -I./../CglGomory -I~/lo/core/workdir/UnpackedTarball/coinmp/CoinUtils/src -I~/lo/core/workdir/UnpackedTarball/coinmp/Osi/src/Osi -I~/lo/core/workdir/UnpackedTarball/coinmp/CoinUtils/src -I~/lo/core/workdir/UnpackedTarball/coinmp/Clp/src/OsiClp -I~/lo/core/workdir/UnpackedTarball/coinmp/Clp/src -I~/lo/core/workdir/UnpackedTarball/coinmp/CoinUtils/src -I~/lo/core/workdir/UnpackedTarball/coinmp/Osi/src/Osi -O -MT CglLandPValidator.lo -MD -MP -MF .deps/CglLandPValidator.Tpo -c CglLandPValidator.cpp -fPIC -DPIC -o .libs/CglLandPValidator.o > CglLandPValidator.cpp: In member function 'int LAP::Validator::cleanCut(OsiRowCut&, const double*, const OsiSolverInterface&, const CglParam&, const double*, const double*)': > CglLandPValidator.cpp:66:22: error: 'fabs' was not declared in this scope; did you mean 'labs'? > 66 | double val = fabs(elems[i]); > | ^~~~ > | labs > CglLandPValidator.cpp: In member function 'int LAP::Validator::cleanCut2(OsiRowCut&, const double*, const OsiSolverInterface&, const CglParam&, const double*, const double*)': > CglLandPValidator.cpp:189:23: error: 'fabs' was not declared in this scope; did you mean 'labs'? > 189 | double smallest = fabs(rhs); > | ^~~~ > | labs subdirectories, and which happened to get solved by the same approach of removing problematic ac_declaration values from configure. I am not sure what all that magic of determining that ac_declaration value is supposed to be good for. There appears to be no trace of it in the corresponding configure.ac sources, so it likely was automatically added by some dated autotools (all three configure files mention "Generated by GNU Autoconf 2.59"). At least on a cursory look, the determined ac_declaration appears to only be used in configure itself, and not leak into the actual coinmp build stage, so dropping the problematic ac_declaration values is hopefully harmless. These three subdirectories were all that failed for me, but there might still be silent issues in other subdirectories when a problematic ac_declaration value would negatively affect other configure checks. (An alternative approach could be to regenerate all the configure files from their configure.ac sources with a recent autotools. But at least some of the existing external/coinmp/*.patch* already change such configure files, which would need to be adapted.) Change-Id: I0a33b0f654800e8288d3ca28e26a64efc23a3f6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103756 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 762aacc4e055fffbc605be81f66f2274dccb4be8) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114999 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 802b76340082e817efe67a5be4a021cb998a28a2) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115502 Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> (cherry picked from commit 7035bb24dd2f925e709ca41241c52fa0aa2e854e)
2021-05-14external/coinmp: C++17 no longer supports "register"Stephan Bergmann
...and GCC 11 trunk g++ now defaults to C++17, so compilation started to fail with that compiler Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99082 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit ad607d898f9826c6fa144783c93541a10ad4740c) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114998 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 656085bf2757437a088058871573385ff45f8ef5) Change-Id: I792e4c7ff59ad88e5571163d5b2362fdb349667d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115501 Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> (cherry picked from commit 7c6f86f10a614b64d7c7097a06670358e11d8cf4)
generated by cgit (git 2.34.1) at 2024-04-19 01:10:53 +0000