summaryrefslogtreecommitdiff
path: root/sw
AgeCommit message (Collapse)Author
2024-06-18tdf#160198 Compatibility in background shapes/picturesOliver Specht
Paint Word background shapes/pictures (wrapped through) above header and footer if the anchor is in the document body. Change-Id: Ic32ba8d64f82c64e502788007e49a9dce4c4c76f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164802 Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de> Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169085 Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-06-18tdf#161054: drop support of last empty span as paragraph mark formatMike Kaganski
Commits 6249858a8972aef077e0249bd93cfe8f01bce4d6 (sw: ODT import/export of DOCX's paragraph marker formatting, 2022-12-19) and 209dce614c43f63f63f5b42a746665c0ec1cbfe3 (sw: fix ODT import of paragraph marker formatting, 2022-12-20) introduced support for paragraph marker formatting in ODF, using an empty trailing span. Later, commit 1a88efa8e02a6d765dab13c7110443bb9e6acecf (tdf#155238: Reimplement how ListAutoFormat is stored to ODF, 2023-05-11) changed how the data was stored in ODF. Then, in commit 69ed893087f89d176a5ec4b263ce8d75774be72b (tdf#160253: fix list identifier export decision code, 2024-04-24), some remnants of the older "trailing empty spans" were removed, but a code was added in XMLParaContext::endFastElement, to keep backward compatible with documents created in the frame between December 2022 and May 2023. The said compatibility code brings own problems, requiring new hacks like commit 2ca93eb5df7ddb8641ff7d884a109261c9700aca (tdf#161023: Empty spans may only define paragraph marks in text documents, 2024-05-13), and keeping the code would need more hacks on top, e.g. to fix the case in ODT documents. Instead, let's bite the bullet, and drop the compatibility with this initial implementation, because it was only a brief period during which the documents could be created, which can be affected by this drop. This makes the code simpler. A testdoc for testNumberPortionFormat was edited to use the new markup for the paragraph marks formatting. Change-Id: I053e72dd1cc2ead83baa6ce7d24c8522b494c8fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167583 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-06-18Make sure to export autostyles from inside frames anchored to pageMike Kaganski
These frames need to export content when collecting autostyles, too. Regression after commit 69ed893087f89d176a5ec4b263ce8d75774be72b (tdf#160253: fix list identifier export decision code, 2024-04-24). Change-Id: If036cab9327e33d32f494fc765bae8e2d685907c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166650 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-06-18tdf#160253: fix list identifier export decision codeMike Kaganski
Commits 8f48f91009caa86d896f247059874242ed18bf39 (ODT export: omit unreferenced <text:list xml:id="...">, 2022-03-10) and 82bbf63582bdf28e7918e58ebf6657a9144bc9f3 (tdf#155823: Improve the check if the list id is not required, 2023-06-14) tried to improve deterministic ODF output, by omitting the list identifiers in case when those identifiers were unreferenced. The latter of these used document model node numbers to check if other lists appeared after the last occurrence of the list that is continuing in the current node. But it turned out, that this isn't robust. Consider this ODF: <text:list xml:id="list1" text:style-name="L1"> <text:list-item> <text:p>a</text:p> </text:list-item> </text:list> <text:p>b<text:note text:id="ftn1" text:note-class="endnote"><text:note-citation>i</text:note-citation><text:note-body> <text:list text:style-name="L2"> <text:list-item> <text:p>x</text:p> </text:list-item> </text:list></text:note-body></text:note></text:p> <text:list text:continue-list="list1" text:style-name="L1"> <text:list-item> <text:p>c</text:p> </text:list-item> </text:list> The paragraphs a, b, and c are all in the main document body, and have sequential document model node numbers (say, 15, 16, 17). If these numbers are checked, there is no node between node 15 ("a") and node 17 ("c") with a different list (both 15 and 17 belong to a list with style "L1" and identifier "list1", and node 16 doesn't belong to any lists). That suggests that the list identifier isn't needed in this case. Bug when the actual output of node 16 is done, it includes a node from an endnote ("x"), which is located in a different place in the document model, and has a node number like 7 (so not between 15 and 17). The paragraph "x" belongs to another list with style "L2", and is output to ODF between paragraphs "a" and "c". Here, we must refer from paragraph "c" to the list of the paragraph "a" using the list id, but this is not obvious when only considering node numbers, and requires the prior knowledge of the actual order of appearance of lists in the ODF. Unless we build a DOM, this is only possible, if we do a two-pass output, and collect the nodes order in the first pass. The output already does that in a "collect autostyles" pass. The problem here is that the "collect autostyles" pass used an optimized function, XMLTextParagraphExport::collectTextAutoStylesOptimized, introduced in commit 8195d7061ed52ebb98f46d35fe5929762c71e4b3 (INTEGRATION: CWS swautomatic01 (1.126.4); FILE MERGED, 2006-12-01) for #i65476# and which used style::XAutoStylesSupplier for optimization to get the autostyles. This drops XMLTextParagraphExport::collectTextAutoStylesOptimized, and reverts to use of collectTextAutoStyles, which handles nodes in the same order as when writing to ODF. There, we build a vector of the node numbers sequence, used later to sort DocumentListNodes. This uncovered an omission from the work on paragraph mark (commit 1a88efa8e02a6d765dab13c7110443bb9e6acecf tdf#155238: Reimplement how ListAutoFormat is stored to ODF, 2023-05-11). Turns out, that the code in SwTextFormatter::NewNumberPortion introduced in commit cb0e1b52d68aa6d5b505f91cb4ce577f7f3b2a8f (sw, numbering portion format: consider full-para char formats as well, 2022-10-20) was left behind when re-implementing paragraph marks to use dedicated property; empty trailing spans still affected how the lists were rendered, and that allowed to overlook import defects, where the paragraph mark properties weren't properly set. In ODF import (XMLParaContext::endFastElement), for compatibility, this treats empty trailing spans as defining paragraph mark (when the paragraph mark wasn't set explicitly). This way, the trailing spans get converted to the paragraph mark. In WW8 import, last cell paragraphs didn't call the code handling the paragraph marks. This is also fixed now. The changes result in slightly different numbering of autostyles in the ODF. It seems, that the new numbering more closely follows the order of appearance of the autostyles in the output; and some cases of autostyles that were written, but unreferenced, are now eliminated. The unit tests were updated accordingly. I hope that the performance impact on the export time would not be too large. It is unclear why outline numbering exports a list element at all. Fixing that to not emit the list element is a separate task / TODO. Change-Id: I5c99f8d48be77c4454ffac6ffa9f5babfe0d4909 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166572 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-06-18tdf#161521 fix page margins on first page with mirrord layoutOliver Specht
Documents starting with an even page on a mirrored layout need to switch left/right margin on the first page. Applies also to docx export. JUnit test included Change-Id: Ia363941c6a7a25f9208acc7e40b77baa88080780 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168658 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
2024-06-17tdf#158658 sw: text formatting: make TabOverMargin even more crazyMichael Stahl
... to better match Word's formatting. The bugdoc has a special case where a right-aligned tab is positioned at the right margin exactly, which causes the bFull condition in SwTabPortion::PreFormat() to be true. An obvious change to replace rInf.Width() - rInf.X() with rInf.GetLineWidth() in the condition makes no difference because m_pLastTab was already reset previously; instead, pass in the last tab from Format(), which indicates that the right edge position of the previous text portion was found via that tab. Additionally, change the condition that checks for TabOverMargin to also allow equal positions, i.e., exactly at the end of the paragraph. Change-Id: I5d3b1c13eca0bffa640745d7c5f4113699f79cad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168823 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 69d873e1c46f3cc8c524e18ac5a307a8d32ddd0f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168864 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-06-17tdf#158658 sw: text formatting: try to make TabOverMargin more crazyMichael Stahl
... to better match Word's formatting; this commit is not based on a complete diagnosis of Word's compatibility-mode tab-in-margin formatting disorders. 1. in SwTabPortion::PreFormat() allow a left aligned tab beyond the width of the paragraph, like already done for TabOverSpacing 2. in SwTextFormatInfo::GetLineWidth() add some extra width to the paragraph so text can be hidden in the right margin. (it's very unclear what Word does here exactly, in one case it puts 339 additional "a" characters in the margin but then the 340th "a" goes onto a new line...) 3. in SwTextFormatter::NewTabPortion() allow manual tab stops to be positioned beyond the width of the paragraph, like already done for TabOverSpacing testTdf118672, testTdf120287b, testTdf120287c fail but the files, converted to RTF, render in Word 2013 basically the same as in Writer with this change. Change-Id: I5f74ced09c704bfd9967df61351c8bac6540e714 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168819 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 10d753b8aadb50ec4309551b97d4cf2163ea3e3d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168863 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-06-12(related: tdf#161215) sw: layout: fix another floating table loopMichael Stahl
The full bugdoc loops; text frame 3160 (on which a floating table is anchored) is split, immediately joined, and split again... SwTextFrame::IsEmptyWithSplitFly() has a wrong condition that compares document coordinates with relative position inside the frame; try to use the confusing SwRectFnSet to compare instead, which prevents this frame from splitting because it actually fits into its upper. Another problem in that function is that it checks RES_PAGEDESC but not RES_BREAK; try to fix that too. (regression from commit 16b5b21d36da87be9b50235acbbb8008ed23b8bb) Change-Id: I94251b7443e51303b28d14f0597b0bf782142480 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168668 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 48659fa6cf8b2c5e3810696cf0c9257ddb57dd4d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168623 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit f38ba192a52f46a386789557fc2f2600dd2e676e)
2024-06-12tdf#161215 sw: layout: don't move into section frame on same pageMichael Stahl
The problem is that in SwFrame::GetNextFlyLeaf() pLayLeaf is in the body on the same page as pFlyAnchor, so the MoveSubTree() effectively removes the pNext chain from the layout into a circular structure whose upper is an indirect lower, causing an infinite loop later. Change-Id: I08f96cf483205d6213d7cec7b239f750fff5d3ad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168529 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 724c17602fac7476f068e6b66f30e9ef3c9f0940) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168536 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 13728add48675b470d596c77fd186d3654b29525)
2024-06-12tdf#161217 sw: layout: don't move into to-be-deleted section frameMichael Stahl
The problem is that in SwFrame::GetNextFlyLeaf() pLayLeaf is found inside a SwSectionFrame that has no m_pSection because it has been scheduled for deletion via SwRootFrame::InsertEmptySct(). Skip such frames, now it goes into infinite loop later... Change-Id: I93e5febba19213c1503fd699c8e4517067c6ec6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168528 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins (cherry picked from commit e607bf096d4fb182388ccaefb1179cdd924af02a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168535 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit a7548d6b38a9b075f31f5955d1512d9ff5017d66)
2024-06-07Merge tag 'libreoffice-24.2.4.2' into HEADThorsten Behrens
Tag libreoffice-24.2.4.2 Change-Id: Ic8eb6fa69fd24d643e67cda579025a295a5f49b0
2024-06-07tdf#161248 Don't duplicate bullets used in documentSamuel Mehrbrodt
Change-Id: I0ef01a6be8207d4cffc89b95dc9ca3bf1baf38d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168371 Tested-by: allotropia jenkins <jenkins@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-06-07tdf#69724 Allow to change default bullet symbols in UITibor Nagy
Change-Id: Ife700096fb55ebc752ae289398a36ee78b3e5ccb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167660 Tested-by: Jenkins Reviewed-by: Nagy Tibor <tibor.nagy.extern@allotropia.de> Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de> (cherry picked from commit 2e1350593c26a70408b3cf7d1bac2f2ff8309852) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168370 Tested-by: allotropia jenkins <jenkins@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-06-06fix crash when push the Bullets button on the toolbar and then press theTibor Nagy
dropdown part of the button caused by commit I40cfc39501006146f7c6c04a1f3c7cf877c6f1c4 (tdf#161056 Show bullets used in document in bullets dropdown) Change-Id: I215d7cb677825821917a4fd8c498deaaab9fc9b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167838 Tested-by: Jenkins Reviewed-by: Nagy Tibor <tibor.nagy.extern@allotropia.de> (cherry picked from commit 708d619e32f251f06af8e8a057bf802627b81fbd) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168369 Tested-by: allotropia jenkins <jenkins@allotropia.de> Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2024-06-06tdf#161056 Show bullets used in document in bullets dropdownSamuel Mehrbrodt
Change-Id: I40cfc39501006146f7c6c04a1f3c7cf877c6f1c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167186 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> (cherry picked from commit c8a5dc46d11f2ef1e3a66d633730d9a700ced24a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168368 Tested-by: allotropia jenkins <jenkins@allotropia.de>
2024-05-31Simplify a bitMike Kaganski
And avoid a second call of pObj->GetUserCall. Change-Id: I4487ad33df594a8a96b517c5b4671512dea7116d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162042 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 5703d3af04b8fe78fdd4dbef14b08d8446402779) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167940 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit 660443e38c2d059d557298e1131cf42b96436e30) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168065 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-05-28Set minimal size to variable field pageOliver Specht
To see the increased height of the name and value fields the edit field dialog needs a appropriate minimum size Change-Id: Ic6c4a01bd969247f770f023ec5c368fed5322550 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168147 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-05-22tdf#161137 sw: AutoText or Paste should copy paragraph indents for listsMichael Stahl
The first commit made the start and end node of the paste look like the list it was inserted into, but the middle nodes may have different paragraph styles and may have different left margin / first line indent. In addition to the SwNumRule, also copy any left margin or first line indent if it is effective on the node that the SwNumRule was taken from. Now all the list labels should be in the same place. Change-Id: Ia5794687ea0ff542f23289b1ca63ea99dae85bc3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167777 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 2bcaa374ea418cd81f9dbf62cd7e896f5977992a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167810 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-05-22tdf#161137 sw: fix AutoText or Paste overriding paragraph indentsMichael Stahl
The problem is that when a paragraph style specifies a SwNumRule, then this style's indents override the indents of the SwNumRule, but if the same SwNumRule is also added to the SwTextNode's mpAttrSet, then the style's indents no longer take effect. This happens both when inserting an AutoText, and when Pasting, into a list item, because DocumentContentOperationsManager::CopyImplImpl() sets the pNumRuleToPropagate as direct formatting on every pasted node. Add another flag to SwDoc::SetNumRule() to check if pNumRuleToPropagate was already in effect due to the paragraph style. Change-Id: Id98ad2a21eab4f8636fb36f9298a054cfe4f7784 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167766 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 7698f386413e514a4478a1af69a8a3be93dfecab) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167689 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-05-21tdf#161172: Also record history for !bChangeOfListStyleAtParagraphMike Kaganski
Change-Id: I6443d7ef76a27ac3ab75f88edd271a8b36e06c14 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167839 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167818
2024-05-19Resolves: tdf#151382 we want to save the FN_KEEP_ASPECT_RATIO stateCaolán McNamara
and not if it is implied to be toggled on by SwFormatFrameSize::SYNCED in which case on "ok" FN_KEEP_ASPECT_RATIO is set from the ui state so both tdf#151382 and tdf132591 work Change-Id: I039de0e8f0f9adcc3c02f0e07c12d83cd807887b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167816 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2024-05-18tdf#161137 sw: AutoText or Paste should copy paragraph indents for listsMichael Stahl
The first commit made the start and end node of the paste look like the list it was inserted into, but the middle nodes may have different paragraph styles and may have different left margin / first line indent. In addition to the SwNumRule, also copy any left margin or first line indent if it is effective on the node that the SwNumRule was taken from. Now all the list labels should be in the same place. Change-Id: Ia5794687ea0ff542f23289b1ca63ea99dae85bc3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167777 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 2bcaa374ea418cd81f9dbf62cd7e896f5977992a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167810 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-05-18tdf#161137 sw: fix AutoText or Paste overriding paragraph indentsMichael Stahl
The problem is that when a paragraph style specifies a SwNumRule, then this style's indents override the indents of the SwNumRule, but if the same SwNumRule is also added to the SwTextNode's mpAttrSet, then the style's indents no longer take effect. This happens both when inserting an AutoText, and when Pasting, into a list item, because DocumentContentOperationsManager::CopyImplImpl() sets the pNumRuleToPropagate as direct formatting on every pasted node. Add another flag to SwDoc::SetNumRule() to check if pNumRuleToPropagate was already in effect due to the paragraph style. Change-Id: Id98ad2a21eab4f8636fb36f9298a054cfe4f7784 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167766 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 7698f386413e514a4478a1af69a8a3be93dfecab) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167689 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-05-18sw: make testTdf131963 less strictMichael Stahl
Asserting number of pages is rather questionable because any number of things can change that and you will spend days debugging that. For some reason this test has 12 pages on my libreoffice-24-2 branch build and 11 pages on my master build, either of which are clearly better than the 2 pages result of the bug that was fixed there. Change-Id: Ie1e97d5cc973f317a2d6ca8a7d13822385b134f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167627 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 9aa22abcbdfe42e516ecc791605e3a1b7ef80327) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167465 Reviewed-by: Caolán McNamara <caolan.mcnamara@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 (cherry picked from commit b969e692000f50aafacc2eb577f545b8836dcc26) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167683 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-05-16tdf#161035: The previous bookmarks can legitimately be not processedMike Kaganski
The enumeration may be called for a partial paragraph selection, and then the bookmarks prior to the selection are not processed. Change-Id: Ib725ffb320ec5a81b39ce77f06392a82bd6d8ee0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167720 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins Reviewed-by: Patrick Luby <guibomacdev@gmail.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167754 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2024-05-16Fix UBSan failure (part 2)Xisco Fauli
Introduced by 495b5db74f0db59395ff68bacc8d8ca67595b66e "sw: check GetUserCall" https: //gerrit.libreoffice.org/c/core/+/166824/comments/8db24a41_2f4e7e4e Change-Id: Ib6f981aa3055f0d37d0b83e3284842d310fe6ef0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166913 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167002 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-05-16Fix UBSan failureXisco Fauli
Introduced by 495b5db74f0db59395ff68bacc8d8ca67595b66e "sw: check GetUserCall" https://ci.libreoffice.org/job/lo_ubsan/3154/consoleFull#-1571115798d893063f-7f3d-4b7e-b56f-4e0f225817cd Change-Id: Ifc80312890f2e6b82dcc9419b5b7e8bfcd5340a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166824 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167001 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-05-16sw: check GetUserCallXisco Fauli
It might return nullptr See https://crashreport.libreoffice.org/stats/signature/SwFEShell::ShouldObjectBeSelected(Point%20const%20&) Change-Id: Ia0ed355a7eb9084b9f57163ffbfe6b549c8bdb3f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166642 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit 495b5db74f0db59395ff68bacc8d8ca67595b66e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166710 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-05-16tdf#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 (cherry picked from commit 6025ac371bd5cd07c0af550d78db323ad394173b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167671 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-05-14tdf#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 (cherry picked from commit 6200d89b905d51776ff4f3c8a84f338655ffaa7f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167221 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-05-14tdf#160836 sw: fix narrow selection area of cell borderLászló Németh
Remove ShouldObjectBeSelected() condition to fix the selection area around the horizontal border. (Its purpose was to avoid of selection of the border, when covered by an image: but that would be !ShouldObjectBeSelected(), with the same problem: halved selection area.) Clean-up commit commit 30de13743f144aced83bc43d310592f82788c910 "tdf#160836 sw: resize rows at images cropped by row height". Change-Id: I6c812a150b67431c7ea3131f29489bda919c1724 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166877 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 38b6e89c9483fdfe3d26bef3b25f890528aef84e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167211 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-05-14tdf#160836 sw: resize rows at images cropped by row heightLászló Németh
Fixed row height can crop cell content, including images anchored as character. Resizing the row height with mouse was not possible there, because selection of the cropped image avoided to drag & drop the horizontal cell border. Change-Id: I6dde79e77563468059794548b6c058cad61586a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166795 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: Jenkins (cherry picked from commit 30de13743f144aced83bc43d310592f82788c910) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167210 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-05-13tdf#160842 sw: select cell content instead of cropped part of imageLászló Németh
It was not possible to select and edit the content of the bottom cell, if an image cropped by the fixed row height "covered" it, i.e. the image was in the previous row, anchored as character. Note: table cells with fixed row height are usable to crop images easily, with a single drag & drop, according to the requirement of the text layout, while the cell above or bottom of the cell with image is for the caption of the image. This is very useful to adjust a book layout with sections with multiple columns and illustrations. Change-Id: I8683b4066db6ce43549ec3aa69b0e639a59e3681 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166794 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit f3b899655018397e71300dbb32cdf4f82940a68b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167089 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-05-13tdf#44773 sw: allow resizing table rows, if cursor outside the tableLászló Németh
If the cursor wasn't in the table, only column width of text tables was resizeable by dragging the horizontal cell borders: It was possible to drag the horizontal border, showing its preview, but the drop cancelled the operation instead of resizing the table row according to the selected position. Now it's possible to resize the height of the table rows without moving the text cursor inside the table. Note: This is important for floating tables containing images: here it's not possible to put the cursor inside the table, if the image is cropped only by the cell borders: so it was not possible to resize the row height. Change-Id: I181d79a28cdeefabb796b7b978ee1368a9378888 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166793 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 6c00a73348511b688be214439941e128fc430a34) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167088 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-05-11Merge tag 'libreoffice-24.2.3.2' into feature/cib_contract49cThorsten Behrens
Tag libreoffice-24.2.3.2 Change-Id: I1ba238eb2cfff7a7d083e54ec4953dc910fd595d
2024-05-10sw: Navigator: don't show virtual drawing objectsMichael Stahl
These can return a non-empty name now, so exclude them explicitly. (regression from commit ae132145ff42a95dc24fb124847c04af4b8c8dab) Change-Id: Ia7f7b9fd7abe67f3302e95b38e3b9fa30b769b5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167349 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins (cherry picked from commit 609d1e353cfd7a9b138fcbe656a2faae9f84c36a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167451 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-05-10tdf#156484 svx,sw: fix visibility of shapes in header/footerMichael Stahl
Similar to commit ae132145ff42a95dc24fb124847c04af4b8c8dab, also forward IsVisible() and IsPrintable() from SdrVirtObj to its real object; evidently the properties aren't copied when creating SdrVirtObj but there is no reason for that to have these properties independent. This triggers an assert in VOCOfDrawVirtObj::createPrimitive2DSequence() because that is called during layout from getObjectRange(); the assert was added in commit ae3ec0d53a22ae5d2b7fb244a6056d0627b71873 and intended for painting, but this isn't painting, and it's not easily possible to detect if the function is called during painting, so remove the assert. Change-Id: Id2a04a5d07f43b86eb9c524b30ba74ecaf6a95c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167350 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins (cherry picked from commit 9fb9bd54a82ee20f5916aa68e428e0fb67f02ed6) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167452 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-05-10tdf#156484: sw_ooxmlexport13: Add unittestXisco Fauli
Change-Id: I3bcda136eff62a61783b4e52132125c4b1794ccb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167446 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2024-05-08tdf#156484 svx,sw: fix visibility of shapes in header/footerMichael Stahl
Similar to commit ae132145ff42a95dc24fb124847c04af4b8c8dab, also forward IsVisible() and IsPrintable() from SdrVirtObj to its real object; evidently the properties aren't copied when creating SdrVirtObj but there is no reason for that to have these properties independent. This triggers an assert in VOCOfDrawVirtObj::createPrimitive2DSequence() because that is called during layout from getObjectRange(); the assert was added in commit ae3ec0d53a22ae5d2b7fb244a6056d0627b71873 and intended for painting, but this isn't painting, and it's not easily possible to detect if the function is called during painting, so remove the assert. Change-Id: Id2a04a5d07f43b86eb9c524b30ba74ecaf6a95c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167364 Tested-by: allotropia jenkins <jenkins@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-05-08sw: Navigator: don't show virtual drawing objectsMichael Stahl
These can return a non-empty name now, so exclude them explicitly. (regression from commit ae132145ff42a95dc24fb124847c04af4b8c8dab) Change-Id: Ia7f7b9fd7abe67f3302e95b38e3b9fa30b769b5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167363 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Tested-by: allotropia jenkins <jenkins@allotropia.de>
2024-05-08Remove known-problematic testsThorsten Behrens
Trying to address similar issues as on 7-6, via https://gerrit.libreoffice.org/c/core/+/164714. Change-Id: I43a3680c12d5e2d69e61854af6496fac24530524 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167297 Tested-by: allotropia jenkins <jenkins@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-05-08tdf#159683 sw content controls, plain text: fix crash with the clipboard docMiklos Vajna
Regression from commit c804c5354855188b5a37219cfe11dc079dc235f4 (sw content control: fix lost properties on copy&paste, 2023-03-10), select a plain text content control, copy it to the clipboard, quit: assertion fails during shutdown because the doc's "placeholder text" char style is still referenced by a client. What happens here is that the SwContentControl copy ctor copies the plain text flag, and that flag is only read in SwTextNode::InsertHint(), so that causes the problem. Note how that code is inconsistent: we avoid the creation of dummy characters in the copy case, but we still try to adjust the start/end of the content control attribute in the copy case, which makes not much sense. Fix the problem by not adjusting the content control attribute boundaries in the copy case, since the original intention was to do thees corrections only at a UI level, during interactive edit. It's not clear why this inconsistency had an influence on the clients of the char style, though. Change-Id: I86b0516464f24fc453dcd97588dafb8afd010a9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166882 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 06aeb9c61d50bba7edafe17f9d3513af26b0782f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167311 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-05-08tdf#160402 writerfilter: extend StyleMap with all Word stylesMichael Stahl
There doesn't appear to be an accurate and complete documentation of all the Word built-in style names, but fortunately Word writes them all into styles.xml in a w:latentStyles element anyway. It turned out that a lot of the Writer built-in style names here were obsoleted by renaming and did not match any more. Change-Id: Ic69785a34524f667b83a06a267715b2c8b0165d0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167242 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 72ea1005b987159a6a59f9379e63321e0b0dd44f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167261 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167292 Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-05-08Fixup: Design change in variable page of the field dialog in WriterThorsten Behrens
Adding improvements from patchset 2, out of https://gerrit.libreoffice.org/c/core/+/167285 Change-Id: I29cb1ab50dd3a59e842724005b443b4b6f1fe483
2024-05-08Case Rotation in Impress and Writer improvedOliver Specht
Word boundaries at the end of the paragraph are now correctly detected. Sentence case is not applied without multi word selection in Writer anymore. Change-Id: If6e2eeaa1ecca215d583e8f33364db466bf7c57d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166928 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-05-08Related: tdf#160833 teach DOC export about DoNotMirrorRtlDrawObjsMiklos Vajna
See <https://gerrit.libreoffice.org/c/core/+/167033/1#message-e1df9bf60b7b8b2acdf0c062484ddc572939a3d9>, no need to undo the import-time mapping in case we know that the mirroring is avoided at a layout level. Change-Id: Idbdc10ad327540dc5045e9b19dd42160b5139470 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167049 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 9d95eb980ef12678f6fb978badcbe1cacbe0c4dc) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167084 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-05-08tdf#160833 sw DoNotMirrorRtlDrawObjs: add UI in cui/Miklos Vajna
The UI code at lcl_ChangeResIdToVerticalOrRTL() was aware that SwAnchoredObjectPosition::CalcRelPosX() mirrors the position when the anchor paragraph is RTL, so swapped the "from left" label to a "from right" label. Don't do this when the compat option is enabled, so not only we render correctly but the UI now correctly explains why we came up with the correct position. Change-Id: I479ed1f085b249d10be47b66d7a656dc1bd4f936 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167031 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 0f410680461d7ba5f70dd65b2a8263dec15ac357) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167083 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-05-07tdf#40142 sw: only check level for table of contentsMichael Stahl
Only Table of Contents has level settings, the level is always 0 for the other ToX types, which erroneously excludes nodes (as can be seen with testFDO77715 failing with upcoming tdf#160402 bugfix). (regression from commit 5c04c4474236cc50009aea6d89f7c443c861af19) Change-Id: Iec1c2b8eaba0ad20b2ad7d8c6b20603315a7a83d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167096 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 7178d6197b892e456a8db8a3d085a24bfd52cf32) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167212 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2024-05-07tdf#160402 writerfilter,sw: STYLEREF field can refer to character styleMichael Stahl
Adapt SwGetRefFieldType::FindAnchor() to search for SwTextCharFormat, and ApplyClonedTOCStylesToXText() to replace "CharStyleName". Works for the "Intensive Hervorhebung" field in bugdoc. Change-Id: Iee126eeb4cc2ff1c570941e3beefd93527c56fee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167098 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins (cherry picked from commit d4fdafa103bfea94a279d7069ddc50ba92f67d01) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167244 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
generated by cgit (git 2.34.1) at 2024-07-21 04:43:48 +0000