summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)Author
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>
2020-10-22writerfilter: add OOXML tokenizer for <w:altChunk r:id="..."/>Miklos Vajna
This is just the tokenizer, the domain mapper part still has to be done. Change-Id: Iba171edeac42f1fa62b49dd0d188d41a539bb0c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104640 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-10-20tdf#133045 sw: add shape alignment to the top page borderSzabolcs Toth
Allow relative alignment to the top page border (the area over PAGE_PRINT_AREA) by adding constant PAGE_PRINT_AREA_TOP to com::sun::star::text::RelOrientation. Fix DOCX shape import of <wp:positionV relativeFrom="topMargin">. Follow-up of commit 6788133b3bdf02097d66a99047aa7bcba3a99a66 (tdf#135720 sw: fix PAGE_PRINT_AREA_BOTTOM alignment with footer) and commit 79107d3f8d10aa0f38641775c5eb47dcfd4fd37e (sw from-bottom relative orientation: add UNO API). Co-authored-by: Balázs Regényi Change-Id: I3a3f7324c0ef8d448526982d3e2f09b67f5fd4d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104113 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-10-18tdf#124176: Use pragma once instead of include guardsmariamfahmy
Change-Id: Ib9fd7e3ffbe8760edf4a108342aa5ed03c453b01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104487 Tested-by: Jenkins Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
2020-10-14related tdf#108944 writerfilter: fix another missing ftn separatorJustin Luth
A comment can also cause a missing footnote separator. Found by doing a code read. Change-Id: I42296f2e9406ad144c6e45873fac0f2cb8d11839 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104282 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-10-13tdf#137180 RTF import: fix bad left margin with direct format/para style/numMiklos Vajna
This is a case when a left margin appears as direct formatting on a paragraph, the paragraph has a style and the style has the same left margin. But the paragraph has a numbering as well: so it's not valid to deduplicate the left margin from the direct formatting, because then the left margin from the numbering will be used, which can be a different value. Change-Id: I5e27502b8d505bdfddfdc910858f62e501db35a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104220 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-10-09tdf#136955 DOCX import: fix shape paragraph marginsLászló Németh
based on bad style inheritance, in the case of not first paragraphs of shapes. Regression from commit dc0300eac3b755bc207cd1fe87217f4ebaeb9f58 (tdf#118521 DOCX import: fix paragraph margin from paragraph style), revealing the problematic m_sCurrentParaStyleName, see also commit 8920d865ee148518bf71f71ce1866b24cc17c07e for more information. Follow-up of commit c04ee66c7cfeb725d637b0f9ec3e3b1f8776bfe9 (tdf#134784 DOCX import: fix shape paragraph margins). Change-Id: I4feab19fc58653d829d7a1ae8da3e3ce4fb3e2c3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104116 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-10-09cid#1467971 Uninitialized scalar fieldCaolán McNamara
Change-Id: I3995a0113046591c136b4b2d2945416e41fe4f0f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104102 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-06loplugin:const* make some params and methods constNoel
Change-Id: I97c5bbb929a2a4a029af4e6cb0fd571bbc2b698b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104030 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-06tdf#97128 DOCX import: fix frame directionDaniel Arato (NISZ)
Frames used to be imported with zero rotation even if a w:textDirection tag explicitly called for a non-default orientation. I found no other solution to pass the incoming frame direction property on to the SwXFrame about to be created. 1. If you put the property into the GetSectionContext(), it gets overwritten when the next w:pPr tag is parsed, so all three frames will end up having the same direction. 2. If you put the property into the GetTopContextOfType(CONTEXT_PARAGRAPH) that context gets popped off the stack before control even gets to CheckUnregisteredFrameConversion(). 3. If you use PushStyleSheetProperties (which is bad in and of itself), the order will be messed up because the frames are not necessarily created in the same order as they are described in the file, so each frame gets a wrong frame direction in the end. Follow-up of commit 5a5597655a4bf12e4ca07c9c2b6f6221e217f080 (tentative fix for fdo#30474# [DOCX rotated text import failure]). Change-Id: I6e3d68fe60c6e2a5b6684c65a964dd86d0168181 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103553 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-10-05loplugin:reducevarscope in writerfilterNoel
Change-Id: I19f12959a04be07cdd2083a6aa519943d069fae6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103947 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-03use more TOOLS_WARN_EXCEPTIONNoel
Change-Id: I8b5cde993c13e0b7c8c830b1ff698933a6b7cfd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103863 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-02tdf#136850 DOCX: fix change tracking in floating tablesLászló Németh
Deleted text still reappeared as normal text in floating tables in the case of combination with tracked paragraph property changes. Follow-up of commit 288db6eb47fbbd2b3ca34ffea0686d8ed8ed9be9 (tdf#132271 DOCX: import change tracking in floating tables) and commit 464a7b0631335a8f8729512b8c27f864747f56a7 (tdf#136667 DOCX import: fix crash of floating tables). Change-Id: I2c8f63054520ce28306c063ef638756f7d8342e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103832 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-25fix Graphic duplication in import and add GraphicMapperTomaž Vajngerl
When importing writerfilter, we change to oox when importing images. This transition doesn't store any previous contexts and all instances are reset. The problem occurs when we have identical images because the transition erases all caches we have to determine if an image has already been imported or not, which causes that we import the same image multiple times which create unnecessary copies. This introduces the XGraphicMapper, which can be used to store the XGraphic for a key and can be transferred between writerfilter to oox. With this we can remember which images were already imported and don't create unnecessary internal copies which decreases memory. This also includes a test which checks that the import and export doesn't produce unnecessary copies of identical images. The test checks that for OOXML, ODF and MS Binary formats. Change-Id: I33dc19218c565937fab77e132b3a996c51358b6e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103283 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-24tdf#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>
2020-09-22tdf#136706 writerfilter: revert my info-gathering assertJustin Luth
The assert was failing in crashTesting for: wget http://bugs.documentfoundation.org/attachment.cgi?id=68205 -O tdf55725-1.docx ./instdir/program/soffice.bin --headless --convert-to docx ./tdf55725-1.docx and also for wget https://bugs.documentfoundation.org/attachment.cgi?id=127288 -O tdf102131-1.docx Both of these documents have SAX errors when loading. Running these interactively, saying "no, do not continue loading" parses a bit more to give the specific error and that is what was running into the assert. Actually importing the document itself does not hit the assert, nor does round-tripping it. Since this is a stupid enough situation, and because I can't think of a good way to word a SAL_WARN, and because I can't say that I have detailed knowledge about this area, I'll just remove the whole thing instead of leaving a warning. Change-Id: If50b06f0103adca348ca314ebc92e7e4045967dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103133 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21update pchesCaolán McNamara
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21tdf#136855 writerfilter: RTF import: buffer annotations inside tablesMichael Stahl
The problem is that one of the annotations is inside a table that happens to start with a covered cell (vertically merged). The table row is buffered, but the annotation is not, so it is inserted before any of the text of the table cells is inserted, so it ends up in the covered cell. The strucuture of annotations is a bit icky; to fix this, buffer both the \annotation destination and \atrfstart \atrfend start and end destinations. Change-Id: Ie955a75a2d254f8d7e965259698b688eece7cbd6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103016 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-09-18tdf#122648 DOCX import: fix table formula in all tablesLászló Németh
Table formula import worked only in the first table, because of using bad fallback table for cell references without table names during formula conversion to internal formula. Set table of the text field as the correct fallback table. Follow-up of commit 68e74bdf63e992666016c790e8e4cfd5b28d6abe (tdf133647 tdf123386 tdf123389 Improved .docx table formula import). Change-Id: Ib080f12426c57c8c74fe919eb45637a655875d1d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102989 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-18tdf#123382 DOCX import: fix range IDs in column ALászló Németh
Range IDs ABOVE, BELOW, LEFT and RIGHT weren't recognized in the first table column. Also the original formula was not grab-bagged in the first table cell (A1), according to the limitation of isInTable(). Follow-up of commit 436cf6d31deb7f9594a5da52ec7883d7e3d34344 (tdf#123355 DOCX import: fix cell range ABOVE, BELOW) and commit 82189fdc93ac337e1de3379d678eca6b7654e6fc (tdf133647 tdf123386 tdf123389 fix DOCX table formula export). Change-Id: Ic7d9c63a5ca989328f7ed33e25e1eda45296b3a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102849 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2024-05-21 03:13:37 +0000