summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)AuthorFilesLines
2019-03-29tdf#121456 sw: DOCX: fix loading of empty TOC titleSerge Krot1-0/+3
Change-Id: Ib241edd07e4c6781d80db274f73146bda310d8c0 Reviewed-on: https://gerrit.libreoffice.org/69827 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit e47a5543f4b8c9e317d1e43af8c0e5a732e461fd) Reviewed-on: https://gerrit.libreoffice.org/69903
2019-03-04tdf#121440 writerfilter: do not use imported style for foot/endnotesVasily Melenchuk1-0/+6
Extra style is causing editing problem near footnote/endnote references. This behavior is a side effect of eaa9cf6a3069fba3d82c046f0041bfb537d9e648, allowing emission of these "technical" styles. Change-Id: I1885b92814746e7b5cd19f3ddd7bc22eb691615e Reviewed-on: https://gerrit.libreoffice.org/68304 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit 691ca4e1a3e510d54894a1e7df7fa4ad9f9cba11) Reviewed-on: https://gerrit.libreoffice.org/68583
2019-02-12tdf#116851: some rtf files provide param with "-" for "edmins"Julien Nabet1-0/+5
Change-Id: I2a2a189ee727a51aeef5601b39bb288d813fc8f3 Reviewed-on: https://gerrit.libreoffice.org/52610 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit c04c6c487e20730391cfc29dfe66b4558b7b4efb) Reviewed-on: https://gerrit.libreoffice.org/67708 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org> (cherry picked from commit 08c98b7aba639e0d246f3662d7950885f8a81432) Reviewed-on: https://gerrit.libreoffice.org/67723
2019-01-16tdf#122224 DOCX import: fix formula field syntaxLászló Németh1-0/+9
by removing the DOCX custom number format string which caused a syntax error message here instead of the formula calculation. Change-Id: Ia643e966440117871f6b4ddceab610100ac34138 Reviewed-on: https://gerrit.libreoffice.org/65945 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 7209feef41c3c858476a2ae9795a7d2264c0ffc0) Reviewed-on: https://gerrit.libreoffice.org/65959 Tested-by: Xisco Faulí <xiscofauli@libreoffice.org> Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org> (cherry picked from commit b095e8f3b27331f0d646b1d33e51e17c37e43e2c) Reviewed-on: https://gerrit.libreoffice.org/66470 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2019-01-15sw: DOCX: recognize TOC title during importSerge Krot2-26/+138
Change-Id: Ifa4fb59858d61580f76e3d104aa4caa6b5902d1b Reviewed-on: https://gerrit.libreoffice.org/64735 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> tdf#121561: sw: DOCX: add std/stdPr/stdContent around TOC During export into DOCX from ODT we need to do it because in this case the TOC title will be recognized inside MS Word as part of the TOC. Later we could add support of these keywords in LO import in order to detect TOC title from DOCX input. Added unit test for export. Change-Id: I7135e91dc04d4c0501e6074a046fc473e041f014 Reviewed-on: https://gerrit.libreoffice.org/63786 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/66307 Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2018-11-28tdf#120551 DOCX import: fix position of group shape with absolute positionMiklos Vajna1-2/+25
Regression from commit af313fc149f80adb0f1680ca20e19745ccb7fede (tdf#105143 DOCX import: enable DoNotCaptureDrawObjsOnPage layout compat option, 2017-01-06), the group shape which covers most of the single page in the document had a negative left position, while it should have a small positive one (checking the drawingML markup). This was a pre-existing problem, but now it's visible since we no longer force objects to be on the page in Word compat mode. Seeing the ODT import never positions group shapes (it's just a container for child shapes), probably the DOCX import shouldn't do that either. Start moving into this direction, first only for absolute-positioned toplevel group shapes only, which already fixes the bug. (cherry picked from commit d220e476df38e86e094066a690985c624316d37f) Change-Id: I152ba06a81a2bd09195a4c724da4b8878b0457bb Reviewed-on: https://gerrit.libreoffice.org/63710 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-11-17tdf#121203 DOCX import: fix loss of free-form text in date controlMiklos Vajna3-6/+41
Date SDT from DOCX is imported as date control since commit 3ec2d26dc2017ac4a27483febfc63328632f352d (bnc#779630 initial DOCX import of w:sdt's w:date, 2013-04-30). One detail I missed there is our date control is strict: it doesn't allow free-form text. However, DOCX date SDT has an optional ISO date, but the actual value can be free-form text. This means that importing free-form text without an ISO date is lost on import. Fix the data loss by restricting the creation of the date control: only do this if we recognize the date format or in case we have an ISO date. Otherwise just show the free-form text to avoid data loss. (cherry picked from commit 3583f7a1256c901199574c8373443038e28813f0) Change-Id: I8125bdc749954a6a1c496de74b6682744adb7680 Reviewed-on: https://gerrit.libreoffice.org/63335 Tested-by: Jenkins Tested-by: Xisco Faulí <xiscofauli@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-10-30tdf#116989: disable conversion of tables in footers to floating for nowMike Kaganski3-11/+19
As the floating objects anchored to footers aren't wrapped around properly (they behave as if they are wrapped through unconditionally), which makes imported tables to overlap the page body text making the document unusable, let's just disable the conversion for the time being (until the actual bug fixed properly). This also backports the unit test from https://gerrit.libreoffice.org/62544 (Change-Id Ia8b5478b0d2a15f91add4ee76455e73c2c970392). Change-Id: I06c984ff7157b71fff2aa8122cc475a1199994c6 Reviewed-on: https://gerrit.libreoffice.org/62523 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/62628 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-10-17tdf#119885: OOXML import: try to get cell paddings as Word doesMike Kaganski1-10/+44
Change-Id: I7abd715b6bb71d6e2e01939c4cf849d94eb6a103 Reviewed-on: https://gerrit.libreoffice.org/61843 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/61877 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-10-04tdf#119599 RTF import: fix missing deduplication of font sizeMiklos Vajna3-27/+46
Deciding when to and when not to deduplicate repeated direct formatting of paragraph / character properties is stricky, this bug is about a case when deduplication should happen and did not, since commit 1970a686273c5d4fc1eeb4430283e37085d9f647 (tdf#113408 RTF import style dedup: separate paragraph and character handling, 2017-10-31). Especially that deduplication works in both directions: it should remove properties which are duplicated and also should insert explicit default values for not repeated properties. Fix the problem by making the getDefaultSPRM() aware of the context (which style type it deals with), and then by making sure that only default properties relevant for the given style type are inserted. (cherry picked from commit 49614a9ea971ff7f370f863ce8a2735aab973cee) Conflicts: writerfilter/source/rtftok/rtfdocumentimpl.cxx writerfilter/source/rtftok/rtfsprm.cxx Change-Id: I35b6599cc47fa51b8754fd921c61a3b31a283547 Reviewed-on: https://gerrit.libreoffice.org/61237 Tested-by: Jenkins Tested-by: Xisco Faulí <xiscofauli@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-10-01tdf#105444 DOCX import: don't put extra paragraphs in commentsLászló Németh1-1/+3
on Win32, waiting only for \r\n instead of \n in RemoveLastParagraph(). Change-Id: I8921a6a72e8397ed04edb9f339ba3f0bf5bbb98b Reviewed-on: https://gerrit.libreoffice.org/60865 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit bdade7e3fc33c1832c6f6a472443fca8238738d2) Reviewed-on: https://gerrit.libreoffice.org/60896
2018-09-20tdf#64264 DOCX import: fix row count of repeating table headerLászló Németh1-1/+1
by ignoring isolated tblHeader settings, according to the standard. (OOXML 17.4.49 tblHeader (Repeat Table Row on Every New Page) "...if this row [with tblHeader property] is not contiguously connected with the first row of the table (that is, if this table row is not either the first row, or all rows between this row and the first row are not marked as header rows) then this property shall be ignored.") Note: with this fix, in a mixed environment, LibreOffice is able to fix the known problems of MS Word 2013/2016 by removing the isolated tblHeaders during DOCX import/export (such problems in MSO: missing repeating headers in a few pages or in the whole table, despite the correct settings; and non-modifiable repeat header row property in the table settings). Change-Id: I73e8394a75b77c937a4bac37d99ff747ad95a06e Reviewed-on: https://gerrit.libreoffice.org/60765 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit ace6bbf3da9ae27aca87865b6be887a3aed341fc) Reviewed-on: https://gerrit.libreoffice.org/60790 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-09-18tdf#118691 DOCX import: fix table loss caused by <w:cr>László Németh1-2/+2
According to the OOXML standard, <w:cr> (carriage return – Unicode character 000D) is equivalent to a break with null type and clear attributes, so we handle it as a <w:br/>, instead of endOfParagraph, fixing losing table paragraphs and tables containing <w:cr/>. Note: It seems, MSO cannot handle carriage return characters in table cells correctly. It shows squares (unknown characters) without line break there. Copying this text to a non-table paragraph in MSO, we get the correct layout with line breaks. Copying this text with carriage return characters back to a table cell, we get squares again. With this LO fix, it will be possible to fix the bad tables edited by MS Word by using LO, because LibreOffice import/export converts all <w:cr>s to <w:br>s (as before, but now without destroying the structure of the tables). Change-Id: Iee42f71e9a00531353582e7127c2c212ea0890d0 Reviewed-on: https://gerrit.libreoffice.org/60585 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit f63a60f56156e4ac17887e6c96d15fb865a2a8eb) Reviewed-on: https://gerrit.libreoffice.org/60655 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-08-30ofz#10056 Null derefCaolán McNamara1-6/+14
Change-Id: I9ea0f272d0a8b13fb51fec55ac57adca47cafc77 Reviewed-on: https://gerrit.libreoffice.org/59601 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2018-08-30ofz#10045 Null derefCaolán McNamara1-2/+5
Change-Id: If9c8edd94b02240510325d6c9c0fc7584ba89b5f Reviewed-on: https://gerrit.libreoffice.org/59574 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2018-08-30Resolves: tdf#118382 crash on paste of rtfCaolán McNamara1-7/+0
into an existing document since.... commit deaa16bd24fba4a3a6b072ab2b94542a7dbd41c6 Author: Serge Krot <Serge.Krot@cib.de> Date: Mon Jan 29 12:17:06 2018 +0100 tdf#72942 Do not overwrite styles from the inserted doc During inserting of the text from the external document we should not change original default styles in currently opened document. because missing styles aren't created, so there's exceptons thrown on their use. I see that the m_bIsNewDoc flag is already checked for since... commit 5ebe826caf75e8d00656b3333385bf0bbc05cb27 Author: Miklos Vajna <vmiklos@collabora.co.uk> Date: Fri Oct 4 11:02:59 2013 +0200 fdo#69384 fix impress -> writer copy&paste Regression from 2ade07126971b79c92f729fae5709f2e2e2b495c (fdo#62044 RTF import: don't overwrite existing styles when pasting, 2013-06-04), during paste, if existing style was found, then the intention was to skip that style, but instead we tried to create one. in the body of the following loop, which should mean that existing styles are left alone and only missing styles created if we remove this hunk of the tdf#72942 commit Change-Id: Ia4aedb5e309c991490656061aa20d11ff24f4f9e Reviewed-on: https://gerrit.libreoffice.org/59519 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 1f1e349bbee1b2bff01a850d9a7fe4d6a77c4f29) Reviewed-on: https://gerrit.libreoffice.org/59636 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-08-20ofz#9934 null derefCaolán McNamara1-2/+3
Change-Id: I6833ad8a556b561a37e468da8845914cabfac4c5 Reviewed-on: https://gerrit.libreoffice.org/59249 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2018-08-14ofz: check sequence length before useCaolán McNamara1-0/+6
Change-Id: I137a9de49c5a73eb5f277dc1519e5e036abba31c Reviewed-on: https://gerrit.libreoffice.org/58946 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-08-10tdf#119136 GetPropertyFromStyleSheet infinite loopJustin Luth1-1/+3
So, apparently we accept a style that has no styleId and define it as such. Due to some reworkings, this function was called instead. Since we can "find" a style without a name, now every parentless style thought it inherited from this nameless style. Change-Id: I47b4119abd37ece94a39e636ddb7798b809ccb04 Reviewed-on: https://gerrit.libreoffice.org/58717 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-08-03forcepoint#62 null derefCaolán McNamara1-2/+2
Change-Id: I255aeb96c3763aa106128d3463e4fd55395ef8b8 Reviewed-on: https://gerrit.libreoffice.org/58409 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2018-08-03forcepoint#58 null derefCaolán McNamara1-0/+2
Change-Id: I826890ec85a16bc05fc1e4cd068079b0f8734d07 Reviewed-on: https://gerrit.libreoffice.org/58394 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2018-08-02forcepoint#56 null derefCaolán McNamara1-6/+8
Change-Id: Iaa9c4d6901a340145412fa46eaf5c292c3fb62e8 Reviewed-on: https://gerrit.libreoffice.org/58387 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2018-07-26related tdf#63561 docx: styles inherit tabstops tooJustin Luth1-1/+1
Add import and export support for style-parent tabstop inheritance. This patch is dependent on GetPropertyFromStyleSheet commit 39171b82b245a7589b9258337a18d6dd281f8ed2 Change-Id: I0245d0e08f140b6cb473c96cffa6f5a4ceff8944 Reviewed-on: https://gerrit.libreoffice.org/57278 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-on: https://gerrit.libreoffice.org/57759 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-07-24tdf#81943 sw RTF import: fix missing wrap in background for in-table shapeMiklos Vajna2-0/+26
Regression from commit 015fd55c94b7b650ed8e572cafaf3b0f903b01b9 (tdf#96275 RTF import: fix anchor of shapes inside tables, 2016-05-10), remember more context when delaying the import of a shape. (cherry picked from commit 0c91f8f839d36c8b5af272b1d3c835d2f4af6b65) Conflicts: writerfilter/source/rtftok/rtfdocumentimpl.cxx Change-Id: Idc02868eb3fe5b7637c9fd00c841bf71423adf2b Reviewed-on: https://gerrit.libreoffice.org/57555 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-07-20tdf#104797 DOCX change tracking: handle moveFrom and moveToLászló Németh2-1/+5
data as deletion and insertion instead of importing them as normal (unmodified) texts (messing up document content and losing change tracking information). Change-Id: I9c0a7da83f3e8235d65d47afdb99ffe188f52704 Reviewed-on: https://gerrit.libreoffice.org/57723 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> Reviewed-on: https://gerrit.libreoffice.org/57729 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-07-19related tdf#106174 writerfilter: replace broken FindParentStyleSheetJustin Luth3-18/+7
FindParentStyleSheet didn't do anything right. An empty stylename was supposed to check currentEntry, but instead it just returned null. The passed stylename was completely ignored if there was a currentEntry. And on top of that, the stylename itself was returned, not its parent. Even worse, the currentEntry properties were ignored because in that case it DID return the parent. Even the comments were totally bogus. Amazing... GetPropertyFromStyleSheet() has the potential for LOTS of use in writerfilter. I'm surprised it has hardly been used. Perhaps the completely wrong results led people to ignore it rather than investigate why it didn't give the expected results. Change-Id: I89a6b02877ab7990aa4eb58e5e0b6a572f3d10e3 Reviewed-on: https://gerrit.libreoffice.org/57195 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit bc67bda7363df48f1983513a8e969b61738139f5) Reviewed-on: https://gerrit.libreoffice.org/57483
2018-07-12tdf#118361 sw ooxmlimport: set footnote separator alignmentJustin Luth3-0/+34
If RTL is defined in the default (Normal) paragraph style, then the footnote separator should be right-aligned. In MSWORD, the alignment is not a property that is stored with the footnote separator definition, and it is not a page property like it is in LO. The reverse needs to happen for LTR default paragraph style. Based on my MSWORD observations, the only place where you can indirectly set RightToLeft is in the "Normal" paragraph style. That option is disabled in all of the other styles. In LibreOffice, this is typically handled by the locale properties. The default PAGE style's Footnotes - Position is RIGHT for RTL locales, but LEFT for LTR locales. It is kinda interesting that no one from a RTL locale complained about wrongly-right-aligned footnote separator from imported LTR .docx's. None of this belongs in export code, since MSO doesn't support specifying the location - it is just a consequence of the RTL/LTR settings. Change-Id: I07d26640116cb12cb9157cd1d902b4c774dbba26 Reviewed-on: https://gerrit.libreoffice.org/56532 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 139750d7c295b84f4c42bf9409ccbdfb0c46b9f6) Reviewed-on: https://gerrit.libreoffice.org/57214 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-07-11backport combined tdf#95115 and tdf#102619: writerfilterJustin Luth1-23/+21
Styles were having FollowStyle set to themselves (Heading 1), not to a defined follow (Text body). The style was being created with a FollowStyle property that identified a style which had not yet been created. And also some stylenames were not recognized since it didn't do an extended search. tdf#95114 writerfilter: follow correctly converted stylename commit ac540c1d743250062b3e71b094209ec1428872e9 tdf#102619 writerfilter: first create style, then set FollowStyle commit 39a4f21fc4a16f7c57a9b6f1ddd5ce2953781576 ~NFC related tdf#102619 writerfilter: use ConvertStyleName() commit d22bca292532ff58839bc593a7b3e1d3b6f3552c These commit were done separately to aid in regression testing in master, but logically all combine together for easy backporting. Change-Id: I77f143760c10be4b7853f16bce2b57474b70d3f1 Reviewed-on: https://gerrit.libreoffice.org/57073 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-on: https://gerrit.libreoffice.org/57175 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-06-05tdf#117843 DOCX import: disable compat increased spacing in header/footerMiklos Vajna1-1/+3
It's only relevant for the body text. (cherry picked from commit 09a37fe50f36ced755bc326fb6b4c1b6fdf61f86) Change-Id: Id894604ed9b2c19400eeabbd2966f104d8b34aab Reviewed-on: https://gerrit.libreoffice.org/55335 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-05-29tdf#117503 DOCX import: fix out of sync first/later top marginMiklos Vajna1-1/+26
Improve the synchronization between the first page and follow page style, so that when the DOC export invokes sw::util::IsPlausableSingleWordSection(), it recognizes that originally these were the same Word section. If they don't match up, then the exporter will insert an explicit section break, meaning we get one more page in the export result compared to the original. (cherry picked from commit b7ae863efeb082816cc4fe660527a9650d90e186) Change-Id: I336cf347698187cdede47be2659cec51e4381e85 Reviewed-on: https://gerrit.libreoffice.org/54988 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-05-24revert tdf#76817 ooxmlimport: connect Heading to existing numbersJustin Luth4-6/+1
tdf#50774 has an example document which was broken by 6.1 commit 8e9e705de29a1a3d9b964c9350aa2a3a17cce6f9. Reverting does a couple of things: -go back to previous behaviour (right or wrong) - no regression. -gives an opportunity to find documents broken by reverting - i.e. it will give an indication as to which state has more broken docs. Can be re-visited in 6.2. -gives me an option to escape from this horrible mess without causing a regression in a production release of LO. Change-Id: Ib594b76d5533a0c4807cf70ef706c107e52cddcf Reviewed-on: https://gerrit.libreoffice.org/54293 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2018-05-20tdf#117502 fix graphical bullets for OOXML and RTFTomaž Vajngerl3-18/+19
This change has multiple parts: - Move "BulletAsImage" test from ODT only to globalfilter and run it on ODT, DOC, DOCX, RTF formats and extend checks of the XGraphic used for the bullets and the size. - Check if GIF is animated as we need to know this in unloaded graphic or bullets aren't rendered correctly if we assume they are animated. - Use "Graphic" property in writerfilter to get the graphic from a XShape and not the "Bitmap" property which returns a Graphic as a MetaFile and not the original Graphic. - Make sure "GraphicBitmap" is filled with XBitmap and not with XGraphic. - Change "testFDO74215" to use the expected bullet size as it is in the original document. Looks like the initial bug was just asserting the bullet size is set to a value (non-zero). Change-Id: I6b151c0bf9f426669e07522f0fc699fbb652046b Reviewed-on: https://gerrit.libreoffice.org/54477 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2018-05-18Fix some IWYU warningsMiklos Vajna3-2/+32
Change-Id: I11d874caad9174fb1a70121f1772e117753ee519 Reviewed-on: https://gerrit.libreoffice.org/54503 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-05-17New o3tl::temporary to simplify calls of std::modfStephan Bergmann1-3/+2
...that ignore the out-parameter integral part Change-Id: I05f07c1a8909023232f8aecf75ea5541d4eb81ca Reviewed-on: https://gerrit.libreoffice.org/54474 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2018-05-17loplugin:redundantcast improvements for floating-integer conversionsStephan Bergmann1-1/+3
Change-Id: I63dbf18f144a792ae775fe6706da81657f790016 Reviewed-on: https://gerrit.libreoffice.org/54416 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2018-05-16tdf#117504 ooxmlimport: check paragraph props for actual styleJustin Luth2-2/+13
m_sCurrentParaStyleName sounds like a nice idea, and has been around since the initial fork, but by the time finishParagraph() rolls around, the chances that it is still accurate are rather low. Anything that contains a paragraph (like comments, textboxes, shapes, tables, flys etc) might have modified that value. This fix queries the current paragraph itself to see if PROP_PARA_STYLE_NAME is set, which it typically is by lcl_startParagraphGroup() except when IsInShape(). If it isn't specified, then fallback to the previous result, which still may not be accurate, but at least it won't be a regression. It is too late in the development cycle to look into fully eliminating m_sCurrentParaStyleName. I hope to investigate that in the 6.2 development cycle. Change-Id: I124688d864f553dd5778b3593f511cc41d31c262 Reviewed-on: https://gerrit.libreoffice.org/54085 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-05-14writerfilter NFC: save ConvertedParaStyleName, not WW8NameJustin Luth3-11/+10
and rename m_sCurrentParaStyleId -> m_sCurrentParaStyleName This is prep work for tdf#117504, where the value saved in m_sCurrentParaStyleId is not accurate. Since the actual value saved inside the paragraph properties is the ConvertStyleName(), lets use the LO-version of the style name, so that FindStyleSheetByConvertedStyleName() can be used for either the paragraph's PropertyValue or m_pImpl->m_sCurrentParaStyleName. Change-Id: I8aed80094417ea91f2515e666dc05ecbb021a128 Reviewed-on: https://gerrit.libreoffice.org/54084 Reviewed-by: Justin Luth <justin_luth@sil.org> Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-05-10tdf#79315 Fix wp:effectExtent issue when exporting inline picture to DOCX.Victor Mireyev1-0/+7
Change-Id: I250bb365593c6a06f1d99f28b36e8bde183b16e6 Reviewed-on: https://gerrit.libreoffice.org/53679 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jacobo Aragunde Pérez <jaragunde@igalia.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-05-10writerfilter, writerperfect: various small cleanupsMiklos Vajna2-3/+3
Change-Id: Iea26b73bd91ed178cc4f2279c23246d79f48a6be Reviewed-on: https://gerrit.libreoffice.org/54063 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2018-05-09Fix some IWYU warningsMiklos Vajna3-6/+38
Change-Id: Iab61e0a7cac2dc89e6b04875a62894b181aa0ff4 Reviewed-on: https://gerrit.libreoffice.org/54016 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-05-09tdf#117137: DOCX import: don't try to set grab-bag as UNO propJustin Luth1-1/+1
This modifies commit a6f2199e9888cb75960f1d35034bd44fb45e5565 "DOCX import: don't try to set grab-gag props as UNO props" Perhaps that commit should simply be reverted, but I will trust that the commit was mostly OK and simply adjust the logic so that *InteropGrabBag is ignored as before. Doing this resolves MSO being unable to open a specific document and LO missing some numbering during LO round-tripping. Probably these are just side-effects from other locations in the code that couldn't deal with these unexpected properties. For example, the numbering.xml file is malformed, since it is missing the w14: namespace. Unfortunately, I failed in my attempt to create a minimal test document. Change-Id: Idf88cd09d96546b7f03d326afb5f6e58439bcf20 Reviewed-on: https://gerrit.libreoffice.org/53271 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2018-05-08tdf#117403 RTF import: fix lost cell border of merged cellMiklos Vajna1-4/+31
If two source cells have different border types, then Writer takes the second, Word takes the first. So mimic the MSO behavior explicitly in dmapper. Change-Id: I25adc62e024a929216c7b05fec44e1f602f28285 Reviewed-on: https://gerrit.libreoffice.org/53956 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2018-05-07[API CHANGE] revert and deprecate *BackGraphicURL add *BackGraphicTomaž Vajngerl1-1/+10
*BackGraphicURL include the following properties: - BackGraphicURL - FooterBackGraphicURL - HeaderBackGraphicURL - ParaBackGraphicURL This were removed, but for backwards compatibility this commit adds them back again and depreactes them in the UNO API. The behaviour also changes as internal vnd.sun.star.GraphicObject scheme URLs aren't supported so this properties can only be set and only if a external URL is provided. If getting such a property then a RuntimeException will be thrown. [ Miklos Vajna: fixed up sw/qa and writerfilter bits. ] Change-Id: If60011837da96197b576bfe2671ecafccad736c7 Reviewed-on: https://gerrit.libreoffice.org/53511 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2018-05-04tdf#117171 DOCX export/import of cardinalText, ordinalTextLászló Németh1-4/+7
and ordinal (indicator) numbering styles. Change-Id: Ia4030c8a170bad67e0b52ec685a49faa77552ccf Reviewed-on: https://gerrit.libreoffice.org/53831 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2018-05-03tdf#117268: treat erroneous \itap0 the same way as Word doesMike Kaganski1-0/+7
... so that if we are inside a table, it would not convert table paragraphs into top-level paragraphs. (The in-the-wild documents with this invalid input are, e.g., generated by Consultant+ legal reference database). Change-Id: I45eb9073a0651bc963badb84229ce5ae437f1a8c Reviewed-on: https://gerrit.libreoffice.org/53790 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-05-03tdf#116801 DOCX import: char styles have no IsAutoUpdate propertyMiklos Vajna1-2/+2
See sw/source/core/unocore/unomapproperties.hxx:447, UNO_NAME_IS_AUTO_UPDATE is part of the COMMON_PARA_STYLE_PROPERTIES define. So it's not "list styles don't have this", but "only paragraph styles have this". Change-Id: I1c256b087cdc2e7e341f55d717ef8e678fc69fb4 Reviewed-on: https://gerrit.libreoffice.org/53766 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-04-28loplugin:countusersofdefaultparamsNoel Grandin1-1/+1
Change-Id: I84868b3115c534a8240394283cc3beedf8cb3a80 Reviewed-on: https://gerrit.libreoffice.org/53543 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-04-26tdf#117246 RTF import: don't loose page breaks inside nested groupsMiklos Vajna1-0/+9
Regression from e3f254ab8211fbab7541cde2100a35c875b0c240 (RTF import: fix spurious page breaks at doc end (related: rhbz#1065629), 2014-02-27), the problem was that now we update the parser state to remember the next section break should set the break type of the current section to "next page", but this state should be remembered once the RTF group ends ("}" character), otherwise \page will be represented with a continuous break, i.e. lost. Change-Id: I69a8413f45e17e11d6d676c7bfd13ca7560b4d43 Reviewed-on: https://gerrit.libreoffice.org/53498 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2018-04-24tdf#116841 RTF import: fix default value of left para margin from numberingMiklos Vajna1-0/+5
The left mragin value is usually spelled out in RTF and DOCX, but this bugdoc used the WW6 RTF markup to declare the numbering rules and there the margin value was missing. This also allows me to partially revert the changes to testTdf106953 from commit 56a695fddb915bcba13b088b5b2b4e0841d4acbc (tdf#112211 RTF import: fix unwanted direct formatting for left indents, 2017-09-26). Change-Id: I9902f2f9ada4080cb4d873624ae9824342c6ee77 Reviewed-on: https://gerrit.libreoffice.org/53364 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2018-04-24tdf#106062 ooxmlimport: skip fake tab only on hanging indentJustin Luth3-17/+24
Export has changed, so that it only exports a tab when the footnote paragraph has a hanging indent. Adjusting the import code to match that change. Please test with MSO before flagging this patch as a regression. Certainly there will be some documents previously saved by LO which will now, in LO, show an extra tab character after the footnote. Any previously saved document without a hanging indent will display this extra tab. However, MSO has always seen that extra tab, so these patches are enhancing compatibility. This patch corrects several incorrect assumptions: -The paragraph style is not necessarily "Footnote". -The paragraph may have directly defined a hanging margin. -An aesthetic tab is needed on a hanging indent, not a defined margin. Change-Id: Ieaa76448ce202d92efdb8d1fc04ba2674ed120ba Reviewed-on: https://gerrit.libreoffice.org/52172 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>