summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)AuthorFilesLines
2019-03-18MSForms: Introduce a new IFieldMark for drop-down form fieldTamás Zolnai1-3/+14
* It was weird anyway that a drop-down form field was represented as an CheckboxFieldmark. * It will be useful for later commits, to have a separate field type for drop-down field. * Needed to fix-up the API a bit because it was designed to specify the field type after initialization. I solved it in a way to not break the API behavior. Hopefully it's not very slow. Reviewed-on: https://gerrit.libreoffice.org/68960 Tested-by: Jenkins Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> (cherry picked from commit f66a83c95c21b4311918a64bb85016857b49f4d4) Change-Id: I3103e6b1c36289b27b62ab9ca7dfeebc14901c8a Reviewed-on: https://gerrit.libreoffice.org/69194 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2019-03-14DOCX import: fix unexpected page break on autotext insert at end of docMiklos Vajna3-4/+12
The problem was that the page style was set on the first paragraph, which means a page break on the UI. So if you used a multi-paragraph autotext twice (insert autotext, press enter, insert autotext again) then you ended up with 2 pages instead of just 1. Fix the problem by tracking when we are in autotext import mode, and similar to pasting, don't set the page style in autotext import mode. (cherry picked from commit adcf656bb56e09fbb638a44b0cccc96f8cfced7f) Conflicts: writerfilter/source/dmapper/DomainMapper_Impl.hxx Change-Id: I4fc551b3c1b999687eb80242e261f186fd1b6f13 Reviewed-on: https://gerrit.libreoffice.org/69254 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2019-02-18tdf#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 (cherry picked from commit 4bf0e6d1b8a6d0f0dc0f7251cdfc047dc8433c89)
2019-01-14tdf#122658: Empty date form field is not exported correctly to DOCX fileTamás Zolnai1-1/+1
We need to export date format and also text content in case of empty date field. Otherwise the exported date field will be lost during import into LO Writer or MSO Word. Reviewed-on: https://gerrit.libreoffice.org/66194 Tested-by: Jenkins Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> (cherry picked from commit 24613d7abf820aff639a276a1819ada8d83e9063) Change-Id: I5cf65bedba010f64ca8f56262057f3cce32b0943 Reviewed-on: https://gerrit.libreoffice.org/66289 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2019-01-10tdf#58944 DOCX import: workaround for hidden table headersLászló Németh1-2/+20
Repeating table headers consisted of more than 10 table rows switch off table header repetition during DOCX table import to fix non-visible table content and broken tables. Repeating header lines are not visible in MSO, if there is no space for them. OOXML (and ODF) standards don't specify this exception, and unfortunately, it's easy to create tables with invisible repeating headers in MSO, resulting OOXML files with non-standardized layout. To show the same or a similar layout in LibreOffice (instead of a broken table with invisible content), we use a reasonable 10-row limit to apply header repetition, as a workaround. Later it's still possible to switch on header repetition or create a better compatible repeating table header in Writer for (pretty unlikely) tables with really repeating headers consisted of more than 10 table rows. Note: This workaround could help to create standard and more portable OOXML files in a mixed environment. Reviewed-on: https://gerrit.libreoffice.org/60689 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 110781a3a27dffe9e6690839bdce993796a08331) Change-Id: I17fbc0173ec1c4f188a46227b99dde5726530da3
2018-11-01tdf#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> (cherry picked from commit ac27f4e7abf5339f71d4f5f3fc09a13b25669fe4) Reviewed-on: https://gerrit.libreoffice.org/62736 Reviewed-by: Aron Budea <aron.budea@collabora.com> Tested-by: Aron Budea <aron.budea@collabora.com>
2018-10-13tdf120224 writerfilter: consume excess bookmark from fieldsJustin Luth1-0/+15
Although this follows a very different code path, copy the ww8 import idea of "consuming" the bookmark of a BOOK_FIELD. This is particularly important for textcontrols, especially since LO keeps duplicating bookmarks as it adds another bookmark for the field name at each save. Existing unit tests that this matches are fdo53985.docx and tdf111964.docx. I expected more, but apparently most fields don't contain or represent any bookmarks. This patch is for import only. A followup patch stops the creation of duplicate bookmarks during export. Reviewed-on: https://gerrit.libreoffice.org/61615 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 579c0749bef8c980507229439715e72060c1b077) Change-Id: I1e11980e52dc523393fd6d621191228d676e9a17
2018-09-13tdf#117988 writerfilter: IgnoreTabsAndBlanksForLineCalculationJustin Luth1-1/+1
Introduced in LO 4.0 in a mass copy of compat settings in commit 355d25eac764713f4d52eac801ade6e2ff1deab0 Reviewed-on: https://gerrit.libreoffice.org/57991 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 49ddaad2f3ba4e17e1e41e94824fb94468d2b680) Change-Id: I0d95941ff2815a43e571be1a6a0dbab1d12185d6
2018-09-12tdf#57589 writerfilter: support hash-encoded colorsJustin Luth1-0/+15
Previously, a hash-encoded value would simply fail to zero and thus the color would be dark black. The unit test covers two conditions. Paragraph 1 has a valid encoding, and pararaph 2 has an invalid coding (which is ignored and fails to COL_AUTO). Change-Id: I68940f5c4b0975a87feb6cab8fb3572b7546a077 Reviewed-on: https://gerrit.libreoffice.org/59295 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 7d01ce4021bafde8184355f46d1cbe2c370767e1)
2018-09-12tdf#118533 fix shape import: zero top margin only in first paragraphLászló Németh1-2/+3
commit 0307a62790b33ee0c02c2323a8f759e53e2035a4 fixed the top margin import of the paragraphs of document sections, and import of first paragraph of the text frames with beforeAutospacing, but nullified all other paragraph top margins in frames. Note: there is no visible margin difference in the unit test (extended by this commit) before and after the fix, because the first paragraph uses also afterAutospacing, resulting still 14pt paragraph space. But the tested beforeAutospacing value of the next paragraph checks the fix correctly. Change-Id: I0ab3b8bbff33c5488f4b4af1ea4dabf7105103f2 Reviewed-on: https://gerrit.libreoffice.org/57231 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 970eaaf1bdade63fd651db591c683e36e662f8f5)
2018-09-12tdf#118533 RTF/DOCX import: fix beforeAutospacing for first paragraphLászló Németh1-1/+7
of a text frame (first bug of tdf#104354), a table cell or a document by setting zero top margin here. This bug could result non visible paragraph content in narrow frames, as in the test document of the commit. See also commit f737c9386a605cb7d8c9dbc210c557f98f6cdc19 for a similar fix for first paragraph of a shape. Fix top margins of the first paragraphs of the affected tdf#82006 and tdf#107480, adding also new paragraphs to their RTF tests cases to keep the original tests, too. Reviewed-on: https://gerrit.libreoffice.org/56737 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 0307a62790b33ee0c02c2323a8f759e53e2035a4) Change-Id: Iea3c735eeb262233b82090fb9491991ed2df2b4e
2018-08-28tdf#119143: introduce tentative directional embedding import supportMike Kaganski3-0/+47
ECMA-376-1:2016 states that w:dir is functionally equivalent to LRE/RLE+PDF pair around the enclosed runs. So this patch does just that. Change-Id: Ibf9775338cc38a3bbc38a42a33fc64ae787b478f Reviewed-on: https://gerrit.libreoffice.org/59643 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/59671 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2018-08-21ofz: check sequence length before useCaolán McNamara1-0/+6
Change-Id: I137a9de49c5a73eb5f277dc1519e5e036abba31c Reviewed-on: https://gerrit.libreoffice.org/58947 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com> (cherry picked from commit 379bf687d1bbbcab5ee308089c1270dc95b2b410)
2018-07-20tdf#112118: DOC: properly import/export border distanceMike Kaganski1-29/+5
DOCX part was done in fb959e581c900b392efd0bb329b7cf30c8ed56a5. This commit fixes DOC part. Line width wasn't taken into account on import; and export was done only with "from text" distance, which gave poor interoperability with Word, where the borders were close to page edge. The common code is moved to editeng/source/items/frmitems.cxx and include/editeng/boxitem.hxx. Change-Id: I3d1d1312cb9dc9a9e00d9847ec11234cd787df60 Reviewed-on: https://gerrit.libreoffice.org/51366 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/57704 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Jan Holesovsky <kendy@collabora.com>
2018-07-20tdf#112118: DOCX: properly import/export border distanceMike Kaganski5-44/+77
https://wiki.openoffice.org/wiki/Writer/MSInteroperability/PageBorder discusses implementation differences between ODF model and MS formats wrt dealing with page margins and distances to borders. This patch corrects import from DOCX, so that the border distance and width doesn't add to the margin size imported from file anymore. It takes care to preserve size from page edge to text (the most important size that affects document layout). When borders go outside of range valid for ODF, the margin is set to keep text area intact, and the border is placed as close to intended position as possible. Export code now also properly handles border width. Also, an improved heuristic implemented to better export cases unsupported by Word, so that the result would look closer to ODF original. We still write correct sizes to OOXML, so that when reopened by LO, the borders will be in correct places; but as Word cannot handle sizes more than 31 pt, it will show borders shifted. This prevents from adding border widths and distances to page margins at each opening of DOCX, saving back the changed value, increasing the margins each time. This also backports commit 6d20aeeda8a346ac10782d44214a89878fd00c40 Change-Id: Ia978ab119dd661949d6c321aea91397f28d205b0 Reviewed-on: https://gerrit.libreoffice.org/51267 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/57703 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Jan Holesovsky <kendy@collabora.com>
2018-06-27tdf#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) Reviewed-on: https://gerrit.libreoffice.org/55335 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit eb65a8c54f56abc8ba66f9cbc779cd20e4740933) Change-Id: Id894604ed9b2c19400eeabbd2966f104d8b34aab Reviewed-on: https://gerrit.libreoffice.org/56053 Tested-by: Jenkins Reviewed-by: Aron Budea <aron.budea@collabora.com> (cherry picked from commit 6dcf475d5cda984ce0d1035e36267cedc3019e50)
2018-05-15tdf#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. (cherry picked from commit 42b32321381126ad70700424b8970dbc45a843f5) Change-Id: I25adc62e024a929216c7b05fec44e1f602f28285 Reviewed-on: https://gerrit.libreoffice.org/54089 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 9223a8766e5a055f77e9cc7bccbfa718e6122e28)
2018-05-15tdf#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". (cherry picked from commit ebcf27d419e41a497242c98fcfec08a2088c0720) Change-Id: I1c256b087cdc2e7e341f55d717ef8e678fc69fb4 Reviewed-on: https://gerrit.libreoffice.org/53773 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 2019109e20dc522dd3bd6a730bf639efc2c00309)
2018-05-15tdf#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). Reviewed-on: https://gerrit.libreoffice.org/53790 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 247dabcb0b92a62b233ec0237deac84e6675325c) Change-Id: I45eb9073a0651bc963badb84229ce5ae437f1a8c Reviewed-on: https://gerrit.libreoffice.org/53813 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit fe3ddff71af9298cc389ce05f6c1474bc0aeb715)
2018-05-15tdf#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. (cherry picked from commit 4a93b46e4652e73ed3460e4c66999d94e50db4b7) Change-Id: I69a8413f45e17e11d6d676c7bfd13ca7560b4d43 Reviewed-on: https://gerrit.libreoffice.org/53506 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit fc1ee8a8473beadbf5d364e059bba6c8006562af)
2018-05-15tdf#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). (cherry picked from commit 810364653b8e5ef8578ae7c9fc2e3b9196e7cdc4) Conflicts: sw/qa/extras/rtfexport/rtfexport3.cxx Reviewed-on: https://gerrit.libreoffice.org/53433 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 03b987372b680a8ecfac61d976c69f7443acba11) Change-Id: I9902f2f9ada4080cb4d873624ae9824342c6ee77
2018-04-26tdf#116976 DOCX import: fix rel size of shape after bitmapMiklos Vajna1-2/+8
We have a queue of these odd relative sizes (which are not XML attributes but text inside the XML element), if the bitmap doesn't pop the queue, the following shape won't get its size. Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport11.cxx Change-Id: I1602208c9509d8889bf0be254f3b25fb25fafca2 Reviewed-on: https://gerrit.libreoffice.org/52970 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 65f4c7b8725e8fe086889fca8c7c9b7e32fdd4d5)
2018-04-12tdf#116410 DOCX import: restrict increased object spacing to multiple shapesMiklos Vajna1-0/+4
This anchored object handling is just there to be bug-compatible with Word, it's not needed for the case when there is a single shape in the paragraph. (cherry picked from commit 2c4d84e93901571ead79c85aa3894ef4e10bf5af) Also: Related: tdf#115719 DOCX import: fix ignore of increased anchored obj spacing If there is only a single anchored object, then ignore only the current paragraph, not all paragraphs of the section. (cherry picked from commit 599ff05300599d4e4ce818092f18e76e738b921e) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport11.cxx Change-Id: I5e3dc4ba9a4a6f459ec6217e8974ebc2d7303bcc Reviewed-on: https://gerrit.libreoffice.org/52022 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit da01b17379fcb3cb89eddf718c922d1676aa482a)
2018-04-03tdf#116269 RTF import: implement reverse deduplication for listsMiklos Vajna5-2/+104
This is the same mechanism that was added in commit 1be0a3fa9ebb22b607c54b47739d4467acfed259 (n#825305: writerfilter RTF import: override style properties like Word, 2014-06-17), except that here the reference is a list definition, not a paragraph style. Also, this commit only implements the part that inserts explicit defaults for not repeated properties, not the actual deduplication, as that already works at a dmapper level. (Saving the bugdoc as DOCX, it's visible in document.xml that DOCX marks these defaults explicitly: <w:ind w:left="0" w:right="-6" w:firstLine="0"/> but RTF does not, so the right place to fix this is in the tokenizer.) (cherry picked from commit 0f0a80123d970ef6f3f8269619813e5277fff4df) Change-Id: Iec88d9bf1032d1d89194bd272500d6780c3c2224 Reviewed-on: https://gerrit.libreoffice.org/51690 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 01d7bbdc13594965aad55269c1283716974ae743)
2018-03-26tdf#113182: DOCX filter: new values of wrap property in text boxSerge Krot1-1/+6
Added support of "none" and "through" values of the w:wrap poroperty in the text box. Change-Id: I83f0c9e8162e93bf457f228d49d3b426050d4dc6 Reviewed-on: https://gerrit.libreoffice.org/51396 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit be02ce71f2ee694fa2609a7a630853c24acfbfff) Reviewed-on: https://gerrit.libreoffice.org/51431 Reviewed-by: Serge Krot (CIB) <Serge.Krot@cib.de> (cherry picked from commit 133821d1526800a93bb395a91f87dc77d29f0b8d)
2018-03-26tdf#116472: import "auto" border color as blackMike Kaganski1-4/+5
Since commit fe6da2feb57c3d5e355a36f6b8ac09b48412ff39, "auto" color is supported in OOXML import. Since ODF doesn't support "auto" color as border color, just convert "auto" border color to black on import, like is done in GetLineIndex in ww8par6.cxx. Incidentally, this also fixes a problem in RTF import, where we used to import black borders ("\red0\green0\blue0;" entries in color table) as 0x000001 ("\red0\green0\blue1;") - see fixed tests in rtfexport2.cxx. Change-Id: I4f5e720d215b51c8a43dc7c58f338741bd608efc Reviewed-on: https://gerrit.libreoffice.org/51519 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/51585 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 88e22b92bce612f349f8aa38adf69a8806361da3)
2018-03-26tdf#116179 Support reading "auto" colour from docxLuke Deller11-12/+51
In docx a colour value is represented as a 6-digit hex RGB value, or alternatively the word "auto" to represent automatic colour. - Add support for reading the value "auto" as COL_AUTO. Previously this would be read as if it were a hex value, stopping at the letter 'u' which is not a valid hex digit, resulting in the colour 0x00000A - a very dark blue, which looks close enough to black that it went unnoticed for a long time :-) - Remove code which tried to handle this wrong 0x00000A value, including the constant OOXML_COLOR_AUTO, as it is no longer needed and will cause surprises for anyone who really wanted this exact shade of dark blue - Fix unit tests that were checking for 0x00000A Change-Id: I6000070341931147ff9341ad6281cd3b53c02b46 Reviewed-on: https://gerrit.libreoffice.org/50995 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Reviewed-on: https://gerrit.libreoffice.org/51461 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 3967aebca94be9ceea3e36b43f7f53589473ad4e)
2018-03-25oox: cosmetic cleanupAshod Nakashian1-34/+26
Change-Id: Ifafd7338ddfec8b707b5ddf4acb39512faf186da Reviewed-on: https://gerrit.libreoffice.org/49325 Reviewed-by: Ashod Nakashian <ashnakash@gmail.com> Tested-by: Ashod Nakashian <ashnakash@gmail.com> (cherry picked from commit 97a73d2772a86e26369fc32e25a59c0d5a274c01)
2018-03-25oox: move putPropertiesToDocumentGrabBag to XmlFilterBaseAshod Nakashian1-35/+3
Reviewed-on: https://gerrit.libreoffice.org/49235 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Ashod Nakashian <ashnakash@gmail.com> (cherry picked from commit e26a95360e60e0c17e70e72f36fb988bb664ddb5) Change-Id: Ic3cbabc420c7856682b889528043563622997c14
2018-03-25DOCX import: don't try to set grab-gag props as UNO propsMiklos Vajna1-9/+0
This fixes loads of warnings like this one: warn:legacy.osl:22335:22335:writerfilter/source/dmapper/StyleSheetTable.cxx:1611: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue during import. They are harmless as we catch the exception, but they are just noise. It seems the code that transforms grab-bag pseudo-props into real props was added in commit 4c3ba3a413be7339115ea5e6edc825a8434cd345 (fdo#75757: Remove inheritance from std::map., 2014-07-26), which is supposed to be a pure refactoring, so just remove this problematic transformation. Change-Id: Ibf45bfedc661f9e065405c47623516c4026148a4 Reviewed-on: https://gerrit.libreoffice.org/49105 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit a6f2199e9888cb75960f1d35034bd44fb45e5565)
2018-03-25tdf#115276: multiply quarter-points by 5 (not divide) to convert to twipsMike Kaganski1-1/+2
Unit test will come in separate commit Change-Id: I4cd6983d708868883c766b239cb57752106a59bf Reviewed-on: https://gerrit.libreoffice.org/48780 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 968084838e980b4152d88b95570c16ebad9d9b16)
2018-03-19tdf#114333: consider trleft for 1st cell width on import; don't...Mike Kaganski4-2/+23
... recalculate cell widths by factor pagewidth/tablewidth on export This makes the import and export symmetrical. Unit test included. Some existing unit tests were updated: - testTdf97035: the previous width of B1 cell (3571 twips) was not stable enough on round-trip. Old code saved table with wrong width, and incidentally that made it to output correct width of the cell. New code outputs table width correctly, and drops unneeded cell width adjustment on export, so the rounding error on initial import makes output cell width wrong. We have a cumbersome arithmetics to import cell widths from RTF: 1. In DomainMapperTableManager::sprm (case NS_ooxml::LN_CT_TblGridBase_gridCol) we do convertTwipToMM100 on initial sizes in twips; 2. Then, in DomainMapperTableManager::endOfRowAction, we do rtl::math::round((fGridWidth * 10000) / nFullWidthRelative) on the mm100 sizes (the 10000 is UNO_TABLE_COLUMN_SUM from unotbl.cxx, which allows to measure cell widths in 100ths of percent of table's width instead of absolute sizes) 3. Last, in SwTable::NewSetTabCols, we do lcl_MulDiv64<long>(nNewPos, rParm.nNewWish, nNewWidth) where rParm.nNewWish is table's width in twips (again), and nNewWidth is 10000. So, the three permutations give us twips back, but rounding errors may make result differ from initial value (as in case of cell width 1927 twips and table width 15527 twips, which results in 1926). The unstable width that resulted in roundtrip error was changed by 1. The changed unit test file is checked to still correctly test tdf#97035 - testFdo55525: previously, the testdoc was imported with wrong width (too narrow); that caused rounding error on cell width calculation. Current tested value is more correct. Change-Id: I69112521c35b316ed6df11d5e4ff7336534164bd Reviewed-on: https://gerrit.libreoffice.org/46094 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 0f9a596aa853b4f2beeff25c131246a7b31492a4)
2018-03-19Check if we have status indicatorMike Kaganski1-1/+2
In other methods it's always checked, so presumably it might be absent. In caller sites (like OOXMLFastContextHandler::endOfParagraph), it can't (and shouldn't) be checked. Change-Id: Ia2edf8b121cac15e6454bc6321d76517fcdf110f Reviewed-on: https://gerrit.libreoffice.org/45951 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit e5a3f12588e8e8eb80cc5af4e412fa2c83f0895e)
2018-03-19tdf#115861 DOCX import: avoid last-paragraph removal when discarding footerMiklos Vajna2-1/+19
Discarding header/footer is necessary when the document or section settings request to ignore first or even headers/footers. In the bugdoc case settings.xml didn't opt-in for different even/odd footers, but there was an even footer to be ignored. Handle this state at two more places, so we don't end up in a situation where we ignore the footer but not its "remove last (empty) paragraph at the end of the footer" action. Also make the debug dumper for text ranges more robust to have a working token dump when we try to get the string for a table. (cherry picked from commit 49cf733effc56c09c5e2eb023120c2d3532b5b3d) Change-Id: I6395f37aa40c42304e2c918d87dadecb21e9d378 Reviewed-on: https://gerrit.libreoffice.org/50884 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Meeks <michael.meeks@collabora.com> (cherry picked from commit 0edb7585c7bdf5f01dcf31f106477c959f107a84)
2018-03-19forcepoint #24 back() on empty vectorCaolán McNamara2-0/+8
Thanks to Antti Levomäki and Christian Jalio from Forcepoint. Change-Id: Idb6723b53a1ae8aaca80847bfe643bc4abaedd21 Reviewed-on: https://gerrit.libreoffice.org/51122 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com> (cherry picked from commit 874ce3384be2e11a7fd0ed02bf7d05e0ab5bea79)
2018-03-19forcepoint #21 pop on empty stackCaolán McNamara1-1/+4
Thanks to Antti Levomäki and Christian Jalio from Forcepoint. Change-Id: I25b1c6361fb0a3ae6b01f2be870c9e1b49bf5b84 Reviewed-on: https://gerrit.libreoffice.org/51115 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit 3686a3fc1b2eaee53b1ab32f33455b2b37aa8c6e)
2018-02-28tdf#115715 RTF import: ignore zero para indents in styles without parentsMiklos Vajna2-5/+29
The only reason the DOCX equivalent of the bugdoc was imported correctly is that these default zero margins are simply missing from the DOCX markup, suggesting Word ignores them. We now do the same, this way the stripped down document's 3 paragraphs all have different margins as expected. (Also rework the testTdf112211_2 testcase to test the original problem better: I verified that the layout is unchanged before/after this patch.) (cherry picked from commit 59363e639b67a8acbd6da240635de47921b2c955) Change-Id: I88d56c27c19e070e983c3392f99bca96597cd56e Reviewed-on: https://gerrit.libreoffice.org/50435 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-02-27forcepoint #10 pop empty stackCaolán McNamara2-1/+7
Change-Id: I96452a86187a6b03251614625445d1b18a5ee218 Reviewed-on: https://gerrit.libreoffice.org/50358 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2018-02-26tdf#115883 DOCX import: catch RuntimeException from SwXFrameMiklos Vajna1-1/+8
getPropertyValue("Surround") for a non-inserted frame can throw, but hasPropertyValue("Surround") still returns true. So fix the regression by just catching the exception, assuming that in that case no increased spacing is needed. Change-Id: I49a78ce8d41b4e1cc7d23721d5dc70f7550c94af Reviewed-on: https://gerrit.libreoffice.org/50175 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 5e1a50cc433a865da677faf7d502ba41858e45f6) Reviewed-on: https://gerrit.libreoffice.org/50348 Reviewed-by: Michael Stahl <mstahl@redhat.com>
2018-02-21tdf#112694 DOCX import: handle <w:titlePg> when turning on follow style headerMiklos Vajna2-11/+10
Commit 17e51f427b3f0cec74ac8e0a1b3f51189006ae6f (DOCX import: first page header should always set default headers as well, 2014-11-21) turned on header/footer of follow page styles of first page styles when the first page style had the header/footer turned on, but failed to consider if <w:titlePg> is present or not. When it's not present, the first page header/footer should be ignored. An additional problem is that by the time DomainMapper_Impl::PushPageHeaderFooter() is called, <w:titlePg> is not parsed yet, so we can't act accordingly. Fix the problem by moving the check to SectionPropertyMap::PrepareHeaderFooterProperties(), which runs at the end of the section properties, where all required info is available, there we can just check for m_bTitlePage. This allows reverting the two changes to existing testcases in CppunitTest_sw_ooxmlexport6 from the original commit as a side-effect. (cherry picked from commit a16275a3647a2fba9913ed23e8329e45b02123b4) Change-Id: Ic628adab99a4b148fcfd66ca39d0cf81eb7dd9f1 Reviewed-on: https://gerrit.libreoffice.org/50027 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-02-16tdf#113258 DOCX import: fix beforeAutospacing for shape first paragraphMiklos Vajna3-0/+32
Commit c761df1e42fd11acc5fc05b0baacd803c3788ca6 (tdf#84678 DOCX import: fix handling of textbox margins, 2016-10-25) uncovered a previously harder to notice problem that single-paragraph shapes have an incorrect upper paragraph margin for the first paragraph. Now that the shape margins are correct this problematic paragraph margin causes crop of the shape text. Fix the problem by adapting the DOCX import to the WW8 import's SwWW8ImplReader::AppendTextNode() (the "If this is the first paragraph in the document" part), where it seems the first paragraph is not only the literally first paragraph in the document, but also the first paragraph of shapes as well. (cherry picked from commit f737c9386a605cb7d8c9dbc210c557f98f6cdc19) Conflicts: writerfilter/source/dmapper/DomainMapper.cxx Change-Id: I9d99b9cfabae2c9a7c33eefefb5a9f008669e93d Reviewed-on: https://gerrit.libreoffice.org/49626 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-02-16tdf#115719 DOCX import: increase paragraph spacing for anchored objectsMiklos Vajna7-29/+135
... like Word 2013 does, when the version string indicates that the new layout is wanted. An alternative to this change would be to add a new sw layout compatibility flag and handle this at a layout level (somewhere in SwAnchoredObject::GetObjRectWithSpaces()). The downside of that approach is that once a layout flag is added, it's not preferred to tweak its behavior, while doing the same at import time is not a problem. Also it's better to have a flag for something which has clear behavior in some spec / implementer notes, which is not the case for this problem. (I've mailed dochelp@microsoft, no answer so far.) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport11.cxx Change-Id: Ibad28d27e4bcbe1991a3be1c686064e18e9ffa4d Reviewed-on: https://gerrit.libreoffice.org/49802 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-02-09tdf#115242 RTF import: order numPr before other paragraph propertiesMiklos Vajna7-11/+48
So that paragraph properties inherited from numbering properties can be properly overwritten with direct formatting, even when we have to take style deduplication into account. The OOXML tokenizer already did this, writerfilter::dmapper::DomainMapper::sprmWithProps()'s NS_ooxml::LN_CT_NumPr_numId depends on this, so adapt the RTF tokenizer accordingly. (cherry picked from commit 03cee02464f230a2efa67d131c137f32fe540052) Conflicts: sw/qa/extras/rtfimport/rtfimport.cxx Change-Id: Iec6026d146f08a9d06266763d01ed626a2d1f3d1 Reviewed-on: https://gerrit.libreoffice.org/49355 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-02-07tdf#114217: Consider relative width when importing floating tableMike Kaganski3-3/+12
Unit test included Change-Id: I8e3338d7df431bd016caa4e06e684fbd189127c4 Reviewed-on: https://gerrit.libreoffice.org/49324 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 76d6fcd05c630a928dd3bd028d560792d9c904ca) Reviewed-on: https://gerrit.libreoffice.org/49333 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2018-02-07rtf: null-derefCaolán McNamara1-21/+30
Change-Id: I9c4510cb91e2572a3ab2b62497dc4dd9fd1119c8 Reviewed-on: https://gerrit.libreoffice.org/49341 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-01-30DOCX import: handle horizontal flip of bitmapsMiklos Vajna1-0/+11
Horizontal mirror on the UNO API level, mirror on the vertical axis internally. (cherry picked from commit 4bdbb5502f5995727017e22bb8a74b9f45552067) Change-Id: If142274a8f81a6875059a2651af6d8470870a36a Reviewed-on: https://gerrit.libreoffice.org/48893 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2018-01-30tdf#115155 RTF import: fix left indent handling inside list definitionMiklos Vajna2-2/+12
This used to work in the past only because the left indent was also imported as a direct paragraph formatting, but that is not the case since left margin of lists is deduplicated during import after commit c9dee880d88305312094b311abdae155e452bf14 (tdf#104016 RTF import: deduplicate before text indent from numbering, 2017-12-05). (cherry picked from commit 7655001a65a250ea7cd70f2efcc78037b5a9813f) Change-Id: I1c9be30700c51ef97fb274e8781d6008db3121d8 Reviewed-on: https://gerrit.libreoffice.org/48888 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-01-27tdf#115153 writerfilter: RTF import: fix vert orient of Word 6 shapesMichael Stahl1-2/+8
The bugdoc is affected by the change of default vertical alignment; apparently it's not even possible to set the vertical alignment of a Word 6 drawing object (\do) so we have to set the Word default. (regression from c79467ba954987f1d239c594c1e1b3af3f5515f6) (cherry picked from commit dc16cc0492ba96007078cc285fee1a8d03f40d55) tdf#115153 the missing test document (cherry picked from commit b7f12d8fd7493a7201ae5fd97e80e0296538f136) Change-Id: I4084a7a7e2a55f864cb569e04632e034d59eefdb Reviewed-on: https://gerrit.libreoffice.org/48524 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-01-23tdf#113946 add 'topMargin' to GraphicHelpers importPatrick Jaap1-42/+44
The case '...topMargin' was not caught for setting a relative vertical position in GraphicHelpers. The test file demands a '7' here, which stands for 'PAGE_FRAME'. The '7' was overwritten in GraphicImport in case 'LN_CT_Anchor_positionV' by a call of 'resolve'. For a better overview a switch is inserted here. Change-Id: Ie98209fe445ecbba15c3dafe5980ca52421126f8 Reviewed-on: https://gerrit.libreoffice.org/47908 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-01-09tdf#114703 DOCX import: apply num defaults only to abstract numsMiklos Vajna2-16/+20
Numbering definitions have two levels: abstract ones and overrides. The full definition is a merge of the two. Make sure that when defaults are added to the numbering level properties, these are only added for abstract ones, otherwise overriding e.g. the start value of a level will also pull in other, unwanted default properties. (cherry picked from commit a6ec829055ab0b9d223979ae5f90d158d5549db1) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport11.cxx Change-Id: If0273ebc6b49476df17b09d636489a3bfb717334 Reviewed-on: https://gerrit.libreoffice.org/47653 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-28 09:48:14 +0000