summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)Author
2022-04-05forcepoint#82 back() called on empty vectorCaolán McNamara
Change-Id: I8017777a58f1fef41d1545899868e333c2184c5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131867 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-08-07crashreport writerfilter: findColumn(unsigned long,unsigned long)Justin Luth
Although the crash reports don't show getRow as a separate item in the list of functions leading to the crash, it just CAN'T be a problem with mTableDataStack.empty() or !mTableDataStack.top() because they are unconditionally used or popped later on in endLevel(). So I resisted the urge to test everything, and just verified that the row (which exists for m_aCellProperties) actually exists in the table manager - similar to getGridBefore(). These functions were added via tdf#129452 writerfilter: use column, not cell when comparing rows 7.1 commit 19d7f9624e92422409ed2744091d502fdae8692b The crash report did not identify any example documents or reproducable steps, so no unit test was possible. Change-Id: I5a27dc40db18f05ad4656789d3e61ec1ff4de471 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119420 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 82b14219969c4f80d421015c9e89e8d3db4650d8) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119616 Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit edc53ec766993b0b7910e87b3765d720565191d6) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119979
2021-06-01tdf#142325 RTF import: tolerate invalid hex markup like "\'3?"Miklos Vajna
The RTF spec says \'hh is the expected form, where both "h" are 0-9, a-f or A-F. But Word accepts the bugdoc, so don't reject this input, handle \'<number><junk> as \'0<number>. At least the current case ignores the actual value, as it's a single character to provide a non-unicode value after \uN for old readers that don't support Unicode. Change-Id: Ib61247ab08278ca5012cc887cee26c7571c29fc6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116499 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 6fc8a6b0b52509d735971f079d7b1660559d475d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116457 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-05-28tdf#139915 DOCX import: fix anchored obj position with to-char and TEXT_LINEMiklos Vajna
There were multiple problems here: - commit 8f1a1092d47947847e1d888b0284e8364c663d1f (tdf#97371 DOCX import: fix text covered by shape, 2016-01-28) disabled to-char anchoring for TEXT_LINE (e.g. "alignment top, relative to line") because changing the anchor type of a TextBox could not be changed, but this has been implemented in sw/ in the meantime, so it can be dropped - Now that the anchor type is to-char, we can set the vertical relation to TEXT_LINE, but Word's positive value is "below line", and ours mean "towards the top of the page, from the bottom of the line", so we need to drop the workaround of commit 3303a4c5f21874453e634d84408c50e7a0055a4d (tdf#135153 DOCX import: avoid line-of-text relation with to-para anchoring, 2021-01-18) Once these are in place, we can fix the remaining problem by inverting the vertical position of the shape, which instantly fixes the overlapping textboxes in the bugdoc. (cherry picked from commit 2f21e4f357ec60450df84ddd858c3cf0a4711b02) Change-Id: I895abb76d3bd3bbe3a84e5c27a77df722b96226a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116155 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-05-26tdf#132752: docx import: improvements for first line indent in listsVasily Melenchuk
As far as I see, Word is using lists with id=0 and no list definitions to reset list numbering used in this paragraph. At the same time Word is still using some of default list properties. For example in this scenario parent style has defined first line indent, but in paragrath it is overwritten by "not existing" list=0 without definitions. To this moment I know about only first line indent behavior, but probably some other properties are also affected. Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport16.cxx Change-Id: I344c907bb7a7b83a91f5727e13ad184fb44137b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115795 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116093 Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-05-07tdf#141540 fix docx import of group or line with rotationRegina Henschel
... and fix case wrap 'Square' and 'in Line' with them. Non-uniform scaling of a rotated shape might produce skew. Such had happened, when setting group or line to the size contained in GraphicImport. Avoid it. Writer has special rules for shape position and marging in case of wrap 'Square' and 'in Line', depending on rotation angle. The patch adds the needed margins. The patch changes some unit tests where we now get slightly different values. The patch fixes the wrong skew in sample document of tdf#73022. Change-Id: Ic743790c3fc8b8b10a4324d9e0184ad945cdceb6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114193 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 2a70cfb09c4d89154d229b6a95cf076e8bd76798) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115195 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-05-05tdf#138782 DOCX import: fix frame positions of old docsAttila Bakos (NISZ)
by limiting AddFrameOffsets compatibility option for docs created by MSO 2010 or older. Likely regression from commit 355d25eac764713f4d52eac801ade6e2ff1deab0 (n#779627: added quite some compat options from the ww8 filter on writerfilter). This patch fixes several bugs, which were collected as duplicates by Gábor Kelemen. Change-Id: I106e90c4bf00bb0b6a8986615cb3ad9c4828d5b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114476 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 5812fb81013cc124a9b6a0b9912a34cc715fc495) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115077 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins
2021-04-07tdf#136740: reimplement the fix using existing m_bIsNewDocMike Kaganski
This reimplements the fix from commit d7c4d0d4ea83481693af3645a03b03b53e456f60. The unit test from commit a90a324aa590a94a4091fbfadea67e0b0203767c still passes. Change-Id: I84c61fa68b9bee679a8e82ef7b8f164297bacb5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113665 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 7fc2cafbba36db25e7d0083cea162d2df08611b5) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113646 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-04-06tdf#136740: Do not initialize document settings when pastingMike Kaganski
When pasting from clipboard, the document already has the defaults set, and pasted text must not change those defaults. When pasting RTF, RTFDocumentImpl::outputSettingsTable does the document settings initialization, and is called from RTFDocumentImpl::checkFirstRun when m_bFirstRun is true. Other defaults are set in the latter function, too. This makes m_bFirstRun false when RTFDocumentImpl is created in the context of a paste operation. Alternatively, checking the context could be made when deciding if to apply specific settings. Change-Id: Ide1eabbef1d04a4fa2f1ca14846b8e404f2a0cb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113613 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit d7c4d0d4ea83481693af3645a03b03b53e456f60) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113634 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-03-25tdf#125936 writerfilter: treat escapement in numbering like stylesJustin Luth
deferCharacterProperties wasn't occurring in the numbering import (and so it was affecting the first run of the body text). But just like character styles, it would be better to just consider this auto-superscript instead of to defer it and calculate based on the fontsize - since that really isn't known until layout time, and so only works with direct formating. Change-Id: I9ce5a31c173089603316f4c3389e5f2e5dbe165a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112987 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-03-18tdf#138895 DOCX filter: fix handling for effect extent vs line widthMiklos Vajna
Regression from commit a5a836d8c43dc9cebbbf8af39bf0142de603a7c6 (DOCX filter: effect extent should be part of the margin, 2014-12-04), the problem was that effect extent is OK to be added as an extra margin, but line width is part of that effect extent in Word, so Writer margin should not be increased with the line width. The Word behavior seems to be that half of the line width is part of e.g. the top effect extent, then the other half is part of the bottom one (and so on). The bugdoc's case was that a too large margin shifted the last line below the shape, and this tiny half-line-width extra margin handled correctly puts the line back to its correct place. Change-Id: Ic897926f3d79f979ea84aef3dbda49c46b18a3ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112558 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/+/112582
2021-03-10tdf#140597 DOCX import: fix missing tblPrEx borderLászló Németh
of first table cells, caused by the workaround for tdf#138612. Now property set of a new cell is a copy of the table exception property set of the table row, as needed for the import of the table style inheritance. Regression from commit f319d6b543c2367546bc80d138e56ed03731e265 (tdf#138612 DOCX import: fix lost part of split table cell). Change-Id: Iaf6637e757fbfeef7651a4300a7f65a23615f5c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112247 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 53884e8fe92597e909e4fa5599192783c3d31a56) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112223 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-03-01tdf#140668 Crashfix: disregard w:textDirection tag outside frameDaniel Arato (NISZ)
DomainMapper_Impl::SetFrameDirection had a false assumption that a w:textDirection tag will only be encountered when the OOXML parser is already inside a frame. This is not always the case. Regression from commit af4e5ee0f93c1ff442d08caed5c875f2b2c1fd43 (tdf#97128 DOCX import: fix frame direction). Change-Id: I39845599b0c7f502870e2de497df8cbdd4475594 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111594 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.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/+/111754
2021-03-01tdf#136570 OOXML import: fix height of OLE objectsAttila Bakos (NISZ)
e.g. OLE icons or math formulas by skipping unset border properties. Regression from 636d16efe45a55c1a5a7a451c46fbb8618bf0393 (tdf#135653 OOXML import: fix OLE background color). Change-Id: I64bd68037d063de81fbb302b90d65b77af50a622 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111119 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit ca7855c24af858f52a11a593761ee9e6b9d6ba79) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111581 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-03-01tdf#140137 Don't throw exception when w:gridCol is missing "w" attrAron Budea
2149e924cbc32c370128c5f87a4f55c50c99e6bd added a division-by-zero check, which caused Writer to throw an error on the bugdoc. Since the file could be loaded fine before, let's return to a working version, with the check included. The cause is the following in document.xml (originating from a non-MS generator): <w:tblGrid> <w:gridCol/> <w:gridCol/> </w:tblGrid> Word still splits such tables differently, but that difference was always there in Writer. Change-Id: I6d91a736f460394a76f035298a238c41da201cb3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111723 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111736
2021-02-26tdf#140572 writerfilter: ignore position in docDefaultsJustin Luth
Despite the documentation saying that anything in docDefaults should apply everywhere unless it is overridden in a higher priority style, the subscript/superscript setting in docDefaults seems to be ignored. Makes sense in a way, but perhaps document those exceptions? I looked for documentation in both "docDefaults" and "position" and didn't see anything suggesting why it is ignored. Change-Id: If676415b112921e4cb8f7306b8c8ad93a6fd8cde Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111442 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 861ca1f5030f2f6b7fbdc3bb3ded3d11130673ed) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111463
2021-02-09tdf#134592 DOCX import: preserve formatting of CREATEDATE fieldsMiklos Vajna
The create date of a document doesn't really change, so we can only loose if the cached result of the field is not preserved. (cherry picked from commit 3b928391b3398c1113e675ea6a542d05d9611e0a) Change-Id: I0105d9c5bb9a06cacc1f5fed2a10b6626fa80fd7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110622 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-01-25tdf#138899 DOCX import: fix removing last para of sectionLászló Németh
Fix regression from commit 39090afac268f9ae985832c2f08863b41e6c06f2 (tdf#120336 DOCX import: fix page break after tracked deletion), limiting the condition only for *empty* section starting paragraphs with tracked deletion. Change-Id: I020c8b0edf5d4a37a9150cccec8c25fce50327d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109779 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit b7ca9576c26ed258537134c0cf2944cfcfc65f2e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109799 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-01-19tdf#135153 DOCX import: avoid line-of-text relation with to-para anchoringMiklos Vajna
Regression from commit 8f1a1092d47947847e1d888b0284e8364c663d1f (tdf#97371 DOCX import: fix text covered by shape, 2016-01-28), the problem was that once the import decides that a shape should have no to-char anchoring, it should not leave behind vertical relation types which make no sense for to-para anchoring. text::RelOrientation::TEXT_LINE is specific to to-char anchoring, so reset the relation back to the default text::RelOrientation::FRAME. This means we'll no longer show "from top" on the UI while the doc model contains "from bottom": and those have to be in sync, otherwise pressing "down" while the shape is selected will actually move it up. (cherry picked from commit 3303a4c5f21874453e634d84408c50e7a0055a4d) Change-Id: I660a7bb30133ea866cc4ba1620ae15fea243ef8f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109617 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-01-16tdf#116394 writerfilter: append '=' if not a formula markerJustin Luth
Oops - a silly mistake to throw away the character if it didn't match a special purpose. There is no point in adding a unit test for this. Change-Id: I3b48af578ae96744405ec0919ff341d1c9b43f65 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109426 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit b232b422a3cfe3b410bbc75e0fffdfc238fd10e7) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109397 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-01-14tdf#138995 DOCX import: fix handling of textbox zordersMiklos Vajna
Regression from commit d379d18666aa42031359ca8eb34b0021960347ae (oox: import WPS shape with text as shape with textbox, 2014-06-18), the problem was that a textbox's shape + textframe are internally 2 sdr objects, so once GraphicZOrderHelper knows the current shape should be on top of a shape+frame pair, it should suggest a larger ZOrder. This is necessary till there is no setter version of SwTextBoxHelper::getOrdNum(), which would allow import filters to ignore this complexity, but that would be a larger change. (cherry picked from commit 200cd2b99bee18962a970edc5d059286f6c3ea0e) Change-Id: Ibbb1bcd9301eb369f25f211120f62be7c59b0fd2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109184 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-12-16tdf#118711 writerfilter: don't hardcode default page descriptionJustin Luth
well, at least not at the beginning of the document. The problem with specifying is that it becomes a property of the paragraph - and so if the paragraph is copied or moved, the page break comes along with it and the user has to remove the unnecessary page break wherever it lands. Since the default will be applied anyway, there is no value in specifying it. I'm not sure how, but at least one test document started with a Converted1 style, so I had to explicitly confirm that the stylename really did match the default for a first section. A unit test also indicated that it needs to be specified if an explict page number is assigned because RES_PAGEDESC contains MID_PAGEDESC_PAGEDESCNAME as well as MID_PAGEDESC_PAGENUMOFFSET. Change-Id: I0d0f6b70767f7daaf300e09c0d31ac4b17b91ed1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107555 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 8787a45f9cbb5dce61b20817ef0e549b5a227a95) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107709 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-12-16tdf#138892 writerfilter: cancel style list if bNoNumberingJustin Luth
This fixes 6.1 regression e24e2d2fb02239753c1520a0458b44683ea4cc2e. Starting in 7.0 (tdf#131321), paragraph styles kept their numbering property. But even before that, non-paragraphs marked by bNoNumbering we having their direct numbering removed, and then finishParagraph applied para-style numbering since there was no direct numbering. So, we need to pass the bNoNumbering to finishParagraph so that it can cancel out a style-assigned numbering. Change-Id: I0c24af4e9bd0ea3712179a47ed3550f91c8f44b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107738 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit bfcd952dc7820c4cf8761c4222d29ede039391dc) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107795
2020-12-09negative return passed to parameter that cannot be negativeCaolán McNamara
I wonder if the test != 0 is what was really intended here, but keep that legacy logic anyway Change-Id: I4b39a2130e961c6f2ca97695e4625df5a95e00b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107478 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-08tdf#135217 DOCX import: remove no longer needed top/bottom margin syncMiklos Vajna
Regression from commit b7ae863efeb082816cc4fe660527a9650d90e186 (tdf#117503 DOCX import: fix out of sync first/later top margin, 2018-05-28), which adjusted the import so that the export can pair first/follow page styles and write them into a single Word section. But changing the import for pairing purposes is not a good idea after all, as it also affects the layout of the imported document. In the meantime, commit 51534ac2b9747975945acb6a1e1ba5cc6d73f5c2 (tdf#127778 DOCX import: fix unexpected heading on non-first page when the first page has a heading, 2020-05-11) already fixed the export side, so this is not even necessary, just remove it. (cherry picked from commit 29993781ac991e85bfbd61f9e076c9d8088cd3ab) Change-Id: I94c02517ae1e0804547f81c43bb5890327d32376 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107400 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-12-07tdf#138612 DOCX import: fix lost part of split table cellLászló Németh
by removing unnecessary rewriting of cell properties during import of w:tblPrEx. Regression from commit da8ea444b004a0be36964ae9a778f73e752b2673 (tdf#133455 DOCX import: fix table border regression) Change-Id: I93ce36991437644db439c8cf02e1a8503fbdfba7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107239 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit f319d6b543c2367546bc80d138e56ed03731e265) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107304
2020-11-25tdf#137894 separate associated character propertiesMark Hung
in ww8filter/RtfAttributeOutput and treat \dbch as CJK and \hich Western in order to roundtrip the RTF document. ww8filter mix all the associated style, including properties for CJK and CTL scripts. Both RtfAttributeOutput::CharFontCJK and RtfAttributeOutput::CharFontCTL output \dbch, that result in incorrect assocation. CharFontCTL should use \rtlch, but it was already in RtfAttributeOutput::MoveCharacterProperties. To make the order correct, I separate the associated character properties that were stored in m_aSyltesAssoc into m_aSyltesAssocRtlch, and m_aSyltesAssocDbch by their script types. Note that it is not clear what associated character properties that we should adopt for \hich and \ltrch. In theory RTL scripts can output high ANSI chars too, so \hich may get properties from either Western or CTL scripts. However, examining Hebrew RTF documents, I didn't see any sign that \hich is used in that way. Use RTL as CTL might be a problem for Mongolian, Manchu and Xibe. They are CTL but top-to-bottom (aka LTR) . But I don't think they will be expressed as high ANSI chars either. Change-Id: I214edbb00a67c2ffe19c5a37254c8988a0828f40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106355 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit f97af19460fbd7483a0e1c1d0137e814f5390e69) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106523 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-11-21tdf#138210 check if CustomShapeGeometry exist first.Mark Hung
CustomShapeGeometry does not exist for a text frame. Getting the property throws an Exception and cause a general IO error. Change-Id: I0e31780292d45211bfd1250d0d359c72def50583 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105834 Tested-by: Jenkins Reviewed-by: Mark Hung <marklh9@gmail.com>
2020-11-19tdf#123936 Formatting files in module writerfilter with clang-formatPhilipp Hofer
Change-Id: Ia60e7c5e2d3be0baa0496a6bd99c6ae98cd4ff96 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105730 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-11-17loplugin:stringviewparam check methods tooNoel
not just functions Change-Id: Icca295dd159002b428b73f2c95d40725434f04d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105789 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-13DOCX import: lost cached result of fields: fix leading whitespaceMiklos Vajna
" IF " and "IF " is the same, but "IFF " is something different. Change-Id: Ieb2d128d28ed3daa3df73128804bcc40dda9878d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105783 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-11-12DOCX import: fix lost cached result inside an IF fieldMiklos Vajna
This builds on top of commit d09336fbdceaafd9320466b660a2b32a07dcc16a (tdf#125038 DOCX import: fix lost MERGEFIELD result inside an IF field, 2019-10-31), and extends it for more cases. We know that DOCVARIABLE, FORMULA and IF fields inside an IF fields is not something Writer is capable of, so make sure we keep the cached result. Change-Id: I20004f97c2073309c33594e5da6f8ba89ba278ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105639 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-11-12Revert "remove Fraction::operator tools::Long()"Noel Grandin
This reverts commit 48b667a7e7d25f835f95df89162a7849d6972531. Reason for revert: some discussion required Change-Id: Ia0990d280837fb68b7ddc9f472ec78b1467b4311 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105540 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-12tdf#137850 writerfilter compatibilityMode15: ignore behindDoc if wrappedJustin Luth
This patch is based on testing results, since I couldn't find anything in the documentation that indicated a change between Word 2010 and Word 2013. But the evidence is fairly clear I think. To quote from MS documentation on relativeHeight: > This attribute shall only indicate the Z-order with respect to other objects > in the document which have an identical behindDoc attribute value. > _All_ objects with a behindDoc value of false shall be displayed > above elements with a value of true. But only wrapNone makes mention of being affected by behindDoc, so apparently MS decided to ignore it for some reason starting in Word 2013. By simply changing the compatibiltyMode value to one lower, Word 2013 again starts to honour the behindDoc setting. Change-Id: I7ef40387707ab5376cf8fa4d8a208c5b6a8b37ed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105486 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-12remove Fraction::operator tools::Long()Noel
which was added in commit 331e2e5ed3bf4e0b2c1fab3b7bca836170317827 Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Thu Sep 14 08:49:52 2017 +0200 long->sal_Int32 in Fraction presumably to make the change impact less code. Instead, update the call sites to reflect the actual bitwidth of the data we will be receiving. Change-Id: If2a678b1cf534f39cb8cb249757462be53658309 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105607 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11loplugin:stringviewNoel
Add new methods "subView" to O(U)String to return substring views of the underlying data. Add a clang plugin to warn when replacing existing calls to copy() would be better to use subView(). Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-10new loplugin:reducevarscopeNoel Grandin
Change-Id: Iefe922c2e0d605114d54673d63eccc5e4abd545d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102143 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-10DOCX import: fix <w:spacing w:before="..."/> for more than 58cmMiklos Vajna
Regression from commit af313fc149f80adb0f1680ca20e19745ccb7fede (tdf#105143 DOCX import: enable DoNotCaptureDrawObjsOnPage layout compat option, 2017-01-06), this now uncovered a deeper problem that paragraph top margin import goes through ConversionHelper::convertTwipToMM100(), which ignores values larger than 0x8000. Previously this problem was not visible as we (incorrectly) captured draw objects inside the page frame. Word does not ignore values larger than that constant for paragraphs, so fix the problem by using convertTwipToMm100() directly to just do the conversion, without any checks on the input. And now that the paragraph margin is not lost, it'll have the correct horizontal position, so the position of the triangle in the bugdoc will be correct, too. Change-Id: If664ad055f1916b7e7fb2fb85d1afa977c2d03aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105496 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-04RTF 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>
2020-11-04tdf#136952 writerfilter: PageBreakBefore - don't always overwriteJustin Luth
There can be a number of things that can set PROP_BREAK_TYPE, and thus an un-inheriting value of PageBreakBefore should not cancel a w:br for example. There are two ways to approach this. One would be to never overwrite, and that should be safe in practice, since I don't see anywhere else that would specify a NONE value. However, if PageBreakBefore is true, it ought to override a theoretical NONE, or potential COLUMN break I would assume, so in that case a "yes" page break should probably override, but a "no" page break should not. Basically, if anything specifically requests a page break, they should get it. (Actually, I'm not sure how, but column and textWrapping breaks seem not to be affected by this - which is good. Only the page break seemed to be lost when PageBreakBefore=false. I tested by changing the w:br type to column, textWrapping, and the invalid value of none.) NOTE: If there is both a w:br and a PageBreakBefore=true, then MSWord 2003 treats both as a valid page break, but neither Word 2010 nor 2016 add the empty page. See bug report for two proof unit tests. Change-Id: I279874c60cc4cc572e0d190dc2afad0ad3431c43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103223 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-03writerfilter: remove leftover commentMichael Stahl
Change-Id: Idb6dbb7ccb9a254def6029bb9ba84a3b02015d70 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105196 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-11-02sw: return SwXFieldmark in SwXFieldEnumerationMichael Stahl
* Implement text::XTextField in SwXFieldmark * That requires overriding XTextContent, just forward to SwXBookmark * Also override XServiceInfo implementation in SwXFieldmark * Add a PropertySetInfo for SwXFieldmark, which doesn't support "Hidden" or "Condition" properties of SwXBookmark * in SwXFieldmark::setFieldType(), only allow sensible new types * fix DomainMapper_Impl assumptions that if it implements XTextField it can't be a fieldmark, which caused CppunitTest_sw_ooxmlexport10 testTdf92157 to fail with a SAXException caused by some disposed SwXTextCursor Change-Id: I1ae2e9cb99ea784040874517e4d1af7e59d24405 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105083 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-11-01std::set->o3tl::sorted_vector in writerfilterNoel Grandin
Change-Id: I8b4527c8e40687918b3d5193f6c14ee86addab53 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105132 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-29tdf#137643 alternative solution to activate embedded fonts in one batchCaolán McNamara
Change-Id: Ib5ffb2b8a31f237d5d2e465bf3f777590e0bfade Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104947 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-26DOCX import, altChunk: fix missing page breakMiklos Vajna
Somewhat similar to copy&paste, the altChunk mechanism drops styles from the inner document by default. A surprising consequence of that is sections in the inner document have the default page size. This leads to a page break when the content of the outer document ends and the content of the inner document starts. Fix the importer to support this: 1) Ignore the page size and number in DomainMapper::lcl_attribute(). 2) Pass the start of the current section to the sub-importer, so that it can insert the starting page break at the right place. Change-Id: Id3955f2b35a139692254c4ac1233e96eef2620e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104821 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-10-26tdf#137593 DOCX import: fix para top margin in cells with shapesLászló Németh
and text boxes. Auto top margin value of the first table cell paragraph is zero. Paragraphs of shapes and text boxes anchored to this cell paragraph don't matter here, so keep m_bFirstParagraphInCell=true in shapes and text box paragraphs to avoid extra top margin of the anchoring point. Regression from commit 5c6bce38a01b21403a603acd3148cf3bbb4c685f (tdf#104354 DOCX import: fix paragraph auto spacing in tables). Change-Id: I22c4ae230bc0192f06d3d155217887c471c67b67 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104816 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-10-26switching long to a 64-bit type on 64-bit windowsNoel
(*) create a rewriting plugin to do most of the work, heavily based on the fakebool plugin (*) but there are still a number of "long"s in the codebase that will need to be done by hand (*) the plugin needs lots of handholding, due to needing to add #include and update macros Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-24clog -> SAL_INFONoel Grandin
Change-Id: I6cf543bd7052f7664b4d674e70c0d8a64cd1f734 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104739 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-22DOCX import: handle <w:altChunk r:id="..."/>Miklos Vajna
This refers to a self-contained full DOCX file inside a DOCX file. Change-Id: Ic9451833db30231f08ff2e2493da678edbc9a4c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104654 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-10-22tdf#137085 writerfilter: RTF import: \trpaddfl and \trpaddl are row...Michael Stahl
...properties, not cell properties. What is supposed to happen here, afaict: 1. \trpaddfr3 either has an effect on the left margin too (despite being defined for right), or \trpaddfl3 is the default, 0 is not the default 2. \trgaph600 should be ignored if the \trpaddfl3 is in effect 3. \trpaddl0 should be in effect, overriding both the value from \trgaph600 and the built-in default of #define DEF_BORDER_DIST 190 CellMarginHandler::lcl_sprm() needs to distinguish between \trpaddfl0 and \trpaddfl3 cases, but its not possible currently because a) \trpaddfl is processed after \trgaph/\trpaddl, and b) both \trgaph and \trpaddl produce the same srpm-id. This fixes \trpaddl handling just enough to import the bugdoc properly, for more fixing a new sprm-id for \trgaph would be needed at least. At the other end, there is a line in DomainMapperTableHandler.cxx: m_aTableProperties->getValue( TablePropertyMap::GAP_HALF, nGapHalf ) ... but nothing that would initialize the GAP_HALF there. That this bugdoc looked right before commit c2a5346b19c57f93f210b76c15cdba64f6871203 appears to be entirely accidental. Change-Id: I80dc34bdd5dadb7d7d7f5ec595907035d621a656 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104638 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
generated by cgit (git 2.34.1) at 2024-07-11 09:01:23 +0000