summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)Author
2023-06-09tdf#152046 Revert "tdf#100680 sw DOCX compatibility: fix wrap of as_char flys"Justin Luth
This reverts 7.4 commit 41b012767feb8552b60a68c7be18d80c403304bf, The premiss of the commit is that as-char flies needed to be handled differently, and yet at the spot where it was implemented, we have no idea whether we are even dealing with an as-char fly!!! As this bug report report shows, it affects paragraphy that don't have any fly whatsoever, let alone an as-char fly. Change-Id: I2fedb2d610093933081e861a16a25de2f2716258 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152780 Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Jenkins
2023-06-07sw floattable, DOCX import: clean up not needed dmapper-level anchor insertMiklos Vajna
This was added in commit 1c99616f86f7d5b83b91edc225fc95fec227d710 (sw floattable, crashtesting: fix PDF export of forum-mso-en3-26783.docx, 2023-05-02) to ensure that in case a floating table is not followed by a text node, then inject one at a dmapper level. Later commit 01ad8ec4bb5425446e95dbada81de435646824b4 (sw floattable: fix lost tables around a floating table from DOCX, 2023-06-05) did the same at a tokenizer level, as doing it in dmapper is too late in some cases. So keep the testcase from the first commit, but the changes to dmapper can be dropped. (cherry picked from commit 4c5438b2c447403194420b69311a81ea7d36e157) Change-Id: If5b702d99e81a3f939491b7ff9de1128da765cbf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152694 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2023-06-07sw floattable: fix lost tables around a floating table from DOCXMiklos Vajna
The DOCX file has 3 floating tables: the first one is immediately followed by a second one, and the second one also has an inner table. The problem is that somehow dmapper thinks it's fine to merge the two outer table together, than the inner table invalidates some of its cell start/end references, so at the end the outer table conversion fails, which means we only have 1 table, not 3. This is a bit similar to commit 1c99616f86f7d5b83b91edc225fc95fec227d710 (sw floattable, crashtesting: fix PDF export of forum-mso-en3-26783.docx, 2023-05-02), but here fixing the problem at the dmapper level sounded too complex. Instead inject the text node that'll serve as an anchor point at a tokenizer level. With this, the DOCX version of the bnc#816603 bugdoc (the one that started all workarounds in 2013) has one less overlapping table, but it still has problems. (cherry picked from commit 01ad8ec4bb5425446e95dbada81de435646824b4) Change-Id: I54307b4c554da51bb55287e61bca700d8343d11c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152642 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-06-06tdf#103869 sw floattable: fix lost table right before a section break from DOCXMiklos Vajna
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. (cherry picked from commit e2f90d1d0e51c68dd01c9968cdb7a3bbb5658613) Change-Id: I4612a15d0d1ad3fe527593a21a4120096790a33f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152527 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-06-02tdf#150769 sw floattable: fix lost PageDescName if section starts with a tableMiklos Vajna
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. (cherry picked from commit 2a380dba73d57f825128fbada91c7a9fe79e8a06) Change-Id: I83245c78c63ec8f3d6015ce3e72ab232220a9fdb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152476 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-06-01use ComplexColor instead of ThemeColor for better OOXML compat.Tomaž Vajngerl
In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 1df0565fb92972bd410e7db85eef1e4bec3fcc31) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152234 Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-31sw floattable: handle \nobrkwrptbl in the RTF filterMiklos Vajna
This is the RTF import/export for the functionality added in commit 08fa2903df1a7cf9a1647fcf967e4c8b57dad793 (sw floattable: add a DoNotBreakWrappedTables compat flag, 2023-05-24). (cherry picked from commit d785d26a5599d3d546b96958b0f1c6d5ed777a0d) Change-Id: I3c458cbe1f4b0947a94651cc205f2a7660d2ec2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152412 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-05-31sw floattable: handle <w:doNotBreakWrappedTables> in the DOCX filterMiklos Vajna
<w:doNotBreakWrappedTables> primarily appears in documents imported from RTF, unless \nobrkwrptbl is specified there (which, confusingly, means to do split floating tables). (cherry picked from commit f5dc52dc9a068fec3323c3089929a81675b0d1ba) Conflicts: sw/qa/filter/ww8/ww8.cxx Change-Id: I1891b89787719805e6c87045dee3c63c68ed2940 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152296 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-05-19tdf#154703 writerfilter framePr: avoid exception with hasValueJustin Luth
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 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151988 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2023-05-19tdf#154129 writerfilter framePr: check whole style inheritance (and dedup)Justin Luth
The fixes related to this bug were broken up into numerous commits, but all combined into one patch for backporting. This is a squashed commit that includes: commit 1519ae101abf32187db983c8a08f7bf1899d5d22 tdf#154129 writerfilter framePr: check whole style inheritance: HAnchor commit b2d754c49b7351f7b2663bb249b4b2f663ef3786 tdf#154129 writerfilter framePr: address nit about nSafetyLimit commit c253fc3877fd91f4345feb60dacb6565f9a2509b tdf#154129 writerfilter framePr: check whole style inheritance: VAnchor commit b1696d2a3e2015b60fc04a785e6a9f7925f4232e tdf#154129 writerfilter framePr: check whole style inheritance: Y/YAlign commit 630732bfd8ed531e9d412a36a083f33763def054 tdf#112287 tdf#154129 writerfilter framePr: fix vAnchor default commit 1bc004f67feb51beb00113cedd5f98a1e6e2bcdd tdf#154129 writerfilter framePr: check whole style inheritance: X/XAlign commit 2571b39158c679a42a68bea5f219e29a42f4e6a6 tdf#154129 writerfilter framePr: check whole style inheritance: W/H commit 6f1052da8d145b1176186024dc4745cbd561fe36 tdf#154129 writerfilter framePr: check whole style inheritance: hRule commit 44837a12d12be3e525fa48b37c3dd2553cc97d94 tdf#154129 writerfilter framePr: check whole style inheritance: wrap commit 2ab9a2e4166264be83300e7ed038be1b803a5ac8 tdf#154129 writerfilter framePr: check whole style inheritance: v/hSpace commit 6eb483d3f27e3ee8c56d422fb96f83844370d325 tdf#154129 writerfilter framePr: remove last use of pParaStyle commit fb8522e457b098b5ade98a4a4babbc8704d3fad4 NFC tdf#154129 writerfilter framePr: deduplicate Hori/VertOrient commit 1a12246fc1deaaf1e2c723c0c541de85cf88101e NFC tdf#154129 writerfilter framePr: deduplicate w:w commit af8f05f859a1fb61d88dfe558d1bc7a8282c792a tdf#154129 writerfilter framePr: deduplicate w:h commit f2a10d9e751bdbc4ba981b6ca9d0dc127439a3c2 tdf#154129 writerfilter framePr: nhRule obey comment instructions commit 1188fa78d0e7b5fd8f4c7c207fd4ec9ced666c12 tdf#154129 writerfilter framePr: deduplicate w:x commit 611288b64548762e0731ed6323e1653e4fca2317 tdf#154129 writerfilter framePr: deduplicate w:y commit 070e62bad980cbe15dfbe9096a5e5d962a70f07c tdf#154129 writerfilter framePr: deduplicate w:hAnchor commit2d331e6bfe8c9ca31f1a4e092dbcffb8919b8655 tdf#154129 writerfilter framePr: deduplicate w:vAnchor commit 33ce22f080bbedfde78fdc907b0d4d5bd0f68f14 tdf#154129 writerfilter framePr: deduplicate w:wrap commit 4237db7f43c08efbf166a2bfa8a0c99d1c5f04a4 NFC tdf#154129 writerfilter framePr: deduplicate lcl.. call commit a777dab7544bd11c26ae26c40cce49ab976dab2d tdf#154129 tdf#73546 writerfilter framePr: fix/deduplicate w:v/hSpace commit d21ba804040bdb275234254fbbe742ce830420c2 tdf#154129 tdf#97128 writerfilter framePr: deduplicate PopFrameDirection commit b1194e42dde6e3749631a6510d9e7b969e5eae8e tdf#154129 writerfilter framePr: deduplicate BackColorTransparency commit 97b84d31a1db2ec690d180effad307f331d62fb9 tdf#154129 tdf#78590 writerfilter framePr: deduplicate grabbag Change-Id: I32eabc6c1090dbc2c467da74fe32c6377e9a3875 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148686 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151987 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2023-05-19writerfilter: prefix members of DomainMapper_Impl, EmbeddedFontHandler, ...Miklos Vajna
... GraphicImport_Impl and StyleSheetEntry See tdf#94879 for motivation. This cherry-picked cleanly from master except for writerfilter/source/dmapper/GraphicImport.cxx which had a couple of mstahl commits already merged. So, the question is whether I go ahead with this full cherry-pick, or do I just attempt to limit it to StyleSheetTable and its dependencies. If I do this, then any 7.6 commit BEFORE Mon Feb 20 08:13:50 2023 that still needs to be backported will run into trouble, while now any commit AFTER that date will run into trouble. Well, Collabora has made most of the changes to these files in the past few months, so I assume most of those have already been backported. A few made by allotropia have also already been backported. So, I think the best is to just go ahead and backport this full commit. I need at least DomainMapper_Impl and StyleSheetTable for my own purposes, so that already counts for about half of it. Change-Id: I83639c40fb8c32c1d205a9b53d24409f9a5a5a15 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147307 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151967 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Justin Luth <jluth@mail.com>
2023-05-13tdf#151974: writerfilter: apply props only to new documentVasily Melenchuk
Properties applied to document shoudl be a case only for new doc, but DomainMapper can be called during pasing of RTF and cause modifications to props in already open document. Tested only for "NoNumberingShowFollowBy" but I assume this is a case for all compatibility props. Change-Id: I4558d809ca477918373b15fa05500ed985e170a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151069 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> (cherry picked from commit 2d0a87f97e2c9ac50cd6ce329ca8256daf94ead4) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151288 Reviewed-by: Stéphane Guillou <stephane.guillou@libreoffice.org> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-05-13tdf#131722 DOCX import: fix lost first character in date selectorCzeber László Ádám
Fix another date selector control bug, date picker first character goes out of the control. The first character of the date separator in the first row of the table is out of control. The fix takes into account the placement of the dummy paragraph in the first row of the table, which caused the date separator to be corrupted. Thanks to Gabor Kelemen for pointing out this error to me. Follow-up to commit e898f95bfab16ddd9b04e516293cb6eb7e0a3847 "tdf#138093 DOCX import: fix broken date selector control in table". Change-Id: I91d272b786a3d3dc047334c2a4a039f987c94ce0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151087 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151164 Tested-by: Jenkins
2023-05-13tdf#138093 DOCX import: fix broken date selector control in tableCzeber László Ádám
In tables, first character of the text value of the date selector control left outside of the control during the import, resulting broken date selector, e.g. 2[023] instead of [2023]. (Clicking on the broken control, according to the year *023*, the selector listed the lowest possible value, year 1900, and selecting that, the result became 2[1900].) Note: the fix works well with nested tables, too, so likely the condition with tables is obsolete. Perhaps regression from commit b36ef83ea59eeaca239e58b95aa0b1acdcb99efc "tdf126701: MSForms: Fix import of date field at the end of the paragraph." and commit 68e1be4ccbb90ee9a788962219a88312c4ffbea2 "MSForms: Rework text-based date form field's representation". Change-Id: Ib217a3a06522bfe7b3b0fbc884f98504f628fc59 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150575 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151053 Tested-by: Jenkins
2023-05-13tdf#154695: use Chapter Numbering Rules to confirm that ToC needs tabsMike Kaganski
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> (cherry picked from commit b6a5f16a9bf3227867bf46b88d012440138b6f24) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150142 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2023-05-09writerfilter: fix crash in DomainMapper_Impl::handleIndex()Miklos Vajna
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 (cherry picked from commit 1e75a434e349110990bcccd80b5c63c11080853e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151512 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151556 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2023-05-05tdf#154478 fix comments empy after ToCJaume Pujantell
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> (cherry picked from commit 5431b756d45bebe74beaba2026704552ee6891f0) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151281 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Justin Luth <jluth@mail.com>
2023-05-04sw floattable, crashtesting: fix PDF export of forum-mso-en3-26783.docxMiklos Vajna
Converting the bugdoc to PDF crashed Writer layout since commit ce3308a926f036b87515b8cd97d2b197063dc77a (tdf#61594 sw floattable: import floating tables as split flys by default, 2023-04-12). Inspecting what the layout does, the trouble was that the bugdoc has a floating table, immediately followed by a non-floating table. This breaks the invariant that floating tables are anchored in the next, text node. In practice we anchored the floating table in the first cell of the next table, which is not the same as a floating table followed by a normal table. (For comparison, the DOC import simply lost the floating table in this case.) Fix the problem by making sure there is a text node after a floating table, in case it's directly followed by a table (no text node in-between). Changed tests: - testFloatingTablesAnchor: this still asserts that the flys are all anchored in the body text - testTdf95755: the problematic table is still not as wide as it used to be in the bad case (cherry picked from commit 1c99616f86f7d5b83b91edc225fc95fec227d710) Change-Id: I30b9ae423914b0b2cb1ebc7c1dce7efcd4cc3cf7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151312 Tested-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-05-02sw floattable, crashtesting: fix PDF export of tdf114111-3.docxMiklos Vajna
Converting the bugdoc to PDF crashed Writer layout since commit ce3308a926f036b87515b8cd97d2b197063dc77a (tdf#61594 sw floattable: import floating tables as split flys by default, 2023-04-12). The stripped down document has 3 tables: a toplevel, a middle and an inner one. The middle one is floating. SwFrame::GetNextFlyLeaf() doesn't support nested tables, so we move an inner table frame to a next page, causing a frame to have the in-table flag, without a table frame parent, leading to a crash. Fix the problem by just disabling floating tables for nested tables for now. It can be enabled later, and not supporting inner floating tables was the intent of 8818dd359fbf0f37e1b318de89ab2ea7d735f58 (sw floattable: fix handling of nested non-floating tables at cell start, 2023-03-20) anyway. (cherry picked from commit 1795d5183d5371a24e8dcb15f8671c78b2c94665) Change-Id: I75db01c6c0fdd803130fbb2a8f2f90c6180051ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151253 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-04-28sw floattable, crashtesting: fix PDF export of fdo72790-1.docx, part 4Miklos Vajna
Converting the bugdoc to PDF crashed Writer layout since commit ce3308a926f036b87515b8cd97d2b197063dc77a (tdf#61594 sw floattable: import floating tables as split flys by default, 2023-04-12). Part 1 already fixed the crash and parts 2-3 already improved the layout partially, towards avoiding a layout loop. The top problem now seems to be that page breaks before floating tables are ignored, which leads to a layout situation that loops. This problem was hidden before, since page breaks were not ignored. Fix the problem at DOCX import time: if there is a "break before" on the table, then transfer that to the anchor paragraph, which gives the correct layout, and also side-steps the above described layout loop. We should probably never call SwTextFrame::JoinFrame() when creating the initial layout for a document, that part is still unfixed, but that looks like a pre-existing problem. (cherry picked from commit 4b6b9411e4ac912817dd804782ad2054bc0d1660) Change-Id: I1e2ecdbf0a3d4e2477cd4768a9b4a35a155e815b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151156 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-04-27tdf#154360: use TOC(N) styles in DOCX as the source of ToC tab stop positionMike Kaganski
Change-Id: Iab8001f8be8a8af437e8898079d55ff57dd6fa3b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149494 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149548 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-04-27tdf#150542: DOCX import: support for document variblesVasily Melenchuk
Writer does insert document variables only if they are in document body as DOCVARIABLE fields. But ones given in settings.xml (w:docVars/w:docVar) were ignored. Moreover variables in settings should have priority and overwrite ones in fields. Word by default does show only field results, but refreshing field values will override values with ones from settings. Change-Id: I7103c90eef59ab18f8a25e616dcf8a8b1c6dcb08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149646 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> (cherry picked from commit 992d86b1b67a6bd28bbf5e63b2d2406881f476b7) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149889
2023-04-27sw floattable: DOCX import: m_bConvertedTable is now unusedMiklos Vajna
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). (cherry picked from commit 400d970f27078a93eab97ead8a6934a32272f549) Change-Id: Ieba43e1175ab59c29c0555299facb8fc0e865acf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151085 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-04-26sw floatable: teach the RTF import about SwFormatFlySplitMiklos Vajna
- if the document has no \nobrkwrptbl, then ignore all floating table control word for now - map the rest of the RTF control words to OOXML attributes under the NS_ooxml::LN_CT_TblPrBase_tblpPr sprm: - \tpv{para,mrg,pg} -> NS_ooxml::LN_CT_TblPPr_vertAnchor - \tph{col,mrg,pg} -> NS_ooxml::LN_CT_TblPPr_horzAnchor - \tposy -> NS_ooxml::LN_CT_TblPPr_tblpY - \tposy{c,b} -> NS_ooxml::LN_CT_TblPPr_tblpYSpec - \tposx -> NS_ooxml::LN_CT_TblPPr_tblpX - \tposx{c,r} -> NS_ooxml::LN_CT_TblPPr_tblpXSpec - \tdfrmtxtLeft -> NS_ooxml::LN_CT_TblPPr_leftFromText - \tdfrmtxtRight -> NS_ooxml::LN_CT_TblPPr_rightFromText - \tdfrmtxtTop -> NS_ooxml::LN_CT_TblPPr_topFromText - \tdfrmtxtBottom -> NS_ooxml::LN_CT_TblPPr_bottomFromText (cherry picked from commit 05425f73bfa41d3f7591461e2ad0beb4fafc39b4) Change-Id: I0b30d0eba8c1b7b6d3497334c958146717d06552 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150900 Tested-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-04-26oox: add model::Theme to oox::Theme and remove createSvxThemeTomaž Vajngerl
This is the start of the change where oox::Theme is only a holder of model::Theme and not a oox structure. This is probably the easiest way how to refactor that. In this commit only prepare that and make the code work the same as it did before. Change-Id: I926a35fd0db383ddb182dc83b36411b2d40b8530 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147692 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit dad60bd52a25c1997d3724361ea81c0fe99b1872)
2023-04-25oox: import directly into docmodel's Theme and ColorSetTomaž Vajngerl
This changes the import to directly fill values of a model::Theme and model::ColorSet, without filling the oox structs first. The goal is to get rid of the oox in the long run, but for now it is necessary to keep reading into both, which is a duplication. The next step is to also fill the FontScheme and FormatScheme structures. Change-Id: I488ec096cbc184bc70d24510ac9091a488540422 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147571 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 6e8c67580974484c790f52991de26298ce8e7e1c)
2023-04-20sw floattable: remove no longer needed DOCX import heuristicsMiklos Vajna
Now that IsFlySplitAllowed() is true, m_aPendingFloatingTables and related code can go in writerfilter/. (cherry picked from commit c50bf5a5daaae3d40f89ea0784a75a8a571c208d) Change-Id: Id69e13e82fc447ad56b9f3926e353c203e600141 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150312 Tested-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-04-20tdf#61594 sw floattable: import floating tables as split flys by defaultMiklos Vajna
To get wider testing. (cherry picked from commit ce3308a926f036b87515b8cd97d2b197063dc77a) Change-Id: Ic05844c6ae48429feb9a0cd3217a7afce6c902dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150311 Tested-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-04-03tdf#154319: fix TOC field codes parsingMike Kaganski
Change-Id: I734697f52df14ca5b316481df8a58fef72ab9571 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149254 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 76777c82fa4bb5080c135e2241c3f7122dcbb298) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149437 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-04-02tdf#153255 DOCX import: fix footnote orderLászló Németh
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> (cherry picked from commit 93a20c1d9c2f379906970bbe8a15905fc1a328bc) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149242 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-03-24sw floattable: fix inner floating table inside normal outer table from DOCXMiklos Vajna
The problem was that CppunitTest_sw_ooxmlexport9's testTdf79329 has a normal outer table and a floating inner table; the inner table was already not floating (so that's not a new problem), but SW_FORCE_FLY_SPLIT=1 even failed the text-to-table conversion for the outer table, so we just had 1 table, not 2 tables. The problem seems to be that the start/end positions for the outer table cell get invalidated by the inner table-to-frame conversion, so the outer table conversion will fail as well. Fix the problem by limiting the table-to-frame conversion for toplevel tables: this avoids the failing text-to-table conversion in the SW_FORCE_FLY_SPLIT=1 case. At some stage I should revisit this, since the DOC import has working floating tables for the inner case, for now just make sure that the DOCX import result has two tables, as before. (cherry picked from commit a1b935ca1bb6d48241e73e7206a367fe2b51f948) Change-Id: I39aa00e46c12a32117c334cb97e1cc0270b77651 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149374 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-03-21sw floattable: fix handling of nested non-floating tables at cell startMiklos Vajna
CppunitTest_sw_ooxmlexport8's testN779642 failed in the SW_FORCE_FLY_SPLIT=1 case. The bugdoc has a floating table, then an inner, non-floating table. The conversion to floating tables was disabled by the c1eebcdac9f2b289fd363399130c485ca5ff444c (tdf#79329 DOCX import: fix missing outer table with floattable at cell start, 2016-11-08). Given that SwFormatFlySplit doesn't need the delayed text frame conversion, we can get rid of this workaround. Fix a similar problem on the export side as well, where the positioning properties of the outer table leaked into the inner table. Once both the import and export are fixed, the test passes. (cherry picked from commit 48818dd359fbf0f37e1b318de89ab2ea7d735f58) Change-Id: I884ad38cbc247c885991b0faf0d37221b70a6ba7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149193 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-03-20sw floattable: fix redline import from DOCXMiklos Vajna
The problem was that sw/qa/extras/ooxmlexport/data/tdf149388.docx contained redlines but those were not imported for split flys. This happened because split flys get imported directly in DomainMapperTableHandler::endTable(), and the redling handling for floating tables was only implemented in SectionPropertyMap::CloseSectionGroup() (where delayed floating tables are imported). Fix this by extracting the redline import code for floating tables into 2 functions and then calling those also from DomainMapperTableHandler::endTable(). Note that the !isExported() branch of the testcase looks like dead code, since we always run this code after an export. (cherry picked from commit 9a9ee21ec237eda5df6ea70bfa3bec07b44b4d21) Change-Id: I860ee0168807077eb5ed33d79888f4cc1de9a717 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149145 Tested-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-03-20sw floattable: unconditionally map <w:tblpPr> to SwFormatFlySplitMiklos Vajna
CppunitTest_sw_ooxmlexport8's testN816593 failed in the SW_FORCE_FLY_SPLIT=1 case because the re-import of the document merged two tables into one. The problem starts earlier, we didn't import the table with a <w:tblpPr> as a floating table, but we should. Fix the problem by never going via m_aPendingFloatingTables in the SW_FORCE_FLY_SPLIT=1 case, since that was only a workaround for layout limitations. This conditionally reverts commit 78d1f1c2835b9fae0f91ed771fc1d594c7817502 (fdo#68607 bnc#816593 DomainMapperTableHandler: don't always start a frame, 2013-09-03). Also add a SwModelTestBase::FlySplitGuard, so it's just a one-liner change to test the SW_FORCE_FLY_SPLIT=1 case from cppunit. The goal is to have this on by default once it's mature enough. (cherry picked from commit d477fa8ac1b0d3ee81427217bbb5950278ab16db) Conflicts: sw/qa/unit/swmodeltestbase.cxx Change-Id: I9d94a49f7a0c27dd43e8fd388867c65d6d25f2e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149144 Tested-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-03-17tdf#146984 writerfilter inline_inline: no break in shapeJustin Luth
make CppunitTest_sw_ooxmlexport18 \ CPPUNIT_TEST_NAME=testTdf146984_anchorInShape Change-Id: I94efea80df1fee9ecd338bfec3430edfdf418e3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149052 Tested-by: Justin Luth <jluth@mail.com> Reviewed-by: Justin Luth <jluth@mail.com>
2023-03-12tdf#153891 DOCX import: crash fix at missing cell propertiesLászló Németh
Regression from commit 81ce88aa80f8e7cde4fdc5b211e9500a3599643c "tdf#132514 DOCX import: fix lost table style with footer". Note: no crash without this fix by removing styles.xml from the test document. Change-Id: I7fd7edfc8f62e6b17c0c8f7a3bdec7d986ba57eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148053 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit e34074feeb1b918ab9f26a18c5fdb0b1f2e35f94) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148105 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-03-12tdf#143311 writerfilter: import decorative flag on as-char flys tooMichael Stahl
Change-Id: I9704d35a8286b92169dffd8de7e57e286884f607 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148016 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit d4355f14d1483a57fa08579b143a762f0aad4631) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148019 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-03-12tdf#153874 writerfilter: fix anchoring of decorative shapesMichael Stahl
Turns out as-char flys can be decorative too. The confusing GraphicImport takes a GraphicImportType by value but everything else is a reference to a DomainMapper_Impl member. The latter appears to work better so handle GraphicImportType the same way and remove the function parameter. (regression from commit 31084ebb59093be7dfe5ab53a20fdb3bcfde34b6) Change-Id: I18c1d47d39751e8ddcaa52498077d89c43a934e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147998 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 043c349f144b615836091707147e57616a1261e7) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148012 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-03-10tdf#104394 writerfilter: no addDummyParaForTable when PrevFramedJustin Luth
The dummy paragraph is only supposed to be added when the table starts the section. In this case, a framed paragraph was the first item in the section. Since it ends up being a floating item, it is probably not correct to turn off GetIsFirstParagraphInSection. In any case, this is a much more targetted fix, and thus much less likely to lead to regressions. Change-Id: I7fb2c6189ddbff5d46828b27d68667c9d4a31122 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148656 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148662 Tested-by: Justin Luth <jluth@mail.com>
2023-03-09sw floattable: partially re-enable widow / orphan control in tablesMiklos Vajna
Widow / orphan control in DOCX tables were disabled in commit 8b13da71aedd094de0d351a4bd5ad43fdb4bddde (tdf#128959 DOCX import: fix missing text lines in tables, 2020-01-28). That workaround helped with the particular bugdoc, but it also disabled widow / orphan handling in general, and breaks e.g. orig-nocompat.docx from tdf#61594, because the second page's last row is meant to contain 6 lines with widow control enabled, but the model has widow control disabled, so the layout can't work properly. Fix the problem by improving the layout's WidowsAndOrphans::FindWidows() to handle conflicting widow / orphan control requirements in a fixed table row height context, so the writerfilter/ change from the above commit can be reverted without re-introducing tdf#128959. An alternative would be to keep the layout unchanged and limit the writerfilter/ change to fixed height rows, but that still feels like a (more specific) workaround. (cherry picked from commit 65dd1525e826006f78f86688032459dbd7ab4bb4) Change-Id: I8378d356e116774275dff337d17b19bd79c84c1c
2023-03-08tdf#153964 writerfilter compat15: top margin after break splitJustin Luth
The problem was that the top margin was being applied to the new paragraph after the split. This is absolutely attrocious in MS Word before 2013. If I am going to be in error, I want to error on the side of being compliant with compat15, since all other versions of MS Word are now unsupported. I think I have the logic of it mostly figured out. In compat15, the top margin never applies after the break. In compat14, if the paragraph properties are not applied to a run before the break, then they can be applied after the break. make CppunitTest_sw_ooxmlexport18 \ CPPUNIT_TEST_NAME=testTdf153964_topMarginAfterBreak14 make CppunitTest_sw_ooxmlexport18 \ CPPUNIT_TEST_NAME=testTdf153964_topMarginAfterBreak15 Change-Id: I8816b391e898cfea58c2e0dbf01c881f87bbc4c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148451 Tested-by: Justin Luth <jluth@mail.com> Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148476
2023-03-08tdf#153613 writerfilter: split para for inline too if not FirstRunJustin Luth
If we have some stuff in a character run (i.e some text usually) and then a page break and then an inline image, then the inline image should start a new paragraph and move to the following page. Only anchored images don't necessarily move to the next page. make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf153613_inlineAfterPgBreak2 make CppunitTest_sw_rtfexport5 CPPUNIT_TEST_NAME=testTdf153613_inlineAfterPgBreak2 Change-Id: I756f756d836b29eedc776a35b7667ba33e6cdebd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147170 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147180 Tested-by: Justin Luth <jluth@mail.com>
2023-03-08tdf#153613 writerfilter: don't always split para for shape w/ pagebreakJustin Luth
The problem was that an extra paragraph was added, and the shape was anchored to the wrong page. There are lots of places that handle deferred breaks, and they typically do this only for FirstParagraph or non-first character properties run. This is needed here too. make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf153613_textboxAfterPgBreak make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf153613_textboxAfterPgBreak2 Of course, RTF is goofy, so handle that as an exception to just leave it alone as it has been. To solve it properly is likely very tricky - as are all things RTF, because we can't trust IsFirstRun in general and especially not for RTF. make CppunitTest_sw_rtfexport5 CPPUNIT_TEST_NAME=testN818997B Change-Id: Iad06f3ea9684a2860ae6ba724887bdf0b5850f94 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147169 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147179 Tested-by: Justin Luth <jluth@mail.com>
2023-03-08tdf#153613 writerfilter: anchors ignore prior run with page breakJustin Luth
Although an image that is INLINE with the text DOES move to the following page when it is preceded by a w:br, an anchored image does not (when it is the last property in the paragraph). make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf153613_anchoredAfterPgBreak make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf153613_inlineAfterPgBreak I also tested with <w:t>x<</w:t> following the anchor and it already works correctly. make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf153613_anchoredAfterPgBreak2 I also tested with <w:splitPgBreakAndParaMark/> and it already works correctly. make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf153613_anchoredAfterPgBreak3 Change-Id: Ibf9c0d38c4dfe56db4e05416a40e3b7881693b17 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147032 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147177 Tested-by: Justin Luth <jluth@mail.com>
2023-03-08tdf#153602 writerfilter: clear isDummyPara after processing table.Justin Luth
Once the table is processed, the fact that we had a dummy paragraph is no longer relevant to the section. So, after carefully figuring out that we have had some other paragraph in the main text body, clear the dummy status used to control bRemove. This fixes the problem of adding an empty paragraph each round-trip. Unfortunately, this would still fail if for example there was only another table following the first one. Well, it wouldn't fail that badly because the first save would add an empty paragraph, and then following saves would use that single empty paragraph as the one that resets things. So we always have at least one CR following a table, but at least they aren't multiplying. Unfortunately this isn't at all clean, because as soon as the table starts, we no longer know that it is the first paragraph in the section. (The other table paragraphs and potentially header, comment, footnote, shape etc can all set IsFirstParagraphInSection to off. Basically, most flags are completely useless since they are not stacked in any way. So we are left with a multitude of conditions to check for everything. Change-Id: Ic6a9795a6c529f8b5dd4f5d1cccc89db01b03d28 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146955 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147016 Tested-by: Justin Luth <jluth@mail.com>
2023-03-08tdf#153592 writerfilter: don't defer breaks into shapes/commentsJustin Luth
When starting a pargraph, we already had a clause to avoid deferring page and column breaks when we were in a shape or a comment. These clauses are also necessary in the other sections of the code where we defer these breaks. The provided test proves the two shape cases in lcl_utext. I just took IsInComments along for the ride, as it certainly would apply in that case as well. make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf153592_columnBreaks ooxmlexport4's testTdf81345_045Original proves that it is also needed in lcl_text. However, it is such a complex document that I wasn't confident that a unit test would be stable enough. Change-Id: I2de15341d3e756bf47fcd85b868a849c8a2419cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146939 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146965 Tested-by: Justin Luth <jluth@mail.com>
2023-03-07tdf#153613 writerfilter: handle defered break before SDT startJustin Luth
If there are deferred column or page breaks before an SDT, then before starting the SDT we need to determine if the existing run needs to split - same as everywhere else. There was only one existing unit test that had any defered page or column breaks, so only two example documents to work from. That was tdf125778_lostPageBreakTOX.docx. Change-Id: I02d71577af13399d8aaf3ba0ce40fc6bed5e6e3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148148 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148362 Tested-by: Justin Luth <jluth@mail.com>
2023-03-03sw floatable: teach the DOCX filter about SwFormatFlySplitMiklos Vajna
- stop creating a grab-bag for floating tables in the DOCX import if split flys are allowed, which gives the exporter an opportunity to actually read the doc model - extract that code that writes a <w:tblpPr> from a ww8::Frame to a new CollectFloatingTableAttributes() - in case a fly frame has a table and the fly has SwFormatFlySplit=true, then call CollectFloatingTableAttributes() even without grab-bags - in the unlikely case that we would have both a split fly and a grab-bag, ignore the grab-bag With this, we get a working DOCX export for multi-page floating tables. The import is still disabled by default. (cherry picked from commit e7be3b821cd42fdc9d8e51772b8202030d76497e) Change-Id: I601833c49f49f94e1ff3cdc994e3027ee0542b94
2023-03-02sw floattable: add ImportFloatingTableAsSplitFly expert settingMiklos Vajna
Mapping DOCX floating tables to Writer split flys is still disabled by default, but now the environment variable affects the DOCX import instead of affecting the Writer item pool's default. This allows mixing ImportFloatingTableAsSplitFly=true and =false tests in the same suite, so the sw/CppunitTest_sw_core_layout_flycnt.mk boilerplate can be dropped. It also allows overwriting this default from an xcu file (expert config, or the XCU file in online.git) for testing / demo purposes. Also extend the layout representation comment / doc a bit. (cherry picked from commit 3282508f8deeafd50f5af45ca0adf760efb114a3) Change-Id: I239e9c6e9d9c8748ed0846ae336c9c818d59f180
2023-03-02DOCX filter: fix horizontal pos of floattables with compat mode >= 15Miklos Vajna
The floating table in the bugdoc has a small negative horizontal indent, which carefully aligns it so that the contained paragraph lines up with the text above the table. It turns out that compatibilityMode >= 15 doesn't do this anymore in Word, so we should at least avoid this tweak on import/export when we know the compat mode. Fix the problem by avoiding the <w:tblpPr w:tblpX="..."> decrease during import and the matching increase on export. This is similar to what commit 9a31d1c83e08600507689dc18f6f0973bc7e4389 (tdf#106742: OOXML import/export: treat "tblInd" properly., 2017-04-04) did for non-floating tables. I discovered this while working on multi-page sw floattables, but this is relevant for single-page sw floattables as well. Next to the modified testcase, sw/qa/core/layout/data/floattable.docx is also a good test file, which shows how the left border now lines up with the body frame, and there used to be a noticeable gap there. Now sw/qa/core/layout/data/floattable.docx gets rendered ~perfectly (with SW_FORCE_FLY_SPLIT=1). (cherry picked from commit 7fb8b73ad320e32af130ceddec80a9ff08407eab) Change-Id: Ia52202f1bc3274f4ce2b7ee02c85d07589454ae9
generated by cgit (git 2.34.1) at 2024-06-17 14:56:23 +0000