aboutsummaryrefslogtreecommitdiff
path: root/source/ur
ModeNameSize
d---------accessibility39logplain
d---------avmedia39logplain
d---------basctl39logplain
d---------basic39logplain
d---------chart239logplain
d---------connectivity74logplain
d---------cui39logplain
d---------dbaccess39logplain
d---------desktop39logplain
d---------dictionaries2067logplain
d---------editeng39logplain
d---------extensions72logplain
d---------extras / source33logplain
d---------filter72logplain
d---------forms39logplain
d---------formula39logplain
d---------fpicker39logplain
d---------framework39logplain
d---------instsetoo_native / inc_openoffice / windows41logplain
d---------librelogo / source33logplain
d---------nlpsolver61logplain
d---------officecfg / registry / data / org35logplain
d---------readlicense_oo35logplain
d---------reportbuilder / java / org / libreoffice / report / function31logplain
d---------reportdesign39logplain
d---------sc39logplain
d---------scaddins39logplain
d---------sccomp39logplain
d---------scp2 / source33logplain
d---------sd39logplain
d---------setup_native / source33logplain
d---------sfx239logplain
d---------shell / source / win32 / shlxthandler33logplain
d---------starmath39logplain
d---------svl39logplain
d---------svtools39logplain
d---------svx39logplain
d---------sw39logplain
d---------swext / mediawiki36logplain
d---------sysui / desktop34logplain
d---------uui39logplain
d---------vcl39logplain
d---------wizards72logplain
d---------writerperfect39logplain
d---------xmlsecurity39logplain
value='private/moggi/opengl-4-4-build-test'>private/moggi/opengl-4-4-build-test LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/sw/qa/core/layout/ftnfrm.cxx
AgeCommit message (Collapse)Author
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-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-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-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-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-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>
2023-08-23tdf#77760 sw floattable: add support for footnotes, layoutMiklos Vajna
Once the footnote was inserted to the document model, the layout was also missing (footnote portion, footnote frame). One problem is that the footnote portion was empty instead of the footnote counter, because SwTextFormatter::NewFootnotePortion() returned early in the fly case. The other problem was the missing footnote frame, but once the footnote portion was created correctly, the matching footnote frame was also created. File filters (ODT, DOCX) still needs more work. Change-Id: If71c44962f604f23fdcfccfe80b0d97787fd99d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155961 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins