summaryrefslogtreecommitdiffstats
path: root/sw/qa/extras/uiwriter/uiwriter.cxx
Commit message (Collapse)AuthorAgeFilesLines
* sw: fix ViewCursor.PageStyleName for multi-page paragraphsdistro/escriba/escriba-5.2Miklos Vajna2019-08-081-0/+31
| | | | | | | | | | | | | | | | | | | | In case the text frames of a text node span over multiple pages and the first page has a page style which has a follow page style, the page style under the cursor depends on not only the text node index, but also on the context index. Without this, the page style under the cursor will expose the first page's style name via the API, even if it's already on a follow page. Reviewed-on: https://gerrit.libreoffice.org/77128 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 9a66b452ede70a25cd6fc8a72772a71b0ee7957a) Conflicts: sw/qa/extras/unowriter/unowriter.cxx Change-Id: I922e153750755317bda87441a88e9f53a6f348b7
* tdf#113686 sw: handle sections when counting height of first content lineMiklos Vajna2017-11-071-4/+36
| | | | | | | | | | | | | | | | | | | | When moving back a row that has a single text frame, it should not matter if that text frame is in a section frame or not. The problem was that the bugdoc has a split (outer) table, the follow's ShouldBwdMoved() returned false, as SwTabFrame::CalcHeightOfFirstContentLine() returned USHRT_MAX, as it had no idea how to calc the height of a text frame in a section frame. Fix this by looking "through" the section frame, and handling "text frame" and "text frame in section frame" the same way. Reviewed-on: https://gerrit.libreoffice.org/44393 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit e024cad7c1365da6a198656c3ca0c32b28938e87) Change-Id: Ic3605a1e2d28bfaa69bf18f31cfbf1e6e681c04f
* tdf#113520 sw split sections in tables: avoid empty page after content delMiklos Vajna2017-10-311-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem was that since split sections are allowed in nested tables, deleting enough content so that the full content of a page is removed results in an empty page, having only a 0 height table. I.e. the split section gets removed properly, the inner table (and its row and column) as well, but the outer table is still there, though it is marked to have 0 height. This results in a situation that the previous page doesn't have free space (the in-table section tries to take as much space as it can), but on the other hand we try (and fail) to move the 0 height table on the current page to the previous one, as it doesn't have free space. At the end the "empty" page still has an invisible table frame, so it is not removed. Fix the problem by allowing the move of a 0 height follow table frame from the current page to the previous one, even it has no empty space. Reviewed-on: https://gerrit.libreoffice.org/44059 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit c9c956f2716c58e2573a9ac07073f712d736ed02) Conflicts: sw/source/core/layout/tabfrm.cxx Change-Id: I2a5fac88b8b7dc2b91d041b58a4ad1b328f56a6b
* tdf#113445 sw: avoid hitting loop control with a dozen of in-table sectionsMiklos Vajna2017-10-261-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | The bugdoc has an (outer) table containing a single cell, which has an (inner) table with 12 cells, all content is inside sections, one section / cell. This relatively simple setup can already hit the loop control in lcl_RecalcRow(), as the SwLayNotify dtor always does invalidation in an async way, so the loop control's counter is incremented after each and every table cell. Instead of increasing the max tolerance in lcl_RecalcRow() (one can easily construct a document where the bug is still there even if the max is set to 100 instead of the current 10 iterations), just calculate the lower synchronously. Reviewed-on: https://gerrit.libreoffice.org/43848 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> Conflicts: sw/qa/extras/uiwriter/uiwriter.cxx (cherry picked from commit cb8b20ab3aa3f790d4979385874cdd4e2a87221b) Change-Id: Ifbffe13e5f2f237e1578bdd3e17d4d8b7c34806d
* tdf#113287 sw split sections in tables: fix missing invalidation on sect delMiklos Vajna2017-10-241-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem was that the Table1:A2 cell contents was wrapped in a section that was first split, then all the contents was moved to the next page, finally the empty master was also moved to the next page. At this point the master had 0 height, and when it was removed, the follow section frame had invalid positions, including all of its contents. Position invalidation for table contents works by first invalidating the table frame position, which triggers an invalidation chain for both all next frames and the lower frame. Other lower frames are not invalidated, that happens when the first lower is calculated, in SwLayoutFrame::MakeAll(), when the SwLayNotify dtor is executed. This mechanism did not help us here, as the master section frame was already marked for deletion, so SwLayoutFrame::MakeAll() was not called for it, so neither of its next frames were re-positioned. Fix the bug by explicitly invalidating the position of the next frame in SwSectionFrame::MakeAll(), for the "return early, this section will be deleted anyway" case. (The alternative could be to watch out for 0-height sections in the SwLayNotify dtor, but the problem is specific to section frames, so SwSectionFrame is probably a more expected place for this change.) Reviewed-on: https://gerrit.libreoffice.org/43604 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit cd74225ddad06ca826a37c8ba91eedd9d2aa23ce) Conflicts: sw/qa/extras/uiwriter/uiwriter.cxx Change-Id: I5ab9475675d25bef7c0647893b1b5909da019f3f
* tdf#113153 sw: fix layout loop with split in-table sectionsMiklos Vajna2017-10-171-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | The problem was in SwFrame::GetNextSctLeaf(): it called WrongPageDesc() to find out if pLayLeaf is a container that is on an acceptable page, but it was too aggressive, and discarded a split table cell that was in a follow table (so later it'll be moved to a next page), but on the same page. The result was that a new page was created, but later in ::doInsertPage() we noticed this unnecessary page and removed it. The effect of that was that the in-progress layout action's m_bIsAgain flag was set to true, restart the layout again and again. Given that in-table split sections never need to create a new page frame for the follow section (the cell does this for us already), just don't discard pLayLeaf when WrongPageDesc() finds it and we're in the split section-in-table case. Change-Id: Iea98a26c14fc1fb3154378eab24daa2fd6e84459 Reviewed-on: https://gerrit.libreoffice.org/43429 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit a69f48d923628facf7113ebc739a8273c4069122)
* tdf#112860 sw: avoid shortcut for tables in SwFrame::GetNextSctLeaf()Miklos Vajna2017-10-061-0/+10
| | | | | | | | | | | | | | | | | | As the comment says the shortcut only works if no columns or pages are between the section frames, while for tables there are definitely table, row and column frames. This resulted later in SwFrame::IsFootnoteAllowed() a nullptr dereference, as the frame was still marked as in-table, but wasn't in a table anymore. Reviewed-on: https://gerrit.libreoffice.org/43091 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit c985ad5f7b479706935459630c5a59ccae6fa8b7) Conflicts: sw/qa/extras/uiwriter/uiwriter.cxx Change-Id: I4191c77d20c6ccc096156fae15ca7c22cc5b68b6
* tdf#112741 sw split sections inside table cells: fix table re-layoutMiklos Vajna2017-09-291-0/+15
| | | | | | | | | | | | | | | | | | | | | | | The bugdoc has a section large enough that it is split across 4 pages. The section is inside a nested table. First we lay this out properly, but when later laying out the footer we need to redo the body frame layout, which first undoes the split of the table/nested table/section. This fails, the master second and its 3 follows are expected to be moved back to the first page (and merged together), but SwSectionFrame::MakeAll() did this only for the first follow, which was moved to the first page, not for the other 2 follows which were on other pages. Fix the problem by merging not only follows which are also next to the section frame, but also the ones which are follows (but not nexts). (cherry picked from commit 813e180521cd17175910af30599509b358166855) Conflicts: sw/qa/extras/uiwriter/uiwriter.cxx Change-Id: I7a69aa58336a50d4f37808ccb105b443c2f6993c
* sw: split section frames inside table cells, handle nested tablesMiklos Vajna2017-09-251-0/+17
| | | | | | | | | | | | Commit 3d1bb76ebf5c51141018cfd76eccdb63472de8de (tdf#112109 sw: split section frames inside table cells, ignore nested tables, 2017-08-31) explicitly disabled this, but the underlying problem is now fixed with commit ec262cbc56822d8fffccd6e983848df196cf5c44 (tdf#112160 sw: audit GetNextLayoutLeaf() calls in SwFrame::GetNextSctLeaf(), 2017-09-04), so we can have it again. Change-Id: Ic17c4921de2c69e4cc16ae82cfed58d096879db7 (cherry picked from commit 8da365e2a7a6b30da6c2ca26b2a5f45f89cd5460)
* tdf#112160 sw: audit GetNextLayoutLeaf() calls in SwFrame::GetNextSctLeaf()Miklos Vajna2017-09-041-0/+25
| | | | | | | | | | | | | | | | | | | | | GetNextLayoutLeaf() returns the next container, not the follow one, so calls to that without checking first if we are in a table are always suspicious. This leads at the end to strange content move, as described in the bug. There appears to be only a single place in SwFrame::GetNextSctLeaf() which may be executed for split sections and called GetNextLayoutLeaf() unconditionally. Reviewed-on: https://gerrit.libreoffice.org/41882 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit ec262cbc56822d8fffccd6e983848df196cf5c44) Conflicts: sw/qa/extras/uiwriter/uiwriter.cxx Change-Id: I759d9ef63660f3d2ffe006c88b18cba7dba99f33
* tdf#112109 sw: split section frames inside table cells, ignore nested tablesMiklos Vajna2017-08-311-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | Commit f8a76d218305a56d15b82b9dac4fafa558872780 (tdf#108524 sw: split section frames inside table cells, non-split text frames, 2017-07-06) added support for moving text frame masters to a next page inside section-in-table frames. But the code in SwFrame::GetNextSctLeaf() responsible for this is not up to nested tables, so don't try to split sections in this case. Otherwise we'll end up with frames which are marked as "in table", but don't actually have have table frame parents, so we crash in SwFrame::IsFootnoteAllowed() which assumes being in a table means a table frame parent. Reviewed-on: https://gerrit.libreoffice.org/41748 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 3d1bb76ebf5c51141018cfd76eccdb63472de8de) Conflicts: sw/qa/extras/uiwriter/uiwriter.cxx Change-Id: Iff19a4eda21a4dbfb9562dea7af8ec6767d47873
* i#95698 sw: fix crash on splitting in-table section containing a nested tableMiklos Vajna2017-08-231-0/+10
| | | | | | | | | | | | | | | | | Found by crashtesting, ooo95698-1.odt crashed sw layout on load. The intended use-case is splitting section frames inside a table frame, so can just blacklist the non-interesting table-in-section-in-table case that causes the problem here. Reviewed-on: https://gerrit.libreoffice.org/41224 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit 802477ae75b39194442d9c01a1342d068c7b9300) Conflicts: sw/qa/extras/uiwriter/uiwriter.cxx Change-Id: Ic47cd8c46cc71f7eaa36b03ec2c4a5df8ca8051c
* CppunitTest_sw_uiwriter: disable testLinesMoveBackwards... on macOSMiklos Vajna2017-08-231-0/+2
| | | | | | | | No idea off the top of my head what is the problem here, seeing Linux and Windows is happy; clang on Linux as well. Change-Id: I56c79b37a5648d9afd02d8e161ea4a279cc89744 (cherry picked from commit 39dd0121f5994dee56f95bc57fae3323bf849a20)
* tdf#108524 sw: handle sections inside tables in SwFrame::GetPrevSctLeaf()Miklos Vajna2017-08-231-0/+29
| | | | | | | | | | | | This addresses the sub-problem described in comment 12 of the bug, i.e. text frames are now moved to the first page from the second one when text frames are deleted on the first page. Change-Id: Ic0ede45381fb84b13d1ac02e4d1f39d817650616 Reviewed-on: https://gerrit.libreoffice.org/39946 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit 850bf99e7d1abcf2e0cce731b6715f87420d0ee6)
* rhbz#739252 sw: fix crash on split tables inside nested sectionsMiklos Vajna2017-08-231-0/+13
| | | | | | | | | | | | | | | | | | | | | | Commit b5e0a143308e976b4165ff6181f4dccc3db0bd31 (tdf#108524 sw: attempt to split section frames inside table cells, take two, 2017-07-03) checked for tables in SwFrame::GetNextSctLeaf() when it considered looking up the next "follow" cell frame. But this is too general, in practice it is only necessary to look for follow cell frames in case the frame in question is in a table, but not in a table-in-section. This at the same time avoids a crash with tables inside nested sections, as it happens in the bugdoc. Reviewed-on: https://gerrit.libreoffice.org/39692 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit 652556ec3e9218655a67b4c4de4e26fbe81855de) Conflicts: sw/source/core/layout/sectfrm.cxx Change-Id: If648cb477be5492c7158f89934435ca7021a6a63
* tdf#108524 sw: split section frames inside table cells, non-split text framesMiklos Vajna2017-08-231-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit f991b842addddeada6dc45c4054deeca5aa7f17b (tdf#108524 sw: attempt to split section frames inside table cells, 2017-06-19) added initial support for multi-page sections inside a table cell, but turns out this only worked in case at the split point there was a long enough paragraph, so it was split into two (a "master" text frame and a "follow" one), and then the follow was moved to the next page by SwContentFrame::MakeAll(), with the MoveFwd() call in the "If a Follow sits next to its Master and doesn't fit, we know it can be moved right now." block. However, if the section contains lots of one-liner text frames, then all of them are masters, so the above code doesn't move them to the next page; so the section frame is still not split. Fix the problem by allowing the move of frames inside table-in-sections in SwSectionFrame::MoveAllowed(), that way SwTextFrame::AdjustFrame() will not set the text frame as undersized, so at the end SwContentFrame::MakeAll() will call MoveFwd() in the "If a column section can't find any space for its first ContentFrame" block. With this the split of text frames in section-in-table frames is consistent regardless if they are of multiple or single lines. Change-Id: Ief9d62da3fd8a5c707e1f9489a92f7a81e7b38ac Reviewed-on: https://gerrit.libreoffice.org/39623 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit f8a76d218305a56d15b82b9dac4fafa558872780)
* tdf#108524 sw: attempt to split section frames inside table cells, take twoMiklos Vajna2017-08-231-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tables-in-sections were already split across multiple pages, but not secions-in-tables. To be safe still don't allow sections-in-tables-in-sections, so you can combine these in both orders now, but not recursively. To achieve this, relax two "not in table" conditions to just require "not in a table that is already in a section", and define that in case a section-in-table is to be split, the follow section frame should be inserted under the follow of its cell. With this, finally the section frame in the bugdoc is split into two, and the second section frame is moved to the second page as expected. This restores commit f991b842addddeada6dc45c4054deeca5aa7f17b, but this second take makes sure that we do not crash while laying out ooo61225-1.sxw. GetNextSctLeaf() used to assume that SwTableFrame::Split() created the follow cell frames; and when that wasn't the case, it crashed. Still don't attempt to create the cell frame in GetNextSctLeaf(), but handle when the cell follow frame is missing, and return early, as it used to be the case before this commit. Reviewed-on: https://gerrit.libreoffice.org/39471 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit b5e0a143308e976b4165ff6181f4dccc3db0bd31) Conflicts: sw/qa/extras/uiwriter/uiwriter.cxx Change-Id: I9dcc76b4c61b39b9d23b140b84420e89cf274cf3
* Avoid loplugin:unreffunStephan Bergmann2017-08-231-1/+7
| | | | | | | | | | | | ...after 272d5a02a3de2350f8af7a93281b651316b24ae5 "Revert 'tdf#108524 sw: attempt to split section frames inside table cells'" (cherry picked from commit 12ca907139c05ded23cb22aab2e03a52645adfa0) Conflicts: sw/qa/extras/uiwriter/uiwriter.cxx Change-Id: Ic1ec8cd3284e2ba98630552c80d99b5d67fc7efd
* Revert "tdf#108524 sw: attempt to split section frames inside table cells"Michael Stahl2017-08-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit f991b842addddeada6dc45c4054deeca5aa7f17b. It doesn't really work and crashes on ooo61225-1.sxw in 1 in SwFrame::FindTabFrame() (this=0x0) at sw/source/core/inc/frame.hxx:913 2 in SwFrame::GetNextSctLeaf(MakePageType) (this=0x3137130, eMakePage=MAKEPAGE_INSERT) at sw/source/core/layout/sectfrm.cxx:1529 3 in SwFrame::GetLeaf(MakePageType, bool) (this=0x3137130, eMakePage=MAKEPAGE_INSERT, bFwd=true) at sw/source/core/layout/flowfrm.cxx:805 4 in SwFlowFrame::MoveFwd(bool, bool, bool) (this=0x31371d8, bMakePage=true, bPageBreak=false, bMoveAlways=false) at sw/source/core/layout/flowfrm.cxx:1861 The code added in GetNextSctLeaf() looks unfinished to me: it assumes that something else has added a follow-frame for the SwCellFrame containing the SwSectionFrame already, but AFAICT the GetNextSctLeaf() function is responsible for creating that SwCellFrame follow. The caller (in GetLeaf()) specifically checks for this condition and avoids calling GetNextCellLeaf(). (cherry picked from commit 272d5a02a3de2350f8af7a93281b651316b24ae5) Conflicts: sw/qa/extras/uiwriter/uiwriter.cxx Change-Id: I51875830771f07f5d2fec293f6063c73fc68d468
* tdf#108524 sw: add split section in table testcaseMiklos Vajna2017-08-231-0/+30
| | | | | | | | | | | | | | | And if we're at it, test the other way around as well, I almost broke it. Reviewed-on: https://gerrit.libreoffice.org/38999 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit e9d2016648c7fdfc57932ac0793547cf099749be) Conflicts: sw/qa/extras/uiwriter/uiwriter.cxx Change-Id: Ia81e46f218336e5db13dafdbad7b896d8dadaf46
* sw: add new TextParagraph property to XTextRangeMiklos Vajna2017-07-281-0/+23
| | | | | | | | | | | | | | | | A text range represents a selection or cursor position, so similar to sections or tables, it makes sense to expose the containing paragraph as well. This new property does exactly that. Reviewed-on: https://gerrit.libreoffice.org/40483 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 7ed402ba648dd0f3de3b0dadebc13403b2c0a620) Conflicts: sw/qa/extras/uiwriter/uiwriter.cxx Change-Id: If92a3b5e61f13c7c14ca52bc8593a2b286a596cc
* tdf#104814 Writer: accepting change tracking changes get stuckNoel Grandin2017-01-101-0/+14
| | | | | | | | | | | | | Reviewed-on: https://gerrit.libreoffice.org/32273 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> (cherry picked from commit b7b5c23e6979205a662d857bc1c83270fb4a43ec) Reviewed-on: https://gerrit.libreoffice.org/32276 Change-Id: Ie8e0919b53c0b21f480b62eec7c394554757a061 Reviewed-on: https://gerrit.libreoffice.org/32887 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* tdf#78727 sw: fix missing textbox text when anchored inside flying tableMiklos Vajna2016-09-101-0/+12
| | | | | | | | | | | | | | | | | | | | It was missing as the shape text range was deleted twice, as DelFlyInRange() thought both the fly and the draw frame format own its contents range, while only the fly one does (when called by SwDoc::MakeFlyAndMove(), called by SwXText::convertToTextFrame()). Thanks Red Hat for the pizza! (cherry picked from commit 9d9e5b40c1a6d91323564e60b25ccf04df86db4b) Conflicts: sw/qa/extras/uiwriter/uiwriter.cxx Change-Id: I26e23550df085511e0e87f593f1a461057413d0e Reviewed-on: https://gerrit.libreoffice.org/28776 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
* Related: tdf#84695 sw: fix TextBox begin text edit by pressing normal charMiklos Vajna2016-05-051-0/+24
| | | | | | | | | | | | | When a draw shape is selected, but its text is provided by a TextBox, then F2 and Enter could start editing already, but pressing a normal character didn't work (unlike for TextFrames or regular draw shapes). Fix this by calling into lcl_goIntoTextBox() at one more place. Change-Id: Ia594279918a6c3087cac8b0c859ce7432e4a685d Reviewed-on: https://gerrit.libreoffice.org/24671 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
* CPPUNIT_ASSERT(a == b) -> CPPUNIT_ASSERT_EQUAL(b, a)Miklos Vajna2016-05-041-1/+1
| | | | | | | Change-Id: I84dcd5ccc48d46f4aaa1ad33b341bfe7542757a3 Reviewed-on: https://gerrit.libreoffice.org/24631 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
* tdf#98512 sw: add unit testMichael Stahl2016-05-031-0/+40
| | | | | | ... and fix the SAL_WARN not to warn spuriously. Change-Id: Ic951fc0d811e5cab39989285d34bdd2fff8f95fd
* Fix tdf#96515 unit testJan-Marek Glogowski2016-04-301-7/+13
| | | | | | | | | | This also makes the test font independent, as it just tests the growth and shrink of the first page in "HideWhitespace" mode. Change-Id: I65d6b7c761939679f72fa24c744f1df23f8ba321 Reviewed-on: https://gerrit.libreoffice.org/24520 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Tested-by: Jan-Marek Glogowski <glogow@fbihome.de>
* teach stylepolice plugin about ref-counted-pointer namingNoel Grandin2016-04-281-5/+5
| | | | | | | Change-Id: I6e91d22fc1826038c05ddb6fc065563c6a250752 Reviewed-on: https://gerrit.libreoffice.org/24459 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
* Fix typosAndrea Gelmini2016-04-211-1/+1
| | | | | | | | Change-Id: Ic4fbc8e7220eb4641f67ef4f85d4853608a369f4 Reviewed-on: https://gerrit.libreoffice.org/24257 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com>
* tdf#84695 sw: make TextBox in shape accessible without mouseMiklos Vajna2016-04-051-0/+25
| | | | | | | | | F2 or Enter can now switch to text edit mode. Change-Id: I1aea09bd2fc4fa64db49b2037894082fe33af934 Reviewed-on: https://gerrit.libreoffice.org/23836 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
* tdf#99004 SwAnchoredObjectPosition: handle textboxes when determining surroundMiklos Vajna2016-04-011-0/+17
| | | | | | | | | | | | | | | | | Writer TextBoxes are always wrapped "through", so that they can appear inside their shapes. However, the surround of the shape may influence its position. So when surround is asked for anchor position purposes, take the surround of the TextBox's "parent" shape instead of the one of the TextBox directly. With this, the TextBox in the bugdoc is properly positioned inside its parent shape as expected. (The problem only happens when at least two shapes are anchored to the same paragraph.) Change-Id: I0cf8a41080e6759aa395c119d862c4be79574d66 Reviewed-on: https://gerrit.libreoffice.org/23720 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
* tdf#98987 sw: add AddVerticalFrameOffsets compat modeMiklos Vajna2016-03-311-0/+19
| | | | | | | | | | | | | | | | | | | | | | | The situation is the following: we have a text frame, with at least two anchored objects: one is wrapped not-wrap-through, the other is. In case the non-wrap-though one shifts the text content of the text frame right or down, then layout may or may not want to re-consider what is the top left corner of the text frame for anchoring purposes. Regarding the x position, sw layout repositioned the anchor point depending on the AddFrameOffsets compat mode: it's enabled for documents imported from Word, disabled otherwise. Regarding the y position, no repositioning was done, however the bugdoc shows that Word does the same repositioning on the vertical axis as well. Add a new AddVerticalFrameOffsets compat mode that enables vertical repositioning as well, and enable that mode for documents imported from DOCX. Change-Id: Idc5cad7d86662008a92ff3bf5fbb3806aa2c7b07 Reviewed-on: https://gerrit.libreoffice.org/23702 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
* fix headless buildOliver Specht2016-03-251-2/+7
| | | | | | | | | | disables OpenGL and glew usage, lets --without-gui do what --without-x did before and disables X related test Change-Id: I680b47c9962a0d43c8ece593db0b82e347ceebdb Reviewed-on: https://gerrit.libreoffice.org/23474 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Oliver Specht <oliver.specht@cib.de>
* tdf#88453 sw layout, nested table split: shrink inner tables as wellMiklos Vajna2016-03-241-0/+11
| | | | | | | | | | | | | | | | | | Commit b4b5dbee1ec7770ed64d7270de46d5cfc06b87b6 (tdf#88453 sw layout: fix split of nested tables with large amount of rows, 2016-03-23) took care of two similar problems when splitting tables which has nested ones (setting cell height to 0 when its content height is 0, and setting row height to 0 when its cells' height are zero). Turns out there is a third aspect of the same problem: when row heights are set to 0 during shrinking for table split purposes, the table height has to be set to 0 as well, in case the table contains only 0-height rows. With this, the original bugdoc's layout is the expected one. Change-Id: I3f5392eb914a60e9caa5182dc6d44bd3a93f41d6 Reviewed-on: https://gerrit.libreoffice.org/23497 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
* Added Test for tdf#63553 copy/paste of cross referencesVarun Dhall2016-03-231-0/+263
| | | | | | | Change-Id: I9d50b170b228e270e60212cb10711fb537dae706 Reviewed-on: https://gerrit.libreoffice.org/22809 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
* tdf#88453 sw layout: fix split of nested tables with large amount of rowsMiklos Vajna2016-03-231-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This does not fix the original bugdoc, just the case described in comment 2. The bugdoc has an outer table of a single cell, and that cell has a nested table with a single column and many rows. When we split the table, we set the height of the last row frame to zero, then the height of the last but one, and so on, till the reduced table fits the page, then move the 0-height frames to the next page, and so on. All this recursively, to support nested tables. The problem is that 0-height is set only for the contents of the cell frames, but not for the cell or row frames themselves, so in case e.g. the default ~0.10cm inner margin of the cell frames, even a 0-height text frame results in a cell frame height of 111 twips. And this error can accumlate if there are enough rows, e.g. with the default fonts 123 rows are enough to trigger the situation when even a completely reduced table doesn't fit the first page frame, and the layout throws up its hands. Fix the problem by setting the height of the cell and row frames to 0 as well in case their content is 0-sized anyway (so a re-format will later restore their correct height). Change-Id: Iefbbb7bd6ef97a9a81929eb2599adb961e52fd38 Reviewed-on: https://gerrit.libreoffice.org/23476 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
* loplugin:constantparam in swNoel Grandin2016-03-221-2/+1
| | | | Change-Id: I56925a8fd776b3ee787cc26adbaa08c58dd022c0
* loplugin:constantparamNoel Grandin2016-03-151-1/+1
| | | | Change-Id: I270e068b3c83e966e741b0a072fecce9d92d53f5
* work on sane lifecylce for SfxFilterMarkus Mohrhard2016-03-111-6/+6
| | | | | | | | | | | | | | | | | | all SfxFilter instances should now be hold inside of a std::shared_ptr. This fixes a number of huge memory leaks in the test framework and removes one huge source of memory issue in sfx2. SfxMedium contains a pointer to the SfxFilter but does not own. Therefore it is required that any SfxFilter belonging to a SfxMedium lives longer. However this seems to work mostly by hoping that all SfxFilter instances are stored in a global array. As we have seen with the tests this is not true (there are also some cases inside of sd that seem to not follow that pattern as well). Change-Id: I12fd04a504cc4efc0a94967abd91c6fe2c6a8ce8 Reviewed-on: https://gerrit.libreoffice.org/23140 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
* sfx2: make SfxClassificationHelper not require a full doc shellMiklos Vajna2016-03-101-3/+13
| | | | | | | So that input filters can build their own doc properties and can also use CheckPaste() without having the full original document around. Change-Id: I0b8a63702f73ce04e8728a360b56ab9d1ca67af1
* Extract Directories from BootstrapFixtureBaseStephan Bergmann2016-03-101-3/+3
| | | | | | | | | | (as some tests derive from the latter only for the Directories part, not for the setUp/tearDown overrides: those tests will be cleaned up next) Change-Id: Ib6b78eea868b8bc21d4cc6e8fd9e1d025deca05f Reviewed-on: https://gerrit.libreoffice.org/23078 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* CppunitTest_sw_uiwriter: add classification copy/paste testcaseMiklos Vajna2016-03-091-0/+27
| | | | Change-Id: Ic3ac02fe28bee0ea3189fb2c9d3548f5ca13fe5c
* tdf#97601 sw: don't mark an already modified chart as modifiedMiklos Vajna2016-03-081-0/+28
| | | | | | | | | | | | | | | | | | | | Regression from commit e2b260fc98e833d4e64426b90992094f2da0498c (sw: let layout not mark embedded object as modified, 2014-06-03), an infinite loop was caused by: 1) SwDoc::SetOLEObjModified() triggering the maOLEModifiedIdle Idle 2) which at the end called SwWrtShell::CalcAndSetScale() 3) which at the end called chart::ChartModel::setModified() 4) where chart code called back into SwDoc::SetOLEObjModified() via the modification listener, and this happened again and again. The original fix wanted to avoid marking the document as modified without a user interaction, so fix the bug by only calling setModified() if it prevents a not-modified -> modified transition. This keeps the original bug fixed, but prevents the infinite loop, that is always a modified -> modified transition. Change-Id: I3b56a91afaacd3e0b7cb646a492fd15f1b5168ee
* tdf#65219 Fix temp files clean up in sw unit testsAleksas Pantechovskis2016-03-071-0/+2
| | | | | | | Change-Id: I57f4dc90bc2ad8488af8cd42515b195f4320a9d9 Reviewed-on: https://gerrit.libreoffice.org/22939 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
* loplugin:unuseddefaultparam in sfx2Noel Grandin2016-03-021-3/+3
| | | | Change-Id: I37afde801a6468c79259fe51acbdea0614c2c8c5
* Updated search flag for testSearchWithTransliterateVarun Dhall2016-02-291-1/+1
| | | | | | | Change-Id: Ie540aca97cddbd657faae5d15293a922ba5196d5 Reviewed-on: https://gerrit.libreoffice.org/22702 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
* loplugin:stringconstantStephan Bergmann2016-02-251-5/+5
| | | | Change-Id: I6e22654d78ba8e043bab1009a295f078f9666000
* Added test for tdf#73660 search for string with soft hyphenVarun Dhall2016-02-251-0/+39
| | | | Change-Id: Ia152f9cd97ead8e4289541ae6cd3e21a9635ffe0
* let SvxSearchItem use SearchOptions2Eike Rathke2016-02-241-2/+5
| | | | | | And all those places that interface to SvxSearchItem. Change-Id: I08915824a596cd0f247a89f44e4684cd22b98082
* tdf#84938 replace FRMMGR_TYPE_ with enumackepenek2016-02-211-1/+1
| | | | | | | Change-Id: I899b57a485b83cd7c10ddc5192c92b4c87fe583a Reviewed-on: https://gerrit.libreoffice.org/22582 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
generated by cgit (git 2.34.1) at 2024-06-03 15:47:47 +0000