summaryrefslogtreecommitdiff
path: root/writerfilter/source/dmapper
AgeCommit message (Collapse)AuthorFilesLines
2024-01-21writerfilter : use constexpr frozen unordered_set instead of std::unordered_setArnaud VERSINI1-7/+10
Change-Id: I37b4b5ec56f846b5c46faeaa5aebb88340ac3c6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161385 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-01-19tdf#159254 import paper bin/paper source from rtf/docx filesOliver Specht7-2/+78
Imports \binfsxn and \binsxn from RTF and w:paperSrc from docx files and applies paper tray to the page style if the printer supports the imported tray value. Works only on Windows. Change-Id: Ie1170c58f7114f0dbf6bdd2721d4e077886cbe16 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162236 Tested-by: Jenkins Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-01-19tdf#159158 DOCX import: relativeHeights of 0/1 are highest zOrder #2Justin Luth1-3/+4
I thought I had removed all fallback stuff from the unit tests, but I was wrong. So do some general clean-up and simplification. I also needed to fix the maximum value for relativeHeight. Sadly, even my my unit test was wrong - since MS Word 2010 clearly showed the yellow star on the top for tdf159158_zOrder_max.docx. FIXED. I can't put my finger on why sometimes 0F00 0000 is a maximum... More testing suggests that generally the max is 01dff ffff. Again, this is based on testing since documentation makes no reference at all to a maximum. I also wonder if the last 10 bits aren't magical somehow... The previous max didn't sound right because there are so many unit tests with relativeHeights above 0F00 0000 (and the values jump by 0400). RTF almost never uses GraphicImport, and no unit tests access relativeHeight, only behindDoc. It is used for IMPORT_AS_DETECTED_INLINE and passing arbitrary property-names and values to a shape (via \sp \sv). Thus, this change is DOCX only (effectively). Change-Id: I18c0e129a078abe5987b998b15697f4ae1a50a96 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162232 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-01-18Related: tdf#159259 Drop obsolete exclusion of framePr inside sdtMike Kaganski1-2/+0
Commit 73bd937420b9a99e1e35950e3f9dcbcfd874876d (n#780853 fix DOCX import of w:sdtContent in table cell, 2012-09-25) had introduced a restriction, where a framePr was ignored, when inside an sdt. It was required to allow table import, which broke otherwise. Since then, the situation has obviously changed; the test case for the change, added in commit 7ea71eb8a28c4b41949299ff7d4b391486c90eea (n#780853 testcase, 2012-09-25) passes after removal of the check. This check disallows importing sdt in frame. This makes the bugdoc of tdf#159259 to import the sdt in frame. The Lorem Ipsum paragraph is still enclosed into the sdt - to be fixed in a follow-up. Change-Id: I60fbb2dd6f753682217d86e4f8d315f1883c6e83 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162258 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-17tdf#135083: make sure to apply pending paragraph properties, even withoutMike Kaganski2-2/+5
... trailing \par. Commit a6ae84cc296d4d28e9a48a57406e955138c87a80 (tdf#70318: Prevent extra empty paragraph in clipboard RTF content, 2015-11-10) made sure to not emit trailing \par for RTF clipboard content. The problem was, that in the absense of the \par, the settings of the last paragraph were not applied (this happens in DomainMapper_Impl::finishParagraph). This change makes sure to call dispatchSymbol(RTFKeyword::PAR) (which eventually calls the mentioned method and applies pending para properties). Since this also adds a new paragraph (which needs to be avoided), a new flag is introduced, set by Stream::markLastParagraph. Its purpose is to make sure that all properties are applied to para, as opposed to bRemove argument to DomainMapper::finishParagraph, which prevents setting some properties (e.g., related to numbering - see DomainMapper::lcl_utext). Change-Id: Ia5e368e540c30f95058c81a280a62205aa85398b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162154 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-16Fix typoAndrea Gelmini1-1/+1
Change-Id: I352ca1bfee42b3dfe49401a4c75fbbb2140d28da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160204 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-01-16tdf#159158 writerfilter: relativeHeights of 0/1 are highest zOrderJustin Luth1-2/+6
Apparently 0 and 1 are the highest zOrders, 2 is the lowest, then 3... At least, this seems to be true for relativeHeight. Of course the documentation doesn't say anything about this, but documents conclusively prove a maximum zOrder of 251,658,240. [When MS Word 2019 round-trips a file with a relativeHeight of 0/1, it replaces them with the highest relativeHeight in the document, but values of 2+ are preserved.] Notice that there are two things that feed into zOrder, the other being z-index where negatives have special meaning in this context, but no special meaning for 0 or 1. Interestingly, relativeHeight is unsigned, but z-index is signed. This ends up not being a problem with a maximum of 0F00 0000. GOOD! LO normally exports starting from 2, but writes 0 if no zOrder. // It seems 0 and 1 have special meaning: // just start counting from 2 to avoid issues with that. Proof case that 0 is higher than both 300 and 225,763,766 make CppunitTest_sw_ooxmlexport8 CPPUNIT_TEST_NAME=testN747461 make CppunitTest_sw_ooxmlexport18 \ CPPUNIT_TEST_NAME=testTdf159158_zOrder_1and0equalA make CppunitTest_sw_ooxmlexport18 \ CPPUNIT_TEST_NAME=testTdf159158_zOrder_1and0equalB make CppunitTest_sw_ooxmlexport18 \ CPPUNIT_TEST_NAME=testTdf159158_zOrder_1and0max Change-Id: I3540252ca5b0be3b2d847f1a3885adb850f39c39 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162038 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-01-16tdf#159158 writerfilter: duplicate relativeHeights? last one wins #2Justin Luth1-10/+5
Revert the previous solution and replace it with this simpler one. This version of the patch is riskier, but from what I can see last one always wins for GraphicImport. I assume that Miklos just limited it to a certain situation as a sanity check to try to avoid causing regressions outside of the scope he was working on. The fact that all DOCX and RTF unit tests pass is a good sign. The only way I would expect this to cause problems is if z-index somehow can come into play with a GraphicImport (since both z-index and relativeHeight feed into zOrder). However, an assert didn't turn up any instances where applyZOrder was called without a relativeHeight being set. assert(m_rDomainMapper.IsRTFImport() || bOldStyle || UsedRelativeHeight); Change-Id: I28e8acd5997eed0e82d5853c85b672c62b21afe5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162036 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-01-16tdf#159158 writerfilter: duplicate relativeHeights? last one winsJustin Luth2-1/+15
[When MS Word 2019 round-trips a file with a duplicate relativeHeight it replaces them with unique relativeHeights in the export.] My THEORY is that bOldStyle should always be true for GraphicImport, so a follow-up commit will basically revert all of this, but at least if my theory is wrong, I'll still have fixed this problem. Notice that there are two things that feed into zOrder, the other being z-Index. I assume the very explicit code that says that (except for bOldStyle) first one wins must be the standard for z-Index. make CppunitTest_sw_ooxmlexport18 \ CPPUNIT_TEST_NAME=testTdf159158_zOrder_duplicate Change-Id: I842d016a7922427ce1290a7134d4e19fed52880f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161989 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-01-13cid#1546354 COPY_INSTEAD_OF_MOVECaolán McNamara1-2/+3
and cid#1546319 COPY_INSTEAD_OF_MOVE cid#1546286 COPY_INSTEAD_OF_MOVE cid#1546283 COPY_INSTEAD_OF_MOVE cid#1546191 COPY_INSTEAD_OF_MOVE cid#1545953 COPY_INSTEAD_OF_MOVE cid#1545874 COPY_INSTEAD_OF_MOVE cid#1545857 COPY_INSTEAD_OF_MOVE cid#1545781 COPY_INSTEAD_OF_MOVE cid#1545765 COPY_INSTEAD_OF_MOVE cid#1545546 COPY_INSTEAD_OF_MOVE cid#1545338 COPY_INSTEAD_OF_MOVE cid#1545190 COPY_INSTEAD_OF_MOVE cid#1545272 COPY_INSTEAD_OF_MOVE cid#1545242 COPY_INSTEAD_OF_MOVE cid#1545229 COPY_INSTEAD_OF_MOVE Change-Id: I88813d9dbd87ce10375db8198028f8b70e23f0fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162027 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-13tdf#139915 tdf#159157 writerfilter: fix image position with TEXT_LINEJustin Luth1-0/+7
This is an IMAGE followup to vmiklos' shape/textbox fix in LO 7.2 commit 2f21e4f357ec60450df84ddd858c3cf0a4711b02 Images follow a different code path, but needed the same treatment. Change-Id: I974944c7fbb4e0fa6aa52ac239c6a16ec7f927e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161986 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2024-01-03tdf#158971: Only copy directly-set propertiesMike Kaganski1-14/+22
Commit f09420fa189be5165b0311083ba127073500a121 (tdf#158855: Make sure to not add extra paragraph after a table in a section, 2023-12-25) had implemented copying all attributes of a paragraph using copyAllProps. But the function didn't check the states of properties, so copied also default values of properties, making them direct properties of the paragraph. Due to tdf#158972, that caused an assertion when saving, and the main problem was a set of direct properties in the paragraph. Fix that by checking the properties states. Also make sure to work with paragraphs, rather than with ranges, which treats any properties set on paragraph level as default-state on the run level. Change-Id: I7cd9c7fbb9313d666c46be201913f0223a6b4f5e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161539 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-12-30drop some IsFuzzing spam we don't needCaolán McNamara1-2/+1
Change-Id: I1da86b0be73713b506044c969930912b58b4d514 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161435 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-30move IsFuzzing to comphelperCaolán McNamara1-2/+2
and try something a bit more generic Change-Id: I1d8256576cd02f0a589df350ba7b53059dd586a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161250 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-29Use emplace_back instead of push_back (writerfilter)Julien Nabet2-5/+5
Change-Id: Ic09353c1c99265c789edb745044b0afe7dffbee6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161404 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-29Fix typoAndrea Gelmini1-1/+1
Change-Id: Ie63bad4bd2ab19ed1557ffc8648500c1183692e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160203 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2023-12-29tdf#157638 Removed old commentsDeclan Fodor1-47/+47
Certain numerical comments in GraphicImport contained debugging information that is no longer relevant to the current code. These have been removed. Change-Id: I931cd8dae6d1e449211d78eedd5422994b8c4423 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161232 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2023-12-25tdf#158855: Make sure to not add extra paragraph after a table in a sectionMike Kaganski3-51/+102
Simplify the condition for last paragraph removal in lcl_utext, and clean up the complications piled after commit 2e8aad6d45c53d554ccaf26de998ede708cfc289 (fdo#39056 fdo#75431 Section Properties if section starts with table, 2014-04-24). This makes sure that the trailing extra paragraph gets properly removed, even when there was a dummy paragraph added for a table in section. Because of the removed check, import used to avoid the removal of the extra paragraph immediately following a table (when the table needed to be the last element in the section); hence, in DomainMapper_Impl::appendTextSectionAfter, a last section's table was followed by two paragraphs (one that is expected to stay after the created section, and one before that, that was not removed after the table). xCursor had ininitally both paragraphs in the selection after the forward goto* calls; and then, gotoLeft excluded only the last paragraph from the selection. After the change, in such a case, there is only one paragraph in the end: the one that should stay after the created section. But calling gotoLeft then would have to put the end of selection to a text node inside the table; since the selection that starts before the table can't end inside the table, the call resulted in the whole table excluded from the selection. This requires to add a paragraph here, to allow the previous behavior of cursor; and then the last paragraph in section is destroyed. The code makes sure that the trailing paragraph kept after the creation of the section has all the properties applied to the old last paragraph. testFdo53985 used to check for total 9 paragraphs in the document; while 3 of those were introduced exactly by the bug fixed here; they are absent in Word. The test is fixed; its logic is unchanged, and it still correctly tests that a round-trip doesn't increase number of paragraphs. Change-Id: Ibf6349ba7906dac185c759eb3b58c1849ee5064a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161275 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-12-23cid#1546006 COPY_INSTEAD_OF_MOVECaolán McNamara13-13/+13
and cid#1545999 COPY_INSTEAD_OF_MOVE cid#1545995 COPY_INSTEAD_OF_MOVE cid#1545994 COPY_INSTEAD_OF_MOVE cid#1545989 COPY_INSTEAD_OF_MOVE cid#1545982 COPY_INSTEAD_OF_MOVE cid#1545977 COPY_INSTEAD_OF_MOVE cid#1545970 COPY_INSTEAD_OF_MOVE cid#1545856 COPY_INSTEAD_OF_MOVE cid#1545845 COPY_INSTEAD_OF_MOVE cid#1545838 COPY_INSTEAD_OF_MOVE cid#1545776 COPY_INSTEAD_OF_MOVE cid#1545774 COPY_INSTEAD_OF_MOVE cid#1545744 COPY_INSTEAD_OF_MOVE cid#1545719 COPY_INSTEAD_OF_MOVE cid#1545716 COPY_INSTEAD_OF_MOVE cid#1545687 COPY_INSTEAD_OF_MOVE cid#1545648 COPY_INSTEAD_OF_MOVE cid#1545643 COPY_INSTEAD_OF_MOVE cid#1545641 COPY_INSTEAD_OF_MOVE cid#1545604 COPY_INSTEAD_OF_MOVE cid#1545531 COPY_INSTEAD_OF_MOVE cid#1545530 COPY_INSTEAD_OF_MOVE cid#1545524 COPY_INSTEAD_OF_MOVE cid#1545516 COPY_INSTEAD_OF_MOVE cid#1545501 COPY_INSTEAD_OF_MOVE cid#1545486 COPY_INSTEAD_OF_MOVE Change-Id: Idcf3e27bb9e81b6a77d5ef75c9376eb1d6aff8c9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161245 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-22cid#1546500 COPY_INSTEAD_OF_MOVECaolán McNamara2-6/+6
and cid#1546492 COPY_INSTEAD_OF_MOVE cid#1546468 COPY_INSTEAD_OF_MOVE cid#1546431 COPY_INSTEAD_OF_MOVE cid#1546382 COPY_INSTEAD_OF_MOVE cid#1546350 COPY_INSTEAD_OF_MOVE cid#1546336 COPY_INSTEAD_OF_MOVE cid#1546314 COPY_INSTEAD_OF_MOVE cid#1546152 COPY_INSTEAD_OF_MOVE cid#1546094 COPY_INSTEAD_OF_MOVE cid#1546077 COPY_INSTEAD_OF_MOVE cid#1546047 COPY_INSTEAD_OF_MOVE cid#1545213 COPY_INSTEAD_OF_MOVE Change-Id: Ia51df9f9cbde755db4d2685e34f22676ed5eceff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161141 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-20tdf#158762 RTF writerfilter: fix list importOliver Specht1-0/+1
While importing the properties NumberingRules and NumberingStyleName interfere with each other. Avoid overwriting NumberingRules with an invalid NumberingStyleName. Regression from 588ff9a228f4894142264c68392ed1e9800a4d7d Change-Id: I706ea514da43faae0fdb9a2c0d4f5b1928ef55f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160967 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-12-19tdf#158044 writerfilter: handle toggle properties in import/exportOliver Specht2-1/+163
DOCX has some odd properties (bold, italic, shadowed, hidden ...), which switch on/off if they are applied multiple times, e.g. with paragraph and character styles. To fix that, a hard attribute has to switch off the attribute in that occasion on import and on export a hard attribute switches it on in Word. Includes partial fix for tdf#154370. Change-Id: Ie4c317cf9b7d02efd89b9d6a9996143585d7e937 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160343 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-12-16cid#1545970 COPY_INSTEAD_OF_MOVECaolán McNamara1-3/+3
and cid#1545957 COPY_INSTEAD_OF_MOVE cid#1545944 COPY_INSTEAD_OF_MOVE cid#1545939 COPY_INSTEAD_OF_MOVE cid#1545931 COPY_INSTEAD_OF_MOVE cid#1545926 COPY_INSTEAD_OF_MOVE cid#1545909 COPY_INSTEAD_OF_MOVE cid#1545899 COPY_INSTEAD_OF_MOVE cid#1545896 COPY_INSTEAD_OF_MOVE cid#1545894 COPY_INSTEAD_OF_MOVE cid#1545858 COPY_INSTEAD_OF_MOVE cid#1545823 COPY_INSTEAD_OF_MOVE cid#1545820 COPY_INSTEAD_OF_MOVE cid#1545819 COPY_INSTEAD_OF_MOVE cid#1545772 COPY_INSTEAD_OF_MOVE cid#1545749 COPY_INSTEAD_OF_MOVE cid#1545743 COPY_INSTEAD_OF_MOVE cid#1545739 COPY_INSTEAD_OF_MOVE cid#1545635 COPY_INSTEAD_OF_MOVE cid#1545603 COPY_INSTEAD_OF_MOVE cid#1545602 COPY_INSTEAD_OF_MOVE cid#1545592 COPY_INSTEAD_OF_MOVE cid#1545544 COPY_INSTEAD_OF_MOVE cid#1545532 COPY_INSTEAD_OF_MOVE cid#1545520 COPY_INSTEAD_OF_MOVE cid#1545512 COPY_INSTEAD_OF_MOVE cid#1545490 COPY_INSTEAD_OF_MOVE cid#1545483 COPY_INSTEAD_OF_MOVE cid#1545467 COPY_INSTEAD_OF_MOVE cid#1545461 COPY_INSTEAD_OF_MOVE cid#1545458 COPY_INSTEAD_OF_MOVE cid#1545428 COPY_INSTEAD_OF_MOVE cid#1545394 COPY_INSTEAD_OF_MOVE cid#1545385 COPY_INSTEAD_OF_MOVE cid#1545383 COPY_INSTEAD_OF_MOVE cid#1545366 COPY_INSTEAD_OF_MOVE cid#1545357 COPY_INSTEAD_OF_MOVE Change-Id: I76224326977b4067b94ca3176cad1ca6de17930a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160847 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-15tdf#158556: provide objects anchored to node as a hidden propertyMike Kaganski1-25/+54
This introduces a hidden property of SwXParagraph, named OOXMLImport_AnchoredShapes. Testing on my system, starting the main process first, then launching another one like time soffice path/to/bugdoc.docx ... so that it only measures time spent in import, gave the following figures: LibreOffice 7.5.0.3 (TDF build): real 1m49.016s user 0m0.000s sys 0m0.000s LibreOffice 7.6.0.3 (TDF build): real 8m37.386s user 0m0.000s sys 0m0.000s Current master (my no-debug build): real 10m6.776s user 0m0.000s sys 0m0.000s Current master with this patch (my no-debug build): real 5m41.524s user 0m0.000s sys 0m0.015s Indeed, it is not as fast as it used to be; and the fix doesn't really remove the quadratic complexity, just uses faster iteration. If there is a way to directly list objects anchored to a given paragraph, rather than iterating over all objects checking their anchors, that would get much faster, but that would be a rather large change. Change-Id: Ie50515815e85fdce498d065185199c9b31d95794 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160813 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-12-14cid#1545211 COPY_INSTEAD_OF_MOVECaolán McNamara7-28/+21
and cid#1545218 COPY_INSTEAD_OF_MOVE cid#1545232 COPY_INSTEAD_OF_MOVE cid#1545243 COPY_INSTEAD_OF_MOVE cid#1545246 COPY_INSTEAD_OF_MOVE cid#1545251 COPY_INSTEAD_OF_MOVE cid#1545260 COPY_INSTEAD_OF_MOVE cid#1545261 COPY_INSTEAD_OF_MOVE cid#1545276 COPY_INSTEAD_OF_MOVE cid#1545295 COPY_INSTEAD_OF_MOVE cid#1545297 COPY_INSTEAD_OF_MOVE cid#1545301 COPY_INSTEAD_OF_MOVE cid#1545302 COPY_INSTEAD_OF_MOVE Change-Id: I97ba935a4a2b8715b55ebbf6e853a66260b2eb90 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160686 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-14cid#1545734 COPY_INSTEAD_OF_MOVECaolán McNamara4-7/+6
and cid#1545723 COPY_INSTEAD_OF_MOVE cid#1545708 COPY_INSTEAD_OF_MOVE cid#1545705 COPY_INSTEAD_OF_MOVE cid#1545684 COPY_INSTEAD_OF_MOVE cid#1545674 COPY_INSTEAD_OF_MOVE cid#1545673 COPY_INSTEAD_OF_MOVE cid#1545667 COPY_INSTEAD_OF_MOVE cid#1545661 COPY_INSTEAD_OF_MOVE cid#1545660 COPY_INSTEAD_OF_MOVE cid#1545657 COPY_INSTEAD_OF_MOVE cid#1545653 COPY_INSTEAD_OF_MOVE cid#1545636 COPY_INSTEAD_OF_MOVE cid#1545624 COPY_INSTEAD_OF_MOVE cid#1546124 COPY_INSTEAD_OF_MOVE Change-Id: I7d50594e046a022147d9ddf077b8b2d8027f9bca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160721 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-14tdf#158681 Revert "tdf#153613 writerfilter: don't always split paraJustin Luth1-8/+8
... for shape w/ pagebreak" This reverts 7.6 commit a9bc19c2d4a35606668aa2dcc53355651b71ee78. The commit in general is probably fine. However, it fails in case of an empty paragraph (with only anchors). Unfortunately, there is no way of knowing ahead of time, so either everything needs to be processed after a delay, or else the paragraph needs to be split and then re-joined in case it is not an empty paragraph. Both options are extremely non-trivial - I don't know how to do either of them. In this case it is also the last paragraph in the document, again something not known during import and which has special-casing in MSO. make CppunitTest_sw_ooxmlexport18 \ CPPUNIT_TEST_NAME=testTdf153613_textboxAfterPgBreak3 Change-Id: I4471e216b6523032b85178d85795434694cc1e22 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160720 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-12-11cid#1545577 COPY_INSTEAD_OF_MOVECaolán McNamara2-2/+2
and cid#1545679 COPY_INSTEAD_OF_MOVE cid#1545691 COPY_INSTEAD_OF_MOVE cid#1545697 COPY_INSTEAD_OF_MOVE cid#1545711 COPY_INSTEAD_OF_MOVE cid#1545730 COPY_INSTEAD_OF_MOVE Change-Id: Ic0777a8ba532b00b021ffed81243505fbb7250f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160568 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-10cid#1545789 COPY_INSTEAD_OF_MOVECaolán McNamara2-5/+3
and cid#1545791 COPY_INSTEAD_OF_MOVE cid#1545800 COPY_INSTEAD_OF_MOVE cid#1545806 COPY_INSTEAD_OF_MOVE cid#1545817 COPY_INSTEAD_OF_MOVE cid#1545832 COPY_INSTEAD_OF_MOVE cid#1545834 COPY_INSTEAD_OF_MOVE cid#1545841 COPY_INSTEAD_OF_MOVE cid#1545848 COPY_INSTEAD_OF_MOVE cid#1545852 COPY_INSTEAD_OF_MOVE cid#1545854 COPY_INSTEAD_OF_MOVE cid#1545864 COPY_INSTEAD_OF_MOVE cid#1545875 COPY_INSTEAD_OF_MOVE cid#1545882 COPY_INSTEAD_OF_MOVE cid#1545900 COPY_INSTEAD_OF_MOVE cid#1545901 COPY_INSTEAD_OF_MOVE cid#1545908 COPY_INSTEAD_OF_MOVE cid#1545921 COPY_INSTEAD_OF_MOVE cid#1546054 COPY_INSTEAD_OF_MOVE cid#1546145 COPY_INSTEAD_OF_MOVE cid#1546146 COPY_INSTEAD_OF_MOVE Change-Id: I8b23d0457cb293aa0e33593131224c1cdd1d8eb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160545 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-10cid#1545177 COPY_INSTEAD_OF_MOVECaolán McNamara1-2/+1
and cid#1545179 COPY_INSTEAD_OF_MOVE cid#1545187 COPY_INSTEAD_OF_MOVE cid#1545188 COPY_INSTEAD_OF_MOVE cid#1545189 COPY_INSTEAD_OF_MOVE cid#1545196 COPY_INSTEAD_OF_MOVE cid#1545197 COPY_INSTEAD_OF_MOVE cid#1545204 COPY_INSTEAD_OF_MOVE cid#1545223 COPY_INSTEAD_OF_MOVE cid#1545236 COPY_INSTEAD_OF_MOVE cid#1545239 COPY_INSTEAD_OF_MOVE cid#1545253 COPY_INSTEAD_OF_MOVE cid#1545274 COPY_INSTEAD_OF_MOVE cid#1545286 COPY_INSTEAD_OF_MOVE cid#1545309 COPY_INSTEAD_OF_MOVE cid#1545311 COPY_INSTEAD_OF_MOVE cid#1545345 COPY_INSTEAD_OF_MOVE cid#1545358 COPY_INSTEAD_OF_MOVE cid#1545361 COPY_INSTEAD_OF_MOVE cid#1545365 COPY_INSTEAD_OF_MOVE cid#1545367 COPY_INSTEAD_OF_MOVE cid#1545372 COPY_INSTEAD_OF_MOVE cid#1545373 COPY_INSTEAD_OF_MOVE cid#1545377 COPY_INSTEAD_OF_MOVE cid#1545392 COPY_INSTEAD_OF_MOVE cid#1545399 COPY_INSTEAD_OF_MOVE cid#1545404 COPY_INSTEAD_OF_MOVE cid#1545408 COPY_INSTEAD_OF_MOVE cid#1545430 COPY_INSTEAD_OF_MOVE cid#1545439 COPY_INSTEAD_OF_MOVE cid#1545449 COPY_INSTEAD_OF_MOVE Change-Id: I3afe836a0bbc8bd70937035e60eb020435e413d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160539 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-10cid#1546281 COPY_INSTEAD_OF_MOVECaolán McNamara2-3/+2
and cid#1546278 COPY_INSTEAD_OF_MOVE cid#1546276 COPY_INSTEAD_OF_MOVE cid#1546247 COPY_INSTEAD_OF_MOVE cid#1546244 COPY_INSTEAD_OF_MOVE cid#1546243 COPY_INSTEAD_OF_MOVE cid#1546220 COPY_INSTEAD_OF_MOVE cid#1546209 COPY_INSTEAD_OF_MOVE cid#1546207 COPY_INSTEAD_OF_MOVE cid#1546206 COPY_INSTEAD_OF_MOVE cid#1546205 COPY_INSTEAD_OF_MOVE cid#1546197 COPY_INSTEAD_OF_MOVE cid#1546180 COPY_INSTEAD_OF_MOVE cid#1546172 COPY_INSTEAD_OF_MOVE cid#1546165 COPY_INSTEAD_OF_MOVE cid#1546164 COPY_INSTEAD_OF_MOVE cid#1546158 COPY_INSTEAD_OF_MOVE cid#1546151 COPY_INSTEAD_OF_MOVE cid#1546135 COPY_INSTEAD_OF_MOVE cid#1546132 COPY_INSTEAD_OF_MOVE cid#1546129 COPY_INSTEAD_OF_MOVE cid#1546128 COPY_INSTEAD_OF_MOVE cid#1546122 COPY_INSTEAD_OF_MOVE cid#1546117 COPY_INSTEAD_OF_MOVE cid#1546113 COPY_INSTEAD_OF_MOVE cid#1546106 COPY_INSTEAD_OF_MOVE cid#1546099 COPY_INSTEAD_OF_MOVE cid#1546091 COPY_INSTEAD_OF_MOVE cid#1546085 COPY_INSTEAD_OF_MOVE cid#1546069 COPY_INSTEAD_OF_MOVE cid#1546063 COPY_INSTEAD_OF_MOVE cid#1546062 COPY_INSTEAD_OF_MOVE cid#1546058 COPY_INSTEAD_OF_MOVE cid#1546056 COPY_INSTEAD_OF_MOVE cid#1546051 COPY_INSTEAD_OF_MOVE cid#1546040 COPY_INSTEAD_OF_MOVE cid#1546030 COPY_INSTEAD_OF_MOVE cid#1546028 COPY_INSTEAD_OF_MOVE cid#1546015 COPY_INSTEAD_OF_MOVE cid#1546001 COPY_INSTEAD_OF_MOVE Change-Id: Ib954c92a300fc323b29f27880fdf8bc46ed98862 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160520 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-09cid#1556778 COPY_INSTEAD_OF_MOVECaolán McNamara1-1/+1
and cid#1546474 COPY_INSTEAD_OF_MOVE cid#1546473 COPY_INSTEAD_OF_MOVE cid#1546469 COPY_INSTEAD_OF_MOVE cid#1546467 COPY_INSTEAD_OF_MOVE cid#1546458 COPY_INSTEAD_OF_MOVE cid#1546448 COPY_INSTEAD_OF_MOVE cid#1546446 COPY_INSTEAD_OF_MOVE cid#1546441 COPY_INSTEAD_OF_MOVE cid#1546424 COPY_INSTEAD_OF_MOVE cid#1546377 COPY_INSTEAD_OF_MOVE cid#1546374 COPY_INSTEAD_OF_MOVE cid#1546352 COPY_INSTEAD_OF_MOVE cid#1546334 COPY_INSTEAD_OF_MOVE cid#1546328 COPY_INSTEAD_OF_MOVE cid#1546310 COPY_INSTEAD_OF_MOVE cid#1546303 COPY_INSTEAD_OF_MOVE Change-Id: I8a43fdd574857ba1d3ec416f23c8269a9a08e12f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160515 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-08cid#1545617 COPY_INSTEAD_OF_MOVECaolán McNamara1-2/+1
and cid#1545748 COPY_INSTEAD_OF_MOVE cid#1545741 COPY_INSTEAD_OF_MOVE cid#1545698 COPY_INSTEAD_OF_MOVE cid#1545594 COPY_INSTEAD_OF_MOVE cid#1545588 COPY_INSTEAD_OF_MOVE cid#1545558 COPY_INSTEAD_OF_MOVE cid#1545545 COPY_INSTEAD_OF_MOVE Change-Id: I5dfec77a68959b9384fc71a2fc0908c5d1b42869 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160448 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-08cid#1546472 COPY_INSTEAD_OF_MOVECaolán McNamara1-2/+2
and cid#1546459 COPY_INSTEAD_OF_MOVE cid#1546452 COPY_INSTEAD_OF_MOVE cid#1546403 COPY_INSTEAD_OF_MOVE cid#1546396 COPY_INSTEAD_OF_MOVE cid#1546394 COPY_INSTEAD_OF_MOVE cid#1546338 COPY_INSTEAD_OF_MOVE cid#1546324 COPY_INSTEAD_OF_MOVE Change-Id: If61457cfaf1d7ce4a069bcecdc0cc657aeb43c68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160445 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-08cid#1546501 COPY_INSTEAD_OF_MOVECaolán McNamara1-2/+2
and cid#1546486 COPY_INSTEAD_OF_MOVE cid#1546485 COPY_INSTEAD_OF_MOVE cid#1546484 COPY_INSTEAD_OF_MOVE cid#1546482 COPY_INSTEAD_OF_MOVE Change-Id: I53cc622f16afc0f57ffd72e3e0a6f18e390fbb83 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160443 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-05writerfilter: fix crash in DomainMapper_Impl::PushSdt()Miklos Vajna1-1/+12
Crashreport signature: Fatal signal received: SIGSEGV code: 1 for address: 0x0 program/libwriterfilterlo.so writerfilter::dmapper::DomainMapper_Impl::PushSdt() writerfilter/source/dmapper/DomainMapper_Impl.cxx:987 program/libwriterfilterlo.so writerfilter::dmapper::DomainMapper::lcl_attribute(unsigned int, writerfilter::Value&) include/tools/ref.hxx:56 program/libwriterfilterlo.so writerfilter::ooxml::OOXMLProperty::resolve(writerfilter::Properties&) include/tools/ref.hxx:56 program/libwriterfilterlo.so writerfilter::ooxml::OOXMLPropertySet::resolve(writerfilter::Properties&) include/tools/ref.hxx:157 Change-Id: I76416ca707a4ac40495e5c22f62fcd017bcb5e48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160336 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit 728f6ec104b1a91c8c8ea0790bc7f56471c67737) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160351 Tested-by: Jenkins
2023-12-05tdf#108505 writerfilter: fix field direct char settingsJustin Luth1-17/+11
Instead of adding characters properties one at a time, lets take care of everything all at once. The results seem to be good so far. There is even some similarity between how MS Word has these properties on the "in-between" pseudo end character, where placing the cursor after the field gets these properties. I don't see it happening in MS Word at the pseudo start character, but it does in LO now... Hopefully that doesn't end up doing bad things. In the unit test, replacing the content ends up in red, italic. However, I see the same thing in MSO when testing with my second FORMTEXT example, so I think everything is "working as expected". I tried to see if I could limit doing this for only certain types of fields or conditions. However, pContext->GetResult() doesn't have a \fldrslt yet at the time this is happening. Also, TextField.is() happens less than I expected. I'm sure I could limit it to just certain pContext->GetFieldId(), but so far no problems are noticed for all field types. make CppunitTest_sw_rtfexport6 \ CPPUNIT_TEST_NAME=testTdf108505_fieldCharFormat make CppunitTest_sw_rtfexport6 \ CPPUNIT_TEST_NAME=testTdf108505_fieldCharFormat2 Change-Id: I3223437fd0d694f5e5733a9f7323f10f03d7802f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160232 Tested-by: Jenkins Tested-by: Gabor Kelemen <kelemeng@ubuntu.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-12-05tdf#108505 writerfilter: fix legacy dropdown fields direct bold settingJustin Luth1-1/+10
Any character property should be passed on, but do that in a follow-up commit, so that at least the bold case will remain intact if the broader fix gets reverted for any reason. make CppunitTest_sw_rtfexport6 \ CPPUNIT_TEST_NAME=testTdf108505_fieldCharFormat Change-Id: Id77980b704db2ff118e89c29eb9d4db82e117cdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160221 Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-12-01Fix typoAndrea Gelmini1-1/+1
Change-Id: I1998241849f0f9fa99d1b111f218cdab7e6074fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160208 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-01tdf#136472 adjust ooxml import to handle first header/footerTomaž Vajngerl6-433/+593
Previously the ooxml import added a new page style when the first header or footer was detected. Since then we gained support to add first page header/footer in an existing page style so we don't need to import it like that anymore. This changes the import code so that the old complication to add "First Page" page style is removed and it always just uses the "Standard" page style for all 3 cases: first, left and right headers and footers. This also adjusts the existing tests to align with this change. Change-Id: Ibf69597e6990499ac520ea9e323a5f73f429800b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157860 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-11-29cid#1554876 Use of auto that causes a copyCaolán McNamara1-2/+4
Change-Id: I8218a4371f0b002d8ef4d544bf9227db6684915f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160012 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-11-25loplugin:fieldcast in DomainMapper_ImplNoel Grandin2-3/+4
Change-Id: I1d734e1d30b91b84d42067b9cc621581ad744a40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159949 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-23fix a regression crash from commit 5082d50Jaume Pujantell2-17/+10
The commit generated crashes in the crashtest documents 7711 bugtrackers/docx/fdo78333-1.docx and 695 forums/docx/forum-mso-en-4096.docx. This was due to "m_xFieldStartRange", the start of the text portion of the block SDT, being recorded too early. This led to including characters that shouldn't be there in the generated content control. This patch moves the calls to setFieldStartRange to just before the first appendTextPortion call. Change-Id: I7230346fee9a37ebac70beb9bcafd9d7b612eb00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159816 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-11-16writerfilter: fix utext()'s dumb sal_uInt8* parameterMichael Stahl10-17/+17
This removes all but 4 reinterpret_cast in the module! TableManager::utext() even assumed that the bytes are little-endian. Change-Id: I12031336cabedfd6c0fb614ee0e3400810f98e2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159486 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-11-16writerfilter: remove DomainMapper::text() handling of paragraph breakMichael Stahl1-11/+5
Convert all remaining callers to utext(). Change-Id: Ie1fdf22e9e474289df2c72eadc236ec6b270df4f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159485 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-11-16tdf#153194 writerfilter: RTF import: testContSectionPageBreak last paraMichael Stahl1-0/+1
For testContSectionPageBreak, Word inserts an additional empty paragraph at the end of the document that was missing in Writer. Ensure markLastSectionGroup() is always called at the end of the document so that the \par that is dispatched in m_bNeedPar case will be inserted and not automatically removed immediately. Also add a test for the same document without \sbknone, which has 4 pages instead of 2. Change-Id: Ib3e4fbdb66df55941e4a487d4b249cd98fe42008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159472 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-11-16writerfilter: DomainMapper: fix undetected merge conflictMichael Stahl2-59/+71
... between commit fce18155052821756466ea043c638f4ed72f41d6 and commit 15b886f460919ea3dce425a621dc017c2992a96b - move the code from lcl_text() to lcl_utext(). Change-Id: Iaa515d2ebd9861e24b442b0d7b41f83662ed58df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159501 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-11-16tdf#153194 writerfilter: RTF import: \spltpgparMichael Stahl1-1/+3
1. Some experimenting with the bugdoc (saving it to DOCX in Word changes the layout in Word to exactly what Writer imports from RTF!) leads to DOCX w:splitPgBreakAndParaMark setting. 2. the RTF implementation of \spltpgpar was missing; apparently if the flag is present the "new" behavior is in effect, which is the opposite of how it's specified in RTF Spec 1.9.1. 3. the DomainMapper code that uses this attribute is not in the text() function to which RTFDocumentImpl sends paragraph breaks, but in the utext() function, so send the break there instead, rather than creating even more copypasta. 4. now some filters-text crashes with nullptr pContext in DomainMapper::lcl_utext(), avoid that. 5. dispatchSymbol(m_nResetBreakOnSectBreak) doesn't do anything because these are handled by dispatchFlag(). 6. Test name: testFdo81892::Load_Verify_Reload_Verify equality assertion failed - Expected: Performance - Actual : Fails because additional paragraph break inserted after \page; in dispatchSymbol() for \sect, remove the parBreak() as already hinted at in commit 3c610336a58f644525d5e4d2566c35eee6f7a618 7. rtfimport.cxx:868:Assertion Test name: testContSectionPageBreak::TestBody equality assertion failed - Expected: - Actual : THIRD It has no paragraph between SECOND and THIRD, whereas Word definitely shows a paragraph there. In dispatchSymbol() for \sect, sectBreak() is not called (which may create a paragraph break); in m_bIgnoreNextContSectBreak case this needs to be done manually for cont-section-pagebreak.rtf to get the empty paragraph between SECOND and THIRD. 8. testFdo52052 fails; in dispatchSymbol() for \sect, if the document ends with \sect (e.g. fdo52052.rtf) a paragraph break must be inserted after this (because DomainMapper unconditionally removes the last paragraph break), but not via m_bNeedCr as that creates unwanted page break in testNestedTable (m_bNeedCr => dispatchSymbol(\par) => m_bNeedSect => sectBreak()); handle it in RTFDocumentImpl::popState() for the end of the document by dispatching \par. 9. rtfimport.cxx:1519:Assertion testTdf108947 now has 1 empty paragraph in the header instead of 2; Word also shows only 1 so it's an improvement. 10. Test name: testFdo49893_2::Load_Verify_Reload_Verify equality assertion failed - Expected: 1 - Actual : 0 - xpath should match exactly 1 node This was reduced to only 2 pages, while Word shows 5; in dispatchSymbol() for \page, for the consecutive \page send an empty string to DomainMapper's utext() which causes a paragraph break to be created if \spltpgpar isn't set (this was not at all obvious!). 11. testTdf133437 fails with some numbers of flys changing, but it had those values before commit 3c610336a58f644525d5e4d2566c35eee6f7a618 which says "the exact number isn't that interesting". 12. testTdf153613_anchoredAfterPgBreak4 fails, but it now looks as in Word, so this is a bugfix. 13. Jenkins build on WNT (only) crashes in testForcepoint93 in sw layout code - disable test for now, debug asap. Change-Id: Ia1063693d96adff900ece943020a5bf69bdeb7a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159471 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-11-15Import Wordprocessing Canvas, wpc:wpc elementRegina Henschel1-6/+14
Currently LibreOffice uses the VML fallback, when a docx document has a wpc:wpc element. This patch implements to use the choice part with the wpc:wpc element. That is often called 'drawing canvas'. The patch uses a similar approach as for SmartArt. The drawing canvas is imported as group shape and for the background an additional rectangular shape is inserted as first in the children vector. Not using VML has the advantage, that the custom shape import is used for preset shapes. VML import produces problems because some properties are not available in VML or the current VML import has deficits. The test suite shows examples, what is better without using the VML fallback. Affected bug reports are e.g. tdf#104671 or tdf#154828. A drawing canvas must be used in Word for connector shapes. A connector in Word on the drawing canvas is not written as cxnSp element, but as ordinary wsp element with additional wps:cNvCnPr child element. The patch generates a connector in such case. Unsolved problems: The path of a curved connector in OOXML is basically incompatible to the path which LibreOffice generates. This patch uses the default path for a curved connector. Same is done in import in Impress. Using the VML fallback had generated a custom shape with the current path and handles, but the connections to the target shapes were lost. Export to docx is missing. The drawing canvas is not recreated, instead a group with the additional background shape is exported. That is no regression, using VML has produced a group too on export. I don't know whether XML_graphicFrame can occur in WordprocessingCanvasContext. At least charts and math equations are not possible on the drawing canvas in Word. Import of WordArt shapes does not work. That is not regression. It works neither in the VML import. Change-Id: I04bf8407efd1939cdf3137775f8afad420b74014 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156629 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-11-10tdf#158044 handling of paragraph attributes in RTF importOliver Specht1-0/+89
style attributes need to be repeated at the paragraph if not repeated then defaults have to be applied Change-Id: I4ee567e8006c240c046b7e7bb75eae92e5563776 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158839 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>