summaryrefslogtreecommitdiff
path: root/sw/qa/extras
AgeCommit message (Collapse)Author
2020-11-24sw: fix SwXTextRange::createEnumeration() inside table cellMichael Stahl
This would set CursorType::SelectionInTable but leave m_pOwnTable and m_pOwnStartNode uninitialised, causing sw/source/core/unocore/unoobj2.cxx:399: SwXParagraphEnumeration: table type but no start node or table and then the enumeration would return the table it's in as the first element, which is quite annoying. Refactor the creation of SwXParagraphEnumeration to prevent this. Change-Id: I4e9e3456bdf66b9822d19ad985a20b094e6bbba4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106532 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit ecc3c621fe5a7e962f0e40cb3709ad5772a5d744)
2020-11-24sw: fix copying and deleting of section content via APIMichael Stahl
The problem happens if a section starts or ends with a table: SwXTextSection::getAnchor() may return a SwXTextRange with one position in a table cell and another position in a different table cell, or outside the table, neither of which is valid to set the cursor via SwXTextViewCurosor::gotoRange(). Introduce a new special mode for SwXTextRange, RANGE_IS_SECTION, analogous to RANGE_IS_TABLE but actually working. Only SwXTextView can be used to create XTransferables, and it requires selecting first via either the SwXTextViewCursor or select(). It's currently not possible to select the content of a section in the ViewShell in these problematic cases, and would be some effort to add. So add a new interface XTransferableTextSupplier that can be used to create XTransferable from the SwXTextRange with RANGE_IS_SECTION. The core CopyRange() and DeleteRange() functions can deal with SwPaMs that start or end in non-text-nodes, so pass the whole section content to these in SwXTextRange::setString() and in SwXTextView::getTransferableFromTextRange(). Change-Id: If7e3210e8a26f5618317c294f2b2f3ed5c217f1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106293 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 7ab349296dac79dad3fec09f60348efcbb9ea17e)
2020-10-16sw: DOCX export: don't export text frames as transparentMichael Stahl
Writer paints text frames without fill still as opaque but nothing is written in the DOCX file and Word by default treats DrawingML text frame as transparent (the VML fallback is opaque though). Change-Id: I0ce539ac8084c5047b4732abc5c199589ee369ee
2020-10-16sw: DOCX export: for soft-page-breaks, export continuous section breaksMichael Stahl
When a section break is produced based on layout information such as soft-page-break and follow page style, it's a bad idea to generate a page break because the break may be in a different position in Word, particularly if it was inside a fieldmark instruction. It wouldn't work that well to ignore such page breaks in MSWordExportBase::NeedTextNodeSplit() because then they would be created when reaching the next node anyway, via FindPageDesc() fall-back to layout. Unfortunately this breaks the test tdf113849_evenAndOddHeaders.odt which has a page style with follow-page-style on the first page; on re-import from DOCX, the continuous section is now no longer converted to a page break, so pages 2-3 have the wrong header/footers... this seems impossible to fix in general in the import because it doesn't know whether the continuous section break coincides with a layout page break. Arguably this worked before mostly by accident? tdf#113849 isn't about this afaics... Change the test file to have an explicit page break there, which round-trips as intended. The real fix would be adding continuous page style change to Writer i guess... Change-Id: I00ffe3971607c148a7d5c13b89afb936718611c0
2020-10-16sw: HACK to disble DrawingML export for rotated text shapesMichael Stahl
Change-Id: I7542d0dd000b974ce490b9b81f3d85412e2409f2
2020-10-16oox: VML export: convert ESCHER_Prop_AnchorText to v-text-anchorMichael Stahl
Change-Id: I903cac8d7b02138680613b5a1b6dab4b1c448158
2020-10-16filter: MSO export: convert TextWrap property to Escher_Wrap*Michael Stahl
There's a paucity of working wrapping modes in Escher unfortunately. Change-Id: Ibaf99c3249a6492dc129f9c9b5707778038f9a4c
2020-10-16oox: VML export: for rotated text shape, produce bottom-to-topMichael Stahl
This is for shapes that fail the lcl_isTextBox() check in VMLExport::StartShape(), they can be rotated too but with a different property than the "TextPreRotateAngle" that is used in VMLExport::EndShape(). Change-Id: I530aae8b7138f47bae8434e205632f5f4adbb231 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100249 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 090c61eb93db4302d4565d5f11f7673190835fdb)
2020-10-16tdf#135464 sw: ODT->DOCX: fix positioning of at-page shapes and framesMichael Stahl
Exporting at-page anchored flys to DOCX can result in wrong positions, because DocxSdrExport::startDMLAnchorInline() converts text::RelOrientation::FRAME to relativeFrom="column", i.e. the margin, but sw displays it as relative to the page. In fact at-page and FRAME is an invalid combination according to the table in ODF 1.3, 20.298 style:horizontal-pos, the paragraph and character relations are not valid for page-anchored flys. Since there are lots of ODT files with this invalid combination, try to fix it on import, in SwXFrame and SwXShape. Funnily, SwXShape is attached before the properties are set, while SwXFrame is attached after the properties are set. The anchor frame for at-page is always a SwPageFrame. Unfortunately there is a case where PRINT_AREA and PAGE_PRINT_AREA differ, namely the CalcClipRect() only handles PRINT_AREA so it will crop to the right margin with that but not with PAGE_PRINT_AREA, so don't map this value. Change-Id: I4d5f7f87d045ac4539b9170e55c34d4afe801f4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100130 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 12645900dece0a9aa0661fee796c27f672217977)
2020-09-23tdf#135942: avoid collecting autostyles during writing themMike Kaganski
This modifies the container over which iteration is performed. Additionally, make sure that all nested table autostyles are collected on the first phase. Change-Id: I74c0bb1aaacad095226c21e6bf51cc8668133bb3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101096 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit f0286ad82465152b29bba01ab2edeb97291397fa) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101069 Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 0273675e7dde577077ccca17571846a0942f2630) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102311 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-09-10tdf#124470: Split export of table autostyles out from collection phaseMike Kaganski
This allows to call collectAutoStyles where required (e.g. when enumerating used fonts), without side effect of writing table styles XML inside the call, out of place. Change-Id: Ida05e373eb8502590c43e2b0e85c3b0c1107c551 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100153 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 35021cd56b3b4e38035804087f215c80085564be) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100221 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100274
2020-08-28tdf#131801: sw: support of style references in ListAutoFormatVasily Melenchuk
ListAutoFormat property did support char attributes, but not style references ("CharStyleName"). It is important for correct formatting of pilcrow symbol or list format in some DOCX scenarios. Export to DOCX already works, but not to RTF/DOC. Change-Id: I1bf23d1e45fcc213adcf9aa6f404be803919fbee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100893 Tested-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit c77b9c349f0a48392d8cb7a49532844b2cafb5ba) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101560 Tested-by: Jenkins
2020-08-27tdf#135973: DOCX export: improved list override supportVasily Melenchuk
Removed remains of old override support which are not working now. Partial refactoring and fixing for listid and overrides detection. Change-Id: I1f94a09b7d51fcc3300b056d6d9e8ea6367a4446 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101238 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101438 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-08-26(related: tdf#132160) sw: fix lcl_RejectRedline if end is on table nodeMichael Stahl
This happens on Undo: sw/source/core/undo/undobj.cxx:1394: void SwRedlineSaveData::RedlineToDoc(const SwPaM&): Assertion `result != IDocumentRedlineAccess::AppendResult::IGNORED' failed. Because the SwRedlineSaveData was created in SwUndoDelete ctor from this: (rr) p *pRedl $18 = (SwRangeRedline) { <SwPaM> = SwPaM = { point = SwPosition (node 13457, offset 0), mark = SwPosition (node 13455, offset 0) }, (rr) p pRedl->GetPoint()->nNode.GetNode().GetNodes()[13457] $19 = (SwTableNode *) 0x80bdbe0 DelFullPara() will delete the end node, see "m_rDoc.GetNodes().Delete( aRg.aStart, nNodeDiff+1 );" or equivalent in SwUndoDelete. So if the end is on a start node, set it back to the previous node, because deleting just a start node is a bad idea. Change-Id: Ib7c35c103ce05ede39e66505fa47fa70bfece018 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101334 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit e2fe4fde592564d35099ad1e2659ad682dfb77f5) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101352 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-08-21tdf#133437: sw: set generated shape name if it is missingVasily Melenchuk
Shape names are required for seting format name and undo/redo and correct displaying of objects in Navigator pane Change-Id: I43caf6a4d5f054283d48c46b081d43b743bd4433 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98312 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit 0c53a58b2dd9bee3d4de6843966486428fdaa78f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100942
2020-08-13tdf#128197: sw: different line height for DOCX with compat=14Vasily Melenchuk
Lines containing just a shape inline without any other text are treated in DOCX with compatibility option 15 and 14 in a different way: while compat=15 is layouting line exatly as LO does, in compat=14 mode minimal line height takes into account just shape height and not current font. Change-Id: Id2bdab941a0bbaa9080567d736435d9e0babd490 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96080 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100542
2020-08-12tdf#134043 DOCX import: new unit tests: ComboBox to DropDownThorsten Behrens
Change-Id: I034b0cd9c6f66c531460d1bb69d9ede5ff46f7d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97531 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99994 tdf#134572 DOCX: Incorrect default value in dropdown text fields Change-Id: I3169e817c2f033d1525adc3b02ac3680ad220d70 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99074 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100306
2020-08-11tdf#128198 sw: text formatting: only consider upper margin for first lineMichael Stahl
The non-first lines start below the first one so the margin is already included in the previous line's Y position. Also move the testTdf116486 to layout.cxx. (regression from d07fc485d46f431405a3f6a002f951a08c559677) Change-Id: I574516ea5f9600e2d861e43162b1a69488c68819 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100440 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 99ef50f97b6d8461b8953c2555298c7bbeb3405b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100499 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-08-02tdf#134436 sw: fix SwUndoDelete::RedoImpl() with section at end...Michael Stahl
... of document; the root cause is that in some intermediate delete operation, the delete will remove a section start/end node pair that surrounds the last text node in the document, but SwUndoDelete::RedoImpl() will not remove it, thus for subsequent Undo actions the indexes are messed up and weird things happen. Fix this in DocumentContentOperationsManager::DeleteRangeImplImpl(), with the same weird "is point at the end" check as SwUndoDelete. Change-Id: Iebf20d3c129c69692df8d57e3c5b9e6fec281e4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99810 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 22a77cb83a3769a8b43d80565282988a74214866) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99858 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-31tdf#133967: sw_uiwriter: Add unittestXisco Fauli
Change-Id: I7ec43fd7109e883b0ae560cc8832e449a09fddb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99758 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit a6e02f6337f038a445b858bb91bf14d1a14768e4) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99735 Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99791
2020-07-30tdf#134252 sw_redlinehide: fix SwUndoDelete for table before end of sectionMichael Stahl
In this funny case, the SwPaM starts inside a section, and ends in the first text node following the end of the section, which happens to be in a different section (but that doesn't matter)... this is because IsSelOvr() moves the end of the selection resulting in the 3rd SelAll off of the table end node (as the section ends with a table), but then it's on the section end node and moves forward again. SwUndoDelete::UndoImpl() must first create the outer section frames, skip over the start text node which has frames handled by RecreateStartTextFrames() and then create the frames following the start text node, where the end node of the outer section now finds its expected outer section frame. This relies on the code from 55576842ec72a748d0bad123d41fa03c89fc136d to move the existing text frame below the new section frame(s). (regression from 6c7245e789f973cf6dad03f7008ab3f9d12d350c) Change-Id: I9f39b09e603e75ef813d5c855d828ec9bd5fdd95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99723 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 740f1796504f66408b692225a9676c9ee3d63722) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99785 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-07-30tdf#134250 sw_redlinehide: fix Undo with section before tableMichael Stahl
... at start of document, part 2: In SwUndoDelete::UndoImpl(), the m_aEndStr wasn't inserted, because the pTextNd was a section node. This caused asserts when trying to add the history hints that used to be in the end text node. thints.cxx:1295: bool SwTextNode::InsertHint(SwTextAttr*, SetAttrMode): Assertion `!pAttr->GetEnd() || (*pAttr->GetEnd() <= Len())' failed. (regression from 57d488660572d62ef0371e50dcdd4ca7a6d98a14) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99644 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 27613259990d39d34b036b3d717d3ceaf5c15e65) tdf#134250 add unit test Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99672 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit 50ceac91a4ac2057847e7d9807f5cb614e6ff755) Change-Id: I48caa7487d2d1e6250b5aceab18f270555d3ee8f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99779 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-30tdf#132944: sw_uiwriter: Add unittestXisco Fauli
Change-Id: I45568da4b3dccd4e0cfe990c50217012f02540c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96590 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit c7f7bbf082806ba74eb5a608bfeabd05bf73510d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99642 Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 3a560c35bd7b652cc956d808b1f451f859c924d4) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99667
2020-07-30CppunitTest_sw_uiwriter: reset the redline author after using itXisco Fauli
See http://document-foundation-mail-archive.969070.n3.nabble.com/CppunitTest-different-results-depending-on-execution-command-td4283987.html Change-Id: I16f07232611d3d2cec675f34f0f93aee9618d80f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99585 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit 720b3c133cc6348537b4d013b4531856f73b392d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99666
2020-07-22i18npool: don't break line at slash '/'Michael Stahl
If sw text formatting gets the result of the special-case code added to the "word boundary break" condition, it may call again the next time with the preceding index, and fall into the "Line boundary break" condition, which hence also needs to special case '/'. (regression from ICU 60, 9206a08ada00e8762c4a634f242bd566028964bb) Change-Id: I2aaefbc7b25af157e0a6ef15fabaa71bff1e8d9a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99104 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit a916e2253df2bf1415c25fb7f974e0d16b615d03) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99132 Reviewed-by: Eike Rathke <erack@redhat.com>
2020-07-22tdf#134400 RTF import: fix unexpected inner properties for picture-in-textframeMiklos Vajna
Regression from commit 4ab658b56f5c6ff0082d38d8ace1924d11e30e96 (RTF import: implement support for tables inside text frames, 2013-06-16), the problem was that both the outer "textbox" and the inner "picture frame" object had a shapeType property, and the properties were stored in a vector. So by the time RTFSdrImport::initShape() looked up the shape type for the inner shape, it thought it's not a picture frame, leading to data loss. (cherry picked from commit 5a083be34456e91427d0f2e2fea172f49f4502db) Change-Id: I4a536789371619d1d54afa8c8d41c7d273b0d21b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99118 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99167 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-07-12tdf#134548: sw: revert of changes to tab at zero posVasily Melenchuk
It looks like solution for provided in 5ed96c for tdf#83309 is enough to resolve original bugdoc, so these changes for emission of tab at zero position are not required and produce just regressions. Corresponding unittest for tdf#83309 is adjusted: it is using now original bugdoc. Conflicts: sw/source/core/text/txttab.cxx Change-Id: I2e7683f071f78c720436b4c9ccb903133a985e7c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98476 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98547 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98564
2020-07-09tdf#134260: docx import: allow default value for list tab positionVasily Melenchuk
It looks like previously used as a testcase document is just a specific case with default values. All other readers (incl. Office 365) displaying that doc with default tab at zero position. Change-Id: I50fe00c7f87b6d790fbe6e2f32a306ac59060c72 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97089 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit 7221994b9b29659d3290e95eee92b1a3f80c2b7e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98331 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit 54b6a6a5c95ed51ce0cd709d9fd3e477ced5ce8f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98332 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-07-07tdf#134472 Only add spacing in header when flag is setSamuel Mehrbrodt
Flag was set, but not evaluated in 9b5805d1ef2b9e9c4e8f389c069807bf4489ea95 Change-Id: I46f19945be521e886baa0fc9a9a419d88c0915fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98224 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit 70f9c3b8f03fb28215985a5b899bd8fae9cb3ac3) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98085 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-07tdf#132956 Chart view: fix missing plot areaBalazs Varga
Do not reduce the inside area of the chart depending on the size of the legend. Use the default legend size. Regression from commit: 739ed2c29f49ea5e83bcd1352b2644c2e2d09f7b (tdf#115630 tdf#88922 Chart: fix custom legend position and size) cherry picked from commit cf46500243c51071227e08c5067041e414180ebc Change-Id: Ic191229d7ceab1f2689ab07424353108f8cb2b95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94059 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: Tünde Tóth <tundeth@gmail.com> Reviewed-by: László Németh <nemeth@numbertext.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95583 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-07-01tdf#134063: sw: redesigned support for tab at zero positionVasily Melenchuk
Initial support for tab position at zero (d2e428d1) was not taking into account hack for tab positions below zero. So previous behavior is restored (search is started from 0) but we also taking into account potential tabs at zero position in SwLineInfo::GetTabStop() Change-Id: I8b315ab69f9a53ac15002a41a81e069ff832f692 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96526 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit 02c0e015f84ddcc6fa94433f603ef89f358a0391) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96582 Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97478 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-06-30tdf#134043 DOCX import: DropDown text field instead of ComboBox form controlSerge Krot
Change-Id: Ide9cedefde3b00fa0eeb37a6540e8d4a420b70c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96471 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96608
2020-06-17tdf#133145 sw ContinuousEndnotes: fix moving endnotes to a previous pageMiklos Vajna
Regression from commit 4814e8caa5f06c4fe438dfd7d7315e4a2410ea18 (tdf#124601 sw: add ContinuousEndnotes layout compat option, 2019-09-30), the problem was that SwFrame::GetPrevFootnoteLeaf() did not take the new compat flag into account when determining the previous footnote page for endnotes. Do the same pattern here as the cases already handled in the above commit, just try to get the "last but one" and not the "last" page, since we try to move these endnotes to a previous page. (cherry picked from commit 35bb0594b2d977312ef06fc5262cc7592bc13d0f) Conflicts: sw/qa/core/layout/layout.cxx Change-Id: I77841a3a0fb68f054941184ee2a8aca0707d2a9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96467 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2020-06-14tdf#131912 sw: fix spell check correct deleting flysMichael Stahl
* SwEditShell::ApplyChangedSentence() should not call DeleteAndJoin() + InsertString() but ReplaceRange() * ReplaceRange() and SwUndoReplace need to set a new flag DelContentType::Replace to tell SwUndoSaveContent::DelContentIndex() not to delete flys but instead record the previous anchor positions * SwUndoReplace::UndoImpl() should also not call DeleteAndJoin() + InsertString(); instead call ReplaceRange() for the start node and then DeleteAndJoin() for any regex "\n" that were inserted (regression from 28b77c89dfcafae82cf2a6d85731b643ff9290e5) Change-Id: I485d79510ae233213cb4b208533871934c5e5ec6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96201 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit e1629c210ad78310e3d48c0756723134a27b89df) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96204 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-06-14tdf#133459 Fix import of fields with user defined number formatsMaxim Monastirsky
commit 59ace23c367f83491a37e844d16f7d716eff6346 ("tdf#101710 Fix invalid style:data-style-name attribute") had a side effect of exporting user defined number formats under <office:styles> instead of under <office:automatic-styles> (which is valid, and what Calc does since forever). As it turned out, this didn't work well for fields: - For fields inside headers or footers, their number format wasn't imported at all. The reason here is that fields use the XMLTextImportHelper::GetDataStyleKey method to resolve data styles, and that method checks only automatic styles. Actually it resolves also styles from <office:styles>, because SvXMLImport::SetAutoStyles has a special code that merges styles from <office:styles> into automatic styles during content.xml reading. The problem is that headers and footers have their contents stored inside styles.xml, and no merging happens at this stage (unless it's a flat odf file). One way to solve this could be to explicitly check for styles from <office:styles> in XMLTextImportHelper::GetDataStyleKey (e.g. see previous gerrit patchsets, or XMLTableStyleContext::GetNumberFormat) I chose to simply modify the condition in SvXMLImport::SetAutoStyles, so that merging happens anyway. - Fields whose format resolution depends on the merging of SvXMLImport::SetAutoStyles, did import the number format itself, but not its language setting. This can be in one of three ways: (a) Fields in the document and the header, when both use the same format. In this case the format is stored once in styles.xml, so at least the consumer from content.xml depends on merging. (b) Field in the document with a user defined format - a regression of the above commit. Now stored in styles.xml under <office:styles> instead of in content.xml under <office:automatic-styles>. (c) Field in a header with a user defined format - depends on merging as a result of the above fix. The reason here is that the merging isn't done with the original SvXMLNumFormatContext objects, but with a newly created fake ones, which only have the format id correct (with the assumption that those formats already imported, and calling code could just find them by the id). The problem is that the fields code uses XMLTextImportHelper::GetDataStyleKey to get the language setting from style objects, and set the IsFixedLanguage property according to it, while we know that those fake objects don't have the language correctly set. Try to fix that problem by setting the correct language on those fake objects. Conflicts: sw/qa/extras/odfimport/odfimport.cxx Change-Id: Ibb362df019921e040708d3bda83bf155535ec7af Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95612 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com> (cherry picked from commit cd0dc1bc592d7952c36659da33d99ab964fe2e93) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96267 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2020-06-12tdf#83309: docx import: allow for lists tabstop at zero positionVasily Melenchuk
Zero position is valid value for tabstop, but previously it was treated as "no tab stop defined". Right now writer distinguishes tab stop at zero postion and no tab stop. Change-Id: Ie32da3d36a263644ba85a882029a8b29ae0501c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95132 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit d2e428d1abb9f2907c0b87d55830e8742f8209b9) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95561 (cherry picked from commit a380a06c1872091e8fa8c810e95a8e1d5dfe1820) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96178
2020-06-12tdf#120394: DOCX list import: simplify zero width space hackVasily Melenchuk
Since introducion of list format string hack with creation of zero-width-space can be much more simple. It was being used to indicate existing, but empty list label suffix to avoid stripping down numbering. Change-Id: I9a0c6047f806b2c656ef5dbab0c6b38200818bd2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94383 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95346
2020-06-11tdf#132754: DOCX import: changed default list start nubmerVasily Melenchuk
Default value for list numbering startAt is zero. If it is not proveded numbering starts from this value. Change-Id: I2cf7be9063e7bfb8b72d6ba77fcd9507e33bb848 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93899 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit f8211e84a5239de25fe6dc45a4bb6b6f8673a1ee) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96048
2020-06-09tdf#133474 DOC import: fix lazy-loading of images with zero sizeMiklos Vajna
DOC typically contains images with a size hint outside the image, but this is optional. Make sure that we load the image in case the size is not available without loading. The effect is that once SwWW8ImplReader::MapWrapIntoFlyFormat() calls SwGrfNode::GetTwipSize(), we always get a valid size. Ideally without loading the graphic. (cherry picked from commit 369355da5c1e25bad7124dd6e187d9e381759751) Change-Id: I81536ceb44c6e455e9bf274a5852008443f9d64f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95907 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-05-29tdf#131684 tdf#132236 sw_redlinehide: fix upper of frame moved...Michael Stahl
... in SwUndoDelete::UndoImpl; this wasn't fixed properly in commit 6c7245e789f973cf6dad03f7008ab3f9d12d350c - the SwTextFrame was moved into the SwSectionFrame but its upper was whatever it was previously. This is rather ugly because with the constraint from the very special case of tdf#131684 the MakeFrames() requires one node with pre-existing frames, and it's not possible to move the pre-existing frame after MakeFrames() because then the tdf#132236 case will have an empty SwSectionFrame and InsertCnt_() will just delete it. So try to detect the situation with some hack in InsertCnt_() to move it into the SwSectionFrame. (regression from 723728cd358693b8f4bc9d913541aa4479f2bd48) Change-Id: Ic0199c85d7523a49676ad3df1d2c4d8fe135c2ff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94881 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 55576842ec72a748d0bad123d41fa03c89fc136d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95023 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-05-29tdf#132236 sw_redlinehide: fix SwUndoDelete with sections even moreMichael Stahl
SwUndoDelete::UndoImpl may want to move something like this into the nodes-array: [ 9] 0x6356fe0 TextNode "", [ 10] 0x31cba00 ~DeletedNode , [ 11] 0x64d8840 TextNode "Introduction - xzn Overview Of KmneqxziTY\t3", [ 12] 0x64e9750 TextNode "shell\t20", [ 13] 0x7a0f0a0 ~DeletedNode , The ~DeletedNode become end nodes of section nodes; in this case m_nSectDiff != 0. Don't skip these end nodes because in the above "Untitled 1.odt" example, they are not necessarily consecutive. Between the 1st and 2nd one a new SwSectionFrame must be created via the outer section, so adapt InsertCnt_() to check for extra end nodes in the range and do this. (regression from 723728cd358693b8f4bc9d913541aa4479f2bd48) Change-Id: I7bfba9efca1789392495ebec37eb3e5b6138bd07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94883 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit ca8e04f1ab739e14288ab5e0be44723536b9ca4e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94963 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-05-29tdf#131684: Add unittestXisco Fauli
Change-Id: Ic59d922700b4046a1ec94be5365b46dc8a021a00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92226 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org> (cherry picked from commit 3ee27693301b50cdebd6a47e35b6621f0ac50cfe) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95022 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-05-28tdf#78352: docx import: allow tab at left indent for listVasily Melenchuk
Looks like first tab stop for list bullets is at left paragraph boundry. Luckely there is a compatibility option for this. Change-Id: Iea4bd2b51912746dbd4722ff61eeb2e9293cab31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94559 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94971
2020-05-26Revert "tdf#104017 DOC export: be less aggressive with merging page styles"Justin Luth
This reverts LO 6.3.4 commit 5d1709a7c4184eb31cfc4c2d3acadff3a4a68189, which tdf#133334 shows is wrong. How this made it past QA is a mystery to me. There should be lots of examples. Change-Id: I17be6e4bab44057f4535d4728825e12d068b65d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94782 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 42a37f8ce27ad8fca222f50b712a8fed52dbda95) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94683
2020-05-23tdf#103602 xmloff,sw: ODF 1.3 import: PageStyle with drawing-page styleMichael Stahl
Associate a style of family "drawing-page" with a style:master-page. This fixes the small part of the draw:fill attribute problem that is covered by OFFICE-3937 in ODF 1.3. This is the import part. Change-Id: I4c86fa24c36407b64ce33f0890e5da8c26c5292a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93670 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 4e98ba4ba5c17ab8ae1170662af645b9d2bfde84) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94587 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-05-19tdf#127778 DOCX import: fix unexpected heading on non-first page ...Miklos Vajna
... when the first page has a heading Regression from commit 17e51f427b3f0cec74ac8e0a1b3f51189006ae6f (DOCX import: first page header should always set default headers as well, 2014-11-21), the problem is around how to split a first + follow page style on import, and then do the opposite on export. This is described using a single section in OOXML, but Writer has 2 page styles for this (unlike in case of the DOC filter). This means the header margin has to be taken from one of these page styles. The above commit tweaked the import, so the follow page style has the wanted header margin, but this leads to incorrect layout. Fix the problem by tweaking the export instead: it has random access to the doc model, so it can take the header margin from the first page style if needed, and then the import side can be reverted, leading to correct layout. Also remove some leftover debug code in test/, which was added in commit 5352d45dd4a04f8f02cf7f6ad4169126d3b3586a (convert AnimationImport to fast-parser APIs, 2020-02-18). (cherry picked from commit 51534ac2b9747975945acb6a1e1ba5cc6d73f5c2) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport6.cxx Change-Id: I4bbf7271f3a437e8432399bd1e32e9d24190a501 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94193 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-05-15tdf#132514 DOCX import: fix lost table style with footerLászló Németh
Table paragraphs collected for table style processing were mixed when both body text and footer contain tables, i.e. clearing paragraph vector at processing the first table resulted missing paragraph vector and table style processing for the other one. (Note: only missing bottom paragraph margin and line spacing were the problems here, not all table style based paragraph settings, as in branch 'master'.) Now tables in footer, also nested tables collect their paragraphs in separated table paragraph vectors. Regression from commit 6c5da2cd7af5c2d90e4d8e9635ba8c9989c87923 (tdf#119054 DOCX: fix not table style based bottom margin). Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93415 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 81ce88aa80f8e7cde4fdc5b211e9500a3599643c) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport6.cxx writerfilter/source/dmapper/DomainMapperTableHandler.cxx writerfilter/source/dmapper/DomainMapperTableManager.cxx writerfilter/source/dmapper/DomainMapper_Impl.cxx writerfilter/source/dmapper/PropertyMap.hxx Change-Id: Ib8568d8379cfb7da869120cdc7fe12895252d661 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93525 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-05-14tdf#132766: DOCX export: always try to set bullet font for listVasily Melenchuk
There are some problems with bullet if we use MS Wingdigs bullets and do not specify Symbol font for it. It shiuld be either UTF-8 or Symbol, but not mixture of both. Change-Id: Ie4a6f7e8fee6cfab21a18fc080f33d1bff455dd9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93846 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94158
2020-05-13tdf#94628: sw: allow setting for bullet for outline paragraphsVasily Melenchuk
Paragraphs in outline (having style "Header XXX") can also be a part of list and have custom bullets. Simplified code of SwXNumberingRules::SetPropertiesToNumFormat(): do not check for properties special for outline/chapters and removed redundant data shuffle with local maps. Change-Id: I1fa7f8f5359acee1d5aa62d9700641490bb91b6c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93672 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94032
2020-05-13tdf#95189: docx import: apply list ovverride only onceVasily Melenchuk
List overrides should be applied only once on first list with override appearance in document. Next reference to this list should not override again and reset list numbering. Change-Id: I7a24398d5980ca97a74fa8ad09d91ac9adff15ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93894 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94031
generated by cgit (git 2.34.1) at 2024-06-16 10:34:42 +0000