aboutsummaryrefslogtreecommitdiff
path: root/source/sah/sw
AgeCommit message (Expand)Author
2023-07-26update translations for 7.6.0 rc2Christian Lohmaier
2023-07-07update translations for master/7.6.0 rc1Christian Lohmaier
2023-06-19update translations for master/7.6Christian Lohmaier
2023-06-12update translations for 7.6/masterChristian Lohmaier
2023-05-31update translations for master/7.6Christian Lohmaier
2023-05-22update translations for master/7.6Christian Lohmaier
2023-05-17update translations for masterChristian Lohmaier
2023-05-10update translations for masterChristian Lohmaier
2023-05-03update translations for masterChristian Lohmaier
2023-04-27update translations for masterChristian Lohmaier
2023-04-19update translations for masterChristian Lohmaier
2023-03-20update translations for masterChristian Lohmaier
2023-03-13update translations for masterChristian Lohmaier
2023-03-06update translations for masterChristian Lohmaier
2023-03-03update translations for masterChristian Lohmaier
2022-12-19update translations for 7.5.0 rc1/masterChristian Lohmaier
2022-12-12update translations for master/7.5Christian Lohmaier
2022-12-07update translations for master/7.5.0 beta1Christian Lohmaier
2022-11-25update translations for master/7.5.0 alpha1Christian Lohmaier
2022-11-23update translations for masterChristian Lohmaier
2022-11-14update translations for masterChristian Lohmaier
2022-10-24update translations for masterChristian Lohmaier
2022-10-22update translations for masterChristian Lohmaier
2022-10-10update translations for masterChristian Lohmaier
2022-08-10update translations for 7.4.0 rc3/masterChristian Lohmaier
2022-07-04update translations for 7.4/masterChristian Lohmaier
2022-06-15update translations for master/7.4Christian Lohmaier
2022-06-09update translations for master/7.4.0 beta1Christian Lohmaier
2022-05-25update translations for master/7.4Christian Lohmaier
2022-05-12update translations for 7.4.0 alpha1Christian Lohmaier
2022-05-04update translations for masterChristian Lohmaier
2022-04-26update translations for masterChristian Lohmaier
2022-04-11update translations for masterChristian Lohmaier
2022-04-04update translations for masterChristian Lohmaier
2022-02-18update translations for masterChristian Lohmaier
2022-01-31update translations for masterChristian Lohmaier
2022-01-10update translations for 7.3.0 rc2/masterChristian Lohmaier
2021-12-21update translations for 7.3.0 rc1Christian Lohmaier
2021-11-24update translations for master/7.3.0 beta1Christian Lohmaier
2021-11-16update translations for masterChristian Lohmaier
2021-10-25update translations for masterChristian Lohmaier
2021-10-04update translations for masterChristian Lohmaier
2021-09-27update translations for masterChristian Lohmaier
2021-09-14update translations for masterChristian Lohmaier
2021-08-30update translations for 7-2/masterChristian Lohmaier
2021-06-13update translations for 7.2.0 beta1libreoffice-7-2-branch-pointChristian Lohmaier
2021-05-31update translations for masterChristian Lohmaier
2021-05-14update translations for 7.2.0 alpha1Christian Lohmaier
2021-05-05update translations for masterChristian Lohmaier
2021-04-28update translations for masterChristian Lohmaier
/option> LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/sw/qa/core/layout/tabfrm.cxx
AgeCommit message (Collapse)Author
2024-10-05Use good old string literals in assertXPath and friendsMike Kaganski
These are only sent to an external API expecting char*-like strings, or for comparison. Having every assertXPath having three of _[ou]str is too much syntactic noise, making the unit tests almost unreadable. Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-07-30sw: get rid of parseDumpXisco Fauli
So parseLayoutDump is only called once per test Change-Id: Ia199e0a7eeac26fbde94f6450d2aa49828940806 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171219 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2024-07-27sw: use calcLayout() everywhereXisco Fauli
Change-Id: Ie03a3f13808456c831db10f2203fbfb84a50b999 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171076 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-06-06loplugin:ostr in sw/qa/coreNoel Grandin
Change-Id: Iaafc85d9b9042769f30c5662dbc9bf8c0e415312 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168487 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-29tdf#158801 sw floattable: fix crash with headers and interactive editingMiklos Vajna
Regression from commit ce2fc5eb29b4e252993b549dee002fa8948c8386 (tdf#158341 sw floattable: fix layout loop when fly is below the body frame, 2023-11-29), open the bugdoc, add an empty paragraph at the start, Writer layout crashes. The immediate problem is that SwTabFrame::MakeAll() assumes that in case HasFollowFlowLine() is true, then GetFollow()->GetFirstNonHeadlineRow() is always non-nullptr, similar to the situation in commit 223d2fac61e061478721a7a4a89b1362f5037d8f (sw floattable: fix crash by trying harder to split tables, 2023-11-22). The deeper problem is that the bugdoc has a repeated table header row, the fly frame temporarily gets shifted down, so nominally the header doesn't fit anymore, and this leads to a modification of the doc model, which creates inconsistency: the model now says we have no header rows but the layout still contains table row frames where the header bit is true. This is problematic in theory, but in practice caused no problem so far. Fix the problem by disabling this mechanism for floating tables: trying to have a table header that doesn't fit the table is asking for trouble anyway, and this way at least we have a layout that is consistent with the model, which also avoids the crash, now that nobody violates the "HasFollowFlowLine -> follow's FirstNonHeadlineRow != nullptr" invariant. Also extend the layout dump, so it's easier to see when the master's flag and the follow's row list gets out of sync. Change-Id: I52b51f6d86ab4e0bab560f892e9cceb183aecd5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164136 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-02-20tdf#159285 sw floattable: fix loop with inner table wrapped by inner tableMiklos Vajna
Regression from 868140fcc1311259b9d5f666637b33d226511a53 (tdf#60558 sw floattable: allow wrap of table on the right of a floattable, 2023-12-05), the bugdoc layout looped on load. Somehow the big while() loop in SwTabFrame::MakeAll() never finishes: it always tries again but can't reach a state where all of frame area position, frame area size and frame print area is valid. Fix the problem by going back to the old behavior (floating table is wrapped by text frames, not by table frames) for the nested table case: that keeps the old tdf#60558 use-case working and fixes the new tdf#159285 use-case. At some point it would be useful to support the combination of nested floating tables and the "floating table wrapped by table" combination, but that will be a new layout feature. Change-Id: Ia3fdbd08de87e13ddef086ae1339e79a8833674d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163630 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-01-23tdf#159017 sw floattable: only shift to the right when neededMiklos Vajna
Regression from commit 868140fcc1311259b9d5f666637b33d226511a53 (tdf#60558 sw floattable: allow wrap of table on the right of a floattable, 2023-12-05), the document had an inline table, followed by a floating table, and we moved the inline table to the right even if the left hand side of the floating table already had enough space. What happens here is that nominally the inline table's original position overlaps, but because the table width is small enough, such an overlap doesn't actually happen. In this case, it's not needed to shift the inline table to the right. Fix the problem by making the check that decides whether it's necessary to increment the left margin of the table more strict: it's not enough to have enough space on the right of the fly, it's also needed to *not* have enough space on the left side. This keeps the original "floating table wrapped by inline table on the right" use-case working, but restores the ~no left margin for the inline table for the new bugdoc. Change-Id: Ifb30d90ca6dba7cc4a402d8a4445251120b575ae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162447 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-12-05Fix typoAndrea Gelmini
Change-Id: I5f000f53f4dfec62a6d5a332361c380dc142d2bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160342 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-05tdf#60558 sw floattable: allow wrap of table on the right of a floattableMiklos Vajna
The bugdoc shows that Word wraps inline tables around floating tables if they have enough space, but Writer didn't do this. Table frames may wrap fly frames by adding some top, left or right margin to the table at a layout level, this is calculated in SwTabFrame::CalcFlyOffsets(). There we currently decide the give a top margin to such tables, which fixes the overlap problem, but the bugdoc is now of 2 pages instead of 1 page, since we don't wrap. Fix the problem by improving the "shift down" case by checking if shifting to the right would also work (has enough space). If so, do that in case the fly frame is a split fly. Note that this could be done for all flys as well, but that would have to be conditional on some Word compat flag and that's not needed to fix the bugdoc, so leave that for later. Change-Id: Idb45413257758fd0334b17ef348ba28010a52316 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160331 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-11-22sw floattable: fix crash by trying harder to split tablesMiklos Vajna
Regression from commit 60e2fdf1d7e8346e5a3835369c47e582c737ce20 (sw floattable: maintain the invariant that fly height is at least MINFLY, 2023-09-28), the bugdoc crashed on load in SwTabFrame::MakeAll(), because the tab frame's HasFollowFlowLine() was true, but GetFollow()->GetFirstNonHeadlineRow() was nullptr and the invarint is that these are always in sync. Digging deeper, what happens is that the master table has a split row at the end, so the follow table has a "follow flow line". We remove that when we try to split the master table (split either moves rows to the follow or creates a new follow), so the follow table only has a "headline row" remaining. Then Split() is called with bTryToSplit set to true, this fails (because only a single line would fit the master, but orphan/widow control rejects that) and then we join the follow table (because it only has headline rows), so a split with bTryToSplit set to false (don't split the row itself) never happens. This at the end leads to a strange table frame with only headline rows and gets deleted, which is odd to happen during the initial layout. Fix the problem by remembering if we just removed the follow flow line, and in case we tried to split the rows itself and table split failed, then don't join the follow table, so a next split can be invoked with bTryToSplit set to false, which leads to the correct layout. This means not only the crash is fixed, but also no layout loop happens and result matches Word. Limit this to tables in split flys, at least for this bugdoc the inline table case would not have this problem as widow/orphan control is disabled inside inline tables. Change-Id: I172e38be11baf6f73df722a4c6c035a6a283d727 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159802 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-11-19Extended loplugin:ostr: swStephan Bergmann
Change-Id: I210f61f6d90776b086b7058fb1a831d235699fb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159670 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-20tdf#157590 sw floattable: avoid hang in the nested + row span caseMiklos Vajna
Regression from commit 905962db870e9d1cf1dcf3bd1be44c347cddafe1 (sw floattable: handle AllowOverlap==false in the layout, 2023-08-10), the document load resulted in a hang due to a layout loop. What happens is that SwTabFrame::MakeAll() first does a Split(), but the problematic row has cells with rowspans, and once this is combined with multi-page nested floating tables, we move all the content to the next page (we only leave a stub table frame on the old page), so the next time SwTabFrame::MakeAll() is called, we do a Join(), and this leads to a loop. The traditional Writer way here would be to add a loop control, but we can do a little bit better: nobody really asked for row span handling with nested floating tables, so just don't split rows with row span in this case, move the entire row forward instead. This is enough to avoid the layout loop, and a next iteration can still use SwFlowFrame::MoveBwd() / SwFlowFrame::MoveFwd() to split the complex row. The bug is fairly hard to hit, any naive simplification to the original bugdoc leads to a working layout. Carefully keeping the size of the document, it's possible to at least simplify the content of the table cells (while keeping their size unchanged), so we avoid half of the tables and half of the shapes for a faster test case. Change-Id: Ib14154200c45ecb7f59e85f9f4f1fe0124c4256e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158228 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-09-27Related: tdf#126449 sw floattable: fix bad join of inline tbl with inner flyMiklos Vajna
The problem is that the bugdoc has 3 pages with an inline outer table, where pages 2 & 3 have an inner floating table. The outer table is only on pages 1 -> 2, while it should be on pages 1 -> 2 -> 3. The trouble is similar to point 4) of commit cfe9c68a7a19dd77d1fcbde3a7dd75730634becc (tdf#157119 sw floattable: fix moving master of split fly to next page, 2023-09-21), i.e. our normal behavior would move up the follow table to page 2 from page 3 and simply shift up the floating table, which is fine for images, but not for floating tables. Fix the problem by checking for flys on the old page when determining if it's OK to move or not. Checking for flys on the new page is already done in SwTabFrame::ShouldBwdMoved(), when it calls the precede's CalcFlyOffsets(). This just fixes a simplified DOCX bugdoc (inline outer table, floating inner table), the full document still needs more fixes. Change-Id: I7946c0f3cb9995a497fdfff3bfac28b6f16ff844 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157306 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-09-25tdf#157263 sw floattable: prefer join over split after moving fwdMiklos Vajna
Regression from commit a4af5432753408c4eea8a8d56c2f48202160c5fe (tdf#120262 sw floattable, legacy: fix text wrap around fly when no content fits, 2023-07-17), the bugdoc was of 3 pages in both Word and Writer, but is now of 4 pages in Writer. The above commit fixed the layout, so the first row of the table around the page 1 -> page 2 boundary goes to the start of page 2 instead of to the end of page 1. This matches the Word layout, so a wanted change on its own, but it regressed the page acount. The reason for this is that the table has a single row on page 2 and its follow on page 3 is not joined, even if there would be still space on page 2. A reduced bugdoc appears to reproduce this problem even without floating tables, also with old versions, so it's not a new problem, but it's now more visible. Fix the problem by tweaking what to do in the next iteration in the loop of SwTabFrame::MakeAll() after moving forward. Moving forward is followed by a next iteration in that function, but it does both a MakePos() and a Format(), so it'll be the last iteration in the "is the postion / size of this tab frame valid" loop. We used to hit the "bSplit == true" case, there we found that there is enough remaining space, so no need to split and we quit the loop. This is now changed, so in case we moved the table forward and there is still enough space for the follow to be next to us, then the last iteration will try to join instead of trying to split. Note that probably split almost never makes sense after moving forward in the !HasNext() && HasFollow() case, but let's stay on the safe side and only do this when the follow definitely fits, which is enough for our needs here. Change-Id: I64b0a7d257b0ab01353741506969a287b361c5ff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157233 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-05-11tdf#154775 sw layout: fix unexpected large table print area left marginMiklos Vajna
The bugdoc had 2 pages, but the second page's content was mostly a table. This table was rendered outside the page frame, so it was practically invisible. This started after commit fd7749fddc5a767461dfced55369af48e5a6d561 (sw: fix handling of table vs fly overlaps in the AddVerticalFlyOffsets case, 2020-02-14), and that behavior is still wanted to have correct table borders, but that change introduced an inconsistent case: we started to always accept an invalid frame area definition of the fly, but we only shifted the content down in the text::HoriOrientation::NONE case. Fix the problem by limiting the "accept invalid frame area definition" based on the horizontal orientation, so we either both ignore the validity flag & shift down or do none of this. This keeps the original bug fixed, but addresses the new "no visible table" problem. Note that this only fixes the regression part; once the image from the header is removed and undo is invoked, a similar problem still happens. But that is a pre-existing, separate problem. Change-Id: Id752c169b7c7fb6b75e6603ad29aaafbb676b8a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151652 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>