summaryrefslogtreecommitdiff
path: root/writerfilter/source
AgeCommit message (Collapse)Author
2019-08-22ofz#10056 Null derefCaolán McNamara
Change-Id: I9ea0f272d0a8b13fb51fec55ac57adca47cafc77 Reviewed-on: https://gerrit.libreoffice.org/59601 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit 48c677d55330ac6caf0065fa1776c985b876eead)
2019-08-22ofz#10045 Null derefCaolán McNamara
Change-Id: If9c8edd94b02240510325d6c9c0fc7584ba89b5f Reviewed-on: https://gerrit.libreoffice.org/59574 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit fabac301a2c431a51bcae435e7ad87c843331877)
2019-08-22ofz#9934 null derefCaolán McNamara
Change-Id: I6833ad8a556b561a37e468da8845914cabfac4c5 Reviewed-on: https://gerrit.libreoffice.org/59249 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit 4fb7390956a193e00c1b599129b89933c41f98ae)
2019-08-22forcepoint#62 null derefCaolán McNamara
Change-Id: I255aeb96c3763aa106128d3463e4fd55395ef8b8 Reviewed-on: https://gerrit.libreoffice.org/58409 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit 9e434f2f5ad61092ee685369bce93d90a28db149)
2019-08-22forcepoint#58 null derefCaolán McNamara
Change-Id: I826890ec85a16bc05fc1e4cd068079b0f8734d07 Reviewed-on: https://gerrit.libreoffice.org/58394 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit 8cee73aae9bca3a94aa7a0aa3bfa82b593d4c3c7)
2019-08-22forcepoint#56 null derefCaolán McNamara
Change-Id: Iaa9c4d6901a340145412fa46eaf5c292c3fb62e8 Reviewed-on: https://gerrit.libreoffice.org/58387 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit 0845c1a74aef650b4aebaeea9587b3bfb5b38ffb)
2019-08-22forcepoint #21 pop on empty stackCaolán McNamara
Thanks to Antti Levomäki and Christian Jalio from Forcepoint. 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) Change-Id: I25b1c6361fb0a3ae6b01f2be870c9e1b49bf5b84
2019-08-22ofz: check sequence length before useCaolán McNamara
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-09-21tdf#119143: introduce tentative directional embedding import supportMike Kaganski
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/59672 Reviewed-by: Aron Budea <aron.budea@collabora.com> Tested-by: Aron Budea <aron.budea@collabora.com> (cherry picked from commit 348a1e11045ca8d9dbceab43a68d44dbde3f922c)
2018-05-23tdf#116976 DOCX import: fix rel size of shape after bitmapMiklos Vajna
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/54669 Reviewed-by: Aron Budea <aron.budea@collabora.com> Tested-by: Aron Budea <aron.budea@collabora.com> (cherry picked from commit e6f39221b5ce652c78cc675c8dd0a662332ecacc)
2018-04-27tdf#117246 RTF import: don't loose page breaks inside nested groupsMiklos Vajna
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) Conflicts: sw/qa/extras/rtfimport/rtfimport.cxx Change-Id: I69a8413f45e17e11d6d676c7bfd13ca7560b4d43 Reviewed-on: https://gerrit.libreoffice.org/53557 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2018-04-07forcepoint #24 back() on empty vectorCaolán McNamara
Thanks to Antti Levomäki and Christian Jalio from Forcepoint. Change-Id: Idb6723b53a1ae8aaca80847bfe643bc4abaedd21 Reviewed-on: https://gerrit.libreoffice.org/51123 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com> (cherry picked from commit 13468a3a667c6719ccbc44c913c194fc77d8e7cf)
2018-04-03tdf#116472: import "auto" border color as blackMike Kaganski
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 rtfimport.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> Reviewed-on: https://gerrit.libreoffice.org/52272 Reviewed-by: Aron Budea <aron.budea@collabora.com> Tested-by: Aron Budea <aron.budea@collabora.com> (cherry picked from commit 3a53fe4456f72dd57640b5bb33c5f08da96069f7) Reviewed-on: https://gerrit.libreoffice.org/52348
2018-04-03tdf#116179 Support reading "auto" colour from docxLuke Deller
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 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) Change-Id: I6000070341931147ff9341ad6281cd3b53c02b46 (cherry picked from commit ccef956c4f11ac6c0612a0d22845d02743c91039)
2018-03-23tdf#115861 DOCX import: avoid last-paragraph removal when discarding footerMiklos Vajna
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) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport11.cxx Change-Id: I6395f37aa40c42304e2c918d87dadecb21e9d378 Reviewed-on: https://gerrit.libreoffice.org/51763 Reviewed-by: Aron Budea <aron.budea@collabora.com> Tested-by: Aron Budea <aron.budea@collabora.com> (cherry picked from commit 01d1fdf8a348013eb6fc4cda61d3225a81681dd5) Reviewed-on: https://gerrit.libreoffice.org/51764
2018-03-23tdf#112118: DOC: properly import/export border distanceMike Kaganski
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/51487 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Miklos Vajna <vmiklos@collabora.co.uk> Reviewed-on: https://gerrit.libreoffice.org/51686 Reviewed-by: Aron Budea <aron.budea@collabora.com> Tested-by: Aron Budea <aron.budea@collabora.com>
2018-03-23tdf#112118: DOCX: properly import/export border distanceMike Kaganski
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. 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/51399 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit c91f81f59fac308d8ab86637b241502e68d7ab6a) Reviewed-on: https://gerrit.libreoffice.org/51400 Reviewed-by: Aron Budea <aron.budea@collabora.com> Tested-by: Aron Budea <aron.budea@collabora.com>
2018-03-06forcepoint #10 pop empty stackCaolán McNamara
Reviewed-on: https://gerrit.libreoffice.org/50359 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 befd67bcd0607bf2f0116a5418f3c7278e471631) Change-Id: I96452a86187a6b03251614625445d1b18a5ee218
2018-02-12DOCX import: handle horizontal flip of bitmapsMiklos Vajna
Horizontal mirror on the UNO API level, mirror on the vertical axis internally. (cherry picked from commit 4bdbb5502f5995727017e22bb8a74b9f45552067) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport11.cxx Change-Id: If142274a8f81a6875059a2651af6d8470870a36a
2018-02-09tdf#114217: Consider relative width when importing floating tableMike Kaganski
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> Reviewed-on: https://gerrit.libreoffice.org/49335 Reviewed-by: Aron Budea <aron.budea@collabora.com> Tested-by: Aron Budea <aron.budea@collabora.com> (cherry picked from commit 561f2a32966ff68bdf0d30a33b90fe95ee7e48cb)
2018-01-17tdf#112352 ooxmlimport: ALWAYS treat 1st nextpage w/cols as contJustin Luth
fix 5.4 regression from 4605bd46984125a99b0e993b71efa6edb411699f. When there are columns, if a nextpage section doesn't contain any other "page style" details we treat it as a continuous break, If we don't, the column info becomes part of the style itself, and not just a section property. However, the very first section is troublesome - by definition it DOES contain page style details, and so if the document starts with columns, the default style would gain the column attribute. Usually that results in a mess, so lets make sure that we avoid that also in the case where headers/footers are defined. Reviewed-on: https://gerrit.libreoffice.org/44505 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org> Tested-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit afc96d263959d10e457b54a574f0829d20e99df4) Change-Id: I7e08a9218e4304206579ed064bc92c9604d4470e Reviewed-on: https://gerrit.libreoffice.org/46638 Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Jan Holesovsky <kendy@collabora.com> Tested-by: Jan Holesovsky <kendy@collabora.com> (cherry picked from commit 2bdfe1355c4c571e71bd4197d5814c6e15fb8db7)
2017-11-15tdf#111964: only trim XML whitespaceMike Kaganski
OUString::trim() uses rtl_uString_newTrim, which relies upon rtl_ImplIsWhitespace. The latter treats as whitespaces not only characters with values less than or equal to 32, but also Unicode General Punctuation area Space and some Control characters. Thus, using OUString::trim() is incorrect when the goal is to trim XML whitespace, which is defined as one of 0x09, 0x0A, 0x0D, 0x20. A unit test included. Change-Id: I45a132be923a52dcd5a4c35aeecb53d423b49fec Reviewed-on: https://gerrit.libreoffice.org/41444 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/44746 Reviewed-by: Aron Budea <aron.budea@collabora.com> Tested-by: Aron Budea <aron.budea@collabora.com>
2017-11-08tdf#105688: findZOrder: catch exceptions from getPropertyValueMike Kaganski
For some reason, sometimes items in GraphicZOrderHelper don't have ZOrder property value, and so throw in getPropertyValue. E.g., SwXFrame::getPropertyValue throws uno::RuntimeException when its GetFrameFormat() returns nullptr. The patch catches these to allow to proceed with fallback z-order. Change-Id: I96140195f45364bccee7c5547d373158e2b49154 Reviewed-on: https://gerrit.libreoffice.org/37392 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit f66b76a4d20719e4c13bd755c49f8140a0e72816) Reviewed-on: https://gerrit.libreoffice.org/44463 Reviewed-by: Aron Budea <aron.budea@collabora.com> Tested-by: Aron Budea <aron.budea@collabora.com>
2017-09-19Word 2013 and 2016 does not honor the <w:view> setting, let's ignore it too.Jan Holesovsky
In other words, let's open documents in the non-web view even when saved with <w:view w:val="web"/>. The behavior I see in Word 2013 (and it's documented that his happens in 2016 too) is that the setting is not a document setting any more, but user's setting. Ie. regardless of what is written in the file, the .docx document opens in the Print Layout if the Word was in the Print Layout until now, and in the Web Layout if it was that mode. We handle the non-web layout much better than the web layout, so let's just default to the normal layout on load. Change-Id: Ieba7ddc280b9b79501a6b89ff21b03a86356583c Reviewed-on: https://gerrit.libreoffice.org/42414 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan Holesovsky <kendy@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/42412 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-09-12tdf#112304 Revert "Watermark: not visible if page background was set"Szymon Kłos
This reverts commit 39c08074a286855dd014ce1c30b8f7ef95b10242. Fixed by: I69517efb7d82acd719d6a27a09ba61554dbf1ec9 Change-Id: Icd45b3f55292670ff7338a367eba212453a0687e Reviewed-on: https://gerrit.libreoffice.org/42155 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/42165 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2017-09-12tdf#112346: take Word no-wrap limit into account also for ww8Mike Kaganski
This also makes ww8 floating-table conversion decision heuristics somewhat closer to OOXML code. Change-Id: I29ca2ebabd1758ad98e02aaf560cf2f44daec3a8 Reviewed-on: https://gerrit.libreoffice.org/42196 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Reviewed-on: https://gerrit.libreoffice.org/42216 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-08-25Watermark: not visible if page background was setSzymon Kłos
Watermark was drawn under the page background. It has to be placed on the upper layer to be visible. Change-Id: I132a313eed6fb712aafdca14a38fe559aa4231c8 Reviewed-on: https://gerrit.libreoffice.org/41289 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/41557 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2017-08-25tdf#109184 auto cell color should be transparentSzymon Kłos
Don't add color to the property map if is set to auto. In this case white color was assumed and tables were white instead of transparent. Reviewed-on: https://gerrit.libreoffice.org/41255 Reviewed-by: Szymon Kłos <szymon.klos@collabora.com> Tested-by: Szymon Kłos <szymon.klos@collabora.com> (cherry picked from commit d239bf6d79e93f650a4241fcd2da0cb77c9cb95b) Change-Id: I7f203b8f3831b86ba8de33dc57de227b3029c6d9 Reviewed-on: https://gerrit.libreoffice.org/41451 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2017-08-25tdf#50097: DOCX: export form controls as MSO ActiveX controlsTamás Zolnai
* Use the same structure for export what MSO uses ** Position and size information are exported as VML shape properties ** Different handling of inline and floating controls (pict or object) ** Do some changes on VML shape export to match how MSO exports these controls ** Write out activeX.xml and activeX.bin to store control properties ** Use persistStorage storage type defined in activeX.xml * Drop grabbaging of activex.XML and activeX.bin * Cleanup control related test code Signed-off-by: Tamás Zolnai <tamas.zolnai@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/41256 Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit c0cc02e2934aeb12dda44818955e5964496c186a) Change-Id: I38bb2b2ffd2676c5459b61ec2549c31348bab41c This test intended to be an export test Change-Id: Ib233bd603185efdb85ed30f3d00c28512d57a0ac Reviewed-on: https://gerrit.libreoffice.org/41355 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> (cherry picked from commit a7e8c5304b740cb4e03e25b7217ce6071c29c09b) Fix two issues in ActiveX DOCX import / export code * Inline anchored VML shape had wrong vertical position ** In MSO inline shapes are positioned to the top of the baseline * During export all shape ids were the same (shape_0) ** VML shapes used to be exported only as fallback, I guess that's why it did not cause any issue before. ** Override the shapeid generator with a new one, which actually generates unique shapeids. Reviewed-on: https://gerrit.libreoffice.org/41319 Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com> (cherry picked from commit 2d1fe7fb67ec1ff1b96912c0945d17d54aecb12e) Change-Id: I752f39d092d0b61d91824141655dae662dbeafbc DOCX: Fix an other test case of ActiveX control export When LO control is anchored to the end of the run, it is exported into a new run. Reviewed-on: https://gerrit.libreoffice.org/41472 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> (cherry picked from commit b129421764ae78a1422812169fce8eb4914a6b22) Change-Id: I9269fd1b34924780aad61c452d1e2094dc8e4aad Reviewed-on: https://gerrit.libreoffice.org/41484 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2017-08-25tdf#91384: DOCX: import ActiveX controlsTamás Zolnai
Reviewed-on: https://gerrit.libreoffice.org/40930 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> (cherry picked from commit 4a764319cbad4e2589cc105145ac27defbf49ff6) Change-Id: Iebf2ff65fcec3231acfc962fb2f1abc2ed2dc67a Avoid warning in OleHandler Related to ActiveX controls. Change-Id: Ief7ee67ca8e4f086a1d5e0400d0eaf3ebc8cdaaf Reviewed-on: https://gerrit.libreoffice.org/40934 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> (cherry picked from commit 368b583b992f2e9cad46c2362c9529a07c36d7a9) Reviewed-on: https://gerrit.libreoffice.org/41483 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2017-08-10tdf#111550: A workaround for out-of-order (in-paragraph) tbl on OOXMLMike Kaganski
Word allows <w:tbl> to be direct child of <w:p>, which is illegal according to ECMA-376-1:2016. This allows for import the data in such tables (previously, this text was simply dropped, causing dataloss) - bug-to-bug compatibility with Word. Change-Id: I19c17ab19915ea46685727c635476fe5df593212 Reviewed-on: https://gerrit.libreoffice.org/40909 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 67a61e54531801645d51ad89aac30064b8c4b4e8) Reviewed-on: https://gerrit.libreoffice.org/40949 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-08-10Revert "A temporary workaround for out-of-order (in-paragraph) tbl on OOXML"Mike Kaganski
A better fix follows This reverts commit 0eb0c7308ad57f4a20b5691d450b5185e52475f6. Change-Id: If36f73c580d96445086d8ab3d87fff6a76cd8b6a Reviewed-on: https://gerrit.libreoffice.org/40948 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-08-04tdf#108944 writerfilter: fix missing footnote separatorJustin Luth
Fix regression from e79ef12b7a904f17d4147fa409d055c12b70f952 tdf#107033 DOCX import: fix unexpected missing footnote separator. Initially related to tdf#68787. If HandleMarginsHeaderFooter was called twice, then it automatically would have disabled the separator. Clearing the HasFtn/HasFtnSep flags also shouldn't be run when in the footnote sections. Reviewed-on: https://gerrit.libreoffice.org/40551 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 6f57c09aadd40009173f8ae3654004dd0cad9fb8) Change-Id: I00cbd1cbc8dc86edf426f852c59c3f943e373b13 Reviewed-on: https://gerrit.libreoffice.org/40590 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 234df2fb5901588ccf20cb35cb4c5922aeb89817)
2017-07-28tdf#109524: use 100% table width when there's no explicit width availableMike Kaganski
According to ECMA-376-1:2016 17.4.63, 17.18.87, etc, all table widths are considered preferred, and actual table layout should be determined using an algorithm described in 17.18.87. When w:tblLayout element is omitted, or there is no explicit width information given, it is assumed that AutoFit Table Layout should be used, i.e. using cells content to determine final widths of table grid. In the description of the AutoFit Table Layout algorithm, it is stated that the table width grows to hold data, but no more than page width. As a first approach, this commit just sets table width to 100% when there's no width data available. TODO is to implement the AutoFit Table Layout algorithm properly. Change-Id: I000c548eb152c70d2c6e053f4d2b1d16e8976c27 Reviewed-on: https://gerrit.libreoffice.org/40500 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit cae5dd9363b68dbabbeb2069f4aee7d057f6b5a8) Reviewed-on: https://gerrit.libreoffice.org/40508 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-07-20tdf#108849: allow out-of-order sectPrMike Kaganski
According to ISO/IEC 29500-1:2016(E) 17.6.17), the final <w:sectPr> must be the last child element of the body element. Also, this is enforced in schema for CT_Body complex type (Annex A. (normative) Schemas – W3C XML Schema, A.1 WordprocessingML, page 3866), where sectPr is a part of <xsd:sequence>, and thus *must* stay at specific place in sequence, namely being the last element, and be at most one instance. However, real-life documents (generated by some third-party software) have sectPr before other body contents. Unfortunately, MS Word seems to allow this standards-violating content, and thus encourages creation of non-standard documents by third-party generators. This patch doesn't assume that current final (body-level) sectPr is the last body element, and does not mark current paragraph as last section's paragraph. Thus, current section (possibly started after previous paragraph-level sectPr) is continued after final sectPr is closed. Change-Id: I8e88288bc6659d77d17986514b3b4fe16a5b45d9 Reviewed-on: https://gerrit.libreoffice.org/40161 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 4b4cd502806cfc9c9cc9754b8aae18a2c2632cdc) Reviewed-on: https://gerrit.libreoffice.org/40216 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-07-18A temporary workaround for out-of-order (in-paragraph) tbl on OOXMLcp-5.3-20Mike Kaganski
This allows for import the data in such tables (previously, this text was simply dropped, causing dataloss). Layout problems are not fixed yet. Change-Id: Id7422adfe0998d1e2adcd4bf0b0e0a1dd7ed37bf Reviewed-on: https://gerrit.libreoffice.org/40105 Reviewed-by: Aron Budea <aron.budea@collabora.com> Tested-by: Aron Budea <aron.budea@collabora.com>
2017-07-14tdf#109053: DOCX: Multipage table is not imported properlyTamás Zolnai
An other use case when converting to a "floating table" is not a good idea. In this case we can check whether next to the table anything fits in the text area. If not then we can avoid floating table conversion. Reviewed-on: https://gerrit.libreoffice.org/39811 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> (cherry picked from commit fc55711f01af172eb3a034454405fa941454c781) Change-Id: I798a2f4c7a9dfe6aecbe4a73e3162b49ea5f0adc Reviewed-on: https://gerrit.libreoffice.org/39930 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2017-07-12Fix tdf#106029 - Add setting XML_doNotExpandShiftReturn when exporting to docxnikki
Change-Id: Ie8ffb0f2d5444c6ead13bdc894715c5a2e6d0baa Reviewed-on: https://gerrit.libreoffice.org/36485 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 9ad9c5183f348384b62ec88459a3a5922e423d83) Reviewed-on: https://gerrit.libreoffice.org/39749 (cherry picked from commit a59cf3ecab2f327801c2b580d20df9e8b643cc6c)
2017-07-12tdf#109063 DOCX import: consider wrap space for multi-page floattablesMiklos Vajna
Follow-up to commit 78d1f1c2835b9fae0f91ed771fc1d594c7817502 (fdo#68607 bnc#816593 DomainMapperTableHandler: don't always start a frame, 2013-09-03), turns out in case there is little space between the table and the edge of the body area, then there is no wrapping performed in Word, so we should not convert to floating table, either. The limit seems to be 266 twips (mm100 unit is used in the code), and this seems to be constant: it does not change if both the table and the page width is changed, nor does it change when the empty paragraph to be wrapped has a different paragraph mark size. For the majority of the documents this means no change as usually there is either no space available for wrapping or there is a lot more available. (cherry picked from commit 25445d24cfa87522ee4c47e4aa7e6e816cdc9a36) Conflicts: writerfilter/source/dmapper/PropertyMap.cxx Change-Id: Ibbf7409065ba958854514f23b360be56677c8fe3 Reviewed-on: https://gerrit.libreoffice.org/39828 Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2017-07-11tdf#108545 show an icon (DOCX inside DOCX)Szymon Kłos
If DrawAspect is equal "Icon", show an icon not document preview Document is opened in the separate window, not in-place. Change-Id: I3a8d81e7340b29d247f8ac440c06b0420bb65644 Reviewed-on: https://gerrit.libreoffice.org/39440 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/39716 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-07-11tdf#108544 edit in window (XLSX inside DOCX)Szymon Kłos
Change-Id: If1dd46643dc2ae9cc74ba94038609ae3445a416c Reviewed-on: https://gerrit.libreoffice.org/39706 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com> (cherry picked from commit 505ce3a2ba3adeef46daecbf9b14c42cea211408) Reviewed-on: https://gerrit.libreoffice.org/39715 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-07-07tdf#108995: take xml:space attribute into accountMike Kaganski
See paragraph 2.10 of XML 1.0 specification and 17.3.3.31 of ECMA-376-1:2016 Change-Id: I7f19d3b9cf2ccce88a5fa03022beeb99facc04fe Reviewed-on: https://gerrit.libreoffice.org/39682 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 7c1a51516aaf2767e43b393259a1ad21570df5fb) Reviewed-on: https://gerrit.libreoffice.org/39688 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-07-07tdf#108714: Also support paragraph-level (line) breaksMike Kaganski
Change-Id: Ida55015363cac3ae29b82a60a9b9a5f1b39086a2 Reviewed-on: https://gerrit.libreoffice.org/39675 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit f95f0ce163743706a3670c6e33593023c22af2ff) Reviewed-on: https://gerrit.libreoffice.org/39677 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-06-28tdf#108714 follow-up: handle deferred break in character groupMike Kaganski
If an out-of-order break happens immediately after a table, then in following paragraph group (before character group start) the table level is > 0, and break is ignored. Since out-of-order break only happens at top level, the following character group necessarily designates a new paragraph group, so it's OK to handle that at the character group level, where table level is already updated. Change-Id: Ic1b1bb89e12407b050c2e880ad971794311845a5 Reviewed-on: https://gerrit.libreoffice.org/39347 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 553204015f954d20db65e6adcda68b823a8ef235) Reviewed-on: https://gerrit.libreoffice.org/39352 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2017-06-27tdf#108806: convert CRLF into space in OOXML textMike Kaganski
Change-Id: I8e2e108a705ecdb55c096a589d83d51c48b0b83c Reviewed-on: https://gerrit.libreoffice.org/39286 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/39322 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-06-27tdf#108714: allow <w:br> as direct child of <w:body>Mike Kaganski
LibreOffice doesn't accept <w:br> element as a child of <w:body>. ECMA-376-1:2016 17.3.3.1 describes br as element of a run content, and points to CT_Br in §A.1. CT_Br may appear only as part of EG_RunInnerContent. In turn, EG_RunInnerContent may appear only inside CT_R. So, using <w:br> outside of <w:r> produces ill-formed OOXML. Open XML SDK 2.5 Productivity Tool for Microsoft Office confirms that, showing OpenXmlUnknownElement error. However, Word accepts it as direct child of <w:body>. It behaves as if the <w:br> were used as first element in first run of the following <w:p> (thus creating page break after next paragraph). Another Word bug that provokes third-parties to create ill-formed documents, and requires LibreOffice to be bug-to-bug compatible. This commit makes the following changes: 1. Registers a dedicated complex type CT_Br_OutOfOrder to handle those unusual breaks, with corresponding handler function. 2. In the handler function, saves the gathered property set to parser state to use later in next paragraph group handler. This reproduces Word behaviour. Change-Id: I5df6927e2de9266b58f87807319ad1c4977e45a7 Reviewed-on: https://gerrit.libreoffice.org/39168 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit a4a1467bc47b81ad68ecad0d5e2e163670582919) Reviewed-on: https://gerrit.libreoffice.org/39303 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-06-23Related: tdf#108269 DOCM filter: preserve VBA streamMiklos Vajna
This is a combination of 3 commits (initial support, then two refactor commits to not duplicate code.) 1st commit: This means 2 new streams when roundtripping DOCM files that actually have macros: word/vbaProject.bin and word/vbaData.xml (+ the relation pointing to the second from the first). Reviewed-on: https://gerrit.libreoffice.org/38360 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 8a59b30bb1af55f7afd8b98e4b60234f98d84c76) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport9.cxx Change-Id: Iba24eea4c5bca8f743a53027c71ed2aae48f1934 2nd commit: Related: tdf#108269 DOCM filter: reuse oox code for VBA preservation With this, the project stream import is shared between DOCM and XLSM. Change-Id: I8fbffefc5acf28adea4875fa6bc4148a99b5ebef Reviewed-on: https://gerrit.libreoffice.org/38495 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit e4adb8d9e77bab353dda26375e11a6b7a456368f) 3rd commit: Related: tdf#108269 DOCM filter: reuse oox code for VBA data preservation Which means the DOCM-specific code to roundtrip VBA things (project, data) can be removed. The oox part has to be extended a bit, as at least for this DOCM bugdoc there is an XML relation of the binary data, while existing shared code assumed the full VBA project is just a single OLE blob. Reviewed-on: https://gerrit.libreoffice.org/38504 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit 0129c2cd9dd95355412b194c595f4b986403ba1e) Conflicts: writerfilter/inc/ooxml/OOXMLDocument.hxx writerfilter/source/ooxml/OOXMLDocumentImpl.hxx Change-Id: I4085e4dba24475e6fd555e5f34fe7ad0f305c57d Reviewed-on: https://gerrit.libreoffice.org/38558 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2017-06-23tdf#108682 DOCX import: fix <w:spacing w:line=...> for negative valuesMiklos Vajna
I didn't find UI in Word to create <w:spacing w:line="-260" w:lineRule="auto"/> the equivalent markup when you set line spacing to exactly 13pt for new documents is: <w:spacing w:line="260" w:lineRule="exact"/> The OOXML spec and Microsoft's implementer notes ([MS-OI29500]) is also pretty silent about what a negative value means. However, if this markup is converted to WW8 by Word, then the WW8 LPSD structure is like this (as presented by doc-dumper): <lspd type="LSPD" offset="5086"> <dyaLine value="0xfefc"/> <fMultLinespace value="0x1"/> </lspd> For the 0xfefc value the [MS-DOC] spec clearly states that means the type of the spacing is "exactly", with the value of 0x10000-0xfefc, i.e. the same 260 twips. Change-Id: I84b485d02dea49c610b6df2e06ccce03e1d29d21 Reviewed-on: https://gerrit.libreoffice.org/39091 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit f575f70b8303ba187f6989920281ff02e7a431c9) Reviewed-on: https://gerrit.libreoffice.org/39162 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2017-06-22Watermark: auto size in the RTFSzymon Kłos
When Watermark size is set to Auto in the MSO, the saved value is equal 1pt. Before this patch in this case Watermark was invisible due to small size. Change-Id: Ia2028a6547cf98dd31031305bcc5375625b83fe0 Reviewed-on: https://gerrit.libreoffice.org/38883 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-06-15Watermark: RTF font import and exportSzymon Kłos
* font size * font family * rotation * TextPath geometry - working transparency & color * revert TextBox export removed by mistake Change-Id: I3f6df86809ae57dc40c275652a96b19d2a3d7eba Reviewed-on: https://gerrit.libreoffice.org/38494 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> (cherry picked from commit dd0df1c8a213ab6f0959145396bc273bf885af39) Signed-off-by: Andras Timar <andras.timar@collabora.com>
generated by cgit (git 2.34.1) at 2024-07-16 00:41:52 +0000