summaryrefslogtreecommitdiff
path: root/sw
AgeCommit message (Collapse)AuthorFilesLines
2021-06-01tdf#138302 partial revert tdf#108496: DOCX: redesign of override in listsJustin Luth5-0/+25
LO 6.4.5 commit cf13fe3e6f6a40f6db064d65d4514d13a23a31f0 was only concerned about DOCX, but just elinated shared code. So restore the shared code and just don't execute it for DOCX. It doesn't look like RTF was working before this, but this does fix DOC format. I looked for existing unit tests in rtf and doc, but none were found that hit this code. Change-Id: Id624f73181384f38e1ef9f27575e0fb82eea19c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116349 Tested-by: Jenkins Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de> (cherry picked from commit f49e5902a3737c02fabf5bec23243ccb126426c4) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116170 Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 5107bc515fba130bf4a488324f97971789a92f37) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116453 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Miklos Vajna <vmiklos@collabora.com>
2021-05-24tdf#142294 drop placeholder on-demand node on directly populating nodeCaolán McNamara1-0/+2
Initially there's a <placeholder> entry to indicate the load-on-demand state. It needs to be there for the expander indicator to be drawn/shown when there are no "real" entries yet. Typically the user clicks on the expander, the expansion remove the <placeholder> entry and calls the provided expander-callback which has the change to populate the node. Here RequestingChildrenHdl is the expander-callback (set via connect_expanding) and populates the node like it should. But then there are two places where it is called directly outside the expander-callback so it merrily appends entries into the node, but because it's called outside the expander-callback the <placeholder> entry was never removed which is then a problem because of the resulting inconsistency. Change-Id: Ie7d034e3f41832591438127c82eba85deb610952 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115952 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> (cherry picked from commit c4767868f1ee024efdd672cb21de9e3258c56694) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115959 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2021-05-18tdf#138209 ODF export: work around forms problem in LO < 7.0Michael Stahl2-2/+4
LO without commit 519d96fd8b83ef4c61576d87b58f97b7e6e6e3c6 makes a mess when storing form documents it has loaded from ODF 1.3 documents: the XML parts are stored as ODF 1.2, but the storage (and therefore manifest entry) keeps version 1.3. To avoid this, store form documents as ODF 1.2 extended by default. Unfortunately a bunch of ODF export code accesses the global SvtSaveOptions variable; with this version override, only SvXMLExport::getSaneDefaultVersion() must be used. Change-Id: I5fa8e286f5103c578ed0d93da07a8a6cbe2f0ddd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115357 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 16de54a5c47fbc4691ee099c1f7bb559a8fe11ac) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115390 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-05-18tdf#137810 sw: fix SwXNumberingRules setting CharStyleNameMichael Stahl4-11/+51
During ODF import, due to removal of the pDocShell parameter, this hits else rCharStyleName = sCharFormatName; while setting the "CharStyleName" property and later GetNumberingRuleByIndex() prefers m_sNewCharStyleNames over the format set in the SwCharFormat?? Also, "BulletFontName" has a similar problem; otoh "HeadingStyleName" only makes sense on chapter numbering. The m_pDoc and m_pDocShell members are such a WTF. (regression from ae0e4a6ba9be2fa99ac2be8e20157806e36209b2) Change-Id: I9d4d4cd7aeb7e6e29221d53facaff213fd4e35a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115495 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit c5e5467f6a13aba68b4706a4d7feb130e824bcc6) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115291 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-05-17tdf#142165 restore a SwShellTableCursor if the orig selection described thatCaolán McNamara1-2/+6
so that we are operating on the same selection that existed when the dialog was originally launched we need to avoid the assert of commit 6db71f70a3b200d4074f6cda8ce445e9861d3296 tdf#140977 drop possible table-cursor before setting the new one and support the multi-selection of commit e08b446e46f56e15af58fdd4396afba1a316f9e5 tdf#140257 duplicate entire PaM ring when making copy and support not scrolling to a different location on changing a table page break style of commit 9c61732677d038e32b73fc9fb883aced14c0febf tdf#135916 just set the target table as selection and keep making it possible to remove aa page break on a table of commit 81f91196b98af38e29af451b86c26a893a109abc tdf#135636 the selection at dialog-launch time is lost by dialog-apply time all of which is necessitated by commit c3a085d22742f88e91ff92f319a26d6e8d1d9a98 lokdialog: Convert the Table -> Properties... to async exec. Change-Id: Ide5f953e63da46a8750e85d623310af0062b048b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115522 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-05-12tdf#141307: adapt null-checkBjoern Michaelsen1-1/+1
- if we check pNd for nullptr, we need to expect it to be nullptr - in that case we shouldnt use the pointer before the null check Change-Id: Ia9d11abe32fac10f36fdbfcefeadd51891f1834e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115264 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org> (cherry picked from commit b0ae5aaaafd236663f7e81af06a567ade8a2a745) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115287 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-05-12Revert "tdf#141015: Show Mail Merge toolbar when DBData has data source"Mike Kaganski1-3/+1
This reverts commit 346153f08c907739ca310934ad45814379971027. It seems to create more problems than expected, and there's no way to remove DB association other than editing document XML. Change-Id: I93171f17c01e231abbcfa9a816fdadce83c983ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115283 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 2009af1c0fb4fead653dd7688347c15d74eaa1b0) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115286
2021-05-08tdf#138518 sw: layout: unbreak fdo80206-1.docMichael Stahl1-1/+1
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. Change-Id: Ib10c46f48746362d8d679c147ddc8b85157be508 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>
2021-05-07tdf#138518 sw: layout: fix assert on ooo43913-1.docMichael Stahl3-13/+19
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>
2021-05-07tdf#141540 fix docx import of group or line with rotationRegina Henschel4-10/+19
... and fix case wrap 'Square' and 'in Line' with them. Non-uniform scaling of a rotated shape might produce skew. Such had happened, when setting group or line to the size contained in GraphicImport. Avoid it. Writer has special rules for shape position and marging in case of wrap 'Square' and 'in Line', depending on rotation angle. The patch adds the needed margins. The patch changes some unit tests where we now get slightly different values. The patch fixes the wrong skew in sample document of tdf#73022. Change-Id: Ic743790c3fc8b8b10a4324d9e0184ad945cdceb6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114193 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 2a70cfb09c4d89154d229b6a95cf076e8bd76798) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115195 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-05-06tdf#126226, tdf#126735 sw Next Change: cycle through tracked changesLászló Németh3-0/+112
Next/Previous Change commands don't stop at the start or end of the document, but continue on the end or start of the document to cycle through all tracked changes, like Find Next/Previous and other office suites do. Change-Id: I5578d6b98b81ca1f8f222ba78e7d3c08339eca89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113716 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115183
2021-05-06tdf#142080 sw: layout: fix infinite loop in CalcContent()Michael Stahl3-5/+25
On page 9, SwSectionFrame::Format() calls CalcContent() and that formats all its content frames, then on SwTextFrame 91 SwObjectFormatter::FormatObj() fails becuase it moved forward. With commit c799de145f7e289f31e3669646e5bd12814e6c5e this now sets the o_rbPageHasFlysAnchoredBelowThis to true, which prevents a call to SwLayouter::InsertMovedFwdFrame(), and the flys anchored in next frames aren't moved off the page at this time. Then the loop starts over at the beginning of the SwSectionFrame, and frame 91 will be formatted again because the loop tries to format the first frame on the next page to see if it will move back; now the MoveBwd() isn't prevented any more so the result is the same failure in SwObjectFormatter::FormatObj(). Fix this by ignoring the bRestartLayoutProcess in case the current frame was originally on the next page and didn't move back (or, as is the case here, moved back and then forward again); it should just be formatted again on the next page. Once that happens, it will eventually be entered into SwLayouter::InsertMovedFwdFrame() too. This happens to fix another problem with this bugdoc too: the first column of the section on page 9 is empty. This also happens in LO 6.4 but not LO 6.1. An alternative would be to move the flys anchored below off the page as is done in SwLayAction::FormatContent() now but sections can be in flys or footnotes or headers so perhaps it should be done only at the top-level. (regression from c799de145f7e289f31e3669646e5bd12814e6c5e) Change-Id: I0965aebb4e3cec687f4e70f8d5e3aa8a55da3393 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115144 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit ed12269c42f75f553bb8a8770923406f7824e473) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115087 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-05-06tdf#141945 sw: layout: check master frame when moving fly forwardMichael Stahl2-2/+6
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) Change-Id: Ic6809a43c467955368807ccc82a7873c29fbfc2e 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>
2021-05-06tdf#140296: Added Edit Fields(context menu) inside of tablesAyhan Yalçınsoy5-0/+5
Change-Id: I22b6a179c1575171315d9eb40cd4895c35d77b6f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114986 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org> (cherry picked from commit 1cf47d932580a58a7855fe29ac39d17cdd79ae01) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115091 Reviewed-by: Ayhan Yalçınsoy <ayhanyalcinsoy@pisilinux.org> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-05-05tdf#138782 DOCX import: fix frame positions of old docsAttila Bakos (NISZ)2-0/+16
by limiting AddFrameOffsets compatibility option for docs created by MSO 2010 or older. Likely regression from commit 355d25eac764713f4d52eac801ade6e2ff1deab0 (n#779627: added quite some compat options from the ww8 filter on writerfilter). This patch fixes several bugs, which were collected as duplicates by Gábor Kelemen. Change-Id: I106e90c4bf00bb0b6a8986615cb3ad9c4828d5b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114476 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 5812fb81013cc124a9b6a0b9912a34cc715fc495) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115077 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins
2021-05-03tdf#141556 Fix 100% CPU usage in Writer idle loopLuke Deller3-36/+48
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
2021-05-02sw: speed up DoIdleJobs(WORD_COUNT)Michael Stahl1-0/+8
SwTextNode::CountWords() has early returns that don't clear the WordCountDirty flag, for nodes that don't contain any plain text. This speeds things up considerably for tdf135116-1.odt, which didn't finish the idle jobs after 5 minutes in an optimized 7.1 build, because the time slice tends to expire iterating nodes in word-count before it can make progress. With this it does ~25 WORD_COUNT pages and then ~90 AUTOCOMPLETE_WORDS pages per idle, sending OnLayoutFinished after 13-14 seconds. jmux just pointed me to commit 0fedac18214a6025401c4c426466a5166553e8ec which is not in 7.1 today and may have improved the performance here. Change-Id: I5e9651da3a173649c49fc36edefb23298dfd6bc4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114936 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 4184569b963877c2a488ff05766654b9db194798) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114919 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-05-02sw: layout: let nested table move forwardMichael Stahl3-2/+13
The problem is that a nested table at the bottom of the page doesn't fit into its cell, but it is split and its first row still remains on the page where it doesn't fit. The outer table 3 tries to split with bTryToSplit=true. In SwTabFrame::MakeAll(), first a split of the nested table 435 with bTryToSplit=true is attempted; this fails and is partially undone - the follow flow line is removed, but the last 2 rows remain in follow. The bTryToSplit=false is skipped because there's only one row now. Then MoveFwd() is tried, but it fails because the top-level table doesn't have a previous frame. Then bTryToSplit=false is tried, and succeeds, again leaving row 436 on page 1 and other 2 in follow. Now another attempt with bTryToSplit=true is made, failing again, not effectively changing anything. During all of this, growing of the outer cell frame 434 and row frame 433 is prevented by the outer table 3 having a follow flow line, see SwRowFrame::GrowFrame(). The result is that cell 434 has content area height 190 but the table 435 with its single row is all valid with height 406, so it's cut off in the rendering. This doesn't happen for SwTextFrame inside table because that one does the MoveFwd(). Plausibly it's the inner table's responsibility to finish with a valid state that fits the constraints of the current page; there are some checks in lcl_RecalcSplitLine() to check for no content frame in the row but none for the row being too small to contain the content that was formatted. So the only valid results for the inner table are that it either moved forward, or it left behind a row containing no content (such as that produced by its own failed attempt to split with bTryToSplit=true), which could be handled by the outer table split code - but the latter could be insufficient in case the outer table is itself a follow, or at least would require further changes in lcl_RecalcSplitLine(). So fix this by removing a condition in MoveFwd() that doesn't make any sense to me - why is it relevant for an inner table during a split of the outer table whether the outer table itself can move forward? Change-Id: I1e01ce233383cc70b9aea72d25369b7278eb75f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114760 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit ca19177728c66d913996a48c91a0ba47d08825d6) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114718 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-04-29Related: tdf#130326 drop ScContentTree::ObjectFreshCaolán McNamara1-2/+2
this was introduced as part of the large IA2 integration commit b41332475783c31136673fb44cf4c411bb0148f8 Author: Steve Yin <steve_y@apache.org> Date: Mon Dec 2 15:54:29 2013 +0000 Integrate branch of IAccessible2 Both calc and writer gained the feature that "space" in the navigator for drawing objects selects the highlighted object, extending the selection of another one is already selected. (notably impress was left unchanged) In calc, but not writer, an ObjectFresh was added which fires on every SfxHintId::ScKillEditView which is broadcast on every exit of the cursor from a cell. Its purpose seems to be primarily to re-highlight the last selected-by-keyboard entry on a content refresh. As far as I can tell this doesn't seem necessary and we already refresh content on SfxHintId::ScDrawChanged events so we shouldn't need to additionally refresh on ScKillEditView and refreshing on every ScKillEditView is very slow on navigating through a calc document with a lot of drawing objects. Change-Id: I64b2840f8510d474314d108e657fc3367f8ab6c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114876 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Jenkins
2021-04-29tdf#116384 only drag hyperlink if user's not currently setting the selectionCaolán McNamara1-2/+3
which is what writer does for normal text. Under gtk its common on selecting by dragging the mouse over a hyperlink for one or two letters of the hyperlink to get selected before that selection then gets dragged as dnd. Under gen StartDragWidth is 2 by default so the drag kicks in before enough text has been selected for writer to select anything, but under gtk gtk-dnd-drag-threshold is used for StartDragWidth and that is 8 by default making it easy to select one or two characters before the gesture is recognized as a possible drag. it seems sane to do the same as for normal text and not dnd if the user is still using the mouse to set a selection Change-Id: I971d429acaf8a5a656c5ce58f52632979b94e40a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114726 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-04-28tdf#138604 sw textbox copy: fix missing fly frames of as-char draw frameMiklos Vajna4-0/+53
Regression from commit 682e0488df819c191c13a03758fad0690706e508 (tdf#134099 sw: fix textbox anchors on copy-paste and undo, 2020-06-29), now that we don't copy draw+fly format pairs more than once, the fly frame of a fly format was missing. This was broken because sw::DocumentContentOperationsManager::CopyFlyInFlyImpl() calls CopyLayoutFormat() with bMakeFrames=true, but the frame format list doesn't contain as-char frames. For as-char frames CopyLayoutFormat() is called by SwTextFlyCnt::CopyFlyFormat() instead, but with bMakeFrames=false, so the fly frame's layout frame were never made. Fix the problem by explicitly making frames in DocumentLayoutManager::CopyLayoutFormat(), which also requires delete+make in SwTextFlyCnt::SetAnchor(). [ This is now consistent with the start of SwTextFlyCnt::SetAnchor(), which also deletes frames for fly frame formats. Otherwise CppunitTest_sw_core_txtnode would crash in testTextBoxCopyAnchor. ] Change-Id: I87003ee09ca75b9fecd70a1aa5c42f762f715be8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114680 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit feeaa5d3ca0c784344549816fbaab2c8716b4105) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114611 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-04-27tdf#141887 SW don't crash on missing SwWrtShellJan-Marek Glogowski1-3/+3
The code assumes that SwEditWin::Command can just be called, while there is still an m_rView.GetWrtShell(), which is at least not true, if you have an IM in pre-selection and close the Writer window via Window decoration. Change-Id: I67d5f1f917e9b2180037babb8c70c72d75c4a7ae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114624 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit 9a1c4a10b08ccb8d874a85a2cd984fd71f08c022) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114604 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-04-27tdf#141924: SwFormatAutoFormat::GetStyleHandle may return nullptrMike Kaganski1-3/+5
Change-Id: Id1b6fe687f5b328fa0743036a287bacfefe5e5fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114685 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114687 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-04-23tdf#138518 sw: layout: avoid moving flys forward prematurelyMichael Stahl3-17/+152
(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. Change-Id: I83e44d65a0b889a49a313b0cd8b08efce4c3afa7 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>
2021-04-23tdf#138785 sw: fix mis-positioned as-char flys when deleting empty pageMichael Stahl2-0/+6
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) Change-Id: If1b421daa0d71718d89d9772f5c0d9e367e76845 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>
2021-04-23sw: layout: if fly's anchor moves forward, move fly off SwPageFrameMichael Stahl9-9/+76
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. Change-Id: I232c6b305e8593bfecd885c36058777f3980f82f 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>
2021-04-21tdf#122962 DOCX drawingML export: fix polygon shape in group shapeMiklos Vajna1-2/+2
Regression from commit cfb5b20cdc230320ff9f864d1cfd81aaea221da0 (DocxAttributeOutput::OutputFlyFrame_Impl: enable DML export by default, 2013-12-18), there were two problems here. First, <a:chOff> and <a:chExt> was not written for docx group shapes. This can be done for toplevel shapes just by writing what would be the shape position and size (but for docx, we don't write the size). Second, (poly)polygon shapes used the bounding rectangle of their points as size, which doesn't necessarily match the shape size. Given that the group shape is meant to simply contain its children in LibreOffice (and not have an own size), switch to using the UNO API for polygon shapes as well, that way the two sizes will always match. Change-Id: I4406ddefe5f6105aa2fc74d805359add452936bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114305 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 4cb71fefc61d9015a0142f3a4fdafc5250913f2c) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114279 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-04-20tdf#141538 Make Remove button work in Select Address List dialogGabor Kelemen1-1/+5
... of the Mail Merge Wizard with non-GTK3 backends This works around the different return value of TreeView::get_selected_text() Change-Id: Id7542f8e73731ffe5d133703f0bd0d0ebf26b89f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113747 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 a258d42c77c3ce65a9455d08dc6106310222bc7b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114181 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-04-19tdf#141525 Fix "Line with Arrow/Circle" insertion error.Jeff Huang1-0/+8
When you insert "Line with Arrow/Circle" from "Lines and Arrows", it will show "Line Starts with Arrow" instead of "Line with Arrow/Circle". This patch can fix this issue. (This issue exists at least since 6.3 series.) Change-Id: I827b9582951fe359d89245970e73d63f7697553f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113963 Tested-by: Jenkins Reviewed-by: Mark Hung <marklh9@gmail.com> (cherry picked from commit 2b498e380a91a536d177376e854cf3a6e2fb0b35) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114179 Reviewed-by: Po-Yen Huang <jeff@mail.ossii.com.tw> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-04-15tdf#132393 sw: disable TabOverMargin layout flag inside sectionsMiklos Vajna3-1/+70
Regression from commit bdfc6363d66aa079512cc8008996b633f693fed1 (n#793998 sw: add TabOverMargin compat mode, 2013-01-08), the problem is that currently adding an alphabetical index generates document model where tab positions are explicitly over the margin and users expect that the page numbers are still visible, even for Word documents. Fix the problem by disabling this mode inside sections. Long-term we may want to fix the ToX generator to create a more sane document model and then this flag can be handled even inside sections. (cherry picked from commit e1cc5041cfb7272eb96f174e1c64285420397588) Conflicts: sw/qa/core/text/text.cxx Change-Id: Ic91ac36e703d59e4711a009db1f921e456bf8645 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114039 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-04-13tdf#141549 sw: fix ordering of virtual SdrObjects for textboxesMichael Stahl3-11/+37
In header/footer it turns out that not only can the text box be inserted after the shape, it can also be inserted before the shape. This is because SwDrawFrameFormat::MakeFrames() ends up first destroying all the SwDrawVirtObj and then creating them from scratch again, while the SwVirtFlyDrawObj survives. 4 SwDrawContact::DisconnectFromLayout(bool) (this=0x6ed0200, _bMoveMasterToInvisibleLayer=false) at sw/source/core/draw/dcontact.cxx:1664 5 SwDrawContact::ConnectToLayout(SwFormatAnchor const*) (this=0x6ed0200, pAnch=0x0) at sw/source/core/draw/dcontact.cxx:1791 6 SwDrawContact::SwClientNotify(SwModify const&, SfxHint const&) (this=0x6ed0200, rMod=..., rHint=...) at sw/source/core/draw/dcontact.cxx:1521 7 SwModify::CallSwClientNotify(SfxHint const&) const (this=0x6ecfd80, rHint=...) at sw/source/core/attr/calbck.cxx:321 8 sw::BroadcastingModify::CallSwClientNotify(SfxHint const&) const (this=0x6ecfd80, rHint=...) at sw/source/core/attr/calbck.cxx:326 9 SwDrawFrameFormat::MakeFrames() (this=0x6ecfd80) at sw/source/core/layout/atrfrm.cxx:3394 10 AppendAllObjs(SwFrameFormats const*, SwFrame const*) (pTable=0x69c1920, pSib=0x38c6100) at sw/source/core/layout/frmtool.cxx:1349 11 InsertCnt_(SwLayoutFrame*, SwDoc*, unsigned long, bool, unsigned long, SwFrame*, sw::FrameMode) (pLay=0x6be4320, pDoc=0x69af7c0, nIndex=157, bPages=true, nEndIndex=0, pPrv=0x6baedc0, eMode=sw::FrameMode::New) at sw/source/core/layout/frmtool.cxx:1927 Fix this by searching for the existing SwVirtFlyDrawObj in SwDrawVirtObj::AddToDrawingPage(). (regression from 3bc8f90e9693f710f12632f69b9348c1c833c906) Change-Id: Ic00878685ab16018c9331190f1e80f874c1a9a4e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113844 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit c2eae4998b3ae79210ef0b5c064e9833218c22de) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113853 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-04-09tdf#97569 docxexport: export russianUpper/russianLower numberingJustin Luth2-8/+8
Change-Id: Iad5f5d4687eccc05a63d6a9a4f81cf3f552cb17d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113829 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 3236020c4b8bed68dcf57210c0437f43f4160130) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113771 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-04-09tdf#139495 doc import: prevent negative Int forced into uIntJustin Luth4-2/+14
Don't cast a negative number into a sal_uInt16 and expect good results. (ww8import test) But for bug 139495 (and ww8export3), the problem area is also related to pHdFormat->SetFormatAttr(SwFormatFrameSize... which takes an awt::Size which consists of Longs. So they should accept negative numbers. Likely the result is being treated as a uInt somewhere. And a negative height doesn't mean very much anyway. There seems to be a fundamental difference between Word and LO here. Word sets the page margins, but that is irrelevant to the header/footer, which have their own distance from the edge. In LO, the header starts at the page margin, and the body text must follow the header, (In Word, the body text can start above the header, as seen in the ww8export3 unit test.) [FYI: DOC format (since forever) seems to ignore the header size, allowing the content to at least overlap with the body text, but DOCX doesn't have that. Likely this is #112727# using floating frames hack. So I'd better not keep messing around in here.] Change-Id: Ie7bffec8a3de25958cf1f311ff2c8338d4870d99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113681 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 28a9a92105f3155d82fd9e31095efabd3ec706ea) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113769 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-04-07tdf#136740: reimplement the fix using existing m_bIsNewDocMike Kaganski1-6/+0
This reimplements the fix from commit d7c4d0d4ea83481693af3645a03b03b53e456f60. The unit test from commit a90a324aa590a94a4091fbfadea67e0b0203767c still passes. Change-Id: I84c61fa68b9bee679a8e82ef7b8f164297bacb5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113665 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 7fc2cafbba36db25e7d0083cea162d2df08611b5) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113646 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-04-06tdf#136740: Do not initialize document settings when pastingMike Kaganski1-0/+6
When pasting from clipboard, the document already has the defaults set, and pasted text must not change those defaults. When pasting RTF, RTFDocumentImpl::outputSettingsTable does the document settings initialization, and is called from RTFDocumentImpl::checkFirstRun when m_bFirstRun is true. Other defaults are set in the latter function, too. This makes m_bFirstRun false when RTFDocumentImpl is created in the context of a paste operation. Alternatively, checking the context could be made when deciding if to apply specific settings. Change-Id: Ide1eabbef1d04a4fa2f1ca14846b8e404f2a0cb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113613 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit d7c4d0d4ea83481693af3645a03b03b53e456f60) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113634 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-04-06Exclude tests based on device color depth, not RDPMike Kaganski1-1/+1
After 5c9ba1f47d00ed10960b59928befd68f6c020b15, the failures on Jenkins (see 21191d0d8953a3ca6eac6022c0a14a87fe9c5e2a) made it apparent that (at least some of) Jenkins builds also run in RDP sessions. Since the tests excluded in commit 9c6142ec26a0ba61b1cf58d1e6bf0b5376394bcd never failed in Jenkins builds before, it is wrong to exclude all those tests in all RDP sessions: our CI would not test those on Windows. In the meanwhile, I discovered that the system that failed the tests actually had 16-bit color depth, despite RDP being configured to use 32-bit colors; that was the reason why the colors were modified on roundtrip. So it is better to test the actual problem to exclude tests. This reimplements the check that was introduced in commit 9c6142ec26a0ba61b1cf58d1e6bf0b5376394bcd to test default virtual device color depth. Change-Id: I329a3e2d8eca21732c77dcacf15394d1246b2e18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113466 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 7f2c6fff796f86d685aa20018ae72375011b1367) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113639 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-03-31tdf#140863: sw: Add UItestXisco Fauli2-1/+77
Change-Id: Ic1d3a56857dd68f436b870168ab394729a31d629 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113365 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-03-31tdf#140863: section.cxx: Remove remaining SwClientNotifyCallsBjoern Michaelsen1-27/+17
Change-Id: I569c5952a7491c37c677ad6b6d5f803a50b2e701 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106341 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org> (cherry picked from commit 5fc6a601d7a1978db291fd0f7dcec638a7c25651) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113361 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-03-31Exclude some tests in Windows RDP sessionMike Kaganski1-0/+2
It seems that RDP may change (limit?) color space (even configured to use 32-bit colors), and then some tests start failing like this: Test name: BackendTest::testDrawAlphaBitmapMirrored equality assertion failed - Expected: c[80000000] - Actual : c[84000000] Debugging ImplDrawBitmap in vcl/win/gdi/gdiimpl.cxx, and adding a call to GetPixel immediately after the call to StretchDIBits, shows that the resulting color on the device is different from the color in the bitmap data: e.g., for original color {128, 0, 0} the result is {132, 0, 0}. Calling GetColorAdjustment shows that there's no color adjustments set for the device, so I can't detect or modify the behavior this way. So just disable the tests for now when running in RDP sessions. Change-Id: Ie89d07f18f53e56bed6f7fa58432b8575b4d9f12 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113388 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 9c6142ec26a0ba61b1cf58d1e6bf0b5376394bcd) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113355 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 95b51c5792a8d71b079eac42d6439abaa15e44e8) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113403 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-03-31tdf#140828 sw textbox: fix AS_CHAR regressionAttila Bakos (NISZ)4-2/+39
Textboxes anchored as characters don't lose their text frames after changing the anchor "To character". Regression from commit 493a916a3113e877835c9bc7c93faef0d29f9a33 (tdf#140158 tdf#138598 tdf#140598 sw: fix sync of AS_CHAR textboxes). Change-Id: I0e6d88c9dcdeff515744bc4c201a5640eb810d1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112209 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113321 Tested-by: Jenkins Reviewed-by: Attila Bakos <bakos.attilakaroly@nisz.hu>
2021-03-30sw fr_FR AutoCorrect: fix crash using "Apply and Edit changes"Julien Nabet1-1/+1
Bad calling of SvxAutoCorrect::FnAddNonBrkSpace() in French documents, see tdf#140849 for a similar problem. Change-Id: I19b964fb8fe437c7f98342a873a456ffded75d82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112120 (cherry picked from commit df41967a29c4f8243d1df2d9b23d7c41d4a13819) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112731 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-03-30tdf#140556 master document view not launching subdocument from context menuCaolán McNamara1-1/+1
Change-Id: I0ae61e51266ae050e340c1af99e0dd6a481e6ff9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113281 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-03-26tdf#141079 Restore double click behavior for script fieldsSamuel Mehrbrodt3-2/+39
Change-Id: I5daa730740ea042bdae56b832f2557ec974339b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112668 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> (cherry picked from commit 5302268de6a33716c7746aa13232746ad2f2b561) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112970 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-03-26tdf#122717: fix handling of zero width/height linesXisco Fauli2-0/+13
The code was introduced in 627c2469843c9461b665c4571f1214aca7fc36a4 < tdf#96674 drawingML import: fix handling of zero width/height lines > and later on removed by 36bade04d3780bc54c51b46bb0b63e69789658a5 < tdf106792 Get rid of SvxShapePolyPolygonBezier > with the comment "I doubt that the additional code to make a line not exactly hor/ver is needed. Checked and it is not needed, thus removed the change from tdf#96674 in shape.cxx." it turned out, it's still needed Change-Id: Ib64ee17227e3e588e94381abeabe5a2ff2e0b7d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113102 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 3e4eb070787d4d44b3bdc95046e5b231dbbef42b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113119 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-03-25tdf#125936 writerfilter: treat escapement in numbering like stylesJustin Luth2-0/+6
deferCharacterProperties wasn't occurring in the numbering import (and so it was affecting the first run of the body text). But just like character styles, it would be better to just consider this auto-superscript instead of to defer it and calculate based on the fontsize - since that really isn't known until layout time, and so only works with direct formating. Change-Id: I9ce5a31c173089603316f4c3389e5f2e5dbe165a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112987 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-03-23Revert "tdf#136929 docx export: keep frame with paragraph"Justin Luth4-29/+7
This reverts 7.1 backport 7d90b50285f294a3c9cce0b22399fefe3ab46ee5. because tdf#141173 gives a disasterous example that fails. Change-Id: Ib3700c582c67973f7b0fac0edda6ae4033acc218 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112986 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-03-23tdf#133933 sw: fix crash on undo of redlined pasted tableMiklos Vajna3-1/+28
This is just a crash fix, there is some deeper problem here around undo: once redlining is on, overwriting table content during paste does not delete the fly frames anchored to empty cells (see lcl_CpyBox()), and we have the same problem on undo as well (see SwUndoTableCpyTable::UndoImpl()). And node indexes are recorded before inserting flys, so if they are not deleted, then the indexes don't match. Change-Id: I419e96c4d64f70a582358cab3808cea8b0e36649 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112939 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 140192fd5a2fc5e9d250d077d00bcebc014f7cbf) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112810 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-03-23tdf#140590 Writer crash in Tools>Chapter NumberingNoel Grandin1-1/+1
and an assert in vcl to catch it a little higher up the stack. Change-Id: Iaa2e70f901f93ca9f678118e4f5a8bc1b6eda20a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112459 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112866
2021-03-23Related: tdf#133933 sw: fix assertion failure in the SwIndexReg dtorMiklos Vajna2-3/+7
Make sure that by the time we delete a text node, no SwIndexes point to us. Change-Id: I9248a2ebe529e5a0aab0e37bf676e669b9bddb1d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112698 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit e782937228479054336b564a4c34697a12530469) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112950 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-03-18tdf#138895 DOCX filter: fix handling for effect extent vs line widthMiklos Vajna3-0/+32
Regression from commit a5a836d8c43dc9cebbbf8af39bf0142de603a7c6 (DOCX filter: effect extent should be part of the margin, 2014-12-04), the problem was that effect extent is OK to be added as an extra margin, but line width is part of that effect extent in Word, so Writer margin should not be increased with the line width. The Word behavior seems to be that half of the line width is part of e.g. the top effect extent, then the other half is part of the bottom one (and so on). The bugdoc's case was that a too large margin shifted the last line below the shape, and this tiny half-line-width extra margin handled correctly puts the line back to its correct place. Change-Id: Ic897926f3d79f979ea84aef3dbda49c46b18a3ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112558 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112582
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-15 18:09:00 +0000