summaryrefslogtreecommitdiff
path: root/sw/qa/core/layout
AgeCommit message (Collapse)Author
2024-12-06tdf#164095 sw: fix missing top margin on paragraph after changing page styleMiklos Vajna
Open the bugdoc, go to the page after the section break, there is a top margin for the first paragraph there in Word, but not in Writer. This went wrong in commit abd90828cf101581a07b9d1c371a8c3156521e9f (tdf#160952 sw: ignore top margin of para on non-first pages with newer DOCX, 2024-05-14), where it seemed that all implicit and explicit page breaks want to ignore that top margin for the first paragraph. Turns out this is more complex: implicit breaks and page breaks should be followed by an ignore, but not paragraphs after "section break (next page)". So restore the margins for the RES_PAGEDESC, but continue to have them for RES_BREAK & implicit breaks. Change-Id: If1fcf3077b81a705d3587bdae422dcfa16f1c17c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177973 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-11-25tdf#108820 tdf#158713 sw layout: no footnote in repeated table rowsJustin Luth
This fixes my LO 7.1 regression from bug 108820. The problem was that footnotes-placed-in-table-headline were being visually removed if a split-table was ever joined during editing, etc. (i.e. one less page needed). Avoid the join() cleanup code being triggered on GetFollow frames because those were wrongly being informed that there was a footnote, despite being deliberately disallowed in IsFootnoteAllowed, so it really must not HasFootnote()! make CppunitTest_sw_core_layout \ CPPUNIT_TEST_NAME=testTdf158713_footnoteInHeadline Change-Id: I8f395217ba66a258738fc3f32846b952c69d367b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177059 Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Jenkins
2024-10-25sw/qa: simplify a bitXisco Fauli
Change-Id: I5d75561f06ce4f981927afb333af5a99bd7ffe26 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175645 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2024-10-25sw/qa: use getSwDocShell() when possibleXisco Fauli
Change-Id: Ia2e3dad4e62fb084c3a88564deb137cbcc7728b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175573 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-10-24sw/qa: use getSwDoc() moreXisco Fauli
Change-Id: I742309d99c4d9839dcd4f8b747fc9aef549998ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175555 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-10-16tdf#138711 sw textbox: capture fly when its draw object is capturedMiklos Vajna
Load the bugdoc, notice that the only shape in the document has a captured (inside the page frame) draw shape, but its inner fly frame is not captured inside the page frame, so a small top margin is paired with a larger right margin, which is unexpected. This is nominally a regression from commit 9835a5823e0f559aabbc0e15ea126c82229c4bc7 (sw textboxes: reimplement ODF import/export, 2014-10-04), because previously the ODF markup for Writer TextBoxes were ignored, so we had correct position of the shape text at the price of losing complex content. Fix the problem similar to what commit a0b6587c4acb1d74e1b00904147821640c98b323 (tdf#161199 sw DoNotCaptureDrawObjsOnPage: capture wrap=none draw objects, 2024-06-13) did: if we detect that the fly frame is part of a TextBox, then work with the wrap type of the draw format, since these inner fly frames always have their wrap type set to "through". This fixes the unexpected position of the fly frame and keeps the import of complex content working. Change-Id: Ib0d861af0fac74d93a09178c10bc19a1b45e3ce7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174987 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
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-10-02tdf#156218 sw hide whitespace: fix increased page size on new para at doc endMiklos Vajna
Create a document of 1 page, add empty paragraphs, so the next empty paragraph would create a second page. Hide whitespace, then add that paragraph: no second page is created. Seems this is a regression from commit 2c23d4ee1e1370b20560e47db7efaeaac1d94b26 (tdf#96515 sw Hide Whitespace: avoid creating unneeded page frames, 2015-12-16), because previously we had the opposite problem: creating new page frames all the time, even if the current page frame could grow. Fix the problem by: 1) In SwPageFrame::MakeAll(), fix the size of the page frame when switching to hide whitespace mode, so margins are not part of the height. At least the last paragraph of the doc is now near the bottom of the page, so it's more likely to create a new page. This means now we're back to still tweaking the size of the last page: but we used to determine the height based on just content and here we just ignore top/bottom margin. 2) In SwPageFrame::CheckPageHeightValidForHideWhitespace(), handle the top/bottom margins, otherwise we'll think that the page frame can still grow, when it should not. 3) Finally in SwPageFrame::MakeAll(), when we determine the height for non-last pages, the text frame for the new paragraph is already inserted, so limit the page frame height: if "content height" is more than "height - whitespace", then that limit should be the height, otherwise the page frame height will grow forever. Change-Id: I1125c31ec8b387df41c0881af98469d56ed773db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174368 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-08-30tdf#155229 Calculate row height incl. border if 'atLeast' is setOliver Specht
Word includes the width of horizontal borders when calculating row height in case the row height is set as "atLeast" This is now handled via a compat flag for doc/rtf/docx formats. The default for ODF is unspecified, which (sanely) continues to treat the row size of "atLeast" and "fixed" as measuring the same thing. Change-Id: I37778e5cdc6e083e94a17f50bd0b75a291ededcd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169611 Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de> Tested-by: Jenkins Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
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-29sw: get rid of discardDumpedLayoutXisco Fauli
Change parseLayoutDump to make it the only place where the layout is dumped and once it's not needed anymore, discard it Change-Id: Ia89ff569752e1e592209fa4ccb0b4753eee17e2b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171075 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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-19tdf#161635 sw DoNotCaptureDrawObjsOnPage: fix handling of left paddingMiklos Vajna
Open the bugdoc, the shape has an 5cm left padding for its text, but only 4cm of that is visible in Writer. Checking the shape, part of that is outside the page frame, so the first 1cm of the left padding is not visible, visually resulting in a 4cm left padding in Writer, but not in Word. Fix the problem by extending SwFlyFrame::MakePrtArea(), so in case the shape is partially outside the page frame, then we make sure to increase the left padding enough that the nominal (5cm) left padding is inside the page frame. With this, the text on the title page of the document is visually centered also in Writer, even if not using an explicit paragraph alignment. Change-Id: I5dcbcf407ed7f12f0bc13820fa39621a76e23fe7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169186 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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-05-31tdf#160984 sw continuous endnotes: fix the endnote continuation separator lenMiklos Vajna
See e.g. <https://bug-attachments.documentfoundation.org/attachment.cgi?id=194455>, one remaining difference for the Word vs Writer note separator is the length of the endnote continuation separator: it's body frame width in Word, shorter in Writer. Seems this is specific to the endnote continuation separator, i.e. normal endnote separator, footnote separator and footnote continuation separator is not affected. Additionally, it's really footnote vs endnote: if you put footnotes to the end of the document in Word, it still doesn't make the separator longer. Fix the problem by extending SwFootnoteContFrame::PaintLine() to handle this: if in Word compat mode, first note frame is a follow endnote frame, then paint the longer separator. The usual render test way via SfxObjectShell::GetPreviewMetaFile() only works with 1st pages and we want to assert the 2nd page here, so go via DocumentToGraphicRenderer, similar to how EPUBExportFilter::CreateMetafiles() does it. Change-Id: Ia0ba1138070f1a68f62ea6f5a6a85fbe0f76d482 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168263 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-05-27tdf#160984 sw continuous endnotes: fix crash on loading forum-mso-en-7731.docxMiklos Vajna
Regression from commit 1ae5ea3f78cca11ba18f2dd1a06f875263336a3b (tdf#160984 sw continuous endnotes: enable DOCX import, 2024-05-21), the bugdoc crashed in SwSectionFrame::GetEndSectFormat_(). What seems to happen is that the first endnote is added to page 1, then more content is inserted, so the endnote is moved to page 2, which leaves an empty endnote section on page 1, which is marked for deletion in SwSectionFrame::MakeAll(), and will be deleted in SwRootFrame::DeleteEmptySct_(). At some point (after marking for deletion, before deletion) SwFootnoteBossFrame::AppendFootnote() tries to find the first endnote section in the layout, and finds this section, but it crashes because there is no SwSection attached to it, as marking for deletion in SwSectionFrame::DelEmpty() clears that. Fix the problem by ignoring to-be-deleted sections in SwFootnoteBossFrame::AppendFootnote(): this way a new, usable section will be created and the to-be-deleted section go away as the layout finishes. An alternative would be to check for SwSectionFrame::GetSection() earlier, as we iterate on pages (hoping that this way we find a later page that has a not-dead endnote section), but that leads to 6 pages instead of 4 pages for the bugdoc, so don't go that way. Change-Id: I9a21cbccb5a088314520c7ade55dbdf9966d1265 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168084 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-05-24tdf#160984 sw continuous endnotes: fix the endnote separator lengthMiklos Vajna
See <https://bug-attachments.documentfoundation.org/attachment.cgi?id=194324>, Word has a longer separator line for the foot/endnote than Writer for this bugdoc. Writer defaults to 25% of the body frame width in the SwPageFootnoteInfo ctor, and we don't seem to change that in the DOCX import. Word has a static 2 inches setting, which is only reduced if it would go outside the body frame. Fix the problem by extending SwFootnoteContFrame::PaintLine() in the DocumentSettingId::CONTINUOUS_ENDNOTES case to do the same. I searched the OOXML spec and the MS implementer notes, they don't specify this 2 inches length, but it seems static: the value doesn't change with the page size. With this, the single-section bugdoc is now rendered fine. Change-Id: I3bb23680937580179b8d37c940ea14e0f80fc7f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168009 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-05-23tdf#160984 sw continuous endnotes: fix the endnote separator positionMiklos Vajna
See <https://bugs.documentfoundation.org/attachment.cgi?id=194306>, the total height of the endnote separator is now correct, but the distribution of upper space, line width, lower space is still bad, when compared to Word. Our model is 2 spacings and a line width, while Word seems to simply split the amount of available space: 60% goes above the separator and the rest goes below. Fix the problem by breaking up the monster expression for the separator rectangle in SwFootnoteContFrame::PaintLine(), and then the compat + horizontal case can do the 60% spacing in the Word compat mode. The width of the separator is still not correct. Change-Id: Ic065c138041892225b3c1b7d4bd64d4f1c625611 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167990 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-05-22tdf#160984 sw continuous endnotes: fix the endnote container's top marginMiklos Vajna
Comparing the Word vs Writer output for the bugdoc, the vertical position of the endnote text is not correct: the y pos should be larger than it is, see the red reference at e.g. <https://bug-attachments.documentfoundation.org/attachment.cgi?id=194265>. Seems this is caused by the different height of the rectangle around the endnote separator: the top margin is 124 twips in Writer, which is a hardcoded default from the SwPageFootnoteInfo ctor, while Word has this separator as a special character, inside a paragraph, which inherits the height of the default paragraph style. Fix the problem by extending sw::FootnoteSeparatorHeight() to also work from RES_POOLCOLL_STANDARD in the Word compat case. Note that it's not enough to take the font size (11pt in this case) from the paragraph style, we want to work with the real font, which knows the spacing between lines (15% in this case). SwFont::GetHeight() has this logic, it's also what e.g. SwTextFrame::FormatEmpty() uses. Note that footnotes have the same problem, but given that they grow from the bottom of the page, the text position was correct, even if the separator height is incorrect. Also, the separator line itself is not changed in this commit, we just make sure that the height is OK, so text below the line has the correct position. Change-Id: If1f4757908355abc81ee711de5ab9db4c751354c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167959 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-05-22Related: tdf#145972 sw images: fix rounding error in relative size calculationMiklos Vajna
Open the bugdoc, see that the image is roughly half of the page width, right click, properties, UI shows that the width of the image is 5% of the width of the entire page. This only happens if tools -> options -> writer -> general sets the UI units to points, the default cm case is fine. This went wrong with commit 9e8712ed6f9fb5dbd971e352a5709bd45fadc74f (sw image dialog: fix fallback width/height for images with relative sizes, 2022-03-17), because the layout size started to matter more after that commit. This lead to the nWidth != m_xWidthED->get_value(FieldUnit::TWIP) check in SwFramePage::Init() to be true, because 11906 * 0.48 is 5714.88, so you got 5714 in the layout, but got 5715 with rounding in SwFramePage::Reset() (which tries to calc the page width based on the 48% and the fly width). And once we had that mismatch, we went down the wrong path. Fix the problem by using rtl::math::round() in SwFlyFrame::CalcRel(), so the relative width twips value is 5715 everywhere: once we have consisteny, the UI value is correct, too. Note that the original bugdoc needs more fixing, this just fixes the bugdoc where KeepRatio is false. Change-Id: I1e8782c95a0cf9d97375c36d41134735c01f3e46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167916 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-05-17tdf#160952 sw: ignore top margin only at page top, not in flyMiklos Vajna
See <https://gerrit.libreoffice.org/c/core/+/167671/2#message-8603b129dd8bd72608259571056ded950182ca96>, multi-column shape text can't appear in DOCX files, so collapsing upper spacing in that case is not correct, avoid it. Change-Id: Icf69c8d84fdd15d6e3289ff614b2f6ba7cee1e0e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167758 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-05-15tdf#161083 sw continuous endnotes: fix layout with a section at doc endMiklos Vajna
Open the bugdoc, notice warnings like: warn:legacy.osl:15059:15059:sw/source/core/layout/wsfrm.cxx:910: Frame tree is inconsistent. Which means we try to insert the new section frame under body frame, but the insert point is behind a frame which is not a direct child of the body frame. This went wrong in commit 6885dcd7ec7b82a946d8344bfc27a3e88eecc44a (tdf#160984 sw continuous endnotes: switch to a section-based layout, 2024-05-14), where I didn't consider the case of having a continuous section break at the Word doc end, which maps to a section frame before the section frame of the endnotes in Writer. Fix the problem by walking up the parent chain till we find the last direct child of the body frame, which is typically not required, except when having one or more (nested) section frames at the end of the document. Interestingly tdf#143456 had the same problem, which was the bugdoc to trigger the revert of the old continuous endnotes code for DOCX in eeda1b35a6e87d5349545464da33d997c52f15e3 (Revert "tdf#58521 DOCX import: enable ContinuousEndnotes compat flag", 2021-08-10). Change-Id: I664672b91087217008a42120e8201c39e2a0a423 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167691 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-05-15tdf#160952 sw: ignore top margin only at page top, not e.g. table topMiklos Vajna
The bugdoc has a table at the top of the 2nd page and we ignored the top margin inside the table cell (for the first paragraph), while this doesn't happen in Word. As mentioned at <https://gerrit.libreoffice.org/c/core/+/167221/3#message-c03abf8e8e3cd20d49006058e6b3eb130585ff8f>, the old code assumed "top of the page" for all frames not having a previous frame, while that code was only tested with text frames directly in the body frame of a page frame. Fix the problem by limiting this "collapse upper spacing" behavior to frames directly in body frames. This keeps the old bugdoc working, but is meant to restore the old, wanted behavior in other cases like e.g. in table cells. If later it's discovered that upper spacing collapsing is wanted in other contexts, those are best added on a case by case basis. Change-Id: Ieb93facd8b2e7f6412fd20873c10ce6c8b775619 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167631 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-05-14tdf#160984 sw continuous endnotes: switch to a section-based layoutMiklos Vajna
The original layout added in commit 4814e8caa5f06c4fe438dfd7d7315e4a2410ea18 (tdf#124601 sw: add ContinuousEndnotes layout compat option, 2019-09-30) puts endnotes to the footnote container on the last page, which fixes the page count but the endnote position is wrong: should be after the body text, not at the bottom of the page. Now that we can have an endnote section (with one or more section frames at a layout level), we have a container that can span over multiple pages, is at the end of the document and is inline. Fix the bad position by: 1) Reverting the layout changes from the old approach, which gives us a bad position for the endnote. 2) Creating an endnote section frame on demand in SwFootnoteBossFrame::AppendFootnote(). 3) Moving part of the endnote to a next page works out of the box, but moving part of the endnote to a previous page needs explicit handling in SwFlowFrame::MoveBwd(), similar to how SwFrame::GetPrevSctLeaf() does this in the simple section case. This needs explicit handling, because the body frame of the endnote section is empty, all content goes to its endnote container. Note that this just reimplements the compat flag, but its enablement (only for DOC import, only for <= 2 endnotes) stays unchanged for now. Change-Id: I8b271895aeff378418aed8705fe6b99a69232bd2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167616 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-05-13Revert "reduce symbol visibility in sw"Thorsten Behrens
This reverts commit 1a6711276f0c8abeb0028a47cc345a7453374a38. After some discussion and experiments, it turned out this rather fundamentally breaks clang's PCH build. Conclusion was: this change is not significant enough to warrant making life harder for developers. Excerpt of errors (affected were vbaswobj, msword & swui libs): - ld.lld: error: undefined symbol: SwFormat::~SwFormat() >>> referenced by fmtcol.hxx:37 (sw/inc/fmtcol.hxx:37) >>> core/workdir/CxxObject/sw/inc/pch/precompiled_vbaswobj.o:(SwFormatColl::~SwFormatColl()) - ld.lld: error: undefined symbol: SwFrameFormat::SetPositionLayoutDir(short) >>> referenced by precompiled_msword.cxx >>> core/workdir/CxxObject/sw/inc/pch/precompiled_msword.o:(vtable for sw::SpzFrameFormat) - ld.lld: error: undefined symbol: SwFrameFormat::SetLayoutDir(SwFrameFormat::tLayoutDir) >>> referenced by precompiled_swui.cxx >>> core/workdir/CxxObject/sw/inc/pch/precompiled_swui.o:(vtable for sw::SpzFrameFormat) Change-Id: I1dcf115cc191b1ebf1f8d5023c0c5015f891287a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167549 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-05-10tdf#160984 sw continuous endnotes: fix testContinuousEndnotesMoveBackwardsMiklos Vajna
Once continuous endnotes are in a section, this failed, even if the generated layout is an improvement. The layout will put the endnotes to a section, which will be directly after the end of the body text, which is closer to what Word does, but makes the test fail, since the foot/endnote container is no longer directly under the page frame (the new tree is page -> body -> section -> column -> ftncont). Fix the problem by relaxing the assert to only check which pages have footnote containers, which passes with and without the move to section-based continuous endnotes, but still fails if endnotes go to their own page, which was the original problem to be tested (endnotes remained on page 3 and didn't move backwards). The assert for the number of pages can remain unchanged. Change-Id: I9a46803463c82dac317c303721de30fae48c6924 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167425 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-05-07tdf#160952 sw: ignore top margin of para on non-first pages with newer DOCXMiklos Vajna
The 2nd page of the bugdoc has a single paragraph, with a non-zero top margin. This is ignored in Word, but wasn't ignored in Writer. Experimenting with the document, it looks like old Word files also don't ignore this top margin: it started when the compat mode is upgraded (from binary DOC or Word 2010) to Word 2023 or newer. Also the top margin is only ignored for the first paragraph on the page, and only in case it's not on the first page. Fix the problem by introducing a new SwFrame::IsCollapseUpper() function to decide if the upper margin should be collapsed or not, and then by using it in SwFlowFrame::CalcUpperSpace() at one place where we read the top margin from the doc model. Take advantage of the fact that we have related, existing compat flags that tell us if we're in "Word >= 2013" compat mode: see e.g. GetFlyAnchorBottom(), which explains DocumentSettingId::TAB_OVER_MARGIN is a good indicator that this is a "Word <= 2010" document. Also, DocumentSettingId::TAB_OVER_SPACING is an indicator that this is a Word document, so we want the "TabOverSpacing && !TabOverMargin" case. This doesn't change all reads of the upper spacing of a text node, but is enough to avoid the unwanted top spacing, as demonstrated by the bugdoc. Change-Id: Ibdebdf5f0555256a0b6ed85d07079f14ef69a576 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167252 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-04-08tdf#160067 sw floattable: fix missing move bwd of paras in split section frameMiklos Vajna
The last (5th) paragraph in the index was on page 2, even if page 1 still had space for it. This is a regression from commit 397d72e582c725d162c7e0b819dc6c0bb62e42b0 (Related: tdf#158986 sw floattable: fix unexpected page break with sections, 2024-02-23), in case SwLayAction::FormatLayout() doesn't calc its lower content frames then this bugdoc is good, but the old bugdoc moves its floating table to the next page, which would be bad. Fix the problem by making the condition for this "calc lower in FormatLayout()" action more strict: only do this for content frames which are in sections, followed by sections. Note that probably a cleaner way would be to completely stop calculating content frames in SwLayAction::FormatLayout() and only do that in FormatContent(), but then it's not clear how to re-fix tdf#158986, and at least this resolves the regression. Change-Id: Id671b3b68d8af8ad1cca3399a9aa028de58df3a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165878 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-03-13reduce symbol visibility in swNoel Grandin
Change-Id: Ib3edefc365d3c605c3024e160572fa4030100ef1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164724 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-23Related: tdf#158986 sw floattable: fix unexpected page break with sectionsMiklos Vajna
Regression from commit c303981cfd95ce1c3881366023d5495ae2edce97 (tdf#156724 sw: layout: fix tables not splitting due to footnotes differently, 2023-08-24), the floating table in the DOCX version of the bugdoc went from page 1 to page 2. It seems what happens is that the first page has 2 section frames, and we used to directly recalc the last lower of the first section frame, which triggered a recalc of the second section frame, so the table moved from page 2 to page 1 once the top of the second section frame was reduced (so the table could fit on page 1). But this direct recalc was removed because it caused problems for split tables and footnotes in tdf#156724. Fix the problem by conditionally restoring the OptCalc() call in SwLayAction::FormatLayout(): only do it for the last lower of section frames, which is enough for the DOCX version of tdf#158986, but it keeps the old tdf#156724 use-case working (the layout of that bugdoc doesn't modify with this change). The RTF version of the bugdoc (which was the originally reported problem) still needs more work, but that's hopefully not a layout problem but an RTF import one. Change-Id: I1134ec3a27aec8ee871b535d81dedf9d27bd6bd5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163805 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-14CppunitTest_sw_core_layout: remove duplicated assertMiklos Vajna
See <https://gerrit.libreoffice.org/c/core/+/160756/2#message-9a43d741ca1307aa796eda092bd3857614c63a6f>. Change-Id: I6db7128240b344a8169214a70fdcaff3cab57286 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160759 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-12-13sw floattable: fix split of anchor text at para startMiklos Vajna
The document has a floating table with some anchor text. If we hit enter at the end of the anchor text, the anchor text remains in the old text node and a new text node is inserted after it, still wrapping around the floating table. If you do the same at the start of the anchor text, then a new paragraph is inserted before the floating table, which is unexpected. The OOXML concept we try to model here is that a floating table is a table-in-fly that's followed by a paragraph that hosts the anchor text, so the anchor position of the floating table should never change. This behavior was even locked down in the testSplitFlyMoveMaster testcase, but there the motivation was to make sure the fly chain is consistent. Fix the problem by removing the special-casing in SwTextNode::SplitContentNode() for the "at para start" case that was added just to please the testcase. Instead update the test assert the bad 1 -> 4 -> 2 chain is not there, so it still covers the old fix but allows the new behavior. With this, the Word and Writer UI behaves the same when inserting a new para right after a floating table. The layout position problem of the empty text node (should be wrapped, is not) still needs fixing. Change-Id: Ib9a1f07eeb144ea929183cdc72a22bc23042fee1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160669 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-12-01sw floattable: fix finding the nearest text in split flys on mouse clickMiklos Vajna
Clicking on the right of the floating table on the page 1 resulted in a cursor position on page 2 instead of a position inside the floating table on page 1. What happens is that the anchor text frame on page 1 is wide enough to contain the mouse click position, but then "before the first character of the paragraph" is on page 2, so a page 1 click results in a page 2 cursor position, which is unexpected. Fix the problem by first ignoring which dummy anchor frames (all non-last ones) in SwLayoutFrame, so SwLayoutFrame::GetModelPositionForViewPoint() in SwPageFrame::GetModelPositionForViewPoint() fails for the perfect match case, and then later looking for split flys explicitly, so the corrected case finds the split fly on the page. I imagine this is not only useful for mouse clicks, but it's also good for everything else that uses GetModelPositionForViewPoint(), e.g. keyboard page-down. Change-Id: I761b211c1b5468d9d8996c59a32ac9be5b83a777 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160194 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-11-29Fix typoAndrea Gelmini
Change-Id: I1ca85b9f1424df5432c76d08280b9dba3e01d2dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160090 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-29tdf#158341 sw floattable: fix layout loop when fly is below the body frameMiklos Vajna
Regression from commit 25b8fdd3b939a221ba00ca37fbf89adaf893aab7 (sw floattable: maintain the invariant that fly height is at least MINFLY, 2023-09-28), the document started to layout-loop on load. What happens is we have a fly frame where the bottom of the body frame is above both the top and bottom of the fly. We used to make sure these flys don't "flip" (with a negative height) and ensure that their height is still MINFLY. But that causes a new problem, because the layout will try to make sure they fit, but they can't have enough space. Fix the problem by improving the correction of the fly height, so in case even the top is below the deadline, then we set the height to 0 and explicitly mark the frame as clipped. That keeps the unwanted warnings about violated invariants fixed and fixes the layout loop. The test just ensures that all pages but the last one has a single multi-page floating table, chained over several pages. Change-Id: Ibac0a465839a59abe5ae49809c0d76c955aa39b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160061 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-11-27sw floattable, per-frame wrap-on-all-pages mode: add layoutMiklos Vajna
The anchor text of a floating table is normally wrapped around the table only on the last page of the table. This property requests to wrap on all pages instead for this frame. Commit 7d7ca347fafa7a06094b00e8fb0d0452c4c81366 (sw floattable, wrap on all pages: add layout, 2023-10-13) already arranged the layout code to go via the per-frame SwFlyAtContentFrame::IsWrapOnAllPages(), so only that needs updating. Instead of always deciding this at a per-doc level, first check if the frame itself requests the on-all-pages behavior. Otherwise keep deciding this on a per-doc level. This is meant to please what the OASIS/ODT proposal wants and also keeps the Word-style per-doc setting. The ODT filter still needs doing. Change-Id: Ibf10b5f016d70e6fe948d5273cc1fb1d98495586 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159981 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-11-15tdf#157911 sw floattable: fix inconsistent inferred bottom border on splitMiklos Vajna
The bugdoc has a split table between page 1 and page 2. The last row of page 1 has a half bottom border: it starts on the left of the table, but finishes earlier than the right of the table. This is since commit 08aea5526c75ff4c5385e960bd940f10ffa19cd5 (tdf#156351 sw floattable: fix missing bottom border in master table, 2023-08-21). The trouble is that Writer table borders are really at a cell-level (and not at row or table level), the current partial border happens because the first row has merged cells and the last row on page 1 doesn't have merged cells, so the layout can't do a 1:1 mapping between the first row and last row cells. It's also far from clear if the fixed result should be no bottom border or a table-width bottom border: - Word documents can have cell-level borders (where no inferred border is wanted) and table-level borders (where inferred borders are wanted), see the tdf#156351 bugdoc for a case where such inferring is wanted - In case only cell-level borders are defined, then Word doesn't do such inferring Fix the problem by always inferring such borders, because: - Writer already did this in some cases for a long time, see commit a4da71fb824f2d4ecc7c01f4deb2865ba52f5f4c (INTEGRATION: CWS fmebugs04 (1.115.46); FILE MERGED 2008/05/13 13:56:19 fme 1.115.46.2: #i9860# Top border for tables - correction 2008/05/13 13:49:23 fme 1.115.46.1: #i9860# Top border for tables, 2008-06-06) - The Word UI creates table borders by default, so the majority of the DOCX documents also want this inferring An alternative could be to only do such inferring for Word documents with a compat flag, but that looks poor, given that Word doesn't always do such inferring itself, either. Change-Id: I052e4591e99d066c3109e8ab8b590e97c8aebd36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159429 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-10-27tdf#157096: sw_layout: Add test for CRASH removing everything in documentOmkarAcharekar
Change-Id: I07fde27e71f112019532c57d90f46568af45fad9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158458 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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-10-17n#775899 sw: add testcase for the FloattableNomargins compat flagMiklos Vajna
This was added in commit 50a1df360c907d8419ce49f098b6bc87a37a9956 (n#775899 sw: add FloattableNomargins compat flag, 2012-08-23), without a testcase, so it was hard to make later changes without breaking the old behavior. Later commit 0898871b7b9492ada947ebc7b8429c5cb56db23c (n#775899 testcase, 2012-08-27) did add a testcase for the bug, it was a different sub-task there, so the test document had no margins, while this compat flag is about some special handling around non-zero paragraph margins and floating tables. So add a new test that fails without the DocumentSettingId::FLOATTABLE_NOMARGINS block in SwBorderAttrs::CalcLeft() to make sure that this keeps working after I fix tdf#157573, which is a related problem. Change-Id: I09661be726e3db6be51d0cbb44cb5c504510e5ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158069 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-10-13sw floattable, wrap on all pages: add layoutMiklos Vajna
The anchor text of a floating table is normally wrapped around the table only on the last page of the table. This compat flag requests to wrap on all pages instead. First, disable the SwTextFrame::FormatEmpty() optimization in this case, so not only the last page has portions inside the text frame. Second, improve SwTextFrame::FormatAdjust(), so that anchor content from the last page can flow to previous pages. Note that having a dedicated SwFlyAtContentFrame::IsWrapOnAllPages() means that later it'll be possible to do per-frame decision on this if there is demand for that (this came up on the mailing list, but it's not something Word would support). Change-Id: I75df539df859aaa6c7eaaeddb33f004639b1c004 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157902 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-10-11sw floattable, crashtesting: fix PDF export of ooo91654-1.docMiklos Vajna
Regression from 89a75cd194371002247d0138e759835bc673f7b0 (tdf#126449 sw floattable: DOC import: handle inner floating table, 2023-10-04), the document crashed Writer layout when exporting to PDF, which triggers a layout calculation. The trouble seems to be that in case the split fly is anchored in a table which is in a section, then we assume that we can create a section on the next page and move the follow fly frame there, which will mean the follow anchor won't be in a table anymore. Fix this by not moving the follow anchor explicitly, similar to what the nested floating table (inline or floating outer table) code does. The layout will later figure out that the available space is not enough, split the outer table for us, which will lead to a correct result. Note that the original bugdoc is DOC, but just saving it as-is in Word hides the problem, so it's not easy to minimize the reproducer. Instead create a similar DOCX reproducer from scratch. Change-Id: I769615af467ccaa88057ab322da2865f11d3d2ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157803 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-10-09crashtesting: fix PDF export of fdo45193-1.docxMiklos Vajna
This started with commit 1d3d2a995239c3c71432006cb795324c56a0412a (tdf#148687 tdf#149173 tdf#149546 sw: fix crash with textboxes, 2022-06-20), the trouble is that once anchored objects are inserted to the anchored object list of a layout frame, the list has to be re-sorted if something that influences the sort key changes. Normally the way to do this is similar to commit 0a6a151c4b7c78a363fb64598fbda39db4f42d07 (Related: tdf#70062 keep drawing anchor objects sorted, 2015-02-11), but here the problematic call is SetFormatAttr(SwFormatAnchor(...)) in SwTextBoxHelper::changeAnchor(), and we don't have a layout by the time that happens, so using UpdateObjInSortedList() is not something we can do. In any case looks like no proper fix is coming for this soon, so at least fix it up so we don't try to do binary search on a vector that's not yet sorted. This also seems to help 3 other documents from crashtesting, and also the tdf#157571 bugdoc (related to sw floattable), which is why I started looking at this in the first place. Change-Id: I9b532a39f6c28604304fa9bbecf9faf9842739a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157691 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
generated by cgit (git 2.34.1) at 2025-02-20 06:12:05 +0000