summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)Author
2023-01-31tdf#148687 tdf#149173 tdf#149546 sw: fix crash with textboxesAttila Bakos (NISZ)
Regression from 2110597ac730fa07dbbdd603fda82b182ed27c9e "tdf#147485 sw: fix group shape crash using std::shared_ptr". Details: 1) Using reference instead of copy assignment in SwTextBoxHelper. 2) Cleanup: Unused parts of SwTextBoxHelper were removed. 3) Fixing destruction of textboxes, in case when first the shape is removed, with clearing all textboxes from the doc and the shape before the pointer is released. All of this only have to be done if the call is not coming from the swdoc dtor, unless there will be double freeing. 4) Missing style conversion was fixed in writerfilter. 5) Don't import sections in textboxes, unless the hack of dummy paragraph before tables in sections will be applied and the paragraph with anchored objects inside will be removed with the objects; 6) ConvertTextRangeToTextFrame also fixed, so embed frames in frames are imported from now. (Also textboxes in frames, this can be useful when there is a floating table having group textbox with nested complex content inside, or floating table in floating table, etc...) Note: Follow up commit will enable group textbox import in frames and tables. 7) Import of group textboxes with complex content in header/footer was impossible, from now this is also supported both from DOCX and ODT (test included). 8) Guard class for blocking unwanted recursive textbox sync has been introduced, and maybe some speedup with group textbox import has been achieved. 9) The anchor sync method got a new function which avoids unnecessary sync when the anchor is the same. 10) Sync of As_char textboxes during layout calculation caused crash so that has a workaround from now, for DOCX import anchor change and Undo. That syncs starts before the layout calculation so sync not needed later. 11) A memory leak was found in Undo, which has been fixed. Note: layout test "testTdf147485Forcepoint" has to be limited to Windows and Mac builds, because font substitution causes crash on the Unix based systems. Change-Id: I69d5d79cc120e3a70ba9285be32ec36a434b2a04 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136192 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143373 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-01-30tdf#151548 sw content controls: preserve tabIndex val="-1"Justin Luth
Either we have to read sal_uInt32 (which I can't figure out how to do) or else we have to write it out as sal_Int32. Microsoft isn't much help here because their documentation does not give any example of a non-tabsltop, and one errata document indicates that MS Word simply ignores tabIndex altogether for Sdt (and ffData). According to the documentation, tabIndex is a CT_UnsignedDecimalNumber which we do not have in our model.xml so it was defined as being a CT_DecimalNumber which works fine for reading something human sensible like -1. However, in our exporting we were exporting a sal_uInt32 which creates large, all positive numbers which were not being read on import. Nothing I tried worked to read these large numbers. Perhaps it is even illegal to do so in MS formats? Since it doesn't seem to matter to MS Word, and for a human it is easier to understand -1, and it is easier to solve in export than import, I'm taking the easy road. Change-Id: I6b296703c9a37149d9e11f29901e6db32bd041b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146149 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/+/146296 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2023-01-17tdf#66039 DOCX: import textboxes (with tables, images etc.) in group shapesAttila Bakos (NISZ)
Text boxes in group shapes were imported as shapes, losing complex text content: tables (tdf#66039), colors (tdf#73022), images (tdf#81958), lists, paragraph styles, hyperlinks (tdf#122960) and track changes. Note: a few unit tests have been deactivated temporarily. Test document "groupshape-trackedchanges.docx" of testGroupshapeTrackedchanges is imported correctly now: with track changes, and the test was modified accordingly. Follow-up to commit 2951cbdf3a6e2b62461665546b47e1d253fcb834 "tdf#143574 OOXML export/import of textboxes in group shapes". Change-Id: I6eb918dbf64393fd723fe43f798f93b5b9a12575 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125051 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143371 Tested-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-01-17tdf#143574 OOXML export/import of textboxes in group shapesAttila Bakos (NISZ)
In this part, oox module has been modified in order to prepare for WPG handling during OOXML import. Note: Wpg is the drawingML equivalent of v:group, supporting text boxes in the group. 1) Added new parameter for WpgContext to support nested Wpg shapes, and WPS enabled for the WPG member shapes. 2) A bug has fixed, where group member line shape and connector shapes have wrong positions before in the group. 3) Unit tests had to be modified, and 3 of them disabled temporarily due to missing Writerfilter implementation (what will be the next commit) Now group shapes can have textboxes and the text is imported for that, but complex content is still missing (this will be fixed in writerfilter by the next commit). Known issue: WPG shapes with textboxes in floating table have issues during import at floating table conversion, so until this is not fixed this function is disabled for shapes in tables (will be fixed a follow-up commit later). Follow-up to commit 19394a924fdc486202ca27e318385287eb0df26f "tdf#143574 sw: textboxes in group shapes -- part 4". Change-Id: I71032187697807087bd8f27f7c3a7b052e174bd7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124964 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143367 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-01-17ooxml: fix theme color type mapping: bg -> light, text -> darkTomaž Vajngerl
Change-Id: I19ad3ef7c911943075d7ddc01626047cdf11d5db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145070 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 1a79594a27f41ad369e7c387c51e00afb1352872) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145649 Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-17introduce {Char,Fill}ColorThemeReference which uses XThemeColorTomaž Vajngerl
Adds a unified UNO property for theme colors *ColorTheme (CharColorTheme and FillColorTheme) which uses XThemeColor, that replaces the properties *Theme, *TintOrShade, *LumOff, *LumMod. The properties are still present for backwards compatibility and to keep ODF support working in tests as that needs a bigger change. Reactor the code and tests to accomodate for this change. Change-Id: If7983decb4ba528b49fe7b5968aa9efc696a9efc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144783 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 197e5f81213d14fdcbff40edf73385ecd4cd9815) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145553 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2023-01-16sw: read theme from OOXML file and set it to the draw pageTomaž Vajngerl
This change extends writerfilter to use oox::ThemeFragmentHandler to read the theme properties, and sets that to the one and only draw page of a Writer document. This change also removes ThemeTable and replaces it with the ThemeHandler, which takes theme font data from svx::Theme instead. In addition, a test has been writen, which loads a document with a theme, and asserts the draw page has the theme and the theme properties currently supported. Change-Id: Iff0048cd21ea030ac55287707852acc463ec3cb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143699 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 312100003fc7cae358038aaec853584782c698f8) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145388 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2023-01-14tdf#152425 Synchronize import and export style names mappingMike Kaganski
1. Make the mapping in StyleSheetTable::ConvertStyleName match the opposite direction mapping happening in MSWordStyles::GetWWId and ww::GetEnglishNameFromSti. Add missing styles, provide comments to clarify the process and find respective pool format ids. 2. Instead of appending " (user)" to conflicting style names, which is the method used by SwStyleNameMapper to disambiguate API names, append " (WW)", which allows to avoid unwanted merging conflicting styles. Change-Id: I47b1c7f570da6e6e21155669fdd1b77de5cc17da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145349 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145377 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2023-01-12sw: support for reading back theme color from OOXMLTomaž Vajngerl
OOXML supports theme colors and tint/shade value that additionally changed the theme color. Read back which theme color + tint/shade value was applied in the resulting color and add this attributes as properties to be used by writer. In sidebar theme panel the changing the theme colors now doesn't takes this into account and changes the colors correctly. Change-Id: I3a2d49d485fd37a1611483ee0bb5e6034ac5f88e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143697 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit df9f3f3fd81d4f81ee2ff984d1e19999abea2963) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145350 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2023-01-04docx: Preserve w15:appearance SdtPr attributeofftkp
Now roundtrips the w15:appearance value which dictates whether there's an effect when hovering a placeholder. Change-Id: I3c911a0cfe31e235b9d981bbff0c1bb5827a85ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144845 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 2fe73bd2362287afc8242289a900821186b36137) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144994 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2022-12-21sw content controls: enhance preserve idJustin Luth
Squashed commit including NFC cleanup docxattributeoutput: use existing function to clear fd14dd0e4c6a7ea0866a686f653db90301d664b6 Follow-up to 100c914d44ae8f362924fe567d7d41d0033ae8ad which added the initial id preservation for DOCX. adding DOCX block SDT grabbaging, ODF import/export [content controls can't exist in DOC format] The ID field is CRITICAL to preserve for VBA purposes. This patch adjusts BlockSDT to also round-trip the id instead of just creating a random one. m_nRunSdtPrToken <never equals> FSNS(XML_w, XML_id) since 2021 with 5f3af56b2c0ef6c628a7cfe5ce6e86f8e1765f5f, so I removed that part of the clause. I had thought about changing the ID to use a string instead of an int, but then the integer version was adopted to fix a regression in the commit mentioned earlier. I think it is AWFUL to have a number as the identifier when it will be used in StarBASIC. The VBA guys have to deal with it, but it would be nice to do something reasonable for LO native access to content controls. However, the concern would be if we allow VBA macro content created in LO to be exported to DOCX format - that would cause problems converting from a string ID to a number ID. VBA editing already is happening to some extent, and mmeeks seems interested in enabling it. So over-all it seems best to just stick with an integer ID. I used the commits for <w:alias> and <w:tag> to compose this patch. XML_ID already existed in include/xmloff/xmltoken.hxx and "id" already exists in xmloff/source/token/tokens.txt The ID can be used in VBA to select a specific control. The id (which is a positive or negative integer in DOCX) specifies a unique control - either by passing the number as a string (of the UNSIGNED value) or by passing as a float (specified with #). For example: msgbox ActiveDocument.ContentControls(2587720202#).ID msgbox ActiveDocument.ContentControls("2587720202").ID but not as an integer since that is used for index access. dim index as integer index = 1 msgbox ActiveDocument.ContentControls(index).ID make CppunitTest_writerfilter_dmapper CPPUNIT_TEST_NAME=testSdtRunRichText make CppunitTest_sw_ooxmlexport17 CPPUNIT_TEST_NAME=testDateContentControlExport make CppunitTest_sw_core_unocore CPPUNIT_TEST_NAME=testContentControlDate make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlExport make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlImport Change-Id: I5c4022dc932d941fad9da6d75ce899ee1ff66ff5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142818 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/+/144625 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2022-12-21tdf#151548 sw content controls: preserve tabIndexJustin Luth
This has to be vital to keyboard navigation. Certainly it is good to have it imported before we start to consider tab-movements for form controls. All tabIndex 1's are processed (in placement order) and then the 2's etc. 0's are to be done last. XML_TAB_INDEX already existed in include/xmloff/xmltoken.hxx and "tab-index" already exists in xmloff/source/token/tokens.txt make CppunitTest_writerfilter_dmapper CPPUNIT_TEST_NAME=testSdtRunRichText make CppunitTest_sw_ooxmlexport17 CPPUNIT_TEST_NAME=testDateContentControlExport make CppunitTest_sw_core_unocore CPPUNIT_TEST_NAME=testContentControlDate make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlExport make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlImport No existing unit test found containing blockSDT with tabIndex. Change-Id: I8a958844e6192b079a2b22a62dedfd8739021f4a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143603 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/+/144623 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2022-12-21tdf#149240 docx content controls: round-trip showingPlcHdr betterJustin Luth
ShowingPlaceHolder causes all the text in the control to be selected when the control gains the focus. Otherwise, just a cursor is placed at the click point. While round-tripping this attribute worked for inline SDTs, it was lost for block SDTs. But BlockSDTs are very easy to create. The MS templates are full of them. Also, these are boolean, but it could have a val=0 specified, in which case it is off, but we were importing it as on. Change-Id: I167afa935311a63bba408ecd489ae819485a5cb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143818 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/+/144621 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2022-12-20tdf#151548 sw content controls: preserve lockJustin Luth
DOCX SdtControls can be locked in two ways: -Content Control cannot be deleted (sdtLocked) -Contents cannot be edited (contentLocked) or both (sdtContentLocked) make CppunitTest_writerfilter_dmapper CPPUNIT_TEST_NAME=testSdtRunRichText make CppunitTest_sw_ooxmlexport4 CPPUNIT_TEST_NAME=testSimpleSdts make CppunitTest_sw_ooxmlexport17 CPPUNIT_TEST_NAME=testDateContentControlExport make CppunitTest_sw_core_unocore CPPUNIT_TEST_NAME=testContentControlDate make CppunitTest_sw_macros_test CPPUNIT_TEST_NAME=testVba make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlExport make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlImport Change-Id: I5a82d9f6b5103a4902f59af66cd8a99addd4e690 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143542 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/+/144553 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2022-12-20tdf#151548 sw content controls: preserve tag for block SDTsJustin Luth
The tag is critical for VBA access. Although we do not yet import blockSdts as content controls, losing this would break any VBA macros for MS Word. So make sure it round-trips. I can't imagine why it wasn't treated the same as alias. I guess because Alias is seen, while tag appears to have no valuable function (until VBA, where it becomes the most likely ID field.) Change-Id: I05a04faa9d2314c7b37c5b86f107bd1a16019509 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143830 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/+/144552 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2022-12-19writerfilter: fix crash in DomainMapper_Impl::convertFieldFormula()Miklos Vajna
Crashreport signature: program/libwriterfilterlo.so writerfilter::dmapper::SettingsTable::GetListSeparator() const writerfilter/source/dmapper/SettingsTable.cxx:489 program/libwriterfilterlo.so writerfilter::dmapper::DomainMapper_Impl::convertFieldFormula(rtl::OUString const&) include/rtl/ustring.hxx:226 program/libwriterfilterlo.so writerfilter::dmapper::DomainMapper_Impl::handleFieldFormula(tools::SvRef<writerfilter::dmapper::FieldContext> const&, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&) include/rtl/ustring.hxx:527 program/libwriterfilterlo.so writerfilter::dmapper::DomainMapper_Impl::CloseFieldCommand() writerfilter/source/dmapper/DomainMapper_Impl.cxx:6458 Change-Id: I7f48f76cacffa00d633d92f0a51b2d82f96d1e74 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144314 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-11-30tdf#152289: implement external glossary relations roundtripMike Kaganski
Change-Id: I20f4439abfbf73485734fd8373fffb2916d390f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143470 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit dda4867a0b5a2d29d8a01a3656e0c8dac7626d2f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143441 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2022-11-25tdf#152200: tolerate begin/end fldChar context mismatchMike Kaganski
We generate such files currently. Fixing that will be another commit. Change-Id: I788501e346cba63c08a767c0e05e063bc1172089 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143223 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 9a7945f36ce95a48e0d525bc444e722b9ec5c452) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143171 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2022-11-24DOCX filter: fix <w:id> creating both grab-bag and content control for <w:sdt>Miklos Vajna
Exporting the DOCX bugdoc back to DOCX resulted in a document that can't be opened in Word. Examining the output, the problem is that the document had 2 inline <w:sdt> elements with <w:id>, and we mapped such <w:sdt> elements to both grab-bags and content controls, leading to duplicate <w:sdt> elements on export. This is schema-valid, but it goes against the intention of the spec and Word can't open it. The initial fix was just a writerfilter/ tweak to avoid grab-bagging <w:id> for inline <w:sdt>, but CppunitTest_sw_ooxmlexport4's testSimpleSdts points out that in other cases we already require preserving <w:id>. Fix the problem by storing <w:id> in the content control, which is essentially a subset of <https://gerrit.libreoffice.org/c/core/+/142818>. Thanks to Justin Luth! - he prototyped the DOCX filter for <w:id>. (cherry picked from commit 100c914d44ae8f362924fe567d7d41d0033ae8ad) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport18.cxx Change-Id: I9f002b770049ce8be30253d0b39410d9a58981dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143139 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-11-23sw content controls: fix SdtHelper missing clear() itemsJustin Luth
Found during a code read, while attempting to add another property. (cherry picked from commit e960d3fea28fe4c180dc5612ce00682e432e9772) Change-Id: I342c51c81f23e1e3178e7d412f9af685f3fd4ae2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143138 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-11-10sw content controls: allow no list items in a dropdownMiklos Vajna
- Replace SwContentControl::HasListItems(), which assumed that the type is dropdown if we have list items. This is not valid, it's OK to have a dropdown with no list items. Add a GetDropDown() instead to check for the type, explicitly. - UNO API sets the dropdown bit when list items are set and the type is not expilcitly combo box or drop down, to keep backwards compatibility with existing documents. - No change to the edit shell, SwDropDownContentControlButton already checked if items are empty and used STR_DROP_DOWN_EMPTY_LIST in that case, but that was dead code previously. - ODT & DOCX filters are now updated, ODF has a new <loext:content-control loext:dropdown="..."> attribute to specify that the type is a dropdown, explicitly. (cherry picked from commit 56db6406b0b63a2d2d99024e7c311ebd874f3893) Conflicts: xmloff/qa/unit/text.cxx Change-Id: Id577ba9639151549a8f953aab31685a73a898504 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142544 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-10-26sw content controls: enable data binding for dateMiklos Vajna
The document had a 2022 date in document.xml, but had a 2012 date in data binding. Writer used to show 2022, while Word picks 2012. Data binding for dates were disabled in commit de90c192cb8f1f03a4028493d8bfe9a127a76b2a (sw content controls, plain text: enable DOCX filter with data binding, 2022-09-19), because the formatting of those date timestamps were missing, so it was better to just not update them from data binding, temporarily. Fix the problem by adding a new read-only DateString property on SwXContentControl, this way the import filter can set not only the timestamp but the formatted date as well. This shares the SwContentControl::GetDateString() code with the UI, which already had the need in the past to turn a timestamp into a date string, based on a provided language and date format. (cherry picked from commit 58002ab85d992c7ac44d8bb4d135246b67aa5cc7) Conflicts: sw/source/core/unocore/unomap1.cxx Change-Id: I842a9483a675f895129a9854caec347be6b6b84e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141867 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-10-16tdf#138625 DOCX import: fix superscript footnote numbering in l10nLászló Németh
Footnote/endnote numbers in the footnote area didn't get superscript etc. formatting in non-English locale settings because of the writerfilter mapping to the English localization ("Footnote Characters" and "Endnote Characters") instead of the correct programmatic character style names ("Footnote Symbol" and "Endnote Symbol") according to SwStyleNameMapper::GetChrFormatProgNameArray(). Testing: unit test of tdf#82173. Manual: e.g. open test document of tdf#138625 in an Italian build, after setting Italian locale in it in Tools->Options...->Language Settings-> Languages->Language of user interface. Follow-up to commit 707eb4db1918658e0c2c2c2033c6a69f80c4eafd "tdf#82173 writerfilter: charStyle XnoteReference->Xnote Characters". Change-Id: I36b3c5ff065e9f80289d051e27f618b40e0c9355 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140918 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 5a1c668747f3495ddc7567ae95f2145663565647) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140891 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2022-10-16writerfilter: avoid divide by zeroXisco Fauli
in DomainMapperTableManager::endOfRowAction() See https://crashreport.libreoffice.org/stats/signature/writerfilter::dmapper::DomainMapperTableManager::endOfRowAction() Probably since 116cadb5d2582532c69677a2f8499e8e9b7b9b80 "tdf#59274 DOCX import: fix tables with incomplete grid" Change-Id: I12f2842107885fbbc62be2186511102f642e3efc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139657 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit b69a37e567a6a0b6c24a4438a0da906497c750f0) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139660
2022-10-12tdf#151261 DOCX import: fix dropdown SDT when the item display text is missingMiklos Vajna
Dropdown content controls have list items, and each list item can have a display text and a value. These are optional, and the bugdoc has a list item where the value is set, but not the display text. The trouble is that later in DomainMapper_Impl::PopSdt() we check if the length of the display texts and values array match and if not, then we throw away these arrays to avoid creating an inconsistent document model. Fix the problem by checking what display text and value we got at the end of each list item; if any of them is missing, we add an empty string, which matches the internal representation in SwContentControlListItem. This also helps in case these array sizes matched by accident, but display texts and values from different list items were mixed previously. (cherry picked from commit f726fbc2699b05199a8dec3055710a7131e0aad6) Change-Id: Ib1eeabd2479963af4a84d4229d4f0ce4572e0f01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141162 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-10-07sw content controls: preserve tagMiklos Vajna
This is similar to <w15:color> to preserve <w:tag>. Resolves <https://gerrit.libreoffice.org/c/core/+/137399/2#message-a5ba9f1e0dc9e586034758ee7c0a94e1533e8922>. (cherry picked from commit 5262aab9d220675f616579720b4bb43ee03cccfb) Conflicts: sw/source/core/unocore/unomap1.cxx Change-Id: I4fdab44aaf13ca812502ae79f38f32ec9468db11 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141025 Tested-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-10-07sw content controls: preserve aliasMiklos Vajna
This is similar to <w15:color> to preserve <w:alias>. Related to <https://gerrit.libreoffice.org/c/core/+/137399/2#message-a5ba9f1e0dc9e586034758ee7c0a94e1533e8922>. (cherry picked from commit 481a082469802ffce08cd8c110e715260015eb97) Conflicts: sw/source/core/unocore/unomap1.cxx Change-Id: I774b7204c5ca02ec6db89f5cbd3a6de6f2bf82a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141024 Tested-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-09-23sw 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. (cherry picked from commit 01b1f57a90172a76faa1489b3b72250ee76169a6) Change-Id: I50e0b961bca99f4ecca86d6784d2e6a13f469314 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140432 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-09-23crashtesting: fix DOCX export of forum-mso-de-99522.docxMiklos Vajna
Export of this document to DOCX wrote not-well-formed XML output, resulting in an assertion failure in debug builds. writerfilter/ maps a selection of <w:sdt> tags to Writer content controls (a safe subset), and leaves the rest unchanged, which means we continue to map those to grab-bags. The trouble is that a combination of content controls and grab-bags leads to bad output on export, as we start the <w:sdt> element twice, but only close it once. Fix the problem by extending writerfilter/ code to not do any grab-bags for the richText type, we already did that in the past for dropDowns. In the long run, we should never do grab-bagging for any <w:sdt> elements that we map to Writer content controls. (cherry picked from commit 7ad44f3dd271a591529b048212c4391d8b38ed9d) Change-Id: I27a0b814efd667cc0477d8f492f7f956c938c854 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140431 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-09-20sw content controls, plain text: enable DOCX filter with data bindingMiklos Vajna
- writerfilter/ had explicit code to not map plain text SDT to Writer content controls if it has data bindings specified, lift this limitation and set the value of content control from data binding, like Word does and Writer did it for input fields since b5c616d10bff3213840d4893d13b4493de71fa56 (tdf#104823: support for sdt plain text fields, 2021-11-24) - call DocxExport::AddSdtData() on the export side to do the opposite on export - give up on the idea to export content controls to DOCX by finding the text attribute in SwWW8AttrIter::OutAttrWithRange(): this needs buffering in both directions (need to start the SDT before the start of the run, need to end it after the end of the run), and solving this using marks and merges at a fast-serializer level looks like hacks on top of hacks. To be more specific, CppunitTest_sw_ooxmlexport7's testSdtAndShapeOverlapping seems to be very hard to fix with this design - instead, give not only the start position but also the length of the run to DocxAttributeOutput::EndRun(), which has random access to the doc model and can look up if there is a content control start or end that needs writing at the current position of the XML output, without any buffering, which also means less code - adapt CppunitTest_sw_ooxmlfieldexport's testSdtBeforeField, which didn't like the empty run at the start of content controls, which seems to be harmless otherwise - fix CppunitTest_sw_ooxmlfieldexport CPPUNIT_TEST_NAME=testSdtDateDuplicate by disabling the "set content control value from data binding" logic for date pickers because that logic in writerfilter/ sets the value as-is and it has to consider the requested date format before this can be enabled As a side effect, this gives PDF export for plain text SDTs, even if they have data binding set. CppunitTest_sw_ooxmlfieldexport's testTdf104823 is now updated to ensure that we import such SDTs as Writer content controls. (cherry picked from commit de90c192cb8f1f03a4028493d8bfe9a127a76b2a) Conflicts: sw/qa/extras/ooxmlexport/ooxmlfieldexport.cxx sw/source/filter/ww8/docxattributeoutput.cxx sw/source/filter/ww8/wrtw8nds.cxx writerfilter/source/dmapper/SdtHelper.hxx Change-Id: I749a845b5a25454c51066b8ded892682f523b6b4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140180 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-08-28tdf#143703 sw: always assign name for fly sectionVasily Melenchuk
Previously generated name was assigned only if not in doc reading mode. But there is no guarantee that it will be assigned later. Better to insert any name in SwDoc::MakeFlySection_() and later it can be overwritten, but fly will definitely have any unique name. * Some test failed because GraphicImport_Impl::applyName() overwrote the name with a different generated one. * This breaks chaining of VML shapes, see test testTDF87348. The code introduced in commit 091fe76b6329b4bb974987554369cbfadd8f2401 in DomainMapper_Impl::ChainTextFrames() breaks if the text frame already has a name; it's a bit confusing which names there come from the file and which come from the API, and it also mixes 2 different cases of VML chaining and DrawingML chaining that look like they should be using different data. * This also breaks moving flys anchored at-char in flys into them in SwXText::convertToTextFrame(), see ooxmlexport13 testFlyInFly. This kind of worked by accident before: the fly is copied and then the original deleted, keeping the same name (with help of SwDoc::mbCopyIsMove); with no name it would compare the SdrObject pointer, which is different for the new copy, now the name is the same. Fix this by only moving flys anchored at the edge of the selection back inoto the body; it turns out that Word actually supports at-char anchors in text frames, but only if it's a VML shape or Compatibility Mode or whatever; i wasn't able to do it in a document created from scratch. This is a bit tricky to ignore the nodes added for floating tables as seen in ooxmlexport10 testFloatingTablesAnchor. * Another change is required in SwDoc::SetFlyName() because of testTdf127732, as it would rename a frame named "Frame1" to "Frame2" when called to rename it to "Frame1". * Some tests failed because after MakeFlySection_() assigns a name it is immediately unconditionally overwritten; replace that with asserts Change-Id: I46752a4413ba3a9e981eccd1e153b3aaf8053781 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127556 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 4d6243693c228703394c00164276f8326447beb9) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137764 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2022-07-27sw content controls, plain text: add DOCX importMiklos Vajna
- the core of this is the writerfilter/ change to call PopSdt() for SdtControlType::plainText, which maps inline plain text SDTs to Writer content controls, not to input fields - disable the grab-bag in this case, otherwise we would run duplicated <w:sdt> elements on export - fix CppunitTest_sw_ooxmlexport7's testSdtAndShapeOverlapping by postponing the SDT start in DocxAttributeOutput::WriteContentControlStart() in case a shape is anchored at the same position as the SDT start: if the shape should start inside the content control, then it should be anchored after the dummy character - reduce the debug output in VMLExport::Commit(), which could write control characters to the terminal on test failure, potentially breaking it (requiring a 'reset' to recover) - fix CppunitTest_sw_ooxmlexport5's testSdt2Run: now we merge two runs inside a plain text content control into a single one, and there is no problem with that, so adapt the test instead - fix CppunitTest_sw_ooxmlexport17's testTdf148361: plain text inline SDT is now a content control, not a field - fix CppunitTest_sw_ooxmlfieldexport's testfdo82492: explicitly assert that there is 1 text run inside the SDT and there is a shape after it (outside). Also extend DocxAttributeOutput::EndContentControl(), so it ends the content control at the correct, earlier position in case it's followed by an as-char shape - fix CppunitTest_sw_ooxmlfieldexport's testfdo82123: again assert that the SDT has 1 run with text, and there is a drawing after the SDT - fix CppunitTest_sw_ooxmlfieldexport's testTdf104823: this revealed that some more complex logic is needed to support data bindings, so exclude text-with-databinding from the scope of this commit and continue to map those to input fields for now - fix CppunitTest_sw_ooxmlfieldexport's testFdo81945: this had a similar problem as as-char shapes, but this time a new SDT is starting right after a previous SDT. Adapt DocxAttributeOutput::EndContentControl() accordingly, though perhaps this should be generalized later, so we always close SDTs in the previous run, unless this is the last run, or something similar (cherry picked from commit 9700c1b2170ad04453a361ed5647937833ac3c18) Conflicts: oox/source/export/vmlexport.cxx Change-Id: Ifaf581be884a683de6c8b932008a03ba43734b75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137494 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-06-30tdf#149654 sw content controls: fix missing string before inline SDT from DOCXMiklos Vajna
The document had a block SDT and inside that, a run SDT. The content that is before the run SDT but already inside the block SDT was lost. To work incrementally, it was intentional that once commit 5ee8670f18cb8b1913a23d04590d6a31ac9730de (sw content controls, date: add DOCX import, 2022-05-30) changed most of run SDTs to content controls, it left block SDTs (and cell/row SDTs, too) unchanged, so they are still mapped to fields. What was forgotten is that m_pImpl->m_pSdtHelper in DomainMapper is a shared state: once a run SDT starts, it assumes that no non-run SDTs are in progress. Fix the problem by explicitly checking for non-run SDTs before PushSdt(), that keeps the separation (content control for run SDT, fields for the rest) but fixes the lost content. This is for plain text SDTs, but other types can be added if necessary. (cherry picked from commit bab023ce3b584e815067a207adc7a8aca1f964af) Change-Id: I46b029a3a945d7416028aa196ac3160e6d96eae8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136664 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-06-27crashtesting: fix assert seen with forum-mso-en-8349.docxCaolán McNamara
a string that ends in spaces Change-Id: I808f046be816d0d4a76f801a349e284024a2061c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136465 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-05-31sw content controls, date: add DOCX importMiklos Vajna
- map <w:date> <w:dateFormat w:val="..."/> <w:lid w:val="..."/> </w:date> to the Date, DateFormat and DateLanguage UNO properties of content controls instead of fieldmarks, which model content controls poorly - fix CppunitTest_sw_ooxmlexport8's testN820509: date SDT is now a content control - add current date DOCX import - fix CppunitTest_sw_ooxmlexport13's testDateControl: date SDT is now a content control - fix CppunitTest_sw_ooxmlexport13's testInvalidDateFormField: date SDT is now a content control - fix CppunitTest_sw_ooxmlexport5's testfdo83048: minimal support for nested SDTs in DomainMapper::lcl_attribute() - fix CppunitTest_sw_ooxmlfieldexport's testDateFieldAtEndOfParagraph: date SDT is now a content control - fix CppunitTest_sw_ooxmlfieldexport's testDateFieldInShape: date SDT is now a content control - fix CppunitTest_sw_ooxmlfieldexport's testSdtDateDuplicate: date SDT is now a content control - fix CppunitTest_sw_ooxmlfieldexport's testSdtDatePicker: - retain placeholder - retain data binding - retain color - fix CppunitTest_sw_ooxmlimport2's testTdf121203: date SDT is now a content control - fix CppunitTest_sw_globalfilter's testDateFormFieldCharacterFormatting: date SDT is now a content control - fix CppunitTest_sw_globalfilter's testDateFormField: date SDT is now a content control (cherry picked from commit 5ee8670f18cb8b1913a23d04590d6a31ac9730de) Conflicts: sw/qa/extras/globalfilter/globalfilter.cxx Change-Id: I5a4c34217d23ed6fa0916e4dd6290351456b7232 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135152 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-05-25sw: copy grab bags in mail mergeMichael Stahl
Otherwise formatting may get lost when the result is stored as DOCX. Change-Id: I62cbeb1fc9f120dd9c424daf5dc0471686715537 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134694 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 123d3a9301c90925c23cfb4806d7b0be01b975d6) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134762 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-05-25tdf#148132: Revert "n#758883 dmapper: paragraph-level..."Vasily Melenchuk
Seems original problem is no longer reprodicible with recent builds but ovewriting of numbering style params with inline values leads to another problems. Removing this mechanics do some impact on RTF filter: it tries to modify numbering styles, so this was also corrected. It is not ideal yet but looks better in support numbering char properties different from paragraph ones. This reverts commit 2123ede032ca64f696ef54af4ad3238974ca2b5d. Change-Id: If8c79d6191de13b2f09c128b59d17efcfdb1a4ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133877 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134636
2022-05-25tdf#148455 docx import/export: improvements to lvlOverrideVasily Melenchuk
On save LO was just emitting w:lvlOverride to actual level where override does happen. But MS Word won't accept override for next level if there are no overrides for previous ones. For example, if we are overriding level 3 we should also emit empty lvlOverride for levels 0-2. Provided fix did cause some problems on DOCX import: overrides were applied to current level, but in this context current != actual level where override did happen. Change-Id: Ia00dd9a5990f7f122027e8126f411642c32da189 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134411 Tested-by: Jenkins Tested-by: Gabor Kelemen <kelemeng@ubuntu.com> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> (cherry picked from commit 198381eb32edcc3e82d0f23df65f0804a08b44e6) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134452 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-05-24sw content controls, picture: add DOCX filterMiklos Vajna
Map Picture UNO property on content controls to: <w:sdt> <w:sdtPr> <w:picture/> ... And do the opposite on import. (cherry picked from commit 22d7cbc0f0c50c59abca7ab5f7db46e4d0e5f86a) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport17.cxx Change-Id: I5b164f796f194f5fc4bb30d7a30e053e577ed92d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134848 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-05-13tdf#146346 DOCX import: fix table margins in footnotesLászló Németh
Paragraph of the anchoring point of the floating table needs zero top and bottom margins, if the table was a not floating table in the footnote originally, otherwise docDefault (Standard) margins could result bigger vertical spaces around the table. Quasi regression from commit c46950fee11f5207fb8324947280cd565ae483e7 "tdf#143583 DOCX import: fix lost empty paragraphs of footnotes" (before this commit, empty paragraphs at the end of the footnotes were removed by accident, which hid the real problem fixed now). See also commit e11c51eefe8c3210cef2b5850f401ba67a401d01 "tdf#95806 tdf#125877 tdf#141172 DOCX: fix tables in footnotes" (Note: before this commit, only a single table was shown instead of the eight tables of the eight footnotes.) Change-Id: I4180a6f7d7c49faf0842637b23aa1c8c5680a76c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133752 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit d1ac8df139a2a65db45d1970ccc0b80e17d827f6) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133728
2022-05-13sw content controls, drop-down: add DOCX importMiklos Vajna
- inline drop-down content controls were imported as an SwDropDownField previously, but that has the drawback of not being able to store both display texts and values of each list items - adapt tests under sw/qa/ which asserted that the import result is a field, and check content control properties instead - change dmapper so that SdtControlType::dropDown is one more inline SDT that gets mapped to SwContentControl - remove the no longer needed grab-bagging in writerfilter/, otherwise we would write the SDT markup twice on export - improve DomainMapper_Impl::PopSdt() to actually map the collected dropdown properties to properties on the to-be-inserted content control (cherry picked from commit 24417d8c3c9e1c619936e85fa7a20481a24e3530) Conflicts: writerfilter/source/dmapper/DomainMapper.cxx Change-Id: I7e88ec8cd1d73bc1c6c75154d6ab07352cbcec8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134258 Tested-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-05-03sw content controls, checkbox: add DOCX importMiklos Vajna
My expectation was that <w14:checked w14:val="0"/> would be mapped to a single SPRM where the int value is 0 or 1 depending on if this is a true or false boolean. But the w14 tokenizer rules actually created a NS_ooxml::LN_CT_SdtCheckbox_checked token with a NS_ooxml::LN_CT_OnOff_val token in it, which itself again didn't contain just a bool but dedicated NS_ooxml::LN_ST_OnOff_true, NS_ooxml::LN_ST_OnOff_1, etc values. To make this more complicated, TextEffectsHandler even depends on this weird behavior. Bring the w14 rules closer to the "main" wml rules by folding the NS_ooxml::LN_CT_OnOff_val token into the parent token (NS_ooxml::LN_CT_SdtCheckbox_checked in this case), but leave the NS_ooxml::LN_ST_OnOff_* values unchanged for now. The rest of the changes are more straightforward: we now handle inline/run checkbox SDTs similar to rich text ones, i.e. map them to Writer content controls, rather than just doing a poor mapping to grab-bags. The main benefit here is that the checkbox type of Writer content controls actually change their value on mouse click, so it's possible to fill in such forms. (cherry picked from commit c53d3a1f4b8430507d54f5fac336870df7a700af) Conflicts: writerfilter/source/dmapper/SdtHelper.hxx Change-Id: Idbf49a8ff1843d5271f2836e5299c4387bb58e55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133743 Tested-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-04-27tdf#148515: RTF filter: do not use char prop defaults for tablesVasily Melenchuk
During deduplication of table row (when nStyleType == 0) we should not deduplicate character properties against default style: this leads to invalid default settings for table rows/cells. Attempts to do so are already made during \pard processing when default style is checked if it is paragraph style. But this is not enough: style definition can contain paragraph and character properties as well. Change-Id: If520c5a248897728b7de08a017136ca1a01a5f13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132943 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> (cherry picked from commit 3a05acb8f0d94728ea6cbfd7a69dac6ffa7ffc68) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133477 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-04-27tdf#139948: docx and rtf import: emulate border in betweenVasily Melenchuk
Writer does not support border in between available in all MS formats. Since this feature is missing in core it will be better to emulate it with top borders than to ignore it completely. Change-Id: I4e5a99cde5908066c4bb483136cfe9a1316df53c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132429 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit e3a996bf72a16f5b22e6ff021745af5cec70a632) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132594 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-04-25sw content controls: add initial DOCX importMiklos Vajna
- map inline/run SDTs with unknown type (i.e. rich text) to SwContentControl - decouple block and run SDTs and leave block ones unchanged - track start position of run SDTs similar to bookmarks, which needs different code to SDT at text start vs later - fix DocxAttributeOutput::RunText() to please CppunitTest_sw_ooxmlexport2's testFdo67013, which had an inline SDT in footer, not at para end (cherry picked from commit f2ab1375b266d7465ef31d06ec8f949c6b91d853) Change-Id: I59b8b7f3170cf37f1547db07ae0992850e0e3aa8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133330 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-04-14tdf#95706: RTF import: tolerant font table parsingVasily Melenchuk
While font name in font table should end with semicolon ({\fonttbl{\f42 Arial;}}) it is not always true and MS Word is tolerant to it: it still able to parse this correctly. Seems LO also should not require strict spec conformance. So idea of font parsing is changed: instead of inserting font on semicolon, it is done on next \fN or destination end. All collected text to this moment is a font name. Change-Id: I6b41951217442a71fd2ebbfc58a3fc79f6f913db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132686 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 844be7358f1eec00094a55fa1fb4fadadb8cd1bf) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132699 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-04-09tdf#95706: RTF import: Use fontname suffixes to detect encodingVasily Melenchuk
Font names like "Arial CE", "Times New Roman Cyr" are not special fonts. They are classical Arial, Times New Roman... And these suffixes can be used to detect encoding used for RTF text. Most interesting: for MS Word these suffixes have priority: {\f34\cpg1253\fcharset161 Arial Baltic;} will have cp1257 and not cp1253. Looks like compatibility issue came from dark ages. Change-Id: Ife8e781d5d04c3f6a8c11fcf604357c74bf33055 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132584 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132681 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-04-06tdf#148361: docx sdt: cleanup databinding data after insertingVasily Melenchuk
Databinding data is used only for current sdt block. It should be clean up after usage to avoid impact on next sdt blocks. Change-Id: I53f47dd655ed027d40eb518784dcae69813e612f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132524 Tested-by: Jenkins Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de> (cherry picked from commit fafadd7aee8c384af210008f693b5007a9f5ea48) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132595 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-04-06tdf#148273 docx import: fix section break format leak to bulletsSarper Akdemir
Fixes RES_PARATR_LIST_AUTOFMT leaking into the next section. Achieves this by resetting list related attributes on the cursor's text node in DomainMapper_Impl::RemoveLastParagraph() after the deletion of the paragraph. Change-Id: Ib4d09c5f190b8b8fd3bdc119ddd57d91f353de2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132324 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132440 Reviewed-by: Andras Timar <andras.timar@collabora.com>
2022-04-06tdf#116358: rtf import: "keep with next" also affects table rowsVasily Melenchuk
Like in DOCX for RTF there is exactly same behavior for paragraphs inside cells. They do affect table breaking over the pages. So: 1) Enable "TableRowKeep" doc setting for RTF documents. 2) Do not ignore \keepn token for paragraphs in tables. Change-Id: I11e45ca9114c792b8cdbeb77dd51359717129651 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132305 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132355
generated by cgit (git 2.34.1) at 2024-06-27 10:21:22 +0000