summaryrefslogtreecommitdiff
path: root/sw/source/filter
AgeCommit message (Collapse)AuthorFilesLines
2020-05-07tdf#98409 doc export: export (non-default) cell marginsJustin Luth1-2/+62
Previously, the only cell margins that were being exported were the row defaults from the last column. These cell margins are tricky, because multiple cells and multiple sides can be combined together into a single definition. A previous commit for tdf#73056 was needed to import these sequences. Change-Id: I513c432ec11a78c7bb52ac6fb628851192e88023 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92701 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-05-07tdf#132637 doc import: don't open readonly for lockRevJustin Luth1-2/+5
Just like with forms, the password should not be required to make changes when only enforcement of track changes is specified. So just grabbag the password and let the document open in read-write mode. TODO for the overly zealous: actually enforce file->properties->security->protect track changes, and also export it. (This has been done for DOCX.) Change-Id: Ib68ec5785aa0f5dbac507a3d50059a443f7ff42b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93551 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-04-30sw reqif-xhtml export, embedded objects: handle Ole10Native streamMiklos Vajna1-2/+94
Normally the embedded object has some OLE2 native data, and we insert our OLE1 header before that. But in case the OLE2 data already has an Ole10Native stream, then don't create an OLE1-in-OLE2-in-OLE1 output: it's pointless and some consumers have trouble parsing that. Change-Id: Ifc8b37494f97da89ce66a147e08a49eaa2f7ae1e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93200 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-04-30loplugin:makeshared in swNoel Grandin10-19/+16
Change-Id: I58d91e75ef96beaab7ec34df519ae3a376dce976 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93201 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-30Update name pReffedStck to xReffedStckAndrea Gelmini1-1/+1
In commit 2a72602824bf8aec44319e7fb9fe6dd3cebc72b3 it was updated Change-Id: I2dbc799f379805b94055e229606d032dc802d6fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90875 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-04-30Revert "Convert TokenContext to fastparser APIs"Noel Grandin1-1/+1
This reverts commit b7bfe6ae08f5b214f2d03d70a40b66c894c0b659. Reason for revert: I missed some call-sites which means this is not going to work properly, which also means we don't have any tests for this functionality :-( Change-Id: Ie340a5e2331609258e79176c3dd12249ad46ba7b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93134 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-29sw from-bottom relative orientation: add DOCX filterMiklos Vajna1-0/+3
The OOXML equivalent is <wp:positionV relativeFrom="bottomMargin">, and the position is typically a negative number (i.e. the position is the offset between the top of the shape and the top of the top or bottom margin; not the distance and it's always the top of some margin). Change-Id: Ia979bc8bfaa37d29b0947c4408335e0a80c05880 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93172 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-04-29Convert TokenContext to fastparser APIsNoel Grandin1-1/+1
Change-Id: Ib40e2f3d37c52b03f2ecbd67aaeed9605e644fea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93163 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-29tdf#73056 doc import: table margins - unknown byte is EndCellJustin Luth1-15/+19
The problem was that the cell margin that overrides the table defaults was only being applied to one cell, while a range of cells might be defined. a sprmTCellPadding is specified by a CSSA. The CSSA starts with an ItcFirstLim, which consists of a start and end cell. The end cell is NOT included. Change-Id: Ia90bc28451d39d60ce343d24b02fd3661b05d950 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92628 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-04-29cleanup my old asserts looking for problematic docsJustin Luth1-6/+0
No docs found after a year or so. Change-Id: I303ecc6fa24216c8f1c7ff9fa2bb70c1a84f2292 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93004 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-04-28tdf#131539 DOCX export: fix position of OLE objectsAttila Bakos1-0/+42
Keeping position of OLE objects anchored to text as a character. Co-developer: Tibor Nagy (NISZ) Change-Id: I9699250ae5c418f9994ea2a7a3b102681b042214 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91983 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-04-27tdf#116883: sw: support for lists level format stringVasily Melenchuk1-1/+7
Multilevel lists are more flexible in case of DOCX. There is supported custom format for any level in DOCX unlike in LO and ODT where we are limited only with prefix and suffix for hardcoded list levels separated by dot. At the same time DOCX can have lists not only "1.2.3.4", but "1/2/3/4" or even "1!2>3)4" and such format can vary on each list level. Here is basic implementation for list format as a core feature for all documents and old way (prefix-suffix + ".") is left as fallback. Practically its usage is currently implemented only in DOCX import/export. Some RTF/OOXML unittests were redesigned: since we are not creating prefix/suffix for these formats conditions should be checked in a different way. Change-Id: I1ec58bcc5874d4fa19aee6a1f42bf1671d853b14 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92106 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-04-27tdf#108496: DOCX: list overrides some cleanupsVasily Melenchuk1-5/+7
This is a follow up commit to cf13fe3e fix with some mostly cosmetic changes. General idea of list overrides is not modified. Change-Id: I35937449bd563eacceb3753e62b9ff7245f12b89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92739 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-04-27tdf#115896 doc import: recognize new version 2013Justin Luth1-0/+1
Now, I don't know for sure that E000 is from Office 2013, since I don't know where the document came from and I don't have 2013 readily available. However, I tried round-tripping the unit test in Office 2016 and it gave the version number 0x2000. Change-Id: Ib02f9440de34225affcb2ccbfd96ed89c717085e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92764 Tested-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-04-27Make upcasting css::uno::Reference ctor require complete typesStephan Bergmann12-1/+12
The main reason for the "home-grown" UpCast introduced with 904b3d1fceee5827076758ed2a81f80cb73493ca "Up-cast conversion constructor for css::uno::Reference" in 2013 was probably that we could not yet rely on C++11 std::is_base_of back then. A (welcome) side effect was that the derived class could be incomplete. However, specializations of UpCast relying on whether or not T2 is incomplete are obviously an ODR violation if the type is incomplete in some TUs and complete (and derived from T1) in others. And even if UpCast had internal linkage, it would still be brittle that its behavior depends on the completeness of T2 at the point of the template's instantiation, and not necessarily at the point of use. That means we should better base that ctor on std::is_base_of (which we can do now since 39a1edd6fec902ef378acce8af42c4d7fba280d0 "Make css::uno::Reference upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on Clang and GCC if the completeness requirements are not met. This change fixes all the cases where types need to be complete now, plus any resulting loplugin:referencecasting warnings ("the source reference is already a subtype of the destination reference"). Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-24NFC ww8export: fix outright lies and false insinuationsJustin Luth2-13/+19
and other general cleanup related to tdf#98409 - see proof example there. The outright lie is that cell border defaults come from the first row and the first column. Instead, margins actually are defined for each row, and come from the last column. And there are no defaults for the border lines themselves. The insinuation is that these are table level settings that only should occur once, but most of them are per-row settings and all of them happen repeatedly. The three functions that appear to repeat table level definitions probably should run only once, but that is likely tricky to do with table-in-table situations, so no intention to do that here in a NoFunctionalChange patch. Change-Id: I9fa60902389668256b147df6bf9a2e972cf9174a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92700 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-04-24loplugin:unusedmethodsNoel Grandin2-30/+0
Change-Id: Ieec5099a8ce9fa3f07e36be244071efc1b101cf7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92803 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-23sw html export: fix handling of paragraph alignment in XHTML modeMiklos Vajna2-0/+11
The problem was that the <p align="..."> markup was used, while XHTML prefers the <p style="text-align: ..."> markup. Note that OutHTML_SvxAdjust() is a special case: other paragraph-level pool items would just call the equivalent of OutCSS1_SvxAdjust(). Fix the problem by bringing the paragraph alignment case close to e.g. SvxULSpace handling, which is the m_bNoAlign == true case. On top of this the reqif-xhtml output is then valid out of the box, since IgnorePropertyForReqIF() already filters out not allowed CSS properties. Change-Id: I5fb4314bec172affcd03b1c49b986406a93c2b12 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92797 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-04-23pass SvxBrushItem around by unique_ptrNoel Grandin9-11/+11
we never create an object that is actually shared, so this is wasted Note1: in IMPL_LINK_NOARG(SwEditRegionDlg, OkHdl, weld::Button&, void) there was a comparison if( aBrush != pRepr->GetBackground() || ... which I removed Note2: In bool SwDoc::GetBoxAttr( const SwCursor& rCursor, std::shared_ptr<SfxPoolItem>& rToFill ) which had a condition else if( rToFill != xBack ) I changed to compare contents Change-Id: Idd769f44917c5ccc7e9f4bfbaddf12f9cd4151cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92791 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-23Fix typosAndrea Gelmini1-1/+1
Change-Id: I6c9fe715c0d188d3970027fcb63c6c039c957fd9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92733 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-04-23tdf#99197 ww8import: all root-level para-styles default to LTRJustin Luth3-12/+13
It is not just the "Normal" paragraph style that should default to LTR. Any new style that does not inherit from anything should be set to LTR, regardless of page/section settings. Change-Id: Ibe1241b813b82afa9b218eae50d6c78042131893 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92468 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-04-22tdf#108496: DOCX: redesign of override in listsVasily Melenchuk6-38/+81
List level overrides are not just about numbering, it is about numbering restart. Thus some changes to DOCX import/export were added. Improved support for several lists referring the same abstract list, especially in situation when one list have overrides. In addition some export cleanup is made: less unnecessary list duplications, less level overrides when no properties were changed. Change-Id: Ic7a69bc2e3080b39f5205cb90b46d14247abf305 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92412 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-04-22tdf#42949 Simplify use of rtl::math::approxEqual in include/basegfx/Gabor Kelemen2-0/+2
Turns out we can save about 500Mb of preprocessor input if we use rtl_math_approxEqual from rtl/math.h instead of its C++ wrapper rtl::math::approxEqual from rtl/math.hxx and manage the fallout accordingly. Before: bin/includebloat.awk | head sum total bytes included (excluding system headers): 19017296671 After: $ bin/includebloat.awk | head sum total bytes included (excluding system headers): 18535432672 Change-Id: I1691171f3a309405a7099882ad9989d147f59118 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92508 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-04-20Translate German variable namesJohnny_M2-3/+3
Ende -> End Change-Id: I5aca2fa92ccf9fe38fb8e03cb8c44b8bdb3d76e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92028 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-04-20Translate German variable namesJohnny_M2-3/+3
Ende -> End Change-Id: I205600e263d2291faa97d967c9a8c7fc0baadb1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92029 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-04-17tdf#79553 ww8import: line numbering distance is auto, not zeroJustin Luth1-1/+3
sprmSDxaLnn: An XAS_nonNeg that specifies the distance between line numbers and the lines of text to which they apply. A value of 0 indicates that the application MUST automatically determine positioning. By default, the positioning of line numbers is automatically determined. Change-Id: I35a440a7fa84f315f4a67e201e1a0066d4e4cf73 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92126 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-04-17Move Word compat option where it belongsSamuel Mehrbrodt1-0/+2
Change-Id: I6b28c6782f22190b7b22b11361c200d68d672aea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92347 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-04-16tdf#132094 doc: fix export of fill in wrap-through fly framesJustin Luth1-4/+7
This builds on commit 2f13dbac060ae6af7e25ad3eff675cc859cfb3ff by Miklos Vajna on Fri Jun 15 08:49:46 2012 +0100 n#325936 fix ww8 export of fly frames with transparent bg where he wisely and cautiously says Regression from commit ed8b5f2d -- to be safe, reverted only for fly frames in headers. because for some unknown reason, way back in 2002, commit ed8b5f2debac216243930aba0873e0d75de8d0dd forced all frames to specify a background fill. Typically of course this is white, and so who notices? Well, you notice if your frame is transparent, and now the area fill hides something that it is over top of. Like for example a transparent image, where the text wraps through the image. At first I was going to just try and revert everything. Then I decided it likely was a difference between how LO and MSO handled stacking/overlapping things. After that, I was going to just make an exception for eShapeType == mso_sptPictureFrame, but that only seems necessary if there is something underneath. If the something is just a background, that is handled anyway, so really it would only be other shapes or (most importantly) text, so the safest thing is testing wrap through, which there was already a pre-defined variable to reuse (and fix the spelling). Change-Id: I9236579fa692e22205bab5a21c3f9d919f4cf24f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92215 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-04-15Fix typoAndrea Gelmini1-1/+1
Change-Id: I78fad18e12254cd3c3bb3f49b5898e09bb7b6c6f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92318 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-04-15add an IsEmpty method to tools::Size and use itNoel Grandin2-6/+4
Change-Id: I7f5201e2ea6c74329336e16bf219630e38ff92cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92264 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-15sw: DOCX export: export AddExternalLeading as w:noLeadingMichael Stahl2-9/+34
For 11pt Arial, can fit 59 paragraphs on a page vs. 57... This is annoyingly complicated by the fact that Word 2013 ignores w:noLeading element if compatibilityMode is 15. Change-Id: Ie3093eabba45cdf6e7903ed860f5bad24dcc0323 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92208 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-04-11Fix typoAndrea Gelmini1-1/+1
Change-Id: I4ae66d3c69850fefedebcc4beeaa924de9859570 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91757 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-04-08tdf#104565 DOCX drawing object export: fix arrow positionsSzabolcs1-2/+6
Saving some arrows from ODT to DOCX scattered them around their correct position. This happened because of a function that recalculates the position of drawing objects when they are rotated, according to the rotation. It turns out we don't have to do this with lines and such. Co-Author: Balázs Regényi Change-Id: Iea6a34d15003cacc27a8030cb73511aba39225f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90989 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-04-07tdf#119038 DOCX: fix FollowTextFlow handlingAttila Bakos1-9/+3
This fix also a clean-up for the following commits: ad8857dab30e099a0cf6ec18d184a6c836b33317 (tdf#130120 DOCX: export o:allowincell) 14ad64270e4fbca3c24da6f55f260b1fb229556a (tdf#129888 DOCX shape import: handle o:allowincell) 10f29d8bf05d44ca8bc11d34d1294ec17f8ac0f1 (tdf#87569 tdf#109411 DOCX import: fix shape anchor in tables) where these patches ignored the option "Follow text flow" and there was no possibility to switch this setting on GUI. Now this is handled on GUI as well by replacing the grab-bag with UNO property "IsFollowingTextFlow". The tdf#119038 bug also fixed. Note: Unit tests for the commits mentioned above were modified for testing the new property, so new tests were not added. Change-Id: Ie35c6e280f8b33d8535ca4cd9749f110f9d592ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90753 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-04-07tdf#119760 docx: table starts at left, not mid-borderJustin Luth1-3/+5
related to compatibilityMode = 15; the new export default. In Word 2013+, it appears that the table starts immediately, and then the border is added. In Writer, the table is considered to start mid-border. So that difference needs to be emulated by adjusting the table margin. The same appears to be true for nested tables. Negative margins appear to just be ignored for nested tables, and Word's UI does not accept a negative value. I modified the existing table-position-15.docx slightly (in Word 2016), just to remove spacing between the caption and the table so that it would be easy to visually compare the table position. One slight difference is that WORD seems to add a small "margin" to the the paragraph shading area - don't let that throw you off. The existing unit test enforced settings that didn't match how Word 2013 was showing the files, despite being written to test exactly that. I assume the author was focusing more on OLDER versions of Word and didn't care too much about the NEW version. A man after my own heart. MISC: -I removed my earlier TODO which was just plain wrong. -the ambiguous make::any caused me untold problems, so I made it unambiguous by moving it into a variable. Change-Id: I0685ab74777f1def2841c7d18ff1cdaf2753f47b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91608 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-04-06loplugin:unusedvariableplus in swNoel Grandin7-10/+0
Change-Id: I0ec780ebe3b347a19a5aa809fe05723a2906cb49 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91738 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-03Turn defines into constexprsMike Kaganski2-2/+2
This allows to see actual values of the WhichIds in IDE easier Change-Id: I31106459cd262000444175d082eb349ff937488d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91513 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-04-02NFC ww8/writerfilter: comment fixes and general code cleanupJustin Luth1-6/+4
1.) Confusing to set a default in the CTOR head, and then change it in the body. 2.) fix spelling 3.) clarify somewhat misleading comments. Change-Id: Icb19a8838f1f01310b2dacc8cef7d9f0c67f3e75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91275 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-04-02cid#1418980 Resource leakCaolán McNamara1-4/+4
Change-Id: I3a09b3165503bacbd2bab394eda9adc793f0bff9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91546 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-04-01tdf#120852 writerfilter: support read-only docProtectionJustin Luth1-8/+23
Setting the document to LoadReadonly nicely does not prompt the user to "press this button to edit". That is what we would generally want when Read-Only is enforced, so lets use that. The user can easily enter edit mode via the edit menu, if they want to temporarily override the protection, which seems natural and discoverable enough. There is a File menu - Properties - Security option that manages the LoadReadonly setting in LO. If the user turns that off, then export will also cancel enforcement of the readOnly grabbag item. The situation where read-only was not enforced before, but now is enforced by LO, is handled by _MarkAsFinal, so that case is ignored. In other words, there was no point in adding a WriterWantsToProtectReadOnly flag. See tdf#107690 for _MarkAsFinal fix. I had started going down the wrong patch of being innovative with boolean &=, not realizing that it now always evaluated the right side. Remove that bad example for other cut-and-pasters. In the end, this logic is much easier to understand anyway. Change-Id: Id26b283078a5fd62d662a26a96cfc461e0ba8459 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90323 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-31Introduce comphelper::ValueRestorationGuard extending FlagRestorationGuardMike Kaganski1-12/+3
... to any value type. Change-Id: I808f4729478cb3f90a86ef30be8158ebc40a6b96 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91428 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-03-31sw: remove m_setFootnote - obsoleted by checking m_nTextTypeMichael Stahl2-6/+2
Change-Id: I44e7864fc159edbef35083b09798b1e3254f6548 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91430 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-03-31sw: DOCX export: avoid section breaks in text frames harderMichael Stahl1-1/+1
Follow-up to 0dd48d1a9a716456ff1ebe67e19881ad2f56939b - in another document, the sectPr is written from DocxAttributeOutput::StartParagraphProperties(), which lacks a check that it's in the body text. Change-Id: Ia3b56f40a7457f072735a0e09205089a0c5f4584 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91429 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-03-31sw: DOCX export: avoid section breaks in text framesMichael Stahl1-0/+12
The problem is that if Word reads a w:sectPr that is inside a w:textbox and has a w:headerReference, then Word throws a confusing error reporting a location inside the headerN.xml file and refuses to open the file. It looks like Word doesn't actually support sections inside text frames, although it doesn't complain if the section break doesn't contain a header/footer reference. The WW8 export appears to avoid this by checking that TXT_MAINTEXT == m_nTextTyp and skipping sections otherwise, but the m_nTextTyp doesn't change when exporting a text frame in DOCX case, so let's change that. Possibly this makes m_bFlyFrameGraphic variable redundant, not sure about that. Change-Id: If862b226254983bb608bbce180f4aa2f41721273 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91421 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-03-31Translate German variable namesJohnny_M1-8/+8
Ende -> End Change-Id: Ib0891bc3f03d7590e94fe0c04b48f0560bdf74d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91210 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-03-31related tdf#106843 docxexport: if not enforced, let Writer protectJustin Luth1-4/+19
The problem was that sections, etc., could not be protected if the document previously had some kind of protection that was now disabled/not enforced. Docx has a special flag that actually enables the selected protection (forms/track changes/readonly). Even if it isn't enabled, grabbagging keeps the "suggestion" for next time when the user wants to enable protection. "If the value of this element is off, 0, or false, all the WordprocessingML pertaining to document protection is still preserved in the document, but is not enforced." If the user requested some kind of protection in Writer, it should be able to override a grabbag "suggestion" and set a real protection value. Change-Id: I638c6420bfb9a1801187f3e16586d2e18dfacb84 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90322 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-30tdf#80635 ww8import:3 take float table orient to inlined tableJustin Luth1-3/+14
Since SW has problems with floating tables, any unnecessarily floated tables are converted to inline. However, the positioning of the tables is mostly lost. So the choice is either to refuse to inline a strangely positioned table or else to transfer the positioning onto the inlined table. For absolutely positioned flies, which are LEFT_AND_WIDTH, pass the X position to the left margin. Change-Id: I996a06c753e8b9b1151f7deea8ad4caf5724dd0d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91273 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-28tdf#80635 ww8import:2 take float table RIGHT to inlined tableJustin Luth1-1/+7
Since SW has problems with floating tables, any unnecessarily floated tables are converted to inline. However, the positioning of the tables is mostly lost. So the choice is either to refuse to inline a strangely positioned table or else to transfer the positioning onto the inlined table. Transferring is easier said than done. But for right-aligned tables, hopefully it is easy to copy that without causing trouble. I didn't find any real-world examples in existing unit tests or bug reports, so I made up my own complicated one using both right margin and BIDI. Change-Id: I855ae62531b5930cbc9a3272c3a7228dd7b0df53 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91272 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-03-28tdf#80635 ww8import:1 take float table CENTER to inlined tableJustin Luth1-0/+9
Since SW has problems with floating tables, any unnecessarily floated tables are converted to inline. However, the positioning of the tables is mostly lost. So the choice is either to refuse to inline a strangely positioned table or else to transfer the positioning onto the inlined table. Transferring is easier said than done. But for centered tables, it is easy to copy that. Change-Id: I8a6deaa63c45277c30ffa12613c8ed125a45d607 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91188 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-03-27sw: DOCX export: ignore linked image with invalid URLMichael Stahl1-0/+10
Word 2013 refuses to open DOCX files with image urls that contain %5C (encoded '\') in path or query (fragment is not a problem). Just don't export such images, they won't work anyway. Change-Id: Iae918791beb8532e76b4f29d49eba6fe0eda8aa8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91204 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-19 06:38:55 +0000