summaryrefslogtreecommitdiff
path: root/writerfilter/source/dmapper/DomainMapper_Impl.hxx
AgeCommit message (Collapse)AuthorFilesLines
2020-11-24loplugin:stringviewparam extend to comparison operatorsNoel1-1/+1
which means that some call sites have to change to use unicode string literals i.e. u"foo" instead of "foo" Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-17loplugin:stringviewparam check methods tooNoel1-1/+1
not just functions Change-Id: Icca295dd159002b428b73f2c95d40725434f04d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105789 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-02sw: return SwXFieldmark in SwXFieldEnumerationMichael Stahl1-1/+1
* Implement text::XTextField in SwXFieldmark * That requires overriding XTextContent, just forward to SwXBookmark * Also override XServiceInfo implementation in SwXFieldmark * Add a PropertySetInfo for SwXFieldmark, which doesn't support "Hidden" or "Condition" properties of SwXBookmark * in SwXFieldmark::setFieldType(), only allow sensible new types * fix DomainMapper_Impl assumptions that if it implements XTextField it can't be a fieldmark, which caused CppunitTest_sw_ooxmlexport10 testTdf92157 to fail with a SAXException caused by some disposed SwXTextCursor Change-Id: I1ae2e9cb99ea784040874517e4d1af7e59d24405 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105083 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-11-01std::set->o3tl::sorted_vector in writerfilterNoel Grandin1-2/+2
Change-Id: I8b4527c8e40687918b3d5193f6c14ee86addab53 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105132 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-26DOCX import, altChunk: fix missing page breakMiklos Vajna1-0/+4
Somewhat similar to copy&paste, the altChunk mechanism drops styles from the inner document by default. A surprising consequence of that is sections in the inner document have the default page size. This leads to a page break when the content of the outer document ends and the content of the inner document starts. Fix the importer to support this: 1) Ignore the page size and number in DomainMapper::lcl_attribute(). 2) Pass the start of the current section to the sub-importer, so that it can insert the starting page break at the right place. Change-Id: Id3955f2b35a139692254c4ac1233e96eef2620e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104821 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-10-22DOCX import: handle <w:altChunk r:id="..."/>Miklos Vajna1-0/+6
This refers to a self-contained full DOCX file inside a DOCX file. Change-Id: Ic9451833db30231f08ff2e2493da678edbc9a4c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104654 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-10-18tdf#124176: Use pragma once instead of include guardsmariamfahmy1-3/+1
Change-Id: Ib9fd7e3ffbe8760edf4a108342aa5ed03c453b01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104487 Tested-by: Jenkins Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
2020-10-06tdf#97128 DOCX import: fix frame directionDaniel Arato (NISZ)1-0/+21
Frames used to be imported with zero rotation even if a w:textDirection tag explicitly called for a non-default orientation. I found no other solution to pass the incoming frame direction property on to the SwXFrame about to be created. 1. If you put the property into the GetSectionContext(), it gets overwritten when the next w:pPr tag is parsed, so all three frames will end up having the same direction. 2. If you put the property into the GetTopContextOfType(CONTEXT_PARAGRAPH) that context gets popped off the stack before control even gets to CheckUnregisteredFrameConversion(). 3. If you use PushStyleSheetProperties (which is bad in and of itself), the order will be messed up because the frames are not necessarily created in the same order as they are described in the file, so each frame gets a wrong frame direction in the end. Follow-up of commit 5a5597655a4bf12e4ca07c9c2b6f6221e217f080 (tentative fix for fdo#30474# [DOCX rotated text import failure]). Change-Id: I6e3d68fe60c6e2a5b6684c65a964dd86d0168181 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103553 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-09tdf#136589 writerfilter: reset ParaHadFieldJustin Luth1-0/+1
::finishParagraph normally resets this, but it exited early because of m_bDiscardHeaderFooter, so the setting spilled over into the following paragraph. This is a bit of a bandaid - likely stacks of paragraphs and sections need to be used so each can hold its own settings and not worry about them being clobbered. But this particular case seems to a single level problem, isolated to headers/footers, so the change should both be enough and regression-safe. Change-Id: I84c9a5d6bf95c35c4996a9b31e53f18c05ade727 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102314 Tested-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-09-07tdf#135949 writerfilter: don't bRemove if anchoredObjectsJustin Luth1-0/+2
Surprised it took so long to find an example of an anchored object on the empty paragraph. I considered making a more useful function, but I didn't want to return a pointer, and my skills and understanding aren't good enough to intelligently return an empty vector reference, so I just left it as I first created it. It seems a bit silly to make a bool function just for this, but nothing returns anything that I wanted to use. So I just made a perfect-fit function for my unique need here. I would have preferred to create a potentially re-useable and flexible function... Change-Id: I8c2527403cd8059223d4bc610b10243656b1db3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102060 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-17tdf133647 tdf123386 tdf123389 Improved .docx table formula importMichael Warner1-1/+2
Converts table formula syntax from MS Word to LibreOffice. This version uses the list separator of the document for the formula regexen; however, it does not convert the decimal or list separators in the case where the person opening the document is using a different locale from the author. Change-Id: I9600a0bea060a76705a7ad6b051ed4fdd50b9d40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98614 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-08related tdf#135216 writerfilter: don't bRemove para with fieldJustin Luth1-0/+1
So the lovely task of building up every possible exception where a paragraph has content without noticed character properties continues... Change-Id: I1df13f1ea96866b82f44cbbedd52bb525e0d3c2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99761 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-07-20compact namespace: writerfilterNoel Grandin1-4/+2
Change-Id: I1dd3aff6c08fb2bce031abd6e88603a4ec9077fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99012 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-14tdf#134793 DOCX import: fix numbering with inline imagesLászló Németh1-1/+4
before page break. Previous fix for tdf#118701 didn't keep numbering of the paragraph marked for deletion. This reverts commit b216fc5b583050cfb1cdf9bd82ec3c1bd2e09d70 (tdf#118701 DOCX import: fix image position on page break). Change-Id: I5bde927f15b4b1f682d81482734fadff7690f6d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98541 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-07-10tdf#118701 DOCX import: fix image position on page breakBakos Attila1-0/+1
If an image anchored to an empty paragraph only with section properties, don't remove that paragraph to keep the image on the page before the page break. IsLastParaEmpty() tries to move a text cursor over the empty paragraph marked for deletion. If it contains an image anchored as a character, the cursor won't reach the end of the previous paragraph by goLeft(2). Co-authored-by: Attila Bánhegyi (NISZ) Change-Id: Ic22c7553948eb06739232d7e35fc49ad14f96518 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97518 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-05-26tdf#133030: DOCX export: fix formula alignment - part 3Attila Bakos1-1/+1
Follow-up of commit 1237acf9851f8b12d1ccd929e2aa8b184c06d552 (tdf#132811 DOCX: fix formula alignment – part 2) Co-authored-by: Tibor Nagy (NISZ) Change-Id: I5466649a2aa6b7ffdb0def723f79dfbecdf1495f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93665 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-05-12tdf#132811 DOCX: fix formula alignment – part 2Attila Bakos1-1/+2
Formula are aligned inline again, but in the right position, fixing both import and export. This partially reverts commit 8b613c4603047dc24aa9b03fb49f4fe1b65af2a3 (tdf#121525 OOXML import: fix formula alignment). Co-author: Tibor Nagy (NISZ) Change-Id: If5c13db749fe5c3b1aee754b47dabc9fabd7ebb9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93631 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-05-11tdf#95189: docx import: apply list ovverride only onceVasily Melenchuk1-0/+3
List overrides should be applied only once on first list with override appearance in document. Next reference to this list should not override again and reset list numbering. Change-Id: I7a24398d5980ca97a74fa8ad09d91ac9adff15ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93894 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-05-10use compact namespace syntaxNoel Grandin1-2/+2
mostly done using git grep -wl namespace | xargs -P 8 perl -i -pe 's/namespace\s*([\w:]+)\s*\{\s*namespace\s*/namespace \1::/g' Change-Id: Ic53dbaf443cf81fb8940155f2582a7128d829e6d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93406 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-10new loplugin:simplifypointertoboolNoel Grandin1-1/+1
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-04tdf#132514 DOCX import: fix lost table style with footerLászló Németh1-3/+0
Table paragraphs collected for table style processing were mixed when both body text and footer contain tables, i.e. clearing paragraph vector at processing the first table resulted missing paragraph vector and table style processing for the other one. Now tables in footer, also nested tables collect their paragraphs in separated table paragraph vectors. Regression from commit 6c5da2cd7af5c2d90e4d8e9635ba8c9989c87923 (tdf#119054 DOCX: fix not table style based bottom margin). Change-Id: Ib8568d8379cfb7da869120cdc7fe12895252d661 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93415 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-04-29tdf#121525 OOXML import: fix formula alignmentAttila Bakos1-1/+1
Formula alignment was not handled at all. Now "oMathPara", "oMathParaPr" elements and m:jc attribute are handled using paragraph alignment, as a workaround. Co-author: Tibor Nagy Change-Id: I71546755492e0f9187c77f5324bada6f3c68f0dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91435 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-04-14tdf#131321 writerfilter: ApplyNumberingStyleNameToParaStyles()Justin Luth1-0/+1
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-03-16Revert "loplugin:constfields in writerfilter"Noel Grandin1-10/+10
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-02-21Drop o3tl::optional wrapperStephan Bergmann1-5/+5
...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-20tdf#42949 Fix IWYU warnings in writerfilter/Gabor Kelemen1-7/+0
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>
2020-02-19tdf#118812 DOCX import: fix table style preference – part 2László Németh1-7/+0
Apply table styles according to OOXML and – in the case of font sizes – MSO exception "overrideTableStyleFontSizeAndJustification". Fix temporary regression in styles of paragraph portions, table cell regions and nested tables from commit f15d67442972c5f69c71925a6bfa5aa1a39d54eb (tdf#129575 DOCX import: fix table style preference). Unit test document was created by Justin Luth. Change-Id: I7b076ac27f5b44d44934b7efb18ac4a878f8b596 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88869 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-02-12tdf#129575 DOCX import: fix table style preferenceLászló Németh1-1/+1
handling by recognizing docDefault properties instead of default-value based heuristics. Change-Id: I3bab9d85d77d0e5f1c357121b1caf02cbe4899c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88457 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-02-12Revert "revert obsolete writerfilter hacks for tdf#119054 and tdf#128752"László Németh1-0/+10
This reverts commit 749fd6508504cf3b2e3822eca52a67fa36d75fb8. Change-Id: Iad4cd836e2908e2c21e70013f88af213b3a1822d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88142 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-01-14tdf#129805 writerfilter: fix import of nested generic fieldMichael Stahl1-1/+1
The problem was that the end of the outer nested generic field did not call PopFieldmark(), so the end of the field was at the end of the document. (regression from f610f9b611fe9f206b872ed06f7e859d688385fc) Change-Id: If5928b14dd35f7dd509370c2b8eef4c31bd149dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86785 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-09writerfilter: fix confusing typo, it's SDT (structured document tag)Michael Stahl1-1/+1
Change-Id: I70f8fa752ddac936de6d9f272eff8d36b83858a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86445 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-08DOCX import: fix lost page break when footer ends with a tableMiklos Vajna1-1/+4
Regression from commit 7d3778e0ef9f54f3c8988f1b84d58e7002d6c625 (bnc#816593 DOCX import: ignore page breaks in tables, 2013-09-02), the page break was ignored because the preceding footer ended with a table (no empty paragraph at the end of the footer stream). Fix the problem by saving/loading the table state around header/footers, that way the page break is not ignored. Adjust testTdf102466 to test the page number from Word. Change-Id: Ia4c22452ee2c37f7f941dfd922db04c851644d0c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86435 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-01-04tdf#129475 DOCX: fix gridAfter with shape-only cellsLászló Németh1-3/+0
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>
2019-12-25sal_Char->char in xmloff..xmlsecurityNoel Grandin1-1/+1
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-22loplugin:unusedfieldsNoel Grandin1-4/+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#123262 writerfilter: completely ignore footnote separatorsJustin Luth1-6/+12
... 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-17tdf#112202 writerfilter,sw: fix loss of headersMichael Stahl1-0/+5
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 Kaganski1-0/+5
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-08fdo#38414 tdf#44986: DOCX table import: handle gridBefore/AfterLászló Németh1-0/+3
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-06Related: tdf#115719 DOCX import: fix increased spacing vs left-aligned objectsMiklos Vajna1-4/+11
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-02revert obsolete writerfilter hacks for tdf#119054 and tdf#128752Justin Luth1-10/+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 Bergmann1-5/+5
...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-19tdf#119054 DOCX: fix not table style based bottom marginLászló Németh1-2/+9
in table cells, ie. using paragraph styles with bottom margin setting or direct paragraph formatting of bottom margin. Both of them overwrite the table style based bottom margin. Change-Id: I527b16c24fe47df8412291089ff86fadd3f9430b Reviewed-on: https://gerrit.libreoffice.org/82800 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2019-11-15tdf#128752 DOCX: fix partial direct paragraph spacing in tablesLászló Németh1-1/+4
When direct formatting of a table paragraph set only top margin, but not the bottom margin, also there was no paragraph style setting for the bottom margin, the paragraph was imported using docDefault bottom spacing instead of the table style bottom spacing. Change-Id: Ib7f5f80dd2485a0fd4ab8e0645b7d730a7ec3c5c Reviewed-on: https://gerrit.libreoffice.org/82771 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-11-07loplugin:unusedmethodsNoel Grandin1-1/+0
Change-Id: I65354c7476dfaede1a607441d7c1b0c7ad038df4 Reviewed-on: https://gerrit.libreoffice.org/82186 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-31tdf#125038 DOCX import: better support for linebreaks in IF fieldsMiklos Vajna1-0/+11
IF fields can't contain linebreaks, so instead of just calling finishParagraph() and hoping it does something sane, explicitly handle them: remember the properties and perform the call only once the field is closed. Change-Id: I676aa2c83f12cb600829177a0eb25558822b1d94 Reviewed-on: https://gerrit.libreoffice.org/81847 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-10-28Related: tdf#125038 DOCX import: fix unexpected MERGEFIELD result inside IFMiklos Vajna1-1/+1
The problem is that DOCX supports nesting MERGEFIELD fields inside IF fields, while SwHiddenTextField only supports a single string as a condition. This means in case there are MERGEFIELD fields inside the IF field, those fields will be inserted to the doc model before the IF field, exposing their value, while Word only uses their value during the evaluation of the IF expression. Fix the problem by inspecting the parent field command before setting the MERGEFIELD result. Change-Id: Ieca098f16f756bab5d23f219fa4ca30d077d4bb7 Reviewed-on: https://gerrit.libreoffice.org/81615 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-10-28related tdf#99602 writerfilter TODO: subscript - use CharStyle fontsizeJustin Luth1-1/+3
GetAnyProperty was missing a check for character style properties. This patch depends on commit 875793d841165aaaaefa2c34b855e8f0f8a8c214 related tdf#99602 writerfilter TODO: subscript - use ParaStyle fontsize and on commit 5e97d1a57717f8dbf69b987d2bda8616972eec52 NFC writerfilter: preparation for adding CharProps to GetAnyProperty Change-Id: I4e28589917e41fa545d5aab05f97a67502486136 Reviewed-on: https://gerrit.libreoffice.org/80216 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-10-28tdf#121441 improve DOCX footnote importJan-Marek Glogowski1-4/+13
ODF represents footnotes by using a fixed string for the label (text:note-citation) and a flexible body (text:note-body) for the representation in the footnote area. The only formatting of the footnote reference is done by changing the character class assigned to the anchor (which is the text range of the label in the text). For most of the setting, the footnote area label just follows the footnote body character formatting. OTOH MS Word has no such "restrictions". It handles the label just as concated, formated text runs with the same style. On top of it, DOCX completely splits the reference from the footnote area part, including its own label, which can easily result in completely different labels for the footnote and the reference, as I happened to repoduce for my test documents. At this point it's quite obvious that for any complex footnotes, LibreOffice won't be able to represent them. IMHO ODF should offer the same flexibility for the label and the body and allow all the normal formatting in the label. I'm not sure that getting footnote area and reference label out of sync is a good idea. So this patch tries to improve the situation in the current constraints set by ODF. 1. It imports all runs of the whole custom DOCX footnote label. 2. If any run contains a symbol, switches the font of the whole label to the referenced symbol font. 3. Completely ignores the label of the footnote area and overrides the font of the footnote area label with the font of the reference. Other problems I found while testing this code: 1. LO edit field correctly gets the font and character set, but displays empty glyphs. So no real way to edit the label. 2. Normally the font of the footnote area label would follow the footnote font. This doesn't work anymore when the font is overridden for the label. Setting the whole font of the label to Symbol doesn't seem like a good solution either. 3. You can't mix multiple fonts, or even symbols and letters, as you can just select one font for the label. 4. You can't change the footnote are label font at all and since it doesn't follow the footnote area anymore, there is basically no way to change it. Change-Id: Iafa16936be81e1866c610ebf0f71ab15e74dd059 Reviewed-on: https://gerrit.libreoffice.org/81370 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-06 17:56:46 +0000