Age | Commit message (Collapse) | Author |
|
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
|
|
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
|
|
Change-Id: Ie03a3f13808456c831db10f2203fbfb84a50b999
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171076
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: Iaafc85d9b9042769f30c5662dbc9bf8c0e415312
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168487
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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
|
|
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
|
|
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
|
|
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>
|
|
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
|
|
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
|
|
Change-Id: I210f61f6d90776b086b7058fb1a831d235699fb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159670
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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
|
|
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
|
|
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
|
|
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>
|