summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)Author
2020-04-26update pchesCaolán McNamara
Change-Id: I83a61da7dda6c72552eecd377f1c3744c92a797e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92909 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-04-24loplugin:unusedmethodsNoel Grandin
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-23Fix typosAndrea Gelmini
Change-Id: I6c9fe715c0d188d3970027fcb63c6c039c957fd9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92733 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-04-22tdf#108496: DOCX: redesign of override in listsVasily Melenchuk
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-22writerfilter: document WrapPolygonMiklos Vajna
Change-Id: I39ef69269a3fafa188b44e741274ec770de463a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92657 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-04-22uiobject.hxx only needs forward declaresCaolán McNamara
and update pches accordingly Change-Id: I411712532fd85961bffe6678416fcdc1d9c7f53d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92617 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-04-21tdf#131446 DOCX import: restrict IncreasedAnchoredObjectSpacing furtherMiklos Vajna
Regression from commit 8b73bafbc18acb4dd8911d2f2de8158d98eb6144 (tdf#115719 DOCX import: increase paragraph spacing for anchored objects, 2018-02-14), this is another case where the workaround for the Word layout bug is not needed. tdf115719.docx and tdf115719b.docx are tweaked to have <wp:anchor ... behindDoc="1"> for 1 shape, as the original bugdoc has it. This allows us to render both the tdf#115719 and tdf#131446 bug documents the same way as Word does. Change-Id: I0c3f197c3360882cd64f8dcf286c6051dc11d674 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92599 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-04-19tdf#132185: field command does not necessarily end with spaceMike Kaganski
Change-Id: I5a5e54fb42e20855b75af7ab523465a032ab46e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92504 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-04-17Move Word compat option where it belongsSamuel Mehrbrodt
Change-Id: I6b28c6782f22190b7b22b11361c200d68d672aea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92347 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-04-17loplugin:buriedassign in tools..xmloffNoel Grandin
Change-Id: I31df6c4fd82c6f6d15bbe5228e92e5171cacba51 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92410 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-15writerfilter: DOCX import: import w:noLeading as AddExternalLeadingMichael Stahl
Change-Id: I3d7fa2984975205d284575c60c6c47284b00c4a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92209 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-04-15Revert "NFC writerfilter: remove pointless asserts"Justin Luth
This reverts commit 708f95b87410c640f0e9e22892f4a71194631cd9. Stephan said I have it all backwards. Asserts are primarily "documentation", and there is no point in asserting something if you aren't going to accept it as true, at least not without any other qualifying remarks etc. So a simple "assert(p)" should never be followed by "if(p)". These asserts basically show that "yes, I'm using this pointer without checking on purpose, and not as an oversight." Change-Id: I7350b627a2acf027d1a6d5b33ea272050d23ce6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92059 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-04-14tdf#131321 writerfilter: ApplyNumberingStyleNameToParaStyles()Justin Luth
Prior to this commit, numbering on paragraph styles was lost on import. This didn't affect layout at all, but it did affect user editing. DOCX: export already was fine, just import was missing. RTF: export is explicitly ignored for non-paragraphs, (ParaNumRule_Impl), so I am ignoring RTF, since this fix is meaningless unless both import and export are working. This is a bit tricky because styles.xml is loaded before numbering.xml, so the names are not known until after numbering.xml has finished. So this helper function runs at the end of the numbering.xml import process. Several existing unit tests nicely confirmed a few things. -tdf95377.docx: numId 0 overrides an inherited numbering -chtoutline.docx proves that outlineLevel styles are exempt. -fdo61343.docx actually has nothing in numbering.xml, so it is possible to have a numbering with no name. Of course, it is a really messed up document, too... Change-Id: I270a581f08704c2595d861ce5c5b546f9d6ba6b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92058 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-04-13NFC writerfilter numbering: remove redundant codeJustin Luth
Remove duplicated StyleSheetImport section, and redundant valid pointer check. Change-Id: I468733fc627fbdbebb2daf7087ce9e65158751df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92065 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-04-11Removed duplicated includeAndrea Gelmini
Change-Id: I7863aedccbf22a0958f407b8f3aefe7ed997f9b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91812 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-04-11NFC writerfilter: remove pointless assertsJustin Luth
In an age where GDB (or whatever other platform debugger you prefer) is easy to use, there is no point in asserting something that is going to crash anyway, is there? Asserting is only good in these cases if you follow it using an _if_ statement. Noel informed me that it can also be used to silence false positive coverity warnings. Change-Id: I5a5cb7a22019768ec2807f6918d4a8ebb51194de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92049 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-10writerfilter: simplify ListDef::GetStyleNameJustin Luth
A simple lookup of the list's stylename has no need for a styleId. That is only used during the naming of the style, in which case both id and styletable are needed. Let's not be confusing and just create a separate function to simply return m_StyleName. Change-Id: Ib0303a45d6154988f27c37d2c1470b0529d6c762 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92035 Tested-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-04-10tdf#132001 DOCX import: fix crash: redline in floating tableLászló Németh
Copying redlines to frame text was failed in tables inside frames. Skip these redlines temporarily. Regression from commit e8bae67b3dbcc90ace8264b6b1aefaf0ce459aba (tdf#125894: DOCX: import tracked changes in frames). Change-Id: I4f3ca2e95fb2e7637f8cf8dca1088a7727bcf98d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91985 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-04-09pyuno,*: kill Python 2 support with fireMichael Stahl
Python 2 support was retained for use with --enable-python=system on RHEL7 and SLES. The time has arrived to remove it. Some .py files that were imported from third parties are not changed to enable easier replacement with updated versions if necessary. solenv/gdb should continue to support Python 2. bin/get-bugzilla-attachments-by-mimetype requires Python 2 to access Launchpad. Change-Id: I26414ae8e9f8402c90336af82020135685694217 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91697 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-04-08tdf#131959 DOCX: import tblInd from table styleLászló Németh
to fix left table indent when direct formatting doesn't overwrite the table style. Note: The imported values are adjusted correctly according to the differences in calculation of table indent positions. See commit d2db4bc9507653a46fdea282d41b9683910a072f (tdf#119760 docx: table starts at left, not mid-border). Change-Id: Ieb6f078b3bd3605d538f2eedb7a5030784a738b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91765 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-04-08simplify QNameToStringNoel Grandin
no need for it to be a class, and no need for the data to be allocated at runtime Change-Id: I80bca34b2af221534eae5a6e90de369fa29037e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91878 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-07tdf#131819 DOCX import: fix fixed size nested tableLászló Németh
Auto width nested table with fixed width cells is imported as fixed width table to keep the original cell widths, which define the width of the table, too. Partial revert of commit bed818c5d5e92a0b189f25e18495fc205d949128 (tdf#104876 writerfilter: m_bTableSizeTypeInserted = false here). Change-Id: If58c58a792853e1084ff1d8f9bf6ef74a593b1bd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91764 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-04-07tdf#119038 DOCX: fix FollowTextFlow handlingAttila Bakos
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 Luth
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-07loplugin:unusedvariableplus in writerfilterNoel Grandin
Change-Id: Idd0fd88dc55df6e916291d173c8f6fc1219fc111 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91783 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
generated by cgit (git 2.34.1) at 2024-08-05 04:52:27 +0000