summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)AuthorFilesLines
2020-01-07tdf#129522 writerfilter: allow char shadow_NONE overridesJustin Luth1-5/+5
Exporting will take some extra work, so keeping that part separate for now. The unit test will come when exporting works. The same change was made for paragraph style-overrides in an earlier patch, and this patch depends on it for proper UNO processing. (commit 4ca73073a0d7c62b12a7354f76f8f80adc5d98c1) Change-Id: I5282a319e89be9a63dbd99e00e35fb2d176a631d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85869 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-01-07tdf#129452 DOCX import: fix bottom border of merged columnSzabolcs Toth1-3/+14
Bottom border of a vertically merged column of a table was missing if the inside borders were turned off and the merge included the last cell of the column. This happened because the first cell (topmost) in a set of vertically merged cells determines the borders of the new merged cell, and the turned off inside borders were at the bottom in this case. Change-Id: I3d3defad18a1315117a554a36ad599eb46daffe9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85988 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2020-01-07tdf#77796 DOCX: import table style based cell paddingLászló Németh2-0/+48
Change-Id: Ib86ed45fe816d7e273539798cdebdbb95d575518 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86295 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2020-01-06tdf#129450 DOCX import: fix bottom border of 1-row tablesSzabolcs Toth1-0/+5
Bottom border was missing in a 1-row table with disabled inside borders. This happened because LO applied the empty horizontal borders to the bottom border of the table. Change-Id: I40140bf63297189edad13088f98fc5f869969c2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85303 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2020-01-06tdf#129442 DOCX import: fix right border of 1-column tablesSzabolcs Toth1-0/+5
Right border was missing in a 1-column table with disabled inside borders. This happened because LO applied the empty vertical borders to the right border of the table. Change-Id: Ib190689bf5059bfd7dbf07b07808cd761015f37e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85301 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2020-01-06Removed redundant semicolonsAndrea Gelmini2-6/+6
Change-Id: Ife14b8c3f7d121deb390deb5f405dd42d3016acf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86156 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-04tdf#129475 DOCX: fix gridAfter with shape-only cellsLászló Németh9-72/+132
and in last row of tables, i.e. regressions caused by the following commit. This reverts commit b2c6d2d961a6113d0f111fab45ae12a40d389a23 (fdo#38414 tdf#44986: DOCX table import: handle gridBefore/After), except some unit testing. Change-Id: Icb2d65b7a0766cf8dd00511cde500af3f94d2a94 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86125 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2020-01-03tdf#129522 SvxShadowItem/writerfilter: allow shadow_NONE overridesJustin Luth1-2/+6
Both editeng and writerfilter were ignoring the case where NONE should override an inherited shadow location. Of course, this situation is very rare. Nearly all unit tests ran when asserting that eLocation is already NONE. The same is true for DOC, except that it is not affected by SvxShadowItem's PutValue problem (and neither is ODT). RTF is not even removing the borderlines themselves, so no point in worrying about the shadow for RTF. Change-Id: I7c1ae67270dde81915daee2f0282aa2074d2ec8e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85658 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-01-02tdf#129605 rtfimport: deduplicating borders loses informationJustin Luth1-0/+13
Because at least ONE direct attribute still existes, that SPRM overrides the style SPRM, and therefore the style contents are ignored. But deduplicating has removed the matching parts from the paragraph, so any children properties that match the style revert to default values. In this unit test, only the green border-color was kept, and so a default none-border was created. The UI in writer also directly applies all border properties during a color change, so further style changes in the border-style or thickness no longer have any effect. So there is no reason to try to deduplicate border stuff. UNRESOLVED PROBLEM NOTE: If deduplication is going to happen, then there needs to be a merging of character style child attributes and the directly applied properties - which in practice is the same as not deduplicating at all. (The problem will still come when the paragraph ONLY redefines the border color - then there is nothing to deduplicate and still the style contents are ignored.) This patch affects paragraph-style borders (in a good way), since it fixes tdf#129631 as well. Probably every SPRM that expects children should just avoid deduplication... UNRESOLVED PROBLEM NOTE: Another problem is that the direct properties themselves do not seem to be deduplicated. In addition, deduplication happens against the FIRST instance of the property, not on the LAST instance (which ultimately is the winner). Change-Id: I97333fba66db5cfb5238de426821fe458def329b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85868 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-01-02tdf#129205 DOCX import: handle the <w:shd w:val="nil" ...> paragraph propertyMiklos Vajna4-1/+77
Reading the spec, "nil" is the opposite of "clear": i.e. if the (background) color is red and the fill (color) is green, then "clear" means green. And you would expect "nil" means red, but it's just nothing in Word. Fix the problem by doing the same: don't set any paragraph property for the "nil" case and keep doing it for the common "clear" case. Change-Id: I30af8a7fb55fb9bab2d12e120069a479fc7ab0a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86096 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-12-25sal_Char->char in xmloff..xmlsecurityNoel Grandin2-7/+7
Change-Id: I292d699ce1de10ca9341525161f5da2592102ff7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85778 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-24Fix grammarAndrea Gelmini1-1/+1
Change-Id: I5536e94dfd502558b00a0ed3d9d97fdf00eb4854 Reviewed-on: https://gerrit.libreoffice.org/85625 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2019-12-22loplugin:finalclasses in UnoControls..writerperfectNoel Grandin1-1/+1
Change-Id: I751c9a45503326dfdaeb471967a688a95d4fa090 Reviewed-on: https://gerrit.libreoffice.org/85711 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-22loplugin:unusedfieldsNoel Grandin5-18/+0
Change-Id: Ib2314f23efe953398ed0a5e88305842c812e18bb Reviewed-on: https://gerrit.libreoffice.org/85708 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-21nitpick tdf#123262 writefilter: use enum class and documentJustin Luth1-1/+10
Change-Id: Ibc040c75fff309699911ffa72d1f44ce5b231688 Reviewed-on: https://gerrit.libreoffice.org/85644 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2019-12-20tdf#129513: drop incorrect and redundant erasure of paragraph sprmMike Kaganski1-1/+0
It was introduced in commit 2499397cb39330dabeb8b7b3e0d7eb6213a0d8f4 "avoid sending duplicated paragraph flags", and supposedly was meant to avoid having duplicating sprms in the collected properties, when new properties were pushed back at that time. Using specific sprm id was likely a mistake (nParam should have been used instead). Now the new sprm is added using RTFSprms::set with eOverwrite having default value of RTFOverwrite::YES, which takes care to avoid dupes, so the call to erase is redundant. This reverts commit 2499397cb39330dabeb8b7b3e0d7eb6213a0d8f4. Change-Id: Ied19f6feb41bd17ef317812d4d295ca0542a5843 Reviewed-on: https://gerrit.libreoffice.org/85602 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-12-20tdf#123262 writerfilter: completely ignore footnote separatorsJustin Luth3-26/+34
... except for processing enough to observe the separator exists. For each footnote reference, the entire footnote.xml file is parsed every time. The text in the "separator" footnote was being added to every footnote. The normal case where this is just a single paragraph was already handled, but this patch generalizes everything to handle cases of actual text or multiple paragraphs. Not every footnote has a type, so we can't depend on that to turn ignoringText ON/OFF. Every footnote has an ID, but theoretically the ID could be processed before or after the type, and it has no idea which type it is. Finally, the skipped text has no idea how many times/paragaphs it needs to skip. So a three-way control was needed to handle on/used/off. As a safeguard, finishing the footnote.xml parse (PopFootOrEndnote) ensures that ignoring won't be left on in the unlikely case that the separator is the last footnote. Change-Id: Ia30ca8d3a36417a4691e3b2e1c978720be017030 Reviewed-on: https://gerrit.libreoffice.org/82172 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-12-20tdf#87569 tdf#109411 DOCX import: fix shape anchor in tablesBakos Attila2-0/+24
Import "relative from page" horizontal setting of VML and DrawingML shapes as "relative from column" in tables, just as MSO handles it. Change-Id: If71f2e52bbba324a98651e701feaeb99acfefc48 Reviewed-on: https://gerrit.libreoffice.org/85141 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-12-20DOCX table import: fix interaction of 1-cell rows and "inside" vertical bordersMiklos Vajna5-1/+127
The interesting part of the bugdoc was: - table style wants visible borders - table direct formatting clears left and right borders - 1st row of the table has 1 cell (2 cells in fact, but they are merged) Fix the "inside" vertical border handling, so that the first cell gets these vertical borders as a right border only in case there are multiple cells. Change-Id: Id847109ecfa95d1745abe62ddf36c4936b730855 Reviewed-on: https://gerrit.libreoffice.org/85536 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-12-19Fix mid-air collisionStephan Bergmann1-1/+1
Change-Id: Iedfd0df670e4aa81fc2acbee5c3bda50c53b9fc7 Reviewed-on: https://gerrit.libreoffice.org/85538 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-19tdf#129247 writerfilter,sw: improve handling of CONTROL fieldsMichael Stahl1-1/+12
The "CONTROL Forms.CheckBox.1" field has a shape as its result. Previously this was imported as an unknown generic field by writerfilter and exported as a CONTROL field followed by a SHAPE field; the CONTROL field was discarded by Writer on a subsequent import. Now this is exported as nested fields to WW8, i.e., SHAPE inside the result of CONTROL, which is an improvement. Unfortunately the WW8 import discards the result of the CONTROL field, because its field code is written as ww::eUNKNOWN = 1, not ww::eCONTROL = 87. To fix that, set the ODF_ID_PARAM parameter in writerfilter for these fields, which is checked in MSWordExportBase::OutputTextNode(). This reveals that the field code was set wrongly on the fieldmark too, it should be set as a ODF_CODE_PARAM parameter and not as the type. Furthermore the WW8 import needs to allow nested fields in the eCONTROL field. Change-Id: If79a186ea30c3b4a933ba1d8325111215250b833 Reviewed-on: https://gerrit.libreoffice.org/85418 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Michael Stahl <michael.stahl@cib.de>
2019-12-18sw RTF export: don't mark these members as constMiklos Vajna1-1/+1
As the destructor wants to std::move() these members, and that only has an effect if the member is not const. Simiarly in writerfilter/, there the const prevents the implicit std::move() on return. Change-Id: I42ce393da9033abbd028bd5b83f15f69d34e254d Reviewed-on: https://gerrit.libreoffice.org/85336 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-12-17tdf#112201 writerfilter: try to apply continuous section page style...Michael Stahl1-0/+15
... on the last node of the previous section. This works for this particular document, but it's quite dubious that it will work in the general case; feel free to revert this if it causes problems. Change-Id: Ia03d41a1127df505c4e9da7131323b70d88a285f Reviewed-on: https://gerrit.libreoffice.org/85294 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-12-17tdf#112201 writerfilter: continuous sections:Michael Stahl1-1/+2
always replace break with follow-page-style, not first-page-style. It looks like Word ignores <w:titlePg> on continuous section breaks, unless it's the first section, which was already handled by code above. Change-Id: If7c0fe96a1789f64f1943ece453db3dbc284ca48 Reviewed-on: https://gerrit.libreoffice.org/85293 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-12-17Convert some defines to constexprMike Kaganski1-9/+5
Change-Id: I78d119857b80d223d6fa8228cee4c0be829627c4 Reviewed-on: https://gerrit.libreoffice.org/85267 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-12-17tdf#112202 writerfilter,sw: fix loss of headersMichael Stahl3-7/+55
There are several problems here: * CloseSectionGroup() is not only called for actual sections in the document but also at the end of every special text like comment, footnote, etc; only actual sections can set page styles. Writer comments use editengine so cannot even contain sections. * With continous section breaks, headers and footers are inherited from the previous section unless defined by the current section; SwXText::copyText() did not copy the content of the header on page 4 to page 5 correctly because it used an SwXTextCursor to create the selection, which cannot select the table at the start of the header. * For continuous section breaks, WW8 import filter has a heuristic to find the first page break in the section and set the PageDescName property on that node to apply the page style with the headers of the new section; do something similar in writerfilter SectionPropertyMap::CloseSectionGroup() Change-Id: I3ebe3d299f83197cbf8f10de46c34de98677626c Reviewed-on: https://gerrit.libreoffice.org/85213 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-12-16tdf#129353, tdf#129402: fix node creation on index importMike Kaganski3-71/+125
ToC, bibliography, and index sections import code changed to closely follow what Word does, make sure that pre-rendered entries don't get imported as standalone paragraphs outside of the index sections, and paragraph count is accurate (no missing or added paragraphs as much as possible). In Word, an index may start and end in the middle of a paragraph: <w:p> <w:r> <w:t>Some text before index</w:t> </w:r> <w:r> <w:fldChar w:fldCharType="begin"/> </w:r> <w:r> <w:instrText> TOC ...</w:instrText> </w:r> <w:r> <w:fldChar w:fldCharType="separate"/> </w:r> <w:r> <w:t>First pre-rendered index entry</w:t> </w:r> </w:p> ... <w:p> <w:r> <w:t>Last pre-rendered index entry</w:t> </w:r> <w:r> <w:fldChar w:fldCharType="end"/> </w:r> <w:r> <w:t>Some text after index</w:t> </w:r> </w:p> However, normally it looks like either no runs precedig index, or no runs of pre-rendered contents will be present. When no Std elements are used, the typical situation is that there's a normal paragraph (possibly with some user text), which ends with index start marker, without any pre-rendered contents in the same paragraph; and all pre- rendered contents goes in following paragraphs. Such index normally ends with index end marker in the *first* run of a paragraph, which then might have normal text runs. When Stds are used, then no leading/trailing out-of-index runs in paragraphs with marks are usually present; and in this case, when paragraphs with index marks don't contain pre-rendered entries, they still are treated as part of the index. In Writer, indexes are node sections (and so cannot be inline with other paragraph contents). When there was some paragraph content already before the start-of-index mark, the paragraph is assumed to end before the index; in this case, when current <w:p> element ends, importer decides if a separate starting paragraph is needed or not, depending on if there was some runs after the mark. When there was no text runs before the starting mark, then the paragraph is treated as leading paragraph of the index. This allows to not miss empty paragraphs before index; and not have two paragraphs where there was one in Word. Only in cases when user had manually typed text both in and outside of the index in the same paragraph in Word, we would have the paragraph split into two in Writer. For end marks, the behaviour depends on whether it's inside Std. When inside, the ending paragraph starting with index end mark is considered part of the index. For out-of-Std case, it's considered normal paragraph (and measures are taken to make sure it's not dropped even if empty, because sometimes such paragraphs don't have other content, and have section settings, which is usually treated by Writer as "drop this paragraph" sign). A special problem is multi-column index. It's wrapped into a continuous section by Word; and in Writer, we also wrap it into a section. It would be possibly useful to detect somehow if this section is part of index definition, and in this case, drop the section and put its properties into the Writer's index section. That would avoid an explicit section in the imported document. This is TODO, for someone who figures how to detect reliably if the section belongs to index definition. See comment in DomainMapper_Impl::appendTextSectionAfter. By the way, current export code is wrong, producing an index that is single-column in Word; this change doesn't touch that. Several existing tests needed to be fixed, which used to test wrong results. Change-Id: I9597c8ab13f31ded9abcc24054d3478d3e3a3b40 Reviewed-on: https://gerrit.libreoffice.org/85089 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-12-16tdf#129242 Regression fixed for one cell table bordersSzabolcs Toth1-1/+1
Had to check an additional criteria before removing inside borders. Change-Id: I0828d973bd331e65ebabc1fe2e2f25f1bcaf58b0 Reviewed-on: https://gerrit.libreoffice.org/84676 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-12-13loplugin:expandablemethodsNoel Grandin2-8/+2
Change-Id: I333d91ea5ce78c82e9bb107f934614efc7bfb8f7 Reviewed-on: https://gerrit.libreoffice.org/85078 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-12Remove some redundant user-provided dtorsStephan Bergmann2-5/+0
...which silences various -Wdeprecated-copy-dtor warnings from Clang 10 trunk about copy functions being implicitly defined as non-deleted even though the class has a user-declared dtor Change-Id: I3409d403c3c709de4ad94eccbc2d7869e41847cc Reviewed-on: https://gerrit.libreoffice.org/85032 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-12Use structured bindingMike Kaganski1-8/+6
Change-Id: I1afea430de43f44f0155078327870b8dc0c937e3 Reviewed-on: https://gerrit.libreoffice.org/85012 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-12-08fdo#38414 tdf#44986: DOCX table import: handle gridBefore/AfterLászló Németh9-132/+72
without serious regressions, ie. losing the import of complex forms with multiple or nested tables. Complete the fix for tdf#116194 (DOCX import: fix missing tables with w:gridBefore) with handling gridAfter on DomainMapper level. This consists of also rejections (except their unit tests) of commit cf33af732ed0d3d553bb74636e3b14c55d44c153 (handle w:gridBefore by faking cells (fdo#38414)) and commit 1d1748d143ab4270a2ca1b5117852b1b1bb4c526 (Related: tdf#44986 DOCX import: handle w:gridAfter by faking cells) Change-Id: I31fa1de03bcdf42424fa5507fb5a3e06aa47107d Reviewed-on: https://gerrit.libreoffice.org/84517 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-12-08tdf#116194 DOCX import: fix missing tables with w:gridBeforeLászló Németh6-15/+65
Regression from the commit cf33af732ed0d3d553bb74636e3b14c55d44c153 "handle w:gridBefore by faking cells (fdo#38414)" This patch replaces the previous fix with a better solution, fixing tdf#38414 on the proposed DomainMapper level. (Note: to reject the old fix completely, its follow-up commit w:gridAfter will be handled in a similar way.) Now the related regressions, tdf#111679, tdf#120512 and the complex forms of tdf#116194, tdf120256 and tdf#122608 are fixed, too. Change-Id: Id25f5fb4d9021c87ee8c82782b2038e6fb255673 Reviewed-on: https://gerrit.libreoffice.org/84263 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2019-12-06Related: tdf#115719 DOCX import: fix increased spacing vs left-aligned objectsMiklos Vajna5-12/+38
Commit 8b73bafbc18acb4dd8911d2f2de8158d98eb6144 (tdf#115719 DOCX import: increase paragraph spacing for anchored objects, 2018-02-14) added an import-time tweak for a problem that has been confirmed to be a Word layout bug in the meantime (and the tweak makes Writer behave the same way if the document has been created by an affected Word version for layout compatiblity). Later, commit 4883da6fd25e4645a3b30cb58212a2f666dae75a (Related: tdf#124600 DOCX import: ignore left wrap on left-aligned shapes, 2018-02-14) fixed left spacing of anchored objects aligned to the left, to be in sync with what the DOC import does. This broke the previous fix in case the shapes are left-aligned. Fix the problem by tracking what is the in-file-format and logical left margin, so the final doc model has the value necessary for correct horizontal positioning and the importer has the value that's necessary for correct vertical positioning. Change-Id: I8f16cbe7bad40e243111c902bdc1ab0e8141d6b9 Reviewed-on: https://gerrit.libreoffice.org/84654 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-12-06tdf#120546 fix DOCX overriding numrule formatJan-Marek Glogowski1-0/+3
... at least in the view. This "fixes" the import side of the exported OOXML document with multiple overridden numrule character format. This prevents the change of the shared numrule, which results in all bullets being formatted like the last overridden numrule. What is missing is a consistent way to edit the override, as the override is currently just stored in an internal attribute, the "ListAutoFormat" property. Fixing editing for good will be a larger work, as "ListAutoFormat" must be reflected in the GUI and must have a higher priority then the numrule format. Currently positioning the curser in front of the number or bullet entry lets one change the numrule format, which is applied to all bullets of the same rule. This special DOCX override mode is enabled by the import filter setting DocumentSettingId::APPLY_PARAGRAPH_MARK_FORMAT_TO_NUMBERING to true. This should also change the edit mode, so that a change of the entry doesn't modify the rule, but the override and this must also be reflected in the GUI character settings. Change-Id: I057f7a354bc3c413b114eec772e06c7063029699 Reviewed-on: https://gerrit.libreoffice.org/81878 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-12-06tdf#121658 Add option to not hyphenate words in CAPSSamuel Mehrbrodt3-1/+8
* Add checkbox to pagraph dialog * Store property in paragraph model * Move docx import/export from grabbag to paragraph model * Add ODF import/export * Add ODF unit test * Add layout test Change-Id: Id4e7c5a0ad145c042f862995d227c31ae2aa0abd Reviewed-on: https://gerrit.libreoffice.org/83979 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-12-05writerfilter: name the FiltersTest test CppunitTest_writerfilter_filters_testMiklos Vajna49-15/+16
To be consistent with CppunitTest_vcl_filters_test. This also allows writing actual manual test code for writerfilter/source/rtftok/ (next to the tested code) later, where the natural choice for such a test suite would be CppunitTest_writerfilter_rtftok. Change-Id: Iff5be9b95b6c2be3ef441e7a766584b2d008a66a Reviewed-on: https://gerrit.libreoffice.org/84460 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-12-04tdf#128428 RTF: switch off longer space at \dntblnsbdbLászló Németh1-0/+5
The Word 6.0 (Japanese) compatibility option \dntblnsbdb switches off the balancing of SBCS/DBCS characters, including the longer space sequences. Note: using \dntblnsbdb, it will be possible to set normal (short) space sequences in RTF export, too, to avoid broken document layout during RTF round-trip. Fix regression from commit 24b04db5a63b57a74e58a7616091437ad68548ac (tdf#123703 RTF import: fix length of space character sequence). Change-Id: I5ade9e0a2db0bde204d1debe831058045fd8f586 Reviewed-on: https://gerrit.libreoffice.org/84397 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2019-12-04some std::set->o3tl::sorted_vectorNoel Grandin1-3/+4
which is much better cache-wise Change-Id: Iacec0df48f043bcdd761ed30c1b1513850a00152 Reviewed-on: https://gerrit.libreoffice.org/84311 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-03PopFieldContext calls CloseFieldCommand itselfMike Kaganski1-3/+0
Change-Id: I4ac75d6e73f4d60ac532829a56c5d23501e6a531 Reviewed-on: https://gerrit.libreoffice.org/84318 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-12-03remove some useless comment linesNoel Grandin2-5/+0
which merely announce that the next declaration is a class Change-Id: Ifdb1398bcd99816b13e0b3769b46d0562bfbc1dc Reviewed-on: https://gerrit.libreoffice.org/84229 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-02revert obsolete writerfilter hacks for tdf#119054 and tdf#128752Justin Luth4-58/+0
These are obsoleted in LibreOffice 6.5 by tdf#118947's commit 6bced3c6a1bf8d4652dd6ba75e41b128ce1bfc5c Both of these hacks were backported to 6.4, but I have no intention of backporting my patch. Change-Id: Ie639b9d55d90d25b58e140fba443fce98f2d7ba1 Reviewed-on: https://gerrit.libreoffice.org/84125 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2019-12-01Introduce o3tl::optional as an alias for std::optionalStephan Bergmann16-75/+75
...with a boost::optional fallback for Xcode < 10 (as std::optional is only available starting with Xcode 10 according to <https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS and macOS is still Xcode 9.3 according to README.md). And mechanically rewrite all code to use o3tl::optional instead of boost::optional. One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per fed7c3deb3f4ec81f78967c2d7f3c4554398cb9d "Slience bogus -Werror=maybe-uninitialized" should no longer be necessary (and whose check happened to no longer trigger for GCC 10 trunk, even though that compiler would still emit bogus -Wmaybe-uninitialized for uses of boost::optional under --enable-optimized, which made me ponder whether this switch from boost::optional to std::optional would be a useful thing to do; I keep that configure.ac check for now, though, and will only remove it in a follow up commit). Another longer-term benefit is that the code is now already in good shape for an eventual switch to std::optional (a switch we would have done anyway once we no longer need to support Xcode < 10). Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses boost::property_tree::ptree::get_child_optional returning boost::optional, so let it keep using boost::optional for now. After a number of preceding commits have paved the way for this change, this commit is completely mechanical, done with > git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g' (before committing include/o3tl/optional.hxx, and relying on some GNU features). It excludes some files where mention of boost::optional et al should apparently not be changed (and the sub-repo directory stubs). It turned out that all uses of boost::none across the code base were in combination with boost::optional, so had all to be rewritten as o3tl::nullopt. Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b Reviewed-on: https://gerrit.libreoffice.org/84128 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-30Rewrite uses of boost::optionalStephan Bergmann2-3/+3
...to only use functions that are also available for std::optional (in preparation for changing from boost::optional to std::optional): * uses of get are replaced with operator * or operator -> * uses of is_initialized are replaced with operator bool * uses of reset with an argument are replace with operator = (All of the replacements are also available for boost::optional "since forever", so this change should not break builds against old --with-system-boost. An alternative replacement for is_initialized would have been has_value, but that is only available since Boost 1.68.) Change-Id: I532687b6a5ee37dab28befb8e0eb05c22cbecf0f Reviewed-on: https://gerrit.libreoffice.org/84124 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-29tdf#118947 writerfilter: remove obsolete tablestyle fontsize hackJustin Luth1-17/+6
LO 6.5 commit 6bced3c6a1bf8d4652dd6ba75e41b128ce1bfc5c obsoletes this old hack. The default paragraph style has (almost) nothing to do with table styles. *Any* specified (non-inherited) paragraph style property should override a table style, including the default paratyle. One exception is the default occurance of the not-yet-supported word/settings.xml compat option overrideTableStyleFontSizeAndJustification = false. The default case should cause the table-style font to override a size 11 or 12 default-paragraph-style font. So that is actually double-reason to remove this old hack which threw out the table-style size altogether. Change-Id: Id1687f32b8431b6fa8770b01c344e75e0ffb344f Reviewed-on: https://gerrit.libreoffice.org/84044 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2019-11-28NFC tdf#120412 cleanup: use DFLT_ESC_* moreJustin Luth1-2/+1
and all of the comment references to 14400% are no longer accurate, so they were removed. Change-Id: Ic958cc240e4898e914958fc32d09e2bb9478f197 Reviewed-on: https://gerrit.libreoffice.org/83845 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2019-11-27Related: tdf#128611 RTF import: handle vertical flip of line shapesMiklos Vajna1-0/+19
UI uses SdrEditView::MirrorMarkedObjVertical() to flip a line shape vertically, handle it similarly at import time as well. Also note that this flips in-place, while the naive '*= -1' for the height would have an incorrect vertical position. Change-Id: I42b7feb5f799b99337ddec734dcf98dd1d553755 Reviewed-on: https://gerrit.libreoffice.org/83929 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-11-27crashtesting: failure on import of tdf113230-1.docxCaolán McNamara1-1/+5
which is a favorite input document for crashes and assert apparently, this is the third time it has triggered a different problem this one is new since... commit 9fdf8c0a5cc036ea9bd1e11dd8f2c1a6e601fae2 Author: Mike Kaganski <mike.kaganski@collabora.com> Date: Sat Nov 16 16:34:25 2019 +0300 Also consider saved exceptions when terminating parse Change-Id: I394b650613e8a835fe8a9f216a48864bdbc5065b Reviewed-on: https://gerrit.libreoffice.org/83924 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-27tdf#76586 fix table width of auto-width nested tablesLászló Németh2-2/+12
when they have (sometimes incorrect) fixed cell widths. Change-Id: I98bf37bfce72b84eed14e354520e4741ae2ddada Reviewed-on: https://gerrit.libreoffice.org/83787 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2019-11-26Remove some unused includesMiklos Vajna1-2/+0
Change-Id: Ia24c806f227570f7a000e85eece75c9d02d25a4b Reviewed-on: https://gerrit.libreoffice.org/83782 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-24 20:51:32 +0000