summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)Author
2020-11-05RTF import: change exception type thrown on destination errorsVasily Melenchuk
Previous exception (std::out_of_range) was not catch in case of invalid RTF imported: wrapping code checks only for uno::exception. This is not a case for loading file, but for parsing of clipboard containing invalid RTF it was causing fatal error, freeze and/or LO crash due to unhandled exception. I think there is no reason to add generic processing for std::exception in RTF filter: this can complicate diagnosing other potential problems. Instead let's throw UNO exception, like in other parts of RTF filter code. Change-Id: I064bbdc1559cc7700c96dbbeaf2911a2c8e0421e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105285 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit 0d84e4bed71a1083c5189408aea5922a34b40686) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105227 Tested-by: Vasily Melenchuk <vasily.melenchuk@cib.de> Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-09-28Merge branch 'libreoffice-6-4'Michael Weghorn
into distro/lhm/libreoffice-6-4+backports Change-Id: Id89f295a3e669a51da822c09a759165dfc79dc6f
2020-09-25tdf#134782 sw: split AddParaSpacingToTableCells flag in 2Michael Stahl
commit 3cccdabf19a99fd3f657985c1822436d7679df2b "extend AddParaSpacingToTableCells with line spacing" changed how the ADD_PARA_SPACING_TO_TABLE_CELLS compat flag works, to improve interop with Word. This commit splits out the change as a separate new compat flag ADD_PARA_LINE_SPACING_TO_TABLE_CELLS ("AddParaLineSpacingToTableCells"), to preserve compatibility with ODT documents that were produced by LO < 6.4 (via SwXMLImport::SetConfigurationSettings()). New documents and WW8/RTF/DOCX import have both flags enabled. The combination false/true is invalid, and treated as equivalent to false/false. Change-Id: Ida20df8fe4a8192a714f91da95345f9726fd7d98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103317 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 38aa699f265c17548769aaa4f20e1ae35d18f202) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103359 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-09-11Merge branch 'libreoffice-6-4'Michael Weghorn
into distro/lhm/libreoffice-6-4+backports Change-Id: Ib3030257fb7c4eec5b910c0b49332be0dd8fa854
2020-08-28tdf#131801: sw: support of style references in ListAutoFormatVasily Melenchuk
ListAutoFormat property did support char attributes, but not style references ("CharStyleName"). It is important for correct formatting of pilcrow symbol or list format in some DOCX scenarios. Export to DOCX already works, but not to RTF/DOC. Change-Id: I1bf23d1e45fcc213adcf9aa6f404be803919fbee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100893 Tested-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit c77b9c349f0a48392d8cb7a49532844b2cafb5ba) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101560 Tested-by: Jenkins
2020-08-13tdf#128197: sw: different line height for DOCX with compat=14Vasily Melenchuk
Lines containing just a shape inline without any other text are treated in DOCX with compatibility option 15 and 14 in a different way: while compat=15 is layouting line exatly as LO does, in compat=14 mode minimal line height takes into account just shape height and not current font. Change-Id: Id2bdab941a0bbaa9080567d736435d9e0babd490 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96080 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100542
2020-08-12tdf#134043 DOCX import: new unit tests: ComboBox to DropDownThorsten Behrens
Change-Id: I034b0cd9c6f66c531460d1bb69d9ede5ff46f7d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97531 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99994 tdf#134572 DOCX: Incorrect default value in dropdown text fields Change-Id: I3169e817c2f033d1525adc3b02ac3680ad220d70 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99074 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100306
2020-07-22tdf#134400 RTF import: fix unexpected inner properties for picture-in-textframeMiklos Vajna
Regression from commit 4ab658b56f5c6ff0082d38d8ace1924d11e30e96 (RTF import: implement support for tables inside text frames, 2013-06-16), the problem was that both the outer "textbox" and the inner "picture frame" object had a shapeType property, and the properties were stored in a vector. So by the time RTFSdrImport::initShape() looked up the shape type for the inner shape, it thought it's not a picture frame, leading to data loss. (cherry picked from commit 5a083be34456e91427d0f2e2fea172f49f4502db) Change-Id: I4a536789371619d1d54afa8c8d41c7d273b0d21b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99118 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99167 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-07-09tdf#134260: docx import: allow default value for list tab positionVasily Melenchuk
It looks like previously used as a testcase document is just a specific case with default values. All other readers (incl. Office 365) displaying that doc with default tab at zero position. Change-Id: I50fe00c7f87b6d790fbe6e2f32a306ac59060c72 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97089 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit 7221994b9b29659d3290e95eee92b1a3f80c2b7e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98331 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit 54b6a6a5c95ed51ce0cd709d9fd3e477ced5ce8f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98332 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-07-07tdf#134264 writerfilter: fix DOCX->DOC of ADDRESSBLOCK fieldMichael Stahl
... and other unsupported ones; the problem was that the field got exported with ww::eUNKNOWN = 1, which can't be imported again. Move the ww8 eField enum to include/ so it can be used from writerfilter. (regression from e511a0ca5dde6d731bb126bbfe21768867890102..d9030ad6298e2f49ee63489d6158ea6ad23c0111) Change-Id: I19193392d62fdf0bba01fac2516bafe9fdfa5a99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98221 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit ae2e8202407e82c9b14f0cc307742561f8c6e530) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98244 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-02Merge branch 'libreoffice-6-4'Thorsten Behrens
into distro/lhm/libreoffice-6-4+backports Conflicts: writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx
2020-07-01DOCX import: fix margins of inline shapes with effects, imported as Draw shapesMiklos Vajna
Effects have an extent, and unhandled effects (like this blurred shadow) need to take space in the margin of the shape to make sure they use the correct amount of space in the layout. This was working in general, but not in case the importer decided to import the shape as Draw shape + the shape was inline. (And also disable a new CppunitTest_sw_uibase_shells test on Windows, which is only stable on Linux, it seems.) Change-Id: I9d0531d9393d8c2cd274e6f54bbbfe8024bf270f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88427 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit bf25e69f8f657d5e3bcdd0bd54c5fa0d66ec85fe) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96234 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-06-30tdf#134043 DOCX import: DropDown text field instead of ComboBox form controlSerge Krot
Change-Id: Ide9cedefde3b00fa0eeb37a6540e8d4a420b70c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96471 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96608
2020-06-18tdf#128195 Keep spacing below last paragraph in header (docx)Samuel Mehrbrodt
Add a layout compat option to keep the spacing below the last paragraph in the header in doc/docx files Change-Id: I259511183a8252e04d9951357dbdd4f4832523ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94577 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit 9b5805d1ef2b9e9c4e8f389c069807bf4489ea95) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96337 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-06-12tdf#83309: docx import: allow for lists tabstop at zero positionVasily Melenchuk
Zero position is valid value for tabstop, but previously it was treated as "no tab stop defined". Right now writer distinguishes tab stop at zero postion and no tab stop. Change-Id: Ie32da3d36a263644ba85a882029a8b29ae0501c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95132 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit d2e428d1abb9f2907c0b87d55830e8742f8209b9) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95561 (cherry picked from commit a380a06c1872091e8fa8c810e95a8e1d5dfe1820) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96178
2020-06-12tdf#120394: DOCX list import: simplify zero width space hackVasily Melenchuk
Since introducion of list format string hack with creation of zero-width-space can be much more simple. It was being used to indicate existing, but empty list label suffix to avoid stripping down numbering. Change-Id: I9a0c6047f806b2c656ef5dbab0c6b38200818bd2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94383 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95346
2020-06-11tdf#132754: DOCX import: changed default list start nubmerVasily Melenchuk
Default value for list numbering startAt is zero. If it is not proveded numbering starts from this value. Change-Id: I2cf7be9063e7bfb8b72d6ba77fcd9507e33bb848 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93899 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit f8211e84a5239de25fe6dc45a4bb6b6f8673a1ee) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96048
2020-06-10tdf#120394: docx import: support for w:styleLinkVasily Melenchuk
Previous implementation for w:numStyleLink was referring just ordinal styles, but there can be another abstract list marked with w:styleLink which should be used in given context. Change-Id: Ic5d4fe8bfd41b19e2f65d74defb6961e38ec9a9d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94332 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95892
2020-06-09tdf#132596 writerfilter: fix paste of RTF with header/footerMichael Stahl
The problem is that writerfilter inserts the content of header/footer into the body text, but then DomainMapper_Impl::PopPageHeaderFooter() calls RemoveLastParagraph() and deletes a body paragraph containing a fieldmark, and then in Undo some SwHistoryTextFieldmark can't find it, and since ffb26b81e1c7ff1d64959200247bb2edd5a569da this crashes. This is because of the borked error handling in DomainMapper_Impl::PushPageHeaderFooter(); the m_xBodyText->createTextCursorByRange() call throws an exception that is swallowed, so the m_aTextAppendStack doesn't have an entry containing the position in the header. To fix the error handling, set m_bDiscardHeaderFooter = false only when everything was successful. Also fix the call to be xText->createTextCursorByRange instead (this is a regression from 232ad2f2588beff50cb5c1f3b689c581ba317583). Then it turns out that Undo still crashes, because sw can't Undo changes of header/footer content, so just return early unless it's a new document. Change-Id: Ie5aeb45447c5fbd4b3ae15c4cffb9800583a6d1d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95797 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 27151ccf2305eac4192f8c4ceeee267170096a19) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95824 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-06-04Merge branch 'libreoffice-6-4' intoMichael Weghorn
distro/lhm/libreoffice-6-4+backports Change-Id: I6c4e4dc74df1a1ce0455526a067c5286534922be
2020-05-28tdf#78352: docx import: allow tab at left indent for listVasily Melenchuk
Looks like first tab stop for list bullets is at left paragraph boundry. Luckely there is a compatibility option for this. Change-Id: Iea4bd2b51912746dbd4722ff61eeb2e9293cab31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94559 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94971
2020-05-19tdf#127778 DOCX import: fix unexpected heading on non-first page ...Miklos Vajna
... when the first page has a heading Regression from commit 17e51f427b3f0cec74ac8e0a1b3f51189006ae6f (DOCX import: first page header should always set default headers as well, 2014-11-21), the problem is around how to split a first + follow page style on import, and then do the opposite on export. This is described using a single section in OOXML, but Writer has 2 page styles for this (unlike in case of the DOC filter). This means the header margin has to be taken from one of these page styles. The above commit tweaked the import, so the follow page style has the wanted header margin, but this leads to incorrect layout. Fix the problem by tweaking the export instead: it has random access to the doc model, so it can take the header margin from the first page style if needed, and then the import side can be reverted, leading to correct layout. Also remove some leftover debug code in test/, which was added in commit 5352d45dd4a04f8f02cf7f6ad4169126d3b3586a (convert AnimationImport to fast-parser APIs, 2020-02-18). (cherry picked from commit 51534ac2b9747975945acb6a1e1ba5cc6d73f5c2) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport6.cxx Change-Id: I4bbf7271f3a437e8432399bd1e32e9d24190a501 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94193 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-05-18Merge branch 'libreoffice-6-4'Michael Weghorn
into distro/lhm/libreoffice-6-4+backports Change-Id: I6861987a5897fa12bf962d4274f1ce52c3efa05e
2020-05-15tdf#132514 DOCX import: fix lost table style with footerLászló Németh
Table paragraphs collected for table style processing were mixed when both body text and footer contain tables, i.e. clearing paragraph vector at processing the first table resulted missing paragraph vector and table style processing for the other one. (Note: only missing bottom paragraph margin and line spacing were the problems here, not all table style based paragraph settings, as in branch 'master'.) Now tables in footer, also nested tables collect their paragraphs in separated table paragraph vectors. Regression from commit 6c5da2cd7af5c2d90e4d8e9635ba8c9989c87923 (tdf#119054 DOCX: fix not table style based bottom margin). Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93415 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 81ce88aa80f8e7cde4fdc5b211e9500a3599643c) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport6.cxx writerfilter/source/dmapper/DomainMapperTableHandler.cxx writerfilter/source/dmapper/DomainMapperTableManager.cxx writerfilter/source/dmapper/DomainMapper_Impl.cxx writerfilter/source/dmapper/PropertyMap.hxx Change-Id: Ib8568d8379cfb7da869120cdc7fe12895252d661 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93525 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-05-14Merge branch 'libreoffice-6-4'Michael Weghorn
into distro/lhm/libreoffice-6-4+backports Change-Id: Iddad99c684fb0a7401ae39f64c54f55808b83d6c
2020-05-13tdf#94628: sw: allow setting for bullet for outline paragraphsVasily Melenchuk
Paragraphs in outline (having style "Header XXX") can also be a part of list and have custom bullets. Simplified code of SwXNumberingRules::SetPropertiesToNumFormat(): do not check for properties special for outline/chapters and removed redundant data shuffle with local maps. Change-Id: I1fa7f8f5359acee1d5aa62d9700641490bb91b6c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93672 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94032
2020-05-13tdf#95189: docx import: apply list ovverride only onceVasily Melenchuk
List overrides should be applied only once on first list with override appearance in document. Next reference to this list should not override again and reset list numbering. Change-Id: I7a24398d5980ca97a74fa8ad09d91ac9adff15ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93894 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94031
2020-05-07Merge branch 'libreoffice-6-4' into distro/lhm/libreoffice-6-4+backportsMichael Weghorn
Conflicts: writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx Change-Id: I2e0b84875a10a1255d88d54a3c5857c3e5832521
2020-05-05tdf#116883: sw: support for lists level format stringVasily Melenchuk
Multilevel lists are more flexible in case of DOCX. There is supported custom format for any level in DOCX unlike in LO and ODT where we are limited only with prefix and suffix for hardcoded list levels separated by dot. At the same time DOCX can have lists not only "1.2.3.4", but "1/2/3/4" or even "1!2>3)4" and such format can vary on each list level. Here is basic implementation for list format as a core feature for all documents and old way (prefix-suffix + ".") is left as fallback. Practically its usage is currently implemented only in DOCX import/export. Some RTF/OOXML unittests were redesigned: since we are not creating prefix/suffix for these formats conditions should be checked in a different way. Change-Id: I1ec58bcc5874d4fa19aee6a1f42bf1671d853b14 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92106 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93125 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Change-Id: Ia8f066913a2565559d81f3caabeba24b29c09052 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93456
2020-05-05tdf#108496: DOCX: redesign of override in listsVasily Melenchuk
List level overrides are not just about numbering, it is about numbering restart. Thus some changes to DOCX import/export were added. Improved support for several lists referring the same abstract list, especially in situation when one list have overrides. In addition some export cleanup is made: less unnecessary list duplications, less level overrides when no properties were changed. Change-Id: Ic7a69bc2e3080b39f5205cb90b46d14247abf305 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92412 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Change-Id: I35937449bd563eacceb3753e62b9ff7245f12b89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92739 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93455
2020-04-29DOCX import: handle <wp:positionH relativeFrom="insideMargin">Miklos Vajna
This is the same as page, but it is from-left on odd pages and from-right on even pages, i.e. our "mirror on even pages" mode. (cherry picked from commit fccbb557add457db16e0556c3f0172cafc2cf981) Conflicts: writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx Change-Id: I018e0ac165a3d802f64cfc314d5c5f58da3cb580 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93003 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-04-28tdf#131446 DOCX import: restrict IncreasedAnchoredObjectSpacing furtherMiklos Vajna
Regression from commit 8b73bafbc18acb4dd8911d2f2de8158d98eb6144 (tdf#115719 DOCX import: increase paragraph spacing for anchored objects, 2018-02-14), this is another case where the workaround for the Word layout bug is not needed. tdf115719.docx and tdf115719b.docx are tweaked to have <wp:anchor ... behindDoc="1"> for 1 shape, as the original bugdoc has it. This allows us to render both the tdf#115719 and tdf#131446 bug documents the same way as Word does. (cherry picked from commit 249428202be04ab9a2271a9cd48922523fa03bc4) Change-Id: I0c3f197c3360882cd64f8dcf286c6051dc11d674 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92978 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-04-20tdf#132185: field command does not necessarily end with spaceMike Kaganski
Change-Id: I5a5e54fb42e20855b75af7ab523465a032ab46e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92504 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 8c8b3a4f83f67882b284ddc3b3fe10d3fe6dedf4) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92444 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-04-14tdf#132001 DOCX import: fix crash: redline in floating tableLászló Németh
Copying redlines to frame text was failed in tables inside frames. Skip these redlines temporarily. Regression from commit e8bae67b3dbcc90ace8264b6b1aefaf0ce459aba (tdf#125894: DOCX: import tracked changes in frames). Change-Id: I4f3ca2e95fb2e7637f8cf8dca1088a7727bcf98d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91985 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 1350832be533ce6627607b1aaabd2b3565e6e7b3) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92015 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-04-08tdf#131594: switch line numbering off if w:countBy="0"Xisco Fauli
See https://bugs.documentfoundation.org/show_bug.cgi?id=131594#c0 for more info Change-Id: Ic57826eb5a440e83cea1d9bde5e9144727e3b6df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91141 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 910197b8cf9b653c1b39b35b73424a36b7c1d1ae) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91512 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-04-07DOCX import: fix margins of inline shapes with effects, imported as Draw shapesMiklos Vajna
Effects have an extent, and unhandled effects (like this blurred shadow) need to take space in the margin of the shape to make sure they use the correct amount of space in the layout. This was working in general, but not in case the importer decided to import the shape as Draw shape + the shape was inline. (And also disable a new CppunitTest_sw_uibase_shells test on Windows, which is only stable on Linux, it seems.) Change-Id: I9d0531d9393d8c2cd274e6f54bbbfe8024bf270f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88427 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit bf25e69f8f657d5e3bcdd0bd54c5fa0d66ec85fe) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91749 Tested-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-04-02tdf#131304 .docx: flag new files as MS Word 2019 native modeJustin Luth
compatibilityMode = 15: [Word 2013/2016/2019] Up till now, documents that were exported into the docx format were treated by default as native Word 2007 format, since no compatibilityMode setting was provided. (Don't worry, we still round-trip existing older values. This patch only affects non-docx >>= .docx export.) Ultimately, this change is for the benefit of MS Word. It has no practical effect for LO. NOTE: This patch depends on previous commit 53f099c842d39266a0b4786a1af3db5628746634 which sets an appropriate value for existing .docx files. This scary change shouldn't actually be all that scary, since we already round-trip native 2019 files, without any complaint from Word or our users. The biggest change is that Word 2010 users might not be able to open NEW files perfectly. But Microsoft has already been doing that to them since 2013. By the time LO 7.0 hits stable version, it will have been months since 2010 has reached end-of-life. The vast majority of documents will still open perfectly for them. Plus, if a Word 2010 user does modify our new document, we will drop back down to their level. A nice, clear explanation of what compatibilityMode does is at howtogeek.com/256269/what-is-compatibility-mode-in-microsoft-office/ The MAIN CHANGE is that MS WORD has been DE-ACTIVATING features when it notices that it is SHARING the document with OLD_VERSION users. So Word is limiting what it will do for the BENEFIT OF THE OTHER USER while collaborating. There are a few instances where layout is affected by compatiblityMode. For example, tdf#123116 wants compat=15 so that Word will nicely layout an oversized table-row. tdf#131121 wants it too. By changing to compat=15, we can help Word take advantage of some fixes since docx 1.0, and avoid having to write new logic to export to old formats as well as new. Unfortunately, documentation on what layout changes are expected has not been identified yet. But in 7 years we should have run into most of them already... well maybe no. Change-Id: I1ce016618a680b9842fa6828c9e87cc6b677a557 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90455 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit f25985c55541cbbc9a4fc79e660592d3d0485196) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90920 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-04-02tdf#131304 .docx: provide default compatibilityMode valueJustin Luth
When a docx is imported without specifying a compat mode, populate the appropriate compatibilityMode setting, which will be written out at save time. "12: Use word processing features specified in ECMA-376. This is the default." The immediate benefit for LO is that this will provide a cacheable result - instead of repeated lookup attempts for something that doesn't exist. Perhaps more importantly, it paves the way for allowing LO to export new documents as compatible with 2013, while leaving existing documents at their current level. Both Word and LO treat the missing compatSetting correctly as mode 12, so this should not have any affect on layout or any other compatibility aspect. Therefore I can't see any reason why it shouldn't be explicitly written. MS Word also writes it out on a round-trip. Writing it out doesn't limit us in any way either. As soon as it is in docx format, it will be treated as mode 12 anyway, so why not make it explicit? Well, I guess that since MS Word has been filling this in since 2010 at least, we could "assume" that if it is missing and has been modified in the past 5 years it was created by LO and thus treat it differently, contrary to standard. But that doesn't seem like a very good idea at all. Change-Id: If68cecc14bf4446c5ca25fd2dd6eebddf8d954a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90439 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 53f099c842d39266a0b4786a1af3db5628746634) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90919 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-03-25tdf#106843 docxexport: don't write double docProtectJustin Luth
regression from LO 6.4 commit 2756ed9317e3474003c11ffe7d1e2f087c1412bf Change-Id: Iaf32974c7282d11bcd9572ed75cf1233ad3f0008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90321 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit b2471b8ab62abaa7f0c2c8342b4fa61c18f013c6) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90953 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-03-25ofz#21168 sw,writerfilter: limit writerfilter hack to writerfilterCaolán McNamara
The problem is that at the end of WW8 import, a delete redline is inserted that ends up calling DeleteAndJoin from inside AppendRedline(). A fly is anchored AT_CHAR at (node 46, offset 0) and the deletion goes from (node 46, offset 0) to (node 48, offset 13) hence the special case check in IsDestroyFrameAnchoredAtChar() for the IsInReading() prevents it from being deleted, and then its anchor is still registered at the node 46 when it gets deleted. So try to restrict the WriterfilterHack to writerfilter, so it won't affect WW8 import. Unfortunately this is far less obvious than expected, because import can happen for creating a new file, in which case it's all done via UNO in writerfilter, or when inserting into an existing file, in which case SwReader::Read() is used. The SwDocShell's pMedium can't be used becuse in insert file case it will be the loaded file, not the inserted file. There isn't any obvious alternative to adding a silly UNO property for the writerfilter to use. Change-Id: Ia7fdc9bb1925202f6692ebee6e4b6b1fe50e5345 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90384 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit c4dab726caaa73be9f9c731312080143b0a0b89d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90951
2020-03-04tdf#123873 DOCX IMPORT: fix unhandled textwrap for objectsBakos Attila
The OLE objects (in this case charts) had bad wrap option setting and this lead to misplaced objects. Now this parameter is set according to the file. Change-Id: I506be91b6801f0ffc3942e514f81119d895fdcb8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88091 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> (cherry picked from commit affe9c8384475fc85027703332bc0f1b36eaa0a6) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89908 Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-02-24tdf#130817 RTF doesn't set custom footnote stateJan-Marek Glogowski
RTFDocumentImpl::dispatchDestination detects the custom footnote and even sets NS_ooxml::LN_CT_FtnEdnRef_customMarkFollows in the character attributes of the context, but that is at least not handled in the DomainMapper later on, so we can't check for m_pImpl->IsInCustomFootnote() here. Change-Id: I26c02ea16d0e75ed5bfde0cda9e0c6a2d30261a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89240 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit 38306ea92560c82b0d70bdc195267549a8bab830) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89143 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-02-24tdf#130814 preserve context before page breaksJan-Marek Glogowski
... and add a comment, so nobody tries to move these again. Change-Id: I79e6f7a1538d0839fd525870439facef3218ec65 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89239 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit 70a9c644c63248719f1f4248e288df7ee06635cc) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89142 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-02-21tdf#130799 DOCX import: fix missing inside vertical bordersSzabolcs Toth
caused by incomplete handling of tables with 1-column rows with merged cells. Have to check the rows below current to see if they contain also one cell, therefore form a column, or more than one cell, in which case do not remove vertical borders. Regression from commit: 8a2eb40abbd52d960dd21308157186be0ca9dd3d (tdf#129442 DOCX import: fix right border of 1-column tables). Change-Id: If9ca7ccd42255e78c61b6271e19262ab5cc8e439 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89081 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 111db716c23f9f8450eda58c13dd2423770fd15e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89134 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-02-21tdf#95495 DOCX import: fix inherited list level of custom stylesSzabolcs Toth
in DOCX export of MSO 2003, 2007 and 2010, where ilvl and outlinelvl settings are missing, based on the settings of the parent styles. Change-Id: I01d239db505d46a89d7f3b9118ef0b55697bc7fc CO-Author: Balázs Nádasdy (NISZ) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87328 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/+/89216 Tested-by: Jenkins
2020-02-14tdf#103964 DOCX import: ignore rotation when setting position of group shapesMiklos Vajna
Regression from commit 36ac7749523e0c6f40a77beac278bd9e7a667a9b (DOCX import: make sure rotation does not affect shape position, 2014-09-24), the motivation for tweaking the rotation when setting the position of a shape was for images. By accident, this also happened for group shapes. But the bugdoc shows it's not a good idea to read the rotation of group shapes: the group shape is just a container, it does not have rotation in itself. (The test120551 intention was probably just to verify that the position is not entirely off, so the small required change to the expected value should be OK.) (cherry picked from commit 9fedce7a261f28dc286943f7bdd2adb010ed9b31) Conflicts: writerfilter/CppunitTest_writerfilter_dmapper.mk Change-Id: I8e12c28e65c5f64168c3f802546fddf472fcc6eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87589 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-02-12related: tdf#106742 sw: DOCX import/export: fix default of table indentMichael Stahl
There's a compatibilityMode in word/settings.xml in DOCX files: https://docs.microsoft.com/en-us/openspecs/office_standards/ms-docx/90138c4d-eb18-4edc-aa6c-dfb799cb1d0d If a document doesn't contain compatibilityMode, then the default is 12, but the code for table indent import/export assumed that the default is 15, so loading an ODF document and exporting as DOCX results in wrong table indent when loaded in Word. (regression from 9a31d1c83e08600507689dc18f6f0973bc7e4389) Change-Id: I3ce32286473640e5b7e12b487aef5f123bfb8d12 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88408 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit d978f5d40102a098f1faf1e98aa39ad122284299) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88392 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-02-11tdf#129221 DOCX import: fix missing restart of numberingMiklos Vajna
Regression from e49d2b31fb2020d065b4ad940d1031d07b10f32b (fdo#78939 [DOCX] Hang while opening due to incorrect modification of Style, 2014-06-06), the problem was that the 2nd sub-list of the bugdoc was not restarted in Writer, while it was in Word. The PR2 paragraph style inherits from the PR1 one and only that sets the numId; tweaking the bugdoc to state the numId directly in PR2 would work around the problem. Fix the issue by improving DomainMapper_Impl::finishParagraph(), so that it uses lcl_getListId() rather than calling pStyleSheetProperties->GetListId() directly; since the previous knows how to walk up the parent chain if needed. (cherry picked from commit 63d3ac37865460ff51348a6e792bbacf2f7c4653) Conflicts: writerfilter/qa/cppunittests/dmapper/DomainMapper_Impl.cxx Change-Id: I1c460919b0389d5b053b4ca1c9210279d6cd183c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88426 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Jenkins
2020-02-10tdf#129912 correctly stop unstyled footnote parsingJan-Marek Glogowski
The bug document somehow manages to generated a footnote, which never terminates the format loop in SwTextFrame::Format_. It contains an unstyled footnote, which I wasn't able to reproduce to create in Word. So I manually edited the XML of the included unit test document, which I used to develop the original patch, and which reproduces the broken parsing behaviour. This patch correctly stops the parsing of the custom footnote reference, if the text run containing the footnote reference is finished, which also fixes loading the bug document. The unit test checks various footnote variants, which represent different problems I found when developing the custom footnote parsing in commit a991ad93dcd6807d0eacd11a50c2ae43a2cfb882 ("tdf#121441 improve DOCX footnote import") and now also includes an unstyled one. It also contains a (still?) broken footnote test, with a complex differing footnote. Change-Id: I748955285d76b6f3122d1da5d8823068f3d7633f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87981 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit 7d886eec953efa593708db9560d0e69ac12c99cf) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87993 Tested-by: Xisco Faulí <xiscofauli@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-02-07DOCX import: don't give up on floating tables in headers completelyMiklos Vajna
This reverts commit 213d6390a2cc59d174173f4359c161625a9c4bdc (tdf#108272 DOCX table-only header: fix SAX parser error, 2020-02-03), except its testcase and replaces it with a better fix that does not import all floating-table-in-header as non-floating tables. See the new testcase, which is 1 pages in Word, it was 3 pages in Writer, and with the better fix it's now 1 pages in Writer as well. Change-Id: Ica3500120f12222d7cf766d55c17d78164865026 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88037 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/+/88098
generated by cgit (git 2.34.1) at 2024-05-22 10:33:02 +0000