summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)Author
2020-04-03fix wrong variable checked in AddTblStylePrNoel Grandin
regression from commit 4c3ba3a413be7339115ea5e6edc825a8434cd345 Date: Sat Jul 26 17:17:27 2014 +0100 fdo#75757: Remove inheritance from std::map. found by my new unusedvariableplus loplugin Change-Id: Ica9a3ade207698ac7af76e010fbb9e6bdd0dc227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91631 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-02NFC ww8/writerfilter: comment fixes and general code cleanupJustin Luth
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-02tdf#131594: switch line numbering off if w:countBy="0"Xisco Fauli
See https://bugs.documentfoundation.org/show_bug.cgi?id=131594#c0 for more info Change-Id: Ic57826eb5a440e83cea1d9bde5e9144727e3b6df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91141 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-04-01tdf#120852 writerfilter: support read-only docProtectionJustin Luth
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-04-01Remove unused includeMiklos Vajna
Change-Id: Ifa3b50b6b31b4a8e8babf7695339848f6730bf11 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91458 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-31RTF import: reset writerfilter bit even if the import failsMiklos Vajna
The old code did not handle when e.g. a lang::WrappedTargetRuntimeException is thrown between the set and unset. The DOCX import had the same problem. Change-Id: I7336d08057a875db985e8b647b320abd97c6eb81 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91381 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-25tdf#106843 docxexport: don't write double docProtectJustin Luth
regression from LO 6.4 commit 2756ed9317e3474003c11ffe7d1e2f087c1412bf Change-Id: Iaf32974c7282d11bcd9572ed75cf1233ad3f0008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90321 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-24ofz#21168 sw,writerfilter: limit writerfilter hack to writerfilterCaolán McNamara
The problem is that at the end of WW8 import, a delete redline is inserted that ends up calling DeleteAndJoin from inside AppendRedline(). A fly is anchored AT_CHAR at (node 46, offset 0) and the deletion goes from (node 46, offset 0) to (node 48, offset 13) hence the special case check in IsDestroyFrameAnchoredAtChar() for the IsInReading() prevents it from being deleted, and then its anchor is still registered at the node 46 when it gets deleted. So try to restrict the WriterfilterHack to writerfilter, so it won't affect WW8 import. Unfortunately this is far less obvious than expected, because import can happen for creating a new file, in which case it's all done via UNO in writerfilter, or when inserting into an existing file, in which case SwReader::Read() is used. The SwDocShell's pMedium can't be used becuse in insert file case it will be the loaded file, not the inserted file. There isn't any obvious alternative to adding a silly UNO property for the writerfilter to use. Change-Id: Ia7fdc9bb1925202f6692ebee6e4b6b1fe50e5345 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90384 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-03-23sw: add pad-to-5 numberingMiklos Vajna
This is the last padded numbering type that is supported by Word but was not supported by Writer. Change-Id: Ica1a0843897c61a4b569105fd21e5bfe7b5012cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90912 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-03-23writerfilter: GCC 9.2.1 -Og -Werror=maybe-uninitializedMichael Stahl
This one isn't GCC's fault, not obvious that the any must contain a bool. Change-Id: Iad94dc5bd1a010be1c22e527e0d14c027f0dcf60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90910 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-03-20sw pad-to-4 numbering: add DOCX filterMiklos Vajna
Now that style::NumberingType::ARABIC_ZERO3 is already handled, this is much easier. Change-Id: Ibe76d90253a5bfad84560395502590a380d559d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90828 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-20tdf#118812 writerfilter: overrideTableStyleFontSizeAndJustificationJustin Luth
Surprisingly, there are NO uses of these compatibility options. Apparently we have a lot of work to do... MS Word finally throws away a goofy exception clause that must have caused them countless grief. And LO finally adds support for that goofy clause now that it should rarely be needed... I modified my previous unit test slightly to increase the difficulty level. A fontsize was changed to 11, and justify was added. Change-Id: I0c4997324e8ee745bac8316a45e837c5de137509 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90625 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-19sw pad-to-3 numbering: add DOCX filterMiklos Vajna
There is no NS_ooxml::LN_Value_ST_NumberFormat_foo code for this on the import side, rather the number format code is set to NS_ooxml::LN_Value_ST_NumberFormat_custom, then a separate NS_ooxml::LN_CT_NumFmt_format contains the number format string. Declare w14 as an XML namespace on the export side, even if we write no <w14:something> elements. This is needed by <mc:Choice Requires="w14">, which refers to an XML namespace in the OOXML markup. (Interestingly officeotron doesn't check for this, though.) Change-Id: If5fbcea4f163bd4d1a1ed820e15ceb61dc9c0519 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90761 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-03-19writerfilter: DocProtect_enforcement defaults to falseJustin Luth
If enforcement is not specified, then it defaults to off. "If this attribute is omitted, then document protection settings shall not be enforced by applications." Since we cannot guarantee that NS_ooxml::LN_CT_DocProtect_enforcement will be called, handle checking the various protection statuses after the import has finished. The unit test previously had an explicit enforcement="0". Removing that was the only change I made. This patch was inspired by a code-review of LO 6.4's tdf#106843 and preparation for tdf#120852. Change-Id: I702f5173fd796eb8bda1ea610411f8297d8889b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90302 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-19tdf#105215 DOCX import: fix paragraph-length direct formattingLászló Németh
in table cells. Paragraph-level direct character formatting (w:p/w:pPr/w:rPr) overwrote portion formatting (w:r/w:rPr), if the same formatting was applied on all portions of the paragraph. Note: with this fix, portion level direct character formatting overwrites the paragraph-level direct formatting also in the table row inserted below the actual row, like MSO does. Regression from commit 2ab481b038b62b1ff576ac4d49d03c1798cd7f84 (tdf#90069 DOCX: fix character style of new table rows) See also commit 0045b6f36e5e1445d699f87a0f6597d665b4cfe4 (tdf#130690: DOCX import: fix lost text formatting in cells) Change-Id: Ice47b93e73aed28b09334eda2f26283c68bd0bd4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90700 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-03-18tdf#131304 .docx: flag new files as MS Word 2019 native modeJustin Luth
compatibilityMode = 15: [Word 2013/2016/2019] Up till now, documents that were exported into the docx format were treated by default as native Word 2007 format, since no compatibilityMode setting was provided. (Don't worry, we still round-trip existing older values. This patch only affects non-docx >>= .docx export.) Ultimately, this change is for the benefit of MS Word. It has no practical effect for LO. NOTE: This patch depends on previous commit 53f099c842d39266a0b4786a1af3db5628746634 which sets an appropriate value for existing .docx files. This scary change shouldn't actually be all that scary, since we already round-trip native 2019 files, without any complaint from Word or our users. The biggest change is that Word 2010 users might not be able to open NEW files perfectly. But Microsoft has already been doing that to them since 2013. By the time LO 7.0 hits stable version, it will have been months since 2010 has reached end-of-life. The vast majority of documents will still open perfectly for them. Plus, if a Word 2010 user does modify our new document, we will drop back down to their level. A nice, clear explanation of what compatibilityMode does is at howtogeek.com/256269/what-is-compatibility-mode-in-microsoft-office/ The MAIN CHANGE is that MS WORD has been DE-ACTIVATING features when it notices that it is SHARING the document with OLD_VERSION users. So Word is limiting what it will do for the BENEFIT OF THE OTHER USER while collaborating. There are a few instances where layout is affected by compatiblityMode. For example, tdf#123116 wants compat=15 so that Word will nicely layout an oversized table-row. tdf#131121 wants it too. By changing to compat=15, we can help Word take advantage of some fixes since docx 1.0, and avoid having to write new logic to export to old formats as well as new. Unfortunately, documentation on what layout changes are expected has not been identified yet. But in 7 years we should have run into most of them already... well maybe no. Change-Id: I1ce016618a680b9842fa6828c9e87cc6b677a557 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90455 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-17tdf#131071 writerfilter: tableStyle uses DocDefaultsJustin Luth
It is kinda surprising to me, but the tableStyle actually includes DocDefaults in its style properties. You would expect that to be irrelevant, because if even the default style specifies a setting, it overrides the table style. Therefore they would either both match DocDefaults, or the style would have specified a value (thus overriding tablestyle). But in the specific default case of overrideTableStyleSizeAndJustification == false, a left alignment or a fontsize of 11 or 12 are overridden by the table style. Perhaps this should ONLY import those two settings in DocDefaults, but obviously the concept is there, so it shouldn't hurt to import the whole thing as that likely is the correct response for other situations as well. Change-Id: Ie2494855fa37c9a21d27d0e15f4da1fa0a216be6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90558 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-03-17tdf#119800 DOCX import: fix vanished objectsLászló Németh
Not hidden objects, for example shapes and tables were converted to hidden text, when they were anchored to empty hidden paragraphs (see w:vanish character property in OOXML). Note: now DOCX round-trip doesn't change the document layout (previously DOCX export hid the vanished object), but Writer shows also an extra empty paragraph with the fixed object, so the layout is still not the same here. Follow-up of commit 2be656908e9f30d0b0f795cc67096f0d673a3a21 (tdf#128646 DOCX import: don't hide shape of hidden paragraph), extending the fix also for not table paragraphs. Change-Id: I2af4ad42dd9e67f0daf4392fcc6875855eb4ba7c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90617 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-03-17Fix buildMike Kaganski
Regression after 2be656908e9f30d0b0f795cc67096f0d673a3a21 that was tested on 73b6b3b4a22f047718d91a7057dba3a096171976 from Feb 19, which was older than 9ad252b2e79576119c2d733a1a45fdd9e9f83140 from Feb 21 that dropped o3tl::optional. Change-Id: I685139e43c6788ca826bcdf4c9baa16a3304c59f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90594 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-03-16tdf#128646 DOCX import: don't hide shape of hidden paragraphLászló Németh
if the shape is not hidden, but it's anchored to an empty table cell paragraph. Change-Id: I97e42431d083d3c70ff67981676e322ca8e7f89d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90568 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-03-16DOCX import: tokenize <w:numFmt w:val="custom" w:format="...">Miklos Vajna
Which means CT_NumFmt has to be a property resource, not a single value, and also ST_NumberFormat needs to recognize "custom" as a valid value. Adapt the RTF tokenizer to emit the new token format. This is needed (but not enough) to support markup like this: <w:numFmt w:val="custom" w:format="001, 002, 003, ..."/> Change-Id: I767e4b92fc41f9425f446d6eaad1d875e2233964 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90578 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-03-16writerfilter: extract dispatch...Value() from disptachValue()Miklos Vajna
This function was a 1582 lines monster. Extract clusters of RTF value keywords into their own function to makes this a bit more readable. Change-Id: Icf95ca11f5f909379acbfd576915485c7eb868ad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90569 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-03-16DOCX import: declare w14 as a supported featureMiklos Vajna
This is needed (but not enough) to support markup like this: <mc:AlternateContent> <mc:Choice Requires="w14"> <w:numFmt w:val="custom" w:format="001, 002, 003, ..."/> </mc:Choice> <mc:Fallback> <w:numFmt w:val="decimal"/> </mc:Fallback> </mc:AlternateContent> Change-Id: I598b0452b5d29624ed0a6795682c29a09fd0dcfe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90564 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-03-16tdf#131304 .docx: provide default compatibilityMode valueJustin Luth
When a docx is imported without specifying a compat mode, populate the appropriate compatibilityMode setting, which will be written out at save time. "12: Use word processing features specified in ECMA-376. This is the default." The immediate benefit for LO is that this will provide a cacheable result - instead of repeated lookup attempts for something that doesn't exist. Perhaps more importantly, it paves the way for allowing LO to export new documents as compatible with 2013, while leaving existing documents at their current level. Both Word and LO treat the missing compatSetting correctly as mode 12, so this should not have any affect on layout or any other compatibility aspect. Therefore I can't see any reason why it shouldn't be explicitly written. MS Word also writes it out on a round-trip. Writing it out doesn't limit us in any way either. As soon as it is in docx format, it will be treated as mode 12 anyway, so why not make it explicit? Well, I guess that since MS Word has been filling this in since 2010 at least, we could "assume" that if it is missing and has been modified in the past 5 years it was created by LO and thus treat it differently, contrary to standard. But that doesn't seem like a very good idea at all. Change-Id: If68cecc14bf4446c5ca25fd2dd6eebddf8d954a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90439 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-16Revert "loplugin:constfields in writerfilter"Noel Grandin
This reverts commit e7c6c05ae5a62e1705ffda97c5405eecd1f62a1e. Change-Id: I9072c4ef9c1a941ac3169e2b53dfd25ae7863770 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90545 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-15cid#1460667 rework to avoid Assign instead of compareCaolán McNamara
Change-Id: Icda6543d674b826ec344d3f1570b5463df9dcf29 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90535 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-03-15!pCellWidths->empty() check means pCellWidths->size() > 0 is always trueCaolán McNamara
Change-Id: I45ea2c5095c2082c5b1a885047f3cbbcd3d6e1c2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90534 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-03-13tdf#131304 writerfilter: cache Word compatibilityModeJustin Luth
GetWordCompatibilityMode() is an expensive call that is called at least for every table row. Caching will soon be even more beneficial when LO also starts writing out this value and thus quickly caches a non-negative result. Anything created by MS Word since at least 2010 specifies this optional setting, so most .docx files specify this value - and thus will benefit from the cache. One difference that I ignored is that Word replaces a "number greater than what I know" with its own compatibilityMode value. (tested in Word 2010 and 2016.) That is probably only a concern at export time anyway... Change-Id: I0ee71d34150c5f3d9858adb678814a10c7fe8959 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90434 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-12writerfilter: extract before/afterPopState() from popState()Miklos Vajna
This function was a 1365 lines monster. Ideally it would be a one-liner, just popping the parser stack. In reality the RTF format has lots of exceptions where the state leaks outside the current push/pop boundaries. Move this large list of special cases to separate functions. Change-Id: Ib6c729c5eccbcd361852f5bbc0539fd51315f86d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90349 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-12tdf#131258 DOCX: fix table styles in empty tablesLászló Németh
Pending paragraphs were disposed before table processing, so empty tables have left out of the rewritten table style preference handling, resulting for example different cell heights. Regression from commit 4d5c0eaf3e0d3d3bcd9e691fffee19b75f3d6631 (tdf#118812 DOCX import: fix table style preference – part 2). Change-Id: I5d5d29f37c8198484e24519ced5a50458c923064 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90347 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-03-11tdf#59274 DOCX import: fix tables with incomplete gridLászló Németh
Fix layout of "auto" width tables with incomplete grids, where table width is defined by cells of an arbitrary table row, not necessarily the first row, and last cells of the rows can be wider, than their saved values. Change-Id: I68bc8f1a4f57f3c64d0e83c585f2be129d9b5a84 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90261 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-03-06rhbz#1810732 crash/assert inserting document with initial graphicCaolán McNamara
Change-Id: Idae665c926856922a25a1228ed34f3cae96e4bdd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90085 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-03-06tdf#130928 Area fill update patternandreas kainz
Change-Id: I309cb3ccd5e870c6624b1a5b4838ee05c56538d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89843 Tested-by: Jenkins Reviewed-by: andreas_kainz <kainz.a@gmail.com>
2020-03-05Remove some unused includesMiklos Vajna
Change-Id: I808b7e3f6b580ee6f1876aa06038b5741d7ff6a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90001 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-04sw padded numbering: add DOCX filterMiklos Vajna
DOCX uses <w:numFmt w:val="decimalZero"/> for this. Change-Id: I12a4a88f472af42a04244d30f9e59fc0b8b4855c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89945 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-03-04comphelper: allow simple ad-hoc measuring with ProfileZonesMiklos Vajna
And then remove the manual measuring from the RTF import. Sample output: comphelper::ProfileZone: RtfFilter::filter finished in 180 ms Change-Id: I85e2e12d82ff491a2991a41e5a6f6d1410e12363 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89905 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-03tdf#130690: DOCX import: fix lost text formatting in cellsLászló Németh
by limiting paragraph-level character property expansion for the whole table paragraph based on all text portions. Follow-up of commit abb9c7db8bcc06f907d39a7811711882161d5803 (tdf#130494: DOCX import: limit paragraph-level character property) regression from 2ab481b038b62b1ff576ac4d49d03c1798cd7f84 (tdf#90069 DOCX: fix character style of new table rows) Change-Id: I4d14fd30c9fbc8464c2430726faf16e292f24e38 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89848 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-03-02tdf#131062 DOCX import: fix table-style paragraph background colorLászló Németh
by comparing fill attributes to ParaBackColor to avoid losing them. Regression from commit a9ba8e57a41c5ddf3597272bddab30e51fb3fd38 (Revert "tdf#118947 sw tablestyle: manually scan parents for ::SET"). See also commit 24077b2d52ab3d0fd0db5afb25d8b94b62386e3e (writerfilter: import paragraph color as fill attributes) Change-Id: Id42ea3adaddf883435dd61e5dea0e6c5fb89f927 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89215 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-02-29tdf#92472 DOCX import: fix checkbox size set by direct formattingLászló Németh
at beginning of paragraphs. Follow-up of the commit 22ad4d69d771708f28a2d9e137cfd43ac846cf3a (tdf#121045 DOCX import: fix checkbox size in table). Change-Id: I06f0dfa4376ff8f5730d8cfe1cbc3de022e8aaff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89726 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-02-25tdf#123757 DOCX import: separate different style tablesLászló Németh
to avoid of losing table layout, color etc. during their prohibited combination into one table: table style of the second table overwrote the table style of the first table, or without table style, the second table was overwritten by the table style of the first table. Change-Id: I0a2663d41f7d019e7b329198944a300260025b65 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89416 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-02-24workaround GCC 9.2.1 -Og -Werror=maybe-uninitializedMichael Stahl
vcl/unx/generic/gdi/salbmp.cxx:727:32: error: ‘pixmapHandle’ may be used uninitialized in this function [-Werror=maybe-uninitialized] vcl/unx/gtk3/gtk3gtkinst.cxx:7336:16: error: ‘eRet’ may be used uninitialized in this function [-Werror=maybe-uninitialized] etc. One looks like it might occur in practice. Change-Id: I09af7d36b134b31cb7bd8047b5c73f4a49c9d9b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89351 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-02-24tdf#121045 DOCX import: fix checkbox size in tableLászló Németh
in cell starting position. Change-Id: Ib99726c03ff3f83177a015721e562ebc5bc516d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89338 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-02-24ofz#20801 Null-derefCaolán McNamara
Change-Id: I2fd0c28499aff97622536754f1899b7b1f015989 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89326 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-02-22tdf#130817 RTF doesn't set custom footnote stateJan-Marek Glogowski
RTFDocumentImpl::dispatchDestination detects the custom footnote and even sets NS_ooxml::LN_CT_FtnEdnRef_customMarkFollows in the character attributes of the context, but that is at least not handled in the DomainMapper later on, so we can't check for m_pImpl->IsInCustomFootnote() here. Change-Id: I26c02ea16d0e75ed5bfde0cda9e0c6a2d30261a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89240 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-02-22tdf#130814 preserve context before page breaksJan-Marek Glogowski
... and add a comment, so nobody tries to move these again. Change-Id: I79e6f7a1538d0839fd525870439facef3218ec65 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89239 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-02-21tdf#130120 DOCX: export o:allowincellBakos Attila
Object anchors are set by allowincell/ LayoutInCell attributes in table cells. Export it by grab bag method temporarily, instead of using the suggested FollowTextFlow, related also to the missing GUI support. Follow-up of commit 14ad64270e4fbca3c24da6f55f260b1fb229556a (tdf#129888 DOCX shape import: handle o:allowincell) Change-Id: If883511b6114e8f60d673ecbd3a11095fcafddc5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88438 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-02-21Drop o3tl::optional wrapperStephan Bergmann
...now that macOS builds are guaranteed to have std::optional since 358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to Xcode 11.3 and macOS 10.14.4". The change is done mostly mechanically with > for i in $(git grep -Fl optional); do > sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \ > -e 's/\<o3tl::optional\>/std::optional/g' \ > -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i" > done > for i in $(git grep -Flw o3tl::nullopt); do > sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i" > done (though that causes some of the resulting #include <optional> to appear at different places relative to other includes than if they had been added manually), plus a few manual modifications: * adapt bin/find-unneeded-includes * adapt desktop/IwyuFilter_desktop.yaml * remove include/o3tl/optional.hxx * quote resulting "<"/">" as "&lt;"/"&gt;" in officecfg/registry/cppheader.xsl * and then solenv/clang-format/reformat-formatted-files Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-21tdf#130799 DOCX import: fix missing inside vertical bordersSzabolcs Toth
caused by incomplete handling of tables with 1-column rows with merged cells. Have to check the rows below current to see if they contain also one cell, therefore form a column, or more than one cell, in which case do not remove vertical borders. Regression from commit: 8a2eb40abbd52d960dd21308157186be0ca9dd3d (tdf#129442 DOCX import: fix right border of 1-column tables). Change-Id: If9ca7ccd42255e78c61b6271e19262ab5cc8e439 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89081 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-02-21writerfilter: make sure own header is the first oneMiklos Vajna
This way we get a build error in case TableManager.hxx is not self-contained. Change-Id: Ia82c30a554c8726db2486cb8fc0dc73013ad2a19 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89169 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-02-20tdf#42949 Fix IWYU warnings in writerfilter/Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I47ff7eecabc87081eb953c5970a3cbd56c86d728 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88897 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
generated by cgit (git 2.34.1) at 2024-06-25 10:41:19 +0000