summaryrefslogtreecommitdiff
path: root/sysui/prj/build.lst
blob: ef2342b09adf98c9a85e42d57f8ec4b059c00e5a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
su	sysui	:	offapi xml2cmp rdbmaker transex3 setup_native SUN:officenames NULL
su	sysui\source\win32\QuickStart		nmake	-	w	su_win32_quickstart NULL
su	sysui\source\win32\QuickStart\so	nmake	-	w	su_win32_quickstart_so su_win32_quickstart.w NULL
su	sysui\desktop\icons					nmake	-	w	su_iconsw NULL
su  sysui\desktop\cleanversion          nmake   -   u   su_dtcleanversion NULL
su  sysui\desktop\share                 nmake   -   u   su_dtshare su_dtcleanversion.u NULL
su	sysui\desktop\menus					get     -   all su_dtmenus NULL
su	sysui\desktop\mimetypes				get     -   all su_dtmime NULL
su  sysui\desktop\redhat                nmake   -   u   su_dtredhat su_dtshare.u su_dtcleanversion.u NULL
su  sysui\desktop\suse                  nmake   -   u   su_dtsuse su_dtshare.u NULL
su  sysui\desktop\mandriva              nmake   -   u   su_dtmdk su_dtshare.u NULL
su  sysui\desktop\freedesktop           nmake   -   u   su_dtfreedesktop su_dtredhat.u NULL
su  sysui\desktop\debian                nmake   -   u   su_dtdebian su_dtshare.u NULL
su  sysui\desktop\slackware             nmake   -   u   su_dtslackware su_dtshare.u NULL
su  sysui\desktop\cde                   nmake   -   u   su_dtcde su_dtshare.u NULL
su  sysui\desktop\solaris               nmake   -   u   su_dtsolaris su_dtcde.u su_dtshare.u NULL
su  sysui\desktop\util                  nmake   -   u   su_desktop su_dtredhat.u su_dtsuse.u su_dtmdk.u su_dtfreedesktop.u su_dtdebian.u su_dtslackware.u NULL
su  sysui\util		                nmake   -   all   su_util su_desktop.u su_win32_quickstart_so.w su_iconsw.w NULL
ore/commit/sw/qa/filter/ww8/ww8.cxx?id=62fb52cd43d7c0d41dd4e35a1c128947b6a14918'>tdf#161771 sw content controls: fix DOCX export of empty dropdown list itemMiklos Vajna Open the bugdoc, save as DOCX, try to open in Word: Word refuses to open, saying that the file is corrupted. Each dropdown item has a value and a display text, it seems it's OK to omit the display text, but the value really should not be empty. Fix the problem by first trying to copy the display text to the value if the value would be empty; and if both are empty, then just omit the dropdown item. Note that the trick used at display text won't work here, omitting the value attribute (instead of writing an empty one) is still invalid DOCX. Change-Id: I4ae86aaf1a11cc8fd7c276634647f5737a9b04e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170142 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2024-06-18loplugin:ostr in variousNoel Grandin Change-Id: I7aa8ed716998a185996482dc561219b398a1c919 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169080 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2024-06-13loplugin:ostr in sw/qaNoel Grandin Change-Id: Ib67997a3f491afaec380ef65bc60588362d9cc3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168812 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2024-05-29tdf#160984 sw continuous endnotes: DOCX: export of <w:endnotePr> pos == sectEndMiklos Vajna In case a DOCX file is re-exported to Word and it collected endnotes at section end, this setting was lost on save. The relevant markup seems to be <w:endnotePr> -> <w:pos w:val="sectEnd"/>, though that's a per-section setting in Writer, and is a per-doc setting in Word. Fix the problem by doing it similar to DocxExport::WriteDocumentBackgroundFill(), which takes the first page style in a similar case; here we take the first section format. This is meant to be good enough for the DOCX editing case, where we know all sections have the same endnote position properties anyway. Change-Id: I95508296e31c9be34196bdc0da2177101647abf9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168187 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2024-05-16tdf#160984 sw continuous endnotes, DOC import: enable this unconditionallyMiklos Vajna DOC files with <= 2 endnotes were imported fine, but not if they had more endnotes. This was added in commit dc11f5b151e1a2ea2623fc8cf806a400763955d9 (tdf#143445 DOC import: limit the usage of the CONTINUOUS_ENDNOTES compat flag, 2023-05-23), because mapping endnotes to footnotes was a dead-end. The limitation can be dropped: I checked that the tdf#143445 bugdoc with all its 72 endnotes is laid out reasonably. Also add a new SwFrame::DynCastColumnFrame() to easily get a column frame from a frame using our own RTTI, if we have it anyway. Change-Id: If7fd856f5dc5f1feb1366fca69a2ad6b3602044d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167722 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2023-11-19Extended loplugin:ostr: swStephan Bergmann Change-Id: I210f61f6d90776b086b7058fb1a831d235699fb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159670 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2023-10-16sw floattable, wrap on all pages: add DOCX filterMiklos Vajna - map DocumentSettingId::ALLOW_TEXT_AFTER_FLOATING_TABLE_BREAK to <w:compatSetting w:name="allowTextAfterFloatingTableBreak"> on export - do the opposite on import - this requires a bit of rework, to avoid routing <w:compatSetting> via a grab-bag when we want to actually read it during import - also expose GetBooleanValue() from the OOXML tokenizer, so dmapper can know when the value of the compat flag is a true-like string. Note that it seems DOC and RTF don't have a matching compat flag for this. Change-Id: I0cb1230ee40994f59b816c42f8e7d2ac658b3212 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158013 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2023-10-10tdf#107786: sw_ww8: Add test for null pointer dereferenceOmkarAcharekar Change-Id: I54bd01ce3b0007abe9adb58c0b17195e38e8ceaf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157742 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> 2023-10-07loplugin:ostr: automatic rewriteStephan Bergmann Change-Id: I2d09b2b83e1b50493ec88d0b2c323a83c0c86395 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157647 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins 2023-10-04tdf#126449 sw floattable: DOC import: handle inner floating tableMiklos Vajna One problem with the bugdoc is that the inner floating tables in the DOC file stay in a single page. Seems the usual to-para anchoring + allow-to-split logic is not used here, because the toplevel table is handled at SwWW8ImplReader::StartApo(), but the inner table is handled in SwWW8ImplReader::StartTable(). Additionally, the toplevel table is anchored to-para (which seems to be the closest to Word's "position this table based on the next paragraph" concept), but the inner table was anchored to-char, and such fly frames can't split. Fix the problem by switching to to-para anchoring even for inner floating tables. This improves consistency with toplevel floatint tables from DOC and all floating tables from DOCX. It seems to the to-char anchor type was added in commit 10f352d2faf6a4d72337b2c098a65377eee5138b (INTEGRATION: CWS swqbugfixes18 (1.111.60); FILE MERGED, 2005-03-30), but there the motivation was to make sure these are not inline; so that use-case keeps working. This does fix the overlapping text with the original bugdoc, but otherwise the DOCX version is still slightly closer to the Word render result. Change-Id: I379a26194da4d3a06241aa3c6f5ae78606f8fc12 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157550 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2023-08-25tdf#77760 sw floattable: add support for footnotes, DOC importMiklos Vajna This is similar to commit 178421a6c719dac9c16f220b76292fec16a53f60 (tdf#77760 sw floattable: add support for footnotes, DOCX import, 2023-08-24), the problematic part was to reject everything that is not in the body text, relax that to allow insertion into split flys. Do an early check to see if we'll insert into the fly/header/footer section, because otherwise it would be pointless to call SwNode::GetFlyFormat(), which can be expensive in case we don't have a layout yet. The DOC export, the RTF import and the RTF export was working already, so filters are mostly covered with this. Change-Id: I59c69fac0692c6656c054e32503ec0cbc2fd11e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156083 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2023-08-14sw floattable: handle AllowOverlap==false in the DOC filterMiklos Vajna Map sprmTFNoAllowOverlap to SwFormatWrapInfluenceOnObjPos::mbAllowOverlap on import, and do the opposite on export. Change-Id: Id61be49adb39862e30ffb2da9ff9aabae11f7d83 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155650 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2023-08-11sw floattable: export <w:tblOverlap w:val=never> to DOCXMiklos Vajna Once split flys containing tables have "allow overlap" disabled, this is not saved to DOCX when we map them to floating tables. The working case is the allowOverlap attribute on shapes, added in commit f8c7a2284b88c149addc8a30abb0cad8a10dad77 (Related: tdf#124600 sw anchored object allow overlap: add DOCX filter, 2019-09-20). Fix the problem by extending DocxAttributeOutput::TableDefinition(), to write <w:tblOverlap> in case overlap is not allowed, after <w:tblpPr>. DOC and RTF filters are still missing. Change-Id: I7d0bd4a15567014d3add8cbbcd92c62c5a33b7e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155573 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2023-07-11sw floattable: make sure floattable after floattable gets own anch pos from DOCMiklos Vajna The bugdoc has 2 floating tables next to each other, which overlap in Writer, but not in Word. This looks quite similar to the DOCX case, which was solved in commit 01ad8ec4bb5425446e95dbada81de435646824b4 (sw floattable: fix lost tables around a floating table from DOCX, 2023-06-05). Fix the problem by improving SwWW8ImplReader::StartApo() so it inserts a fake paragraph when a floating table is immediately followed by a floating table. A similar case, floating table followed immediately by an inline table was already handled like this in WW8TabDesc::CreateSwTable(). Creating a reproducer document from scratch is quite tricky, as Word will also insert a fake paragraph on the first save of the DOC test file (so the doc model will be floattable-para-floattable-para) and manual edit of binary DOC files is also not easy. So the compromise is that the testcase file has 2 floating tables anchored to the same paragraph, but they don't overlap visually, while they do overlap in the original, internal bugdoc. With this, finally the bnc#816603 DOC bugdoc renders without overlaps, which was the case before my multi-page floating table changes. Change-Id: Ib1b4c7c80833db5a7bde38092c8c3ed6fd1d2462 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154290 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2023-07-10sw floattable: enable AddVerticalFrameOffsets compat flag for DOCMiklos Vajna The bugdoc has a floating table, followed by an inline table. The inline table should be on the second page, but instead it's on the first page, overlapping with the floating table. It seems this works already for DOCX since commit 50223ea6e212b60b7d33839c2753c5601fb50f95 (tdf#98987 sw: add AddVerticalFrameOffsets compat mode, 2016-03-31). Fix the problem by enabling the same compat flag for DOC, since the intention was to have this on for Word formats in general. The original bnc#816603 bugdoc still needs more work, though. Change-Id: If9b4e1d3feeeaa24d6e84fea9a10ecdfd995c18f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154235 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2023-07-05sw floattable: fix lost floating table right before a table from DOCMiklos Vajna The bugdoc has a floating table, anchored in a paragraph that is hidden via character formatting. The bugdoc also has a normal table. This leads to 1 table in Writer, but 2 tables in Word. We already have code that tries to make sure floating tables have a suitable anchor, see the code in WW8TabDesc::CreateSwTable(), but that checks for the case when the next node after a floating table would be table (and not text), instead of the hidden character property. Fix the problem by not creating the hidden char attribute in the first place in SwWW8ImplReader::SetToggleAttr() in case the pool item would be inserted at the paragraph start and we just inserted a floating table, which makes the 2nd table visible in Writer as well. This is for DOC, interesting when Word converts this document to DOCX, then the hidden attribute is removed, so there this is not really needed. Change-Id: I3a7411e6fcc318740bcbd4b0cde9f34134f384a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154017 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2023-05-26sw floattable: handle fDontBreakWrappedTables in the DOC filterMiklos Vajna This is the binary DOC import/export for the functionality added in commit 08fa2903df1a7cf9a1647fcf967e4c8b57dad793 (sw floattable: add a DoNotBreakWrappedTables compat flag, 2023-05-24). Change-Id: I91c29b9049e8e9079ed16b1beeefddfa2f6e9a6a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152291 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2023-05-25sw 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). Change-Id: I1891b89787719805e6c87045dee3c63c68ed2940 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152255 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2023-05-23tdf#143445 DOC import: limit the usage of the CONTINUOUS_ENDNOTES compat flagMiklos Vajna The bugdoc has 72 endnotes and not all of them were listed at the end of the document, since commit 4814e8caa5f06c4fe438dfd7d7315e4a2410ea18 (tdf#124601 sw: add ContinuousEndnotes layout compat option, 2019-09-30). The problem is that for simple documents the strategy to just place the endnotes (in the form of footnotes) on the last page works, but this approach breaks when the document is growing, since nobody moves the endnotes from the former last page to the new last page. Additionally, it's not trivial to know what the effective last page is, once you have enough endnotes that the end of the body text is not on the last page. Fix the problem by restricting when the DOC import sets this compat flag. The limit is picked to be 2 endnotes, just because that keeps the use-cases for continuous endnotes working. A future solution would be to create a layout-level section at the end of the document for such endnotes: that would allow them to be inline, and we know how to keep endnotes inside a section & know how to keep a section at the end of the document. But that would be a bit of a feature work, let's keep this regression fix simple. Change-Id: Ideea1c52f4e31ded3e28e9441aace2bc3857079e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152127 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2023-04-28Revert "Revert "introduce sw::SpzFrameFormat ...""Bjoern Michaelsen apparently, in SwHistoryChangeFlyAnchor::SetInDoc, m_rFormat might actually reference a DrawFormat, not a FlyFormat, and that is likely fundamentally broken. But for now, lets just make m_rFormat a sw::SpzFrameFormat -- this already removes some pointless up and downcasting. This reverts commit 52acefd6024ec79f8333ba40eef83816eda3046f. Change-Id: I040d98548bf9ac1c25b93214224eb0812f8cb653 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151150 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org> 2023-04-27Revert "introduce sw::SpzFrameFormat ..."Stephan Bergmann This reverts commit 09cdcb5f37bb4e42da7b28db6e757b9f2affed14. It broke at least CppunitTest_sw_uiwriter3 (<https://ci.libreoffice.org//job/lo_ubsan/2756/>), > /sw/source/core/undo/rolbck.cxx:938:46: runtime error: downcast of address 0x61300041fd00 which does not point to an object of type 'SwFlyFrameFormat' > 0x61300041fd00: note: object is of type 'SwDrawFrameFormat' > 00 00 00 00 70 83 cf 09 25 7f 00 00 00 83 47 00 30 61 00 00 40 e5 43 00 30 61 00 00 80 66 5d 00 > ^~~~~~~~~~~~~~~~~~~~~~~ > vptr for 'SwDrawFrameFormat' > #0 0x7f24fca9c5b9 in SwHistoryChangeFlyAnchor::SetInDoc(SwDoc*, bool) /sw/source/core/undo/rolbck.cxx:938:46 > #1 0x7f24fca880f3 in SwHistory::Rollback(SwDoc*, unsigned short) /sw/source/core/undo/rolbck.cxx:1208:15 > #2 0x7f24fcb47832 in SwUndoDelete::UndoImpl(sw::UndoRedoContext&) /sw/source/core/undo/undel.cxx:1031:33 > #3 0x7f24fcb703c2 in SwUndo::UndoWithContext(SfxUndoContext&) /sw/source/core/undo/undobj.cxx:225:5 > #4 0x7f2543b8b57c in SfxUndoManager::ImplUndo(SfxUndoContext*) /svl/source/undo/undo.cxx:712:22 > #5 0x7f2543b8c4f8 in SfxUndoManager::UndoWithContext(SfxUndoContext&) /svl/source/undo/undo.cxx:664:12 > #6 0x7f24fca6a074 in sw::UndoManager::impl_DoUndoRedo(sw::UndoManager::UndoOrRedoType, unsigned long) /sw/source/core/undo/docundo.cxx:696:32 > #7 0x7f24fca6b38f in sw::UndoManager::UndoWithOffset(unsigned long) /sw/source/core/undo/docundo.cxx:731:16 > #8 0x7f24fa830b18 in SwEditShell::Undo(unsigned short, unsigned short) /sw/source/core/edit/edundo.cxx:141:57 > #9 0x7f250088f448 in SwWrtShell::Do(SwWrtShell::DoType, unsigned short, unsigned short) /sw/source/uibase/wrtsh/wrtundo.cxx:45:26 > #10 0x7f24ff7f16e2 in SwBaseShell::ExecUndo(SfxRequest&) /sw/source/uibase/shells/basesh.cxx:651:27 > #11 0x7f24ff7eea14 in SfxStubSwBaseShellExecUndo(SfxShell*, SfxRequest&) /workdir/SdiTarget/sw/sdi/swslots.hxx:2203:1 > #12 0x7f2523fbc059 in SfxDispatcher::Call_Impl(SfxShell&, SfxSlot const&, SfxRequest&, bool) /sfx2/source/control/dispatch.cxx:254:9 > #13 0x7f2523fd1ced in SfxDispatcher::Execute_(SfxShell&, SfxSlot const&, SfxRequest&, SfxCallMode) /sfx2/source/control/dispatch.cxx:753:9 > #14 0x7f2523f61333 in SfxBindings::Execute_Impl(SfxRequest&, SfxSlot const*, SfxShell*) /sfx2/source/control/bindings.cxx:1060:22 > #15 0x7f252437496b in SfxDispatchController_Impl::dispatch(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> const&) /sfx2/source/control/unoctitm.cxx:688:53 > #16 0x7f2524377211 in SfxOfficeDispatch::dispatchWithNotification(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> const&) /sfx2/source/control/unoctitm.cxx:266:16 > #17 0x7f24cad28dd6 in framework::DispatchHelper::executeDispatch(com::sun::star::uno::Reference<com::sun::star::frame::XDispatch> const&, com::sun::star::util::URL const&, bool, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /framework/source/services/dispatchhelper.cxx:163:30 > #18 0x7f24cad27cb2 in framework::DispatchHelper::executeDispatch(com::sun::star::uno::Reference<com::sun::star::frame::XDispatchProvider> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /framework/source/services/dispatchhelper.cxx:120:16 > #19 0x7f24cad29684 in non-virtual thunk to framework::DispatchHelper::executeDispatch(com::sun::star::uno::Reference<com::sun::star::frame::XDispatchProvider> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /framework/source/services/dispatchhelper.cxx > #20 0x7f24e91d386d in unotest::MacrosTest::dispatchCommand(com::sun::star::uno::Reference<com::sun::star::lang::XComponent> const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /unotest/source/cpp/macros_test.cxx:94:33 > #21 0x7f25319b2012 in testTdf132321::TestBody() /sw/qa/extras/uiwriter/uiwriter3.cxx:982:5 Change-Id: Ibeb181bc38cd6f88df76403cca8a15b45090633f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151027 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2023-04-26tdf#154855 DOCX export: fix <wp:anchor layoutInCell="1"> with <wp:wrapNone>Miklos Vajna The bugdoc has a table where shapes are anchored in cells. The wrap type is set to "none" ("in front of text" in Word UI terms) and the follow text flow ("layout in table ell" in Word UI terms) option is enabled. The import into Writer is fine, but saving back to DOCX and checking in Word is not: all shapes move to the left cells. What happens is that since commit e993638d5ecd33783f2eebdccfa87a81e5a8a2c5 (DOCX import: fix <wp:anchor layoutInCell="1"> with <wp:wrapNone>, 2022-01-24), we ignore layoutInCell in case wrapNone is used with a suitable horizontal relation orient, since Word doesn't capture anchored shapes inside the cells in practice in that case. This helps for the old bugdoc, but introduces the problem that we now lose the layoutInCell setting on export, which is not wanted. Fix the problem by leaving the import and the layout unchanged, but do the opposite mapping on export: if we have the relevant wrap and horizontal relation orient case, then enable layoutInCell, even if the doc model doesn't have it. Note that Word itself behaves inconsistently here: if you change the vertical offset of one of these shapes to position the shapes outside the cell, Word does it, even if "layout in cell" is enabled. Change-Id: I980a995d76afdee4716f7669081c688065427ee8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151000 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2023-04-24introduce sw::SpzFrameFormat ...Bjoern Michaelsen - ... as a base class of frame formats allowed into the spz frame format container - with a private ctor and friends SwDrawFrameFormat and SwFlyFrameFormat so only these two classes derive from it - with that, switch over the SpzFrameFormats to only ever allow these types into the container - in followups, likely quite a bit of stronger typing can be introduced. - ultimately, it would be nice to have each SwDrawFrameFormats and SwFlyFrameFormats in their own strongly typed container in the end. Change-Id: Ic30efc1220aded701533c9ca5003d2aaf8bbdaec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150452 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org> 2023-04-20sw floattable: import floating tables from DOC as split flys by defaultMiklos Vajna To get wider testing. Change-Id: Id9d21aeca3bb9c00a5b4adfd45934a242e7559bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150597 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2023-04-14sw floatable: teach the DOC import about SwFormatFlySplitMiklos Vajna - add a new DOC/ImportFloatingTableAsSplitFly setting, replacing the old (enabled by default DOCX/ImportFloatingTableAsSplitFly) one - clean up old uses of SwModelTestBase::FlySplitGuard - if SwWW8ImplReader::StartApo has a table position, then map that to SwFormatFlySplit=true in the ImportFloatingTableAsSplitFly case - testcase for this Change-Id: Ibd798ea7eb79d7ec00620dd8921797232f4732d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150381 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2023-04-14-Werror,-Wunused-variableStephan Bergmann Unused ever since the two variables got introduced in a825e23a2980fcb3d970834c4ce1f8403fb93054 "DOCX export: fix not-well-formed XML when hyperlink end is a textbox anchor" and 87e82f80e87bb4a216ea83383864d494f3e92eea "docx: export symbol characters correctly", respectively. (Found with an experimental Clang build supporting __attribute__((warn_unused)) on individual ctors rather than just whole class types, and the corresponding css::uno::Reference ctor marked accordingly.) Change-Id: I89b8324633d598b06c8aa206747f9213d4634cac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150361 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2023-02-22sw 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. Change-Id: I601833c49f49f94e1ff3cdc994e3027ee0542b94 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147429 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2023-01-03docx: export symbol characters correctlySzymon Kłos Previously we had: after save: <w:t></w:t> original content: <w:sym w:font="Wingdings" w:char="F0E0"/> This patch checks if paragraph has symbol font used and exports content using w:sym mark in that case Change-Id: I74f4bb0d249cbf5dfc930e931f7d91bd0d2e9821 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143455 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144949 Tested-by: Jenkins Reviewed-by: Szymon Kłos <szymon.klos@collabora.com> 2022-11-25SwModelTestBase: use createSwDocXisco Fauli in order to unify the code Change-Id: Iedeff59cc45775c80844e8e030f61354325399da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143282 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> 2022-11-22tdf#152045 DOCX export: fix empty display text for content control list itemsMiklos Vajna Regression from commit f726fbc2699b05199a8dec3055710a7131e0aad6 (tdf#151261 DOCX import: fix dropdown SDT when the item display text is missing, 2022-10-10), the problem was that the correct way to represent "no display value" is not an attribute with empty value but a missing attribute. Change-Id: I25b2bb564444f43d1ca1bf95d1c59b208cb24530 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143048 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2022-11-08swmodeltestbase: remove duplicated methodXisco Fauli save needs to set mbExported to true, otherwise parseExport returns nullptr Change-Id: I1ba779e0ac0f20663fb722df16210ca144717479 Change-Id: I330abdc72226d5ac7b4d6747bdcc48cedfc9e90f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142400 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> 2022-11-04SwModelTestBase: make mpTestDocumentPath privateXisco Fauli in preparation for future inheritance from UnoApiTest Change-Id: Ie5dee5af3609d8490d7d7bad0d6dbc4c8fc17bb9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142280 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> 2022-11-03swmodeltestbase: use maTempFile everywhereXisco Fauli Change-Id: Ifd840984e4144599f2527702a57688863854b7ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142235 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> 2022-09-27DOCX export: fix not-well-formed XML when hyperlink end is a textbox anchorMiklos Vajna We failed to save a document which contained anchored text and the anchor position was inside a hyperlink. The problem was that the hyperlink covered content which has anchored text, so when the text inside the shape ended its paragraph, it wanted to finish the hyperlink that was started outside the shape, which is not well-formed XML. This was a problem since 7246e57216bb20c15af0ecf6a0183f5ffa81e780 (tdf#143591 DOCX import: handle anchored objects as at-char, 2021-09-20), previously we lost the character position of such anchor positions, so in practice this problem was not visible. Fix this similarly how we stash away the current state when entering a table cell: just save / restore the number of hyperlinks we have to close, that'll close the hyperlink outside the shape. Note that the source document has the hyperlink outside the shape's anchor, while we include the shape inside the hyperlink, but that doesn't cause problems in practice. Change-Id: I711fad2336fd78e2ba709c3fc0a4f75de32aae8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140650 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2022-09-22sw content controls, combo box: add DOCX filterMiklos Vajna Map the ComboBox UNO property to: <w:sdtPr> <w:comboBox> ... </w:comboBox> </w:sdtPr> and the opposite on import. Change-Id: I50e0b961bca99f4ecca86d6784d2e6a13f469314 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140399 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2022-07-25sw content controls, plain text: add DOCX exportMiklos Vajna Map the PlainText UNO property to: <w:sdtPr> <w:text/> </w:sdtPr> Change-Id: I57f365fcfb3a80acb74aa932432a8ae8f3acc92b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137398 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2022-06-08RTF filter: allow measuring page borders from the edge of the pageMiklos Vajna This is similar to commit 51942eafdb4439559b6d59f3becd4afab45277f0 (DOC import: allow negative page border distances, 2022-06-08), except here we map \pgbrdropt's 5th bit to the "from page edge" bool, and then the rest of the import works already after the DOCX fixes. Similarly, the export has to map the "from page edge" bool to \pgbrdropt and has to call into editeng::BorderDistancesToWord(), but the rest of the process works after the DOCX fixes. Change-Id: Ic88f1ab17ac169025c38790ffa895748df0a76c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135502 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2022-06-08DOC import: allow negative page border distancesMiklos Vajna In case the margin (distance between body frame and page frame) is smaller than the border spacing (distance between border and page frame), then we can map that to a negative border distance during the import of DOCX files since commit 1f127a2b9e1c1daab0972f98fc8708ecb7afa299 (sw layout: allow negative page border distances, 2022-06-07), but DOC import had the same problem. The above commit intentionally kept the default behavior of BorderDistanceFromWord() unchanged to avoid side effects in other clients of that function (not DOCX import), but means that DOC import was still broken. Given that it turns out there are only 2 callers of BorderDistanceFromWord(), fix the problem by allowing negative border distances unconditionally: this simplifies code & SetBorderDistance() in the DOC import will now get the correct border distance out of the box. DOC export works out of the box without any additional work. Change-Id: I6bf15b3c73823c9265218b7b3a7b869e131818db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135484 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>