summaryrefslogtreecommitdiff
path: root/writerfilter/source
AgeCommit message (Collapse)Author
2024-04-18move writerfilter inside swNoel Grandin
writerfilter wants to convert incoming RTF and OOXML files into writer's document model. But it currently has to do so by manipulating the limited subset that we expose through the UNO API. This is both slower and less accurate than having access to the full document model. So move it inside, and then we can strip out various hacks, and optimise imports. Change-Id: Ie1114d28130ef5f9a786531bc552cb8ee7768015 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165953 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-04-13Simplify a bit, and use more o3tl::convertMike Kaganski
Change-Id: I30f619b81d831db9c1e212a1588d5696b9ad3dd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166048 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-04-11tdf#132599 cui offapi sw xmloff: add hyphenation-keep-typeLászló Németh
Support XSL attribute "column" and CSS 4 attribute "spread", stored in loext:hyphenation-keep-type, to give better control over hyphenation-keep. E.g. spread: both parts of a hyphenated word shall lie within a single spread, i.e. when the next page is not visible at the same time (e.g. the next page is not a right page of a book). – css::style::ParaHyphenationKeep is a boolean property now, importing hyphenation-keep = "page" as true. – type of ParaHyphenationKeep, including the new non-ODF types is stored in the new ParagraphProperties::ParaHyphenationKeepType. – default value of ParaHyphenationKeepType is COLUMN for interoperability. – Add checkboxes to Text Flow -> Hyphenation Across in paragraph dialog: * Column (previously: Hyphenate across column and page) * Page * Spread – enabling/disabling them follows XSL/CSS 4/loext, i.e. possible combinations: * No Hyphenation across (hyphenation-keep = "page" and loext:hyphenation-keep-type = "column") * Hyphenation across [x] Column (hyphenation-keep = "page" and loext:hyphenation-keep-type = "page") * Hyphenation across [x] Column [x] Page (hyphenation-keep = "page" and loext:hyphenation-keep-type = "spread") * Hyphenation across [x] Column [x] Page [x] Spread (hyphenation-keep = "auto") – Add ODF import/export – Update DOCX import – Add ODF unit tests Note: recent implementation depends on widow settings: disabling widow handling allows hyphenation across columns and pages not only in table cells. Note: RTF import-only, but not used bPageEnd has been renamed to bKeep. Depending on the RTF test results, likely it will need to disable the layout change, e.g. GetKeepType()=ParagraphHyphenationKeepType::AUTO, if PageEnd uses obsolete hyphenation rule, i.e. shifting only the hyphenated word to the next page, not the full line. More information: – COLUMN (standard XSL value, defined in https://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#hyphenation-keep) – SPREAD and ALWAYS (CSS 4 values of hyphenate-limit-last, equivalent of hyphenation-keep, defined in https://www.w3.org/TR/css-text-4/#hyphenate-line-limits). Follow-up to commit 9574a62add8e4901405e12117e75c86c2d2c2f21 "tdf#132599 cui offapi sw xmloff: implement hyphenate-keep" and commit c8ee0e8f581b8a6e41b1a6b8aa4d40b442c1d463 "tdf160518 DOCX: import hyphenation-keep to fix layout". Change-Id: I3ac6d9e86d0ed1646f105de8607c0e8ebc534eaa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165954 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2024-04-09tdf#88214 sw: text formatting: adapt empty line at end of para to WordMichael Stahl
For an empty line at the end of an empty paragraph, Writer already uses any existing text attribute in the paragraph, see for example testEmptyTrailingSpans. For an empty line at the end of a non-empty paragraph, Writer text formatting uses only paragraph attributes, ignoring any text attributes, whereas the UI will display the attributes from the text attributes (such as font height) if you move the cursor there. Word uses text attributes also in this case, so adapt the inconsistent Writer behaviour: text formatting now uses text attributes too. Apparently this can be achieved by calling SeekAndChgBefore() instead of SeekAndChg(). Add another compat flag "ApplyTextAttrToEmptyLineAtEndOfParagraph" to preserve the formatting of existing ODF documents. Adapt test document fdo74110.docx, it has a line break with "Angsana New" font. Change-Id: I0863d3077e419404194b47110e4ad2bdda3d11c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165887 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-04-04tdf160518 DOCX: import hyphenation-keep to fix layoutLászló Németh
To fix layout interoperability, import DOCX compatSettings allowHyphenationAtTrackBottom and useWord2013TrackBottomHyphenation as hyphenation-keep setting "COLUMN", shifting last hyphenated lines of pages and columns, like MSO does. Follow-up to commit 9574a62add8e4901405e12117e75c86c2d2c2f21 "tdf#132599 cui offapi sw xmloff: implement hyphenate-keep". Change-Id: Ib2a06efc22a4f30d8f8be8a752460b09d09e97a3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165798 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2024-03-28tdf#158803 test for membership should be 'not in'LeSasse
Change-Id: I9ed1a2cb83cfd0be8298e7a90c7b4fb931c33528 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165369 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-25tdf#158556 speedup docx loadNoel Grandin
If we want to know if an XText is a header/footer object, no need to loop over the draw objects, we can just query its service name. Reduces load time from 167s to 97s Change-Id: I10158c11dd24c4945b3ea6cfed4916717bd4f2f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165269 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-22Relatted: tdf#160139 RTF paste: don't turn off headers/footersMiklos Vajna
Regression from commit d918beda2ab42668014b0dd42996b6ccc97e8c3a (tdf#158814 DOCX import: fix unwanted header with type="first" & no titlePg, 2024-02-05), pasting shape text into the body text of Writer turned off the header, which was not intentional. The original use-case was DOCX/RTF import, and the paste case was just not considered. Fix the problem by leaving the paste alone: we already omit a number of actions in this case (e.g. not overwrite styles), don't turn off headers, either. Note that the original problem is wider: we would probably need to track what page styles are created and only touch those, or something similar. Change-Id: If08fa7956e98766d5807332c5c0baa25b46afe38 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165191 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-03-21Revert "tdf#159730 add compatibility option in RTF import"Oliver Specht
This reverts commit 3b04e74503ec6d07dc4befdb756e6abdc3de4e58. Reason for revert: The compatibility option is the wrong approach. This results in wrong line calculation as seen in tdf#159730#c6. The problem that really needs to be fixed is the 9pt attribute of the hidden line breaks in the first paragraph that are used to calculate the height of the first paragraph. Only the 1pt font attribute of the remaining visible space should define the line height. Change-Id: I6e0a1a499adaf2df9f68afbcfd6afcd6677e8f76 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165006 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-03-13tdf#152878 switch off replacment image in picture frameOliver Specht
RTF documents may contain shapes of the type "Picture frame" ({\sn shapeType}{\sv 75}) that are imported as SdrGraphObj This change prevents the display of a replacement picture if there is no picture set. Change-Id: Ia3a576ddcb2a3bbffae859102d274d4ecd214f6c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164755 Tested-by: Jenkins Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-03-11GraphicImport.cxx: address nitJustin Luth
less emphasis on minimizing "if logic" and more emphasis on readability (especially since the comment comes after the logic). In the most common cases, this version should actually finish sooner to. Change-Id: I18cf760e806c53f6d32afadca8d127df2df89653 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164655 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2024-03-08tdf#142133: partially revert 576611895e5Xisco Fauli
if 'Internet Link' character style doens't exist then apply the hyperlink style This also reverts 023285158bde72dcd73b965ce205cf8550e7a5e2 "tdf#128504 save DOCX as ODT: don't color not highlighted hyperlinks" which is no longer necessary Change-Id: Id100af5fddb10745af9d56c0ba75cb2366ecbe55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164576 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-03-08tdf#160077 writerfilter: shape vertRelation is FRAME for layoutinCellJustin Luth
When layoutInCell is active, then the offset must be applied against the paragraph instead of the page or page margins. There were only two unit tests that matched this, and both were off-sheet positioned. -tdf151704_thinColumnHeight.docx -tdf92157.docx make CppunitTest_sw_ooxmlexport21 \ CPPUNIT_TEST_NAME=testTdf160077_layoutInCell Change-Id: I28241136c0c0be12d3f2dd876550ecdf91b0009c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164514 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-03-07tdf#160049 dml shape import: use margins with left/right HoriOrientRelJustin Luth
make CppunitTest_sw_ooxmlexport21 \ CPPUNIT_TEST_NAME=testTdf160049_anchorMargin Change-Id: I3e2df2037cabfedbb6df6b8c8257e90baeaab96e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164445 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2024-03-06tdf#160049 dml import: use margins with left/right HoriOrientRelationJustin Luth
I'm really surprised this wasn't found much earlier. Even DOC format isn't handling this. compat15 gets rid of this inconsistency. Surprisingly, there were no interesting unit tests matching this. make CppunitTest_sw_ooxmlexport21 \ CPPUNIT_TEST_NAME=testTdf160049_anchorMarginVML make CppunitTest_sw_ooxmlexport21 \ CPPUNIT_TEST_NAME=testTdf160049_anchorMargin15 Change-Id: Ic5c316569ad3640ba0e786d39a6e5c006c74d665 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164443 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-03-01NFC writerfilter GraphicImport: streamline if statementJustin Luth
The function is a const static, so it doesn't require being run. Change-Id: I31fb35e9daf54103071197e669c54818d4062264 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164172 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2024-03-01tdf#159158 writerfilter: headers always behind text (!opaque)Justin Luth
If the body-anchored thing is in the background, then if any header stuff was NOT in the background, then it would show up above the body thing, and that should not happen in a DOCX world. This test was not easy to produce. ODT kind of knows that headers are special, and so it tries really hard to put stuff in the background without any wrap - at least after a round-trip. So I had to hand-craft from my example DOCX that exhibited a behindDoc which actually had some wrapping component to it. make CppunitTest_sw_ooxmlexport18 \ CPPUNIT_TEST_NAME=testTdf159158_zOrder_headerBehind2 Change-Id: I31617cd7bf2d38add2233a7a06ffe9a8ec00ec0a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164130 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2024-03-01tdf#159158 writerfilter: headers always under other z-ordersJustin Luth
I guessed that a negative z-order will be below a positive relativeHeight when it is in the header. It seems like a reasonable assumption. No unit tests hit this situation AFAIK. make CppunitTest_sw_ooxmlexport18 \ CPPUNIT_TEST_NAME=testTdf159158_zOrder_headerBehind Change-Id: I06e31f3df413ad9c32791c8f4b940831630131dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164105 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2024-03-01NFC prepwork for tdf#159158: flatten writerfilter applyZOrderJustin Luth
limit code shuffle in the fix itself Change-Id: Ic506ac700403fa434dd6410e9ea566c6d0e19676 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164154 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2024-02-28Related: tdf#158986 sw floattable, RTF import: use more setNeedPar()Miklos Vajna
See <https://gerrit.libreoffice.org/c/core/+/163844/1#message-ea0bfde78fa24ad83e5c153ecaddbf897a89f547>, this keeps the bug fixed but is a better version, as pointed out by Michael S: > there was a bug where dispatching PAR here caused a deferred page > break to be lost, which was fixed by calling setNeedPar(true) instead. Change-Id: Ibe6e4c14286d40d3066ce9cb7fac9f6847fb81dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164081 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-02-28Related: tdf#150408 RTF filter: handle legal numberingMiklos Vajna
The bugdoc's 2nd para started with 'Sect I.01', while Word rendered this as 'Sect 1.01'. The reason for this difference is that there is an "is legal" boolean property on the numbering that we ignored from RTF during import/export. Fix the problem by extending RTFDocumentImpl::dispatchTableSprmValue() for the numbering table import + RtfAttributeOutput::NumberingLevel() for the export. The import default for this value was also wrong, given that the default is to enable it when the control word is present. Change-Id: I4dcd23768000ba29d4df314b475b412bb371545e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164078 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-02-27address nit: use oox::drawingml::PER_DEGREE instead of 60,000Justin Luth
Change-Id: Ie3ca5a76376a3c26f0d3079b6e819ec29afd2c17 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163968 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-26tdf#158986 sw floattable: fix RTF import of table followed by \sectMiklos Vajna
The bugdoc had a floating table, immediately followed by a section break. The floating table went to the second page, should be on the first page. The trouble is that RTF's section break is just a special symbol, so we can have a section break right after a floating table. This is in constrast with DOCX where a non-last section break is a paragraph property, so it's guaranteed to have at least a paragraph start after a floating table and before a section break, which can nicely serve as an anchor point for the floating table. Fix the problem similar to what the OOXML tokenizer did in a similar case in commit 01ad8ec4bb5425446e95dbada81de435646824b4 (sw floattable: fix lost tables around a floating table from DOCX, 2023-06-05), by injecting a paragraph before the section break. Handling this at a tokenizer level seems to be the right place, since the DOCX version of the same document was already imported OK. Change-Id: Ic945c472c08ba872a5c46e2b8f75e919678aa0a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163929 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-02-24tdf#126533 rtf import: page background fillJustin Luth
I worked on this mainly to see what the impact of the docx changes would be on RTF. It seemed to be OK. This patch shows that RTF can now import gradient page backgrounds. It does NOT import image backgrounds (at least no the ones I tested) because they were specified as XML_sn: fillBlip XML_sv: <shape_as_text_string> which is an unknown property in RTFSdrImport::resolve. The only fill type that RTFSdrImport::resolve knows about is XML_gradient. The only existing unit test I noted was page-background.rtf Change-Id: Ie40b91468d21b29a102472c859cd1eecfcb2a5f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163199 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2024-02-23related tdf#159824 RTF import/export gradient angleJustin Luth
The fillAngle is important for obvious visual reasons, but also significantly because a negative angle means that the start/end colors should be swapped (which is the normal case since LO's 0 degree angle == -180 VML/RTF angle). There were no existing unit tests with a "fillAngle" specified, or with a non-180 angle (0 VML/RTF angle) in LO. make CppunitTest_sw_rtfexport8 \ CPPUNIT_TEST_NAME=testTdf159824_gradientAngle1 make CppunitTest_sw_rtfexport8 \ CPPUNIT_TEST_NAME=testTdf159824_gradientAngle2 make CppunitTest_sw_rtfexport8 \ CPPUNIT_TEST_NAME=testTdf159824_axialGradient Change-Id: I4bb2c47bd2a79833d11bedac72ba2152b65b7c73 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163714 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2024-02-22SAL_WARN->INFO in CellMarginHandler::lcl_attributeNoel Grandin
this has been here since commit 6a9e4e77e83875ecce3b387736f6dd1ea221ced8 Author: Rüdiger Timm <rt@openoffice.org> Date: Fri Apr 18 11:11:49 2008 +0000 INTEGRATION: CWS xmlfilter04 (1.1.2); FILE ADDED and is very noisy, but does not seem to indicate a problem, given the lack of changes here. I added an assert here, and I saw all of: case NS_ooxml::LN_CT_TcMar_top: case NS_ooxml::LN_CT_TcMar_left: case NS_ooxml::LN_CT_TcMar_bottom: case NS_ooxml::LN_CT_TcMar_right: Change-Id: Id698f2344844c1335edac981023228be7e27da7e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163711 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-21tdf#158360 - sw, ooxml import - fix insertTextPortion crashBalazs Varga
Before this patch da8dead8e9282010893cbd12519e107baf03cd1a SvxUnoTextBase::insertTextPortion returned an empty XTextRange in case of texts in comment. (SwTextAPIObject) Lets use finishParagraphInsert which also give back an empty XTextRange. regression from commit: da8dead8e9282010893cbd12519e107baf03cd1a (tdf#73537 - sc: show author and creation date in calc comments) Change-Id: I0b33e5b3cae32718a62a7be04b9a88562f85652c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163670 Tested-by: Jenkins Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2024-02-21tdf#159815 DOCX import: fix redlined to-char image followed by inline SDTMiklos Vajna
The 2nd para of the bugdoc has a leading word, then a redlined anchored shape, finally a redlined checkbox content control. The Writer import result's content control starts at para start, while it should only start after the anchored shape. What happens is that writerfilter::dmapper::DomainMapper_Impl::PushSdt() gets called to remember the SDT start, then DomainMapper_Impl::applyToggleAttributes() deletes some content since commit 8726cf692299ea262a7455adcf6ec25451c7869d (tdf#142700 DOCX: fix lost track changes of images, 2021-07-08), which invalidates the SDT start position, finally PopSdt gets called, but that fails because our start position is no longer valid. This used to abort the import process. Since commit 1b0f67018fa1d514ebca59e081efdd24c1d7811b (docx import: correct redline content-controls, 2024-02-20), the import finishes the but start of the SDT is incorrect: it's at the para start, while it should start in the middle of the paragraph. The direct reason for the invalidation is a call to SwXTextRange::Impl::Notify(), which is from a content deletion from applyToggleAttributes(). Fix the problem by not deleting content when we're past PushSdt() and we haven't called PopSdt(): extract the redlined anchored shape code into a new DomainMapper_Impl::MergeAtContentImageRedlineWithNext() and call that also in DomainMapper_Impl::PushSdt() early, so it won't be called when we're in the middle of an SDT. This way createTextCursorByRange() should not fail, so warn in case it still fails in DomainMapper_Impl::PopSdt(). Change-Id: Ic4198804a92088ec268203d44c0da2d6997754b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163678 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-02-20tdf#153196 writerfilter: fix page style for even/odd section breakMichael Stahl
This is a bit of a special case, where the first section starts with an evenPage break (\sbkeven), which causes a Left-only page style to be created. In completeCopyHeaderFooter(), the HeaderTextFirst and FooterTextFirst are copied from the source style to the Left-only page style, but then they also need to be deleted from the source style, because the Left-only page style is the one that is used for the first page of the section, and the source style is used for the subsequent pages. Additionally, when there is *only* a "first" header/footer, and no previous section has one to inherit, Word will not display a header/footer at all on subsequent pages; a PageStyle will always have a header/footer if it has a HeaderTextFirst/FooterTextFirst. In this case, delete the header/footer from the source style. Unfortunately exporting this doesn't work ideally, a spurious evenPage footer will be created, both due to the FooterShare being automatically reset for no obvious reason in ItemSetToPageDesc(), and setProperty("FooterIsShared", true) "stashing" the left footer since commit b802ab694a8a7357d4657f3e11b571144fa7c7bf. (presumably regression from commit b32881b6723072c8d1a652ea147d12e75766d504) Change-Id: Ie4f9c49605df690e9705e14777c0e4bcb0dfad8e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163668 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-20Fix typoAndrea Gelmini
Change-Id: I6a4cb5143d964408955749822c71d8dcb88f7d14 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163664 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-02-20docx import: correct redline content-controlsAshod Nakashian
When inserting and deleting content-controls with change-tracking enabled, we hit a few corner-cases that we need to handle more smartly. First, we shouldn't redline the controls themselves, just the placeholder text. Second, we have to take special care to create valid XML structure with the redline tags. Includes unit-test that reproduces the issues and verifies that both saving and loading work as expected. Change-Id: I6af4d0d2c3f0661e7990d5414cc93effc96f0469 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163647 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-20tdf#126533 docx import: page background vml fillJustin Luth
This patch imports bitmaps/tiled textures (primarily), but also somewhat for gradients (because of a gradient2 -> gradient mismatch somewhere) and somewhat for patterns (because patterns are not well imported in general). Note that the imported fill likely will NOT match MSO, because their background CHANGES BASED ON THE ZOOM LEVEL. For example, my primary testing file (A6 landscape) has a logo which is only 25% visible in Word 2003 at 100%, but shows 90% of the logo at 200%, and many tiles of logos when exported as PDF. The same is true for gradients etc. Changing background on zoom is an absolutely bizarre implementation, and naturally LO could only accidentally look identical (and should never try to do so). make CppunitTest_sw_ooxmlexport21 \ CPPUNIT_TEST_NAME=testTdf126533_noPageBitmap make CppunitTest_sw_ooxmlexport21 \ CPPUNIT_TEST_NAME=testTdf126533_pageGradient This is slightly ugly, but I don't know how to make a COPY of the XPropertySet UNO junk. All I have is references, and dispose deletes everything, even the references. I took some inspiration from RTF which just disposes the shape after grabbing the background color. Thus, just change the page style known to exist and be used, and then simply remove the fill if it isn't needed in the end. Any new page styles can just copy the default page style fill. Change-Id: Id3ea002c685642ff4c289982d0108247a6e9bb8d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162958 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-19tdf#159254 fix import of printer tray in docxOliver Specht
Change-Id: I9f3835800c921dbc90ef09a8dfa3001bed74d2d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163589 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-02-16tdf#159730 add compatibility option in RTF importOliver Specht
Set IgnoreTabsAndBlanksForLineCalculation in RTF import to improve formatting. Change-Id: If0129f748c48400f1dd882672b5779f62e685ecd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163429 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins
2024-02-15tdf#158597 writerfilter,sw: fix toggle properties in ListAutoFormatMichael Stahl
... for DOCX import. These can be set both via paragraph style and via character style in the w:pPr/w:rPr, so use the applyToggleAttributes(). Adding a test for this requires adding the "CharStyleName" property to GetAutoCharStylePropertyMap(). Change-Id: I9701d5ac82ec3e7757650c08861791dc398a1a77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163386 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-14tdf#145539 convert const char[] in files to constexpr OUStringLiteralvarshneydevansh
OStringLiteral represent read-only memory for string literal while OUString is a dynamic string class with reference counting hence use OUString when you need reference counting, string manipulation along with _ustr suffix. Change-Id: Ib566df156d81c7527f5650bcc6bd5db6509128cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162911 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2024-02-13tdf#155663 writerfilter: RTF import: don't lose \piccrop*Michael Stahl
For DOCX the a:srcRect is imported in oox module in BlipFillContext and set on the XShape; obviously that doesn't work for RTF. The crop was already taken into account in RTFDocumentImpl::resolvePict(), but only to set the size of the picture; to actually set a crop effect, set shape's "GraphicsCrop" property in dmapper::GraphicImport::lcl_attribute(). Change-Id: Ib12853724744542a09b0073fefc42ad32bb2ff19 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163310 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-13tdf#159453 sw floattable: fix unexpected overlap of in-header fly and body textMiklos Vajna
Regression from commit e2076cf7a92694bc94bdc9f3173c2bddbe881a89 (tdf#155682 sw floattable: fix DOCX with big pictures causes endless loop, 2023-10-25), the bugdoc's body text was wrapping around the floating table from the header, while the expectation was that the top of the body frame is below the bottom of the header frame. It seems IsFollowingTextFlow is only needed when the relation of the floating table is not "page", and this bugdoc has has an examplicit vertical relation of page. Solve the problem by limiting the IsFollowingTextFlow=true request for the floating table to the VertOrientRelation=page case, which fixes the bugdoc and keeps the old use-case working. The doc model for the new bugdoc now matches the WW8 import result. Change-Id: Ia3da65cd52d70b357e448a26a50ffb92a39795e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163290 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-02-12tdf#158983 writerfilter: RTF import: fix page breaks and shape anchorsMichael Stahl
Somehow, not sure why, the added import of \wrapdefault in commit 86c0f58b6f9f392865196606173d1b98a6897f32 caused the page break in fdo55504-1.rtf to get lost. The first problem is that there is a \sbknone before the first \sect - this should not have any effect before \sect because \sbk* affect the *previous* section break, but it's not an option to simply ignore it (even if it works for this bugdoc) because it may be that there is no \sectd after \sect and then it will have an effect for the later section. The problem was in handling \page: here the premature \sbknone caused a sectBreak() which ate the page break; ignore it here by checking m_bHadSect. The second problem then was that now all but the first shape were anchored on page 2. This was because RTFDocumentImpl::beforePopState() for \shape of the 1st shape called parBreak() and that set the bIsFirstParaInSection flag. This flag prevented DomainMapper::lcl_utext() in the "if (m_pImpl->isBreakDeferred(PAGE_BREAK)) if (GetSplitPgBreakAndParaMark())" branch from inserting another paragraph break that is necessary to preserve the already inserted shapes anchored to the 2nd paragraph on page 1. (This is how it works for the equivalent DOCX document, with settings.xml edited to add w:splitPgBreakAndParaMark and remove "compatibilityMode" etc. because Word 2013 doesn't set these correctly.) The consequence is that when the second SwTextNode is converted to a text frame, all the shape anchors move to the next paragraph, the one with the RES_BREAK on it. Fix this by limiting the parBreak() handling in RTFDocumentImpl::beforePopState() to when the shape is a SwGrfNode, which is the scenario in the commit 0d9132c5046e15540abc20e45d64080708626441 "fdo#47036 fix RTF import of shapes inside text frames at the start of the doc" - the testFdo47036 fails if the block is removed completely. This caused 2 test failures, but both cases look the same as in Word 2013 now: Test name: (anonymous namespace)::testTdf158826_extraCR::Load_Verify_Reload_Verify An uncaught exception of type com.sun.star.uno.RuntimeException - unsatisfied query for interface of type com.sun.star.text.XTextTable! rtfexport2.cxx:537:Assertion Test name: (anonymous namespace)::testFdo47495::Load_Verify_Reload_Verify equality assertion failed - Expected: 2 - Actual : 1 Change-Id: I43fa9431721650a6d748d1f4bda9aeaa7a9c6b45 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163200 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-08tdf#159478 read field comment in default encodingOliver Specht
If a symbol font is applied inside a field the command string was wrongly converted as symbol text. This is fixed by using a default RTL_TEXTENCODING_MS_1252 encoding. Change-Id: I11326ef3c79d6d74c720a2b4ac4987ee6716d912 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162844 Tested-by: Jenkins Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-02-08tdf#158586 writerfilter: RTF import: fix assert on ooo113308-1.rtfMichael Stahl
warn:legacy.osl:::writerfilter/source/dmapper/DomainMapper_Impl.cxx:1278: section stack already empty DomainMapper_Impl.cxx:9817: void writerfilter::dmapper::DomainMapper_Impl::substream(): Assertion `m_aContextStack.size() == contextSize' failed. Before substream(), there is one CONTEXT_SECTION, after there is an additional CONTEXT_PARAGRPAH. The first OSL_ENSURE is because RTFDocumentImpl::tableBreak() calls endParagraphGroup() but in the substream, startParagraphGroup() hadn't been called; fixing this also makes the assert failure go away. This worked previously because sectBreak() called endParagraphGroup() after reading the header substreams, but it seems dubious that a paragraph group started in the body should be used in the substream. (regression from commit 57abad5cf990111fd7de011809d4421dc0550193) Change-Id: I98864bca03b59099c17080c0a7582de2b77d41e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163096 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-06writerfilter: move these members to FieldContextMichael Stahl
Change-Id: I7449c7e7bb2a54ca0fdfe2bcb67009f76fbb1d13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163055 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-06writerfilter: move even more members to SubstreamContextMichael Stahl
Change-Id: I5d080353075b17d8752ad6509240f77563c4306f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163053 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-06writerfilter: move yet more members to SubstreamContextMichael Stahl
Change-Id: I708375204226fbad502155f4d2efc81ecc206a31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163052 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-06tdf#158409: RTF import: use current run props for fieldsVasily Melenchuk
Fields import was not using current run properties causing fallback to used style or default style what is wrong for RTF. Change-Id: I0189c6122b703a23ff910ee38da78aa05ac4d9f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160387 Tested-by: Jenkins Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
2024-02-06writerfilter: move more members to SubstreamContextMichael Stahl
m_bIgnoreNextTab can be removed altogether, it is only set to true in one place and immediately checked and reset in the next 2 statements. Don't move m_bHasFtnSep, somehow breaks lots of tests. Change-Id: I24bcb3ced839d2c87a367e8a1bcd7664361f9975 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163042 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-05tdf#158814 DOCX import: fix unwanted header with type="first" & no titlePgMiklos Vajna
The bugdoc had no header in Word, but had one in Writer, since commit 17e51f427b3f0cec74ac8e0a1b3f51189006ae6f (DOCX import: first page header should always set default headers as well, 2014-11-21). The code has changed a log in the meantime, today we import first page headers and left/right page headers as a single page style, but still code was missing to detect the case when <w:headerReference w:type="first"> was not followed by <w:titlePg>, which is an indicator that the first page header/footer should be used. Fix the problem by new flags to SectionPropertyMap to track if we ever seen a first/left/right header. This allows making an informed decision in SectionPropertyMap::setHeaderFooterProperties(): if the header is on, but we effectively don't have none of a first, left or right header, then it's time to turn it off, similar to what the DOC import does. Note that this only changes behavior for headers, but if there is a practical need, then the same could be also done for footers as well. Instead of adding a new test, notice that testTdf112694 in CppunitTest_sw_core_header_footer explicitly tests this case: a first header which is not a title page. So change that testcase to assert the behavior now matches Word and drop the FIXME. Change-Id: Ib604e786d7a5a197d4b562533326206697de882a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162992 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-02-02writerfilter: fix missing paragraph break on tdf136445-1.rtfMichael Stahl
This causes an assert: crossrefbookmark.cxx:44: sw::mark::CrossRefBookmark::CrossRefBookmark(): Assertion `IDocumentMarkAccess::IsLegalPaMForCrossRefHeadingBookmark(rPaM) && "<CrossRefBookmark::CrossRefBookmark(..)>" "- creation of cross-reference bookmark with an illegal PaM that does not expand over exactly one whole paragraph."' failed. The problem is that there is an annotation at the end of a paragraph, and reading the annotation changes various members of DomainMapper_Impl, in particular m_bParaSectpr and m_bParaChanged, causing "bRemove" in DomainMapper::lcl_utext() to be erroneously true, removing the just inserted paragraph break again. Move all flags that are evaluated for bRemove to SubstreamContext. This causes one test failure, but it turns out that the new result is the same as in Word 2013. Test name: (anonymous namespace)::testTdf108947::TestBody equality assertion failed - Expected: Header Page 2 ? - Actual : Header Page 2 ? (regression from commit 15b886f460919ea3dce425a621dc017c2992a96b) Change-Id: I44a7a8928ab04c600d4d3c43bc4e4deeafe57d89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162932 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-01writerfilter: replace members w/ SubstreamContext::eSubstreamTypeMichael Stahl
This should not change any behaviour. Change-Id: Ic970f0e1b6401119d875c9e811589b9c210e0c34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162842 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-01writerfilter: move m_bFirstParagraphInCell to SubstreamContextMichael Stahl
This is a change to set it for all substreams. Change-Id: I44ed9a5485000f40f8ccfe3ec885ef8f05f5aab2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162841 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>