summaryrefslogtreecommitdiff
path: root/writerfilter/source/dmapper/DomainMapper_Impl.cxx
AgeCommit message (Collapse)AuthorFilesLines
2023-10-04related tdf#157572 writerfilter framePr: no vAlign if vAnchor=textJustin Luth1-2/+5
See bug 157572 for the documentation. This can be seen in MS Word's UI. Have the vertical position be centered, and then change to "para": -> the vertical position changes to a numbered distance. make CppunitTest_sw_ooxmlexport5 \ CPPUNIT_TEST_NAME=testTdf157572_noVAlignAsText make CppunitTest_sw_ooxmlexport5 \ CPPUNIT_TEST_NAME=testTdf157572_insidiousCombination Change-Id: I6c00a34f14633e16178c1504a37e644a30cf4cd7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157529 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-10-04related tdf#157572 writerfilter framePr: no vAlign if w:y definedJustin Luth1-5/+9
Documentation suggests that vAlign overrides w:y (as long as vAnchor is not equal to text). However, testing proves the opposite. Only when w:y is not defined does vAlign take effect. make CppunitTest_sw_ooxmlexport5 \ CPPUNIT_TEST_NAME=testTdf157572_defaultVAnchor make CppunitTest_sw_ooxmlexport18 \ CPPUNIT_TEST_NAME=testTdf154703_framePr2 Change-Id: I8a5366d9b6bde0ad838f9584836a85fe79ce8b1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157528 Tested-by: Justin Luth <jluth@mail.com> Reviewed-by: Justin Luth <jluth@mail.com>
2023-10-04tdf#157572 tdf#112287 tdf#154129 writerfilter framePr: fix vAnchor defaultJustin Luth1-7/+9
Fixes LO 7.6 regression commit 630732bfd8ed531e9d412a36a083f33763def054 See bug 157572 for the documentation. To test this, I used ooxmlexport5's tdf112287B.docx with Word 2010: -changed vertical relative to Paragraph - exported w:vAnchor="text" -changed vertical relative to Page - exported w:vAnchor="page" -changed vertical relative to Margin - did not export w:vAnchor So, obviously the default is "margin" Note that it always exports w:y=1 For importing, the default vAnchor changed depending on whether w:y=0 (text) or w:y=1 (margin) * an exception is when w:y=0 and vAlign is defined - then 'margin' make CppunitTest_sw_ooxmlexport5 \ CPPUNIT_TEST_NAME=testTdf157572_defaultVAnchor Change-Id: I126094eafc43a83e3a4efdd1ebc8d9cab9d49759 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157527 Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Jenkins
2023-09-25change bool header or footer parameter to use enum type insteadTomaž Vajngerl1-9/+10
Is much more readable. Change-Id: Ie81aaf344758182915796b18efbe25d3f45df4b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157236 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-09-19m_nLastTableCellParagraphDepth is write-onlyNoel Grandin1-2/+0
ever since commit 2d43c34333076fad092f0cdc0f60f81580acdbee Author: Miklos Vajna <vmiklos@collabora.com> Date: Fri Sep 15 13:37:41 2023 +0200 Related: tdf#55160 sw floattable, nested DOCX imp: fix inner tbl at cell start Change-Id: Ifa2837fde41cecdf51ba4858dd52a59d79e4474e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157041 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-08-25Revert "use more Reference::query instead of UNO_QUERY_THROW"Noel Grandin1-1/+5
This reverts commit 7fc6063914432d58d86cfcbd728d967e7c86ebfd. sberg noticed that there is a difference now: there's a subtle difference now, in that if y was null originally, it would have thrown a (caught) exception, whereas now it will crash in the y.query<X>() call. Change-Id: Idbb5a08d635d15b5ca63f4822eddf05fb0a5afa0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156002 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-08-24tdf#77760 sw floattable: add support for footnotes, DOCX importMiklos Vajna1-1/+0
This was originally added in commit 2fe248f2b36d541c0d243a620c217058a50a9d5d (tdf#87460 DOCX import: fix missing endnote in floattable, 2015-06-23), because Writer core only allows footnotes in floating tables since commit 56da1d30afe48cc4acd79567052a575e81f8c7a0 (tdf#77760 sw floattable: add support for footnotes, doc model, 2023-08-22). The DOCX export works already. The ODT filter also works: there is a mechanism to try to not insert footnotes in text frames, but the way XMLTextImportHelper::IsInFrame() is implemented means that it only rejects footnotes directly in text frames, not in tables-in-textframes, which is the interesting case for us. Change-Id: I90a5f0228385b2e3db8d994c6c76064fe595f439 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156024 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-08-18use more Reference::query instead of UNO_QUERY_THROWNoel Grandin1-5/+1
since querying with exceptions is consideably more expensive Change-Id: I968a9a40766b2abb0d3058549b0ed44011fd5716 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155791 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-07-22tdf#149498 sw: fix Undo crash at bookmark over cellsLászló Németh1-2/+3
Importing DOCX files with bookmarks between w:p paragraph elements resulted bookmark ranges over cell boundaries within text tables, causing crash with Undo. Partial revert of commit 9e1e88ad5cf2dc0e9b188c60930445652a6c7519 to avoid bookmark ranges over cell boundaries, creating only collapsed bookmarks here, as before. Regression from commit 9e1e88ad5cf2dc0e9b188c60930445652a6c7519 "tdf#145720 DOCX export: fix loss of tracked moving". Note: to avoid of another assertion, skip testing with debug builds. Change-Id: I3ed6daa55323f20130fcee6cc24d00a480731d0c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154743 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2023-07-21Fix typoAndrea Gelmini1-1/+1
Change-Id: Ied624a73804f99a63b71f9088d6179ad2d93cef6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154564 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-07-17tdf#156030: sw: better import of IF field for RTF and DOCXVasily Melenchuk1-1/+29
Since long time IF field was converted to ConditionalText, but no parameters were given. So condition, then text and else text were lost during import. Change-Id: I9b45e8ab394f3c53bb34370bf3ea15a939a400fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154101 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-07-11tdf#156130: Use default tab stop when TOC*N style doesn't define oneMike Kaganski1-6/+31
When TOC*N style only defines one tab stop, it's used by Word as the page number position, and the tab between chapter number and chapter name is set to a default position. When the style has no tab stops, they are both defaulted. testTdf154319 is updated to test this. Change-Id: I561995a8e96882e1f17ee9982e3fc640e621cda2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154281 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-07-09tdf#153804 DOCX import: fix lost footnotes in case of commentsLászló Németh1-1/+1
Incomplete handling of m_bIsFootnote had a conflict with XNote stream COMMENTS (i.e. not FOOTNOTES and ENDNOTES) since commit 96a856f87f16cca2e039c973c18d57c8b9dca362 in DomainMapper::lcl_checkId(), resulting lost (order or content) of footnotes, when were comments in the document. Regression from commit 96a856f87f16cca2e039c973c18d57c8b9dca362 "tdf#152206 DOCX import: fix mixed first footnote". Change-Id: I8d6901e8db1e183b959fecd350d6a263e79b5591 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154147 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2023-06-24tdf#133560: re-anchor objects, to use paragraph's dispose for bEndOfDocumentMike Kaganski1-66/+103
1. During import, XParagraphAppend::finishParagraph(Insert) are called, which are implemented using SwXText::Impl::finishOrAppendParagraph, and the latter calls m_pDoc->getIDocumentContentOperations().AppendTextNode( *aPam.GetPoint() ); // remove attributes from the previous paragraph m_pDoc->ResetAttrs(aPam); so that there is always another (empty) paragraph after the finalized one; 2. During import, lcl_AddRange is called to create anchored text content; the start and end of it may reference the very end of the document (using xTextAppend->getEnd()) - i.e., that last (maybe empty, maybe extra) paragraph. 3. In many places, and in particular, in DomainMapper_Impl destructor, DomainMapper_Impl::RemoveLastParagraph is called; and the latter uses one of the two techniques to remove that last paragraph: 3.1. It either obtains the paragraph's lang::XComponent interface, and calls its dispose (SwXParagraph::dispose), which eventually calls DocumentContentOperationsManager::DelFullPara; 3.2. Or it uses cursor to select 1 ch back, and replace the resulting selection with nothing. 3.1 has an advantage of keeping the formatting of the remaining (second- to-last) paragraph, but DocumentContentOperationsManager::DelFullPara, among other things, removes all anchored objects, thus this mode is not used for the end-of-document case (e.g., see commit message of commit e521930ea1c855c236efb67793e540d07c201d35 "fdo#58327: writerfilter: RemoveLastParagraph is tricky:", 2013-01-10); 3.2 keeps the anchored objects, but needs workarounds to keep bookmarks, and destroys the remaining paragraph character formatting. Let me try to use #3.1 also in the end-of-document case, by introducing code to move anchored objects to previous paragraph before calling XComponent::dispose. Indeed, it may happen that more processing could be needed, if more properties would happen to be bound to the very last extra paragraph. This change adds a call to DocumentRedlineManager::CompressRedlines in DocumentContentOperationsManager::DelFullPara, because previously, this was called during #3.2 inside setString. testTdf150086 failed without this change. testTdf131386 and testTdf152872 were changed to the now-correct import of last paragraph properties (previously both of them relied on the hidden property not present there, while it is there in Word). In DomainMapper_Impl::RemoveLastParagraph, the check of the content of selection made by moving backward one character was generalized to be run before both cases, because RTF sometimes has only one paragraph after a table (see e.g. testTdf148515), which now could be removed in the absence of the check. testTdf104390 was changed to not check the number of runs, because now the paragraph keeps the trailing "paragraph mark formatting" empty run, which previously was dropped using setString path. Also, the fix for tdf#148273 is re-implemented here, by dropping RES_PARATR_LIST_AUTOFMT in lcl_RstAttr. Likely keeping it was an unintended side effect of placing RES_PARATR_LIST_AUTOFMT inside RES_PARATR_LIST_BEGIN/END. After the change, explicit drop of it will be not needed at arbitrary boundary, which is section break; this property should only be applied where it's defined. This change can't be done separately, because of interrelated unit test failures left and right. In XMLParaContext::endFastElement, setting ListAutoFormat property must be set only after setting style now, because otherwise it will be reset in lcl_RstAttr when the style is set. Some test documents were modified, to drop font from the last paragraph properties, because their respective tests started to crash (see commit 172270a8f04388a8f8062f672f9c3f3144a01a1f "abort writer layout tests if a font isn't found", 2022-05-01). Before this change, these paragraphs had lost their formatting, so those fonts weren't used in layout. Change-Id: I7e41c20e68e24c78fae1d2005c3fd75fb146ba2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153481 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-06-16tdf#155736 replaced m_bStartTOC condition with a method IsInTOC()Satya1-1/+1
Modified IsInTOC() method and refactored usage of m_bStartTOC with IsInTOC() in the previous commit,but m_bStartTOC is still used at one place and now which is replacing with IsInTOC() to maintain consistency. Change-Id: I7fe50770741d68d9db35d74e138417728c2e3dec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153165 Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Justin Luth <jluth@mail.com>
2023-06-15tdf#155736 Modified IsInTOC() to handle IsInHeaderFooter() case.Satya1-6/+15
This fixes a problem of page numbers missing in the footer. The importer might start processing the footer before the TOC has finished - m_bStartTOC might be true. In this case we are not actually IsInTOC,and m_bStartTOC should be ignored and make use of IsInHeaderFooter() and m_bStartTOCHeaderFooter to confirm if the footer/header itself has TOC. Change-Id: Ieede9f8e2120556630ba57b9c748935788f3cc9a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153052 Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Justin Luth <jluth@mail.com>
2023-06-14tdf#155690 writerfilter: fix import of bookmark in table...Michael Stahl1-0/+6
... at start of section. (regression from commit 2e8aad6d45c53d554ccaf26de998ede708cfc289) Change-Id: I1e0e720758b607b69645b29c46f4092264289f9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153053 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-06-13DOCX filter: improve handling of negative <w:position> in paragraph stylesMiklos Vajna1-2/+2
The bugdoc has a <w:position w:val="-1"> in its Normal paragraph style, which is almost not visible in Word, but we mapped this to default subscript text in Writer, leading to very visible bad font height in practice. The root of the problem is that <w:position> works with an absolute offset in half-points, while Writer works in percentages, so the import/export code can only do a correct mapping in case the font size is known. This initial mapping was added in commit e70df84352d3670508a4666c97df44f82c1ce934 (try somewhat harder to read w:position (bnc#773061), 2012-08-07), and later commit d71cf6390a89ea6a4fab724e3a7996f28ca33661 (tdf#99602 writerfilter: import subscript into character style, 2019-10-04) gave up on this for character styles. Fix the problem by working with paragraph styles similar to what the binary DOC filter already does, just assuming that the font height from the style won't be overwritten, or will be overwritten together with a matching <w:position>. Do this only for negative <w:position> for now, as that's good enough for our needs. Do the opposite of this at export time. It would be still possible in the future to add native handling for absolute escapements, and then this mapping would not be needed at all. Change-Id: I771c7bed27fa2596153aa77c472c91b819fa4cb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152962 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-06-01tdf#103869 sw floattable: fix lost table right before a section break from DOCXMiklos Vajna1-0/+8
The bugdoc has 2 pages and 2 tables, one table on each page. The table on the first page was missing in Writer. What happened is that the floating table is anchored in the next paragraph, but that is removed (since it's the last one in the section, so no need for a "next" paragraph), which shifted the table to the next section, which was already a wrong anchor point. Then that next section (next page) started with a (floating) table, so a dummy text node was inserted at the start, which means once it's disposed at the end of the 2nd section, we lost the first floating table with its bad anchor. Fixing the problem was a bit tricky, because DomainMapper_Impl::RemoveLastParagraph() is called before the text frame conversion would be invoked in DomainMapperTableHandler::endTable(), so we can't check if this last paragraph has something anchored in it, as it's too early. Instead, detect that a floating table will be created, and don't remove the last paragraph in this case, since we know that we're at the end of the section (that's why we remove the last paragraph). The export result looks OK, we keep the paragraph-table-paragraph-table-paragraph model correctly. Change-Id: I4612a15d0d1ad3fe527593a21a4120096790a33f (cherry picked from commit ba2f4ebc5343f3eca27baaaf27906be2e6486fcd) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152472 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-05-31tdf#150769 sw floattable: fix lost PageDescName if section starts with a tableMiklos Vajna1-0/+75
The bugdoc has 2 tables in it, separated by a section break (next page). This page break was missing in Writer, so the tables overlapped. The page break was lost because the 2nd section started with a table, where we insert a dummy initial paragraph (to side-step the problem that you can't have a selection starting in a table and finishing outside that table), and once it's disposed, its properties are lost. Fix the problem by copying the PageDescName property from the dummy paragraph to the next paragraph before dispose. Note that we need this combination of creating a range (using gotoNextParagraph()) and then enumerate over the range, because gotoNextParagraph() would skip a leading non-floating table, which would lead to an additional, not wanted page break, as pointed out by CppunitTest_sw_ooxmlexport15's testTdf134649_pageBreak. This went wrong in ce5f82dbaf1c22f45a08c60eb213bc9bc821c1d1 (DOCX import: floating table with negative top margin has to be a fly frame, 2022-01-21), and it turns out to be related to normal floating tables, unrelated to multi-page floating tables. Change-Id: I83245c78c63ec8f3d6015ce3e72ab232220a9fdb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152411 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-05-20loplugin:unusedmethodsNoel Grandin1-8/+0
Change-Id: Ief95f111350808f010539bb733a553007d30a9df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152006 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-12avoid some OUString construction in writerfilter/Noel Grandin1-2/+2
no need to repeatedly construct these Change-Id: Ie271c8adaf1cb558d3174c9f325de524c46e399b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151698 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-08writerfilter: fix crash in DomainMapper_Impl::handleIndex()Miklos Vajna1-1/+4
Crashreport signature: program/libwriterfilterlo.so writerfilter::dmapper::DomainMapper_Impl::handleIndex(tools::SvRef<writerfilter::dmapper::FieldContext> const&, rtl::OUString const&) writerfilter/source/dmapper/DomainMapper_Impl.cxx:6116 program/libwriterfilterlo.so writerfilter::dmapper::DomainMapper_Impl::CloseFieldCommand() include/rtl/ustring.hxx:527 program/libwriterfilterlo.so writerfilter::dmapper::DomainMapper::lcl_text(unsigned char const*, unsigned long) writerfilter/source/dmapper/DomainMapper.cxx:3735 program/libwriterfilterlo.so writerfilter::rtftok::RTFDocumentImpl::singleChar(unsigned char, bool) writerfilter/source/rtftok/rtfdocumentimpl.hxx:718 Change-Id: I4e0f93ce50c8c9a1f9a1a0f9204bd4fee70cdde4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151502 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-05-03tdf#154478 fix comments empy after ToCJaume Pujantell1-10/+7
TOC creation entered a malformed state where it interfered with the creation of other elements (e.g. annotations and textboxes). This change is also a fix to tdf#154481, so the patch from 94de79e7d3c98 can be removed. Change-Id: I423f9d048b8c5b89fd38229c4f3ad41213d5ab67 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151103 Tested-by: Jenkins Reviewed-by: Ashod Nakashian <ash@collabora.com>
2023-04-29Simplify a bitMike Kaganski1-3/+1
Change-Id: Idd17018c0fe452979f699d63f2166ae95241a3b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151129 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-26sw floattable: DOCX import: m_bConvertedTable is now unusedMiklos Vajna1-3/+0
This was added in commit 659c0227a50d298780d72902314e03df8824bc06 (tdf#107889 DOCX import: consider page breaks for multi-page floattables, 2017-05-16), but is no longer used since commit c50bf5a5daaae3d40f89ea0784a75a8a571c208d (sw floattable: remove no longer needed DOCX import heuristics, 2023-04-12). Change-Id: Ieba43e1175ab59c29c0555299facb8fc0e865acf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151067 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-04-21tdf#133363 sw DOCX import: remove extra auto space in mixed listCzeber László Ádám1-1/+4
Remove extra auto space even for mixed list styles. For mixed style lists, it has not removed all the extra space needed. See also commit 9cca15204af9cc44a8a9528ccf2f36616fb70e69 "tdf#133052: DOCX import: fix top auto margin of subitems". Change-Id: I15e58616d5810ea57ac9339bdd8e4b5859f09c81 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150313 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2023-04-16tdf#154703 DOCX {im,ex}port framePr: adjust framesize by para spacingJustin Luth1-2/+29
The specified frame size does not seem to account for left and right paragraph border spacing. At first I assumed it was just RTF, but DOCX needed it as well. This is all VERY nasty. In practice, the paragraph border spacing normally matches the frame's border spacing, but not necessarily. Plus, the user might have interferred. MS Word must know that this is a special kind of frame. LO doesn't. To handle this properly, LO frame UI would need to adjust ALL of the paragraphs' border properties when any changes are made to the frame. For the present, we have to import the frame properly, and export as well as possible. RTF export is losing paragraph borders already, so it has been excluded from consideration. No other unit tests were found that had a significant border spacing. make CppunitTest_sw_ooxmlexport10 CPPUNIT_TEST_NAME=testLibreOfficeHang Change-Id: I03d801ff0ec3c2b93a77761da8ad1f43aeaacf42 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150357 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-04-14tdf#154703 writerfilter framePr: RTF != INVERT_BORDER_SPACINGJustin Luth1-4/+6
Change-Id: I839b187f8e5822fb162255595aeeeac36427cb5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150356 Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Jenkins
2023-04-14tdf#154703 docx export framePr: merge para/frame FormatBoxJustin Luth1-4/+3
Now that export knows about both frame and para border spacing, we can remove an import hack. When exporting the paragraph properties, not only do the direct border settings and the paragraph styles settings apply, but also (uniquely for framePr) do the frame properties. The most significant property is the border spacing. On import only the paragraph keeps the spacing (with the purpose of keeping paragraph shading looking right) and the frames itself has no border spacing. [That is also good, because the frame size is specified as the size without border spacing, and LO does not expand the frame when borders spacing is added.] One exception of course is if the user adds spacing during editing. Another (theoretical) situation comes during an ODT->DOCX export. Fortunately, both of these situations should be handled by just adding the frame and paragraph properties together. It is emulation, but it seems to work pretty good. I modified the unit test from 7.1 commit 49e2bd6103669ca94d4e308fc08beed57f85c7e2 Author: Tibor Nagy on Mon Aug 10 10:51:20 2020 +0200 tdf#131420 DOCX export: fix missing border of frame because we should _not_ have two pBdr entries, just one, non-empty entry. Table import and export are already a mess. See ooxmpexort5's fdo 60957-2.docx for a great example, and tdf104394_lostTextbox.docx is also fascinatingly complex. Change-Id: I011100ee2790de6b8573d6a8bc99b9455f65e76d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150242 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-04-13tdf#154481 sw DOCX import: fix page loss and freezing at ODT exportAttila Bakos (NISZ)1-0/+9
Disable TOC creation in case when field context stack is empty but TOC creation is in progress in textboxes. Before if TOC creation failed because it is already existed, the TOC creation member (mbStartTOC) kept true resulting in broken textbox handling. Textbox and TOC import use the same text append stack but the TOC was not removed from the stack so content have been written into the TOC instead of the textbox, resulting page loss, and because of the broken structure, freezing at further ODT export. Change-Id: If27aa477c49f276d4e538b6e125798d89f0ac423 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150099 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2023-04-13tdf#105035 writerfilter framePr: don't allow overlap in extreme caseJustin Luth1-15/+91
I NEED to do something about preventing overlap because in certain cases MS Word (2010/2016 tested) does not overlap frames even though their vertical placement is identical. The previous commit just fixed mis-combining separate frames into one, but now those frames might overlap each other - which is worse than being combined into one IMHO. Unfortunately, Microsoft's decision to not overlap seems arbirary. In most cases it needs to be allowed, so I have developed a minimal set of specifications that prevent overlap for bug 105035's specific document, and it should be flexible enough to allow other cases to be added. I tested a number of cases when designing my formula. It doesn't seem to prevent overlap for page or margin position. It doesn't seem to prevent overlap when set to top/middle/bottom. It doesn't seem to prevent overlap if the frames are below the first line of text. I still have a problem: the order of the frames might layout wrong - as in this unit test. Sigh. Too bad this code is so ugly and long, but it should be relatively performant. make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf105035_framePrB Change-Id: Iddaf36b9797a38b7906bb980e06cc73da7012eed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150063 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-04-12tdf#105035 tdf#127622 writerfilter framePr: compare using style infoJustin Luth1-58/+68
Prior to this patch, we were only comparing frame definitions based on direct formatting properties. Well, the definition can be spread throughout the paragraph styles, and only if the end result matches will they all be part of one frame. This patch fixes bug 127622 where three different styles all had the same framePr settings. It partially fixes bug 105035 - the frame is split in two - but now the frames overlap. There is no "overlap" tick box in MSO, although they do allow overlap - just not from other framePr text. So this could end up giving me a lot of grief, where two frames joined look OK, but split they will almost inevitably be stuck overtop of each other - like we previously saw in bug 127622. make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf127622_framePr Change-Id: Ie9ce9076d06029b8789a95b46f4ed49190ab09f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150036 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-04-11use more string_view in filterNoel Grandin1-2/+2
Change-Id: Icbccd81fd0fa18fc15a32aa2729b1c5f9a3ee542 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150220 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-04-09tdf#154703 writerfilter framePr: don't duplicate top/bot spacingJustin Luth1-0/+7
With framePr, all of the background/border settings are really just paragraph properties. BETTER would be to zero out the frame spacing and leave it on the paragraph. After all, there could be multiple paragraphs and each could have their own spacing. However, in this case we are getting the whole range as one propertySet, so that basically means it is treated as one. I presume. But the biggest reason for zeroing out the paragraph instead of the frame is because on export only the frame borders are being written out. So that really needs to be fixed first. make CppunitTest_sw_ooxmlexport10 CPPUNIT_TEST_NAME=testLibreOfficeHang Change-Id: I1faeef6bf12668fb28e2b3710053ff545a4c36e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150157 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-04-08tdf#154703 writerfilter framePr: avoid exception with hasValueJustin Luth1-1/+2
I'm assuming that because the range has multiple border definitions in the various paragraphs that the left border was considered undefined. Whatever the reason, a (void) uno::Any as a border was causing the conversion to fail. No matching existing unit tests found. make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf154703_framePr Change-Id: I02fabfd035cad0f2094b023936ff1d33ed7f3fb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150156 Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Jenkins
2023-04-08tdf#154695: use Chapter Numbering Rules to confirm that ToC needs tabsMike Kaganski1-6/+30
Indeed, this still can't handle it per-element, like Word does: the latter would omit both the number and the tab for headings without numbering. But at least the most common case should be handled better now. Change-Id: I0be5d61a5d2cbbf778ee88a11129a6e7655593ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150133 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-05tdf#148906: Ukrainian letters miss in bullets and numbering dialogJulien Nabet1-1/+5
Change-Id: Ieef2b2a7052da342709baf298b618d2c29fa3e43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149768 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-03-30loplugin:stringadd in variousNoel Grandin1-2/+1
when applying my upcoming patch to also consider O[U]StringBuffer Change-Id: I8cf6a47ad357ddc73e2c430d966be72d5efd1485 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149767 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-03-29tdf#124472 DOCX import: fix broken field command by skipping delInstrTextCzeber László Ádám1-1/+10
Process only inserted and not tracked parts of the (partially) tracked field commands to avoid of broken fields, e.g. hyperlinks with bad URLs. For example, instead of the previous bad URL 'https://www.libreoffice.org/"HYPERLINK https://bugs.libreoffice.org/', now the hypertext field of the test document imported with the correct URL 'https://www.libreoffice.org/'. Field commands have change tracking in OOXML, but not in ODF/Writer. OOXML delInstrText, i.e. deleted part of the field commands was imported as part of the actual command, resulting broken fields, e.g. hyperlinks. FieldCommand was splitted into two parts, deleted and non-deleted elements. This way the commands do not get mixed up if the order is changed and no fragmentation of deleted items occurs (otherwise it could fail on the test of tdf#150086). Change-Id: I97d22e5ee1fe647715206f86c4160ebcc4b9cca0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148528 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2023-03-24tdf#154360: use TOC(N) styles in DOCX as the source of ToC tab stop positionMike Kaganski1-26/+49
Change-Id: Iab8001f8be8a8af437e8898079d55ff57dd6fa3b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149494 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-03-23tdf#154319: fix TOC field codes parsingMike Kaganski1-50/+100
Change-Id: I734697f52df14ca5b316481df8a58fef72ab9571 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149254 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-03-21Simplify a bitMike Kaganski1-7/+10
Also takes care of one place where dereferencing wasn't safe Change-Id: I4ed67ad709610bea9cbed8184710f53d18d76d11 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149225 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-03-21tdf#153255 DOCX import: fix footnote orderLászló Németh1-3/+11
Simple unit test for tdf#152203 allowed to create bad ordering algorithm by accident without noticing the problem, which caused problem for most of the DOCX files, where serialization in footnotes.xml doesn't follow the order of the footnotes. Regression from commit 9b39ce0e66acfe812e1d50e530dc2ccdef3e1357 "tdf#76260 DOCX import: fix slow footnote import". Follow-up to commit 09ae3c01940bbc25ffde51963683b04e3cb4bb6a "tdf#152203 DOCX import: fix mixed footnotes/endnotes". Change-Id: I0628d96e3b8ad4df38d26e9288b47d39b958c441 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149176 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2023-03-16cid#1522030 Uninitialized scalar fieldCaolán McNamara1-0/+1
Change-Id: Iaf8ad5edd483da25cad45d91afc27f9cc3aa9040 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149002 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-03-15tdf#154129 tdf#78590 writerfilter framePr: deduplicate grabbagJustin Luth1-8/+4
Well, not really deduplicate, because it only existed once. But I can't imagine why it would depend on a parent style. It was added with commit 1c876f5616522ab695de8c0316cdb0c601081815 Author: Rohit Deshmukh on Fri Jun 13 11:39:56 2014 +0530 fdo#78590: Fix for Corruption of para with framePr & drawing object into para Typically only RTF files don't have a parent style, so the lack of it being there in the "else" clause likely wouldn't have been noticed. Change-Id: I36828863f9bc9b51fbd7c019d3865ac477662795 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148816 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-03-15tdf#154129 writerfilter framePr: deduplicate BackColorTransparencyJustin Luth1-4/+6
Well, not really deduplicate, because it only existed once. Added long ago with commit 4ac48167662c592c21025b89fe8f6925c680c6e0 Author: Miklos Vajna on Mon Feb 20 15:46:08 2012 +0100 n#695479 fix rtf/docx import of transparent frames However, it didn't handle the situation where {\stylesheet{\fs19\lang1033 \snext0 Normal;}} was missing. In that case there is no "Normal" paragraph style to inherit from, and thus his fix is also needed in the no-style case. make CppunitTest_sw_rtfexport3 \ CPPUNIT_TEST_NAME=testTdf154129_transparentFrame Change-Id: Iaa5b92cd626192d44d11c1365b9b483bd46dff9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148815 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-03-15tdf#154129 tdf#97128 writerfilter framePr: deduplicate PopFrameDirectionJustin Luth1-5/+6
Well, not really deduplicate, because it only existed once. But I can't imagine why it would depend on a parent style. Recently added with 7.1 commit af4e5ee0f93c1ff442d08caed5c875f2b2c1fd43 Author: Daniel Arato (NISZ) on Wed Sep 16 08:48:32 2020 +0200 tdf#97128 DOCX import: fix frame direction Typically only RTF files don't have a parent style, so the lack of it being there in the "else" clause likely wouldn't have been noticed. Change-Id: I8e561dcfc5a1dfc6ac1979ad4226b6c5f35800d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148814 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-03-15tdf#154129 tdf#73546 writerfilter framePr: fix/deduplicate w:v/hSpaceJustin Luth1-44/+32
This is not quite a No Functional Change commit. Now, the difference between the two clauses that I am calling deduplicated is rather severe in this case. But that seems to be because only one half was fixed with 4.3 commit 896714db527f39497aedee8946964e5acd73778c Author: umeshkadam on Fri Jan 17 19:00:29 2014 +0530 fdo#73546 : faulty value of attribute value in <wp:anchor> tag So I expect that the "else" side is simply wrong. That side is generally only hit by RTF formatted files (or docx that are basically missing styles.xml). Change-Id: Id0fd4f4807c38f281d2fbf8f805a49d6ae9acc0d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148813 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-03-15NFC tdf#154129 writerfilter framePr: deduplicate lcl.. callJustin Luth1-8/+4
Change-Id: Iedaea9d6d6f344ebd66bf83d1a9ee243cae5875b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148812 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-20 15:59:41 +0000