summaryrefslogtreecommitdiff
path: root/xmloff
AgeCommit message (Collapse)Author
2023-11-10warn about exotic protocols as wellcp-23.05.5-4Caolán McNamara
Change-Id: I50dcf4f36cd20d75f5ad3876353143268740a50f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158902 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-11-10Fix STYLEREF crashes and forwards-compatibilitySkyler Grey
This commit fixes a crash in STYLEREF caused by a dereferenced nullptr when serializing chapter fields for .doc export. Along with the STYLEREF changes, I also changed the chapter export logic to allow exporting chapter fields when they were in document text, and to use the style of the thing they pointed to. Unfortunately, in some cases that would be null. This commit makes us fall back to previous behavior in those cases. This commit also adds import logic for styleref on the TEXT namespace in addition to LO_EXT. This is important as if/when the STYLEREF field is no longer LO_EXT we want to be able to open new documents in old versions of libreoffice. This was erroneously missed when we changed TEXT references to LO_EXT in our export logic. Change-Id: I383828c9409afc8545af379307f528cee2e1a960 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159230 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-10-25tdf#157663 SW: Tracked change improve moveAttila Szűcs
Made accept/reject handle move redlines other pair, (moveto-movefrom) and handle the whole move redline, even if it is split into small pieces that separated from each other. Added unique ID to every move redline to help find their other parts. This move ID is generated in case of: move recognition moveing a paragraph. (directly create move redline with unique id without calling the recognition it is faster and more stable) (there are other cases that could be improved to not use recognition, but generate ID directly, like moveing selected partial text with mouse) Implemented the odt export/import of this move ID. it is a tag like this: "<loext:move-id>4</loext:move-id>" next to creator/date Improved the docx import to generate this move ID, so move redlines can find their other parts (Not changed Docx export... it works a bit, but far from perfect) Improved move reckognition: It can find them even if they are split into multiple parts differently. (like "ab"+"cd" == "a"+"bcd") Disabled this because of probably performance issue. made a complex unit test for it. Note: Left the move recognition on every place, to avoid as much regressions as possible.. but in the future, we may can disable it in some cases. Note2: We will have to keep move recognitnion, because there are documents from past, saved without any move informations in the file, and users expect to see move redlines there. (generated by the recognition.) Change-Id: If968d4235b676c5e538cfaf4187a4482a86eae9f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157740 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-10-25Enable STYLEREF flag export/import with ODFSkyler Grey
This commit enables exporting the following STYLEREF flags with ODF - Search from bottom to top - Hide non numerical After this commit, the following steps have been implemented - The document model (I7d8f455ffe90cface4f3b1acf6b9bef6a045ed19) - The layout (I7d8f455ffe90cface4f3b1acf6b9bef6a045ed19) - The UI (I7d8f455ffe90cface4f3b1acf6b9bef6a045ed19) - UNO (Ib664fec059aa1f7f130acc76c253d5d298fa59f7) - DOCX/ODF filters (here and Ib664fec059aa1f7f130acc76c253d5d298fa59f7) Change-Id: Iad8e8001807f5ceeaedc9665838672695174a936 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158265 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-10-19Add tests for STYLEREF and fix STYLEREF bugsSkyler Grey
- testTdf86790 tests that the "sample file with STYLEREF" document from tdf#86790 has the correct fields - testStyleRefSearchUp tests that the STYLEREF searches up when there are bits of text both above and below it - testStyleRefSearchDown tests that the STYLEREF searches down when there are bits of text below it only - testMarginalStyleRef tests that the STYLEREF searches from the page top when it is placed in a footer - testFootnotetyleRef tests that the STYLEREF searches from the reference mark when it is placed in a footnote - As an artifact of changing the STYLEREF namespace from TEXT to LO_EXT partway through, some references to STYLEREF being in TEXT still remained. This caused STYLEREFs saved to ODF to vanish on import. This has been fixed - Previously STYLEREF kept a pointer to the frame and text node containing it. Unfortunately, sometimes these could be destructed and the STYLEREF later asked to update which led to a crash due to use-after-free. STYLEREF no longer keeps a pointer to these values, instead preferring to not update when it is not given them - As part of the review process for I25dd7a6940abee5651a784b9059fe23b32547d6c we added SearchForStyleAnchor, a function used only in reffld.cxx, to an anonymous namespace. Unfortunately we neglected to do the same for StyleRefElementType just above it. This has been fixed Follow-Up-To: I25dd7a6940abee5651a784b9059fe23b32547d6c Change-Id: I35dc36197b62fa53def4745da1d4755ece79ed22 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157911 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-10-13tdf#86790: Add support for a word-style stylerefSkyler Grey
STYLEREF is a field type in Word which changes its content based on nearby paragraphs. For example, upon creating a styleref referencing "Heading 1" you will see the text of the nearest "Heading 1"-styled paragraph that is above the field. This patch implements STYLEREF in Writer as a cross-reference. By using "insert>cross-reference>styles" you'll be presented with a list of styles. Selecting one and clicking "insert" will create a field which has text from the "most relevant" instance of the style. To find the most relevant instance we first search up for paragraphs with the style, and if there are any we take the closest. If there weren't any, we search down for paragraphs with the style. This patch also updates our use of STYLEREF for chapters exported to docx by using it for all chapters not only those in headers and footers. This allows us to approximate more chapter field functionality even when moving between Writer and Word. Still TODO: - [ ] Update documentation - [ ] Implement reverse-searching (\l) and nondelimiter suppression (\t) - Probably these 2 will be in a followup patch Change-Id: I25dd7a6940abee5651a784b9059fe23b32547d6c Signed-off-by: Skyler Grey <skyler.grey@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156912 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-09-18add referer to ole objectsCaolán McNamara
so we can identify what document is requesting their contents extends: commit 5668e73beb30b95abc6520b7432c54972ca3ab2c Date: Wed Nov 20 14:43:45 2013 +0100 avmedia: Implement "block untrusted referer links" feature See f0a9ca24fd4bf79cac908bf0d6fdb8905dc504db "rhbz#887420 Implement 'block untrusted referer links' feature" for details. This adds some further /*TODO?*/ comments, and one known problem (marked /*TODO!*/) is that movies/sounds are not blocked during a slideshow presentation. to these objects too, namely OLE2Shape and derivatives AppletShape, FrameShape and PluginShape so in paranoid mode we won't load the contents of such objects from documents considered "untrusted". Change-Id: I6d988035d0cd09fd3fade5f6885fe336c95579ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156599 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2023-09-06xmloff: rename m_aObject in XMLThemeContext and clarifyTomaž Vajngerl
Clarify what m_aObject is in the theme import (XMLThemeContext) and rename to a better name. It is refering to an object that has the "Theme" property, which is usually found in on XPage (master page) or XModel, but technically could be any object that has the property (for getting and setting the XTheme type). Change-Id: If15a8c42a0c516cd0566f4ee9e81f7315ef1651e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156511 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit ca120667c3855fbfc1e3579d4cf4ed0e3b93770a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156545 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-09-05drop a stray printfCaolán McNamara
Change-Id: Ie9b48ab2db03c7c45aa4ffc24ca4532522bb60a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156547 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-09-05Added test case to comment property test.Gökay Şatır
Signed-off-by: Gökay Şatır <gokaysatir@gmail.com> Change-Id: I033f6574b4875fcb76b16c8b5b9d9f7d55b52cbe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156406 Tested-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-09-05Added parent / child relationship to comments.Gökay Şatır
Adding parent name of a comment into odf file when there is a parent. Signed-off-by: Gökay Şatır <gokaysatir@gmail.com> Change-Id: I08b5ab6eb11adcafcbf3559896d79d41b449b26a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156391 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Miklos Vajna <vmiklos@collabora.com>
2023-09-04sc: add ODF import/export of the Theme + testsTomaž Vajngerl
One missing thing is the support in calc to save the Theme into the ODS document and read that back. The theme element is added as a child element to the office:styles - the same as it already is added in Writer. Also adds "Theme" property as a top level document property so it is possible to get and set the theme in xmloff. Also tests have been added to cover this usecases. Change-Id: Ic214ff5e945b77d50e6c881def9d49509560a0e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156363 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit b36f7769dd07a6b6f55cdf4ce76e2f39ed186e89) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156456 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-09-04move theme element export to xmloff to remove code duplicationTomaž Vajngerl
Both Impress/Draw and Writer export the model::Theme in a similar way, but the code is duplicated. Remove duplication and move the code to a common place (on the SwXMLExport class) so it can be reused at both places. Change-Id: Id93acfafb0dd4ab0168b3228079f6ce6f64e6b55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156362 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit b53a03d1d55de7fd04efc47c4a57baa11d72dd85) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156455 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-08-31tdf#157018 Enable import of color theme for DrawRegina Henschel
Use the color theme import in Draw too, otherwise we will not be able to detect theme colors. Change-Id: I8f01ba69848a6265193407a952144b31e3a7fdb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156313 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit b8eebad5c7d9311b3007f6717e72e96634e57c05) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156370 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2023-08-31tdf#156975 Save a Theme in Draw too not only in ImpressRegina Henschel
Draw and Impress have many things in common and should therefore be treated equally where possible. Only if the theme colors are present in the document, colors can be recognized as theme colors during import. Change-Id: Ia1fae2aff989ae305c210efa3f925a80898880e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156267 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 6cdafbe4043ac98f94feda87318db44ffebba7d2) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156224 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2023-08-28xmloff: support stroke/line complex color import/export + testTomaž Vajngerl
Change-Id: I4ed901fd5b23e58aafa781e2b07f460f034fbba3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155685 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 9d1140cb745613625bbd8af251c778a7c789e6d0) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156162 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-08-28ComplexColor various clean-up and (trivial) refactoringsTomaž Vajngerl
Don't allow access to member variables of ComplexColor and makes them private. Needs a lot of changes. Change "scheme" to "theme" to be more consistent. In LO we usually call the "theme color" what is usually refered to as "scheme color" in OOXML, where it is sometimes refered to as "scheme" and other times as theme color. Remove ThemeColor class which was replaced with CmplexColor some time ago. Remove un-needed includes and un-needed components. Use isValidThemeColor in many places where we check that the ComplexColor is of "Theme" type and that ThemeColorType is set to a valid value. Change-Id: I325595fa65b8e56a4707e9d22acc6330aac28961 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155359 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 9d5a7d9257db78eb3f4d77c39eae1affe877ea6b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156150 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-08-28sc: theme color support for sparklines + ODF & OOXML import/exportTomaž Vajngerl
This changes Sparkline colors to use complex colors instead and adds Sparkline theme color import and export support for ODF and OOXML. Change-Id: I58edd525d50f95199bd4fe7825afb51aaa7fc091 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155113 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit c8d8bf4282cbd04abacfa69ba2cc0fa4300e35e1) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156106 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-08-28sc: Add import/export ODF support for border complex colorsTomaž Vajngerl
ODF Import and export support for border {left,right,top,bottom} complex colors. In addition round-trip test was extended with the border use case. Change-Id: I1d14690272c06e8ffcfcd483eb7f688ca5bb1e5d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155014 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 5e34a25aa7f58b37a2303aef9318bbe5a9af5d37) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156101 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-08-28xmloff: fix import of CharComplexColor - add StylePropertiesContextTomaž Vajngerl
Import of CharComplexColor in Calc didn't work because the class XMLComplexColorContext wasn't used. This introduces a new class StylePropertiesContext, because the plain SvXMLPropertySetContext is not enough as we can't define to use XMLComplexColorContext when XML_CHAR_COMPLEX_COLOR is used on that class. Also adds a import/export test for CharComplexColor. Change-Id: I765ac71a801a5e9bcb105aaea73637df5e601b85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155008 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit b543463f639ecee793484e8b419147d565a53d52) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156100 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-08-28sc: ODF import/export of background cell complex colorTomaž Vajngerl
Change-Id: Idf526aea21ccfeda9b03d1fb69588f120b6e161d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154571 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit dceeb9550dfd4e40e93180b7e10f2539b594529f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156099 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-08-28xmloff: move XMLComplexColor* import/export classes to public includeTomaž Vajngerl
Change-Id: I52aad31f63858eba905481812cbf971493252642 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154570 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 2455826917868a5da5ab1bb4586e067d6c968c43) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156082 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-07-11tdf#150408: Implement "Legal" numbering (all levels using Arabic numbers)Mike Kaganski
Enabling this feature on a list level makes all numbered sublevels, that constitute the number of this level, to use Arabic numerals. This doesn't change the labels of other levels: e.g., if level 1 uses A,B,C; level 2 uses i,ii,iii; level 3 uses a,b,c, and is "Legal"; and level 4 uses 1,2,3; then a list may look like A. Something A.i. Some subitem A.ii. Another subitem 1.2.1. This is a "Legal" sub-subitem A.ii.a.1. And its child This improves interoperability with Word. This change introduces document model, ODF and OOXML import and export. In ODF, a new boolean attribute of 'text:outline-level-style' element, 'loext:is-legal', is introduced; its default value is "false". Change-Id: I5ae9f970864854c7e84c4b2f7ce46634b3ef104e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154288 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154332 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-07-08tdf#133560: re-anchor objects, to use paragraph's dispose for bEndOfDocumentMike Kaganski
1. During import, XParagraphAppend::finishParagraph(Insert) are called, which are implemented using SwXText::Impl::finishOrAppendParagraph, and the latter calls m_pDoc->getIDocumentContentOperations().AppendTextNode( *aPam.GetPoint() ); // remove attributes from the previous paragraph m_pDoc->ResetAttrs(aPam); so that there is always another (empty) paragraph after the finalized one; 2. During import, lcl_AddRange is called to create anchored text content; the start and end of it may reference the very end of the document (using xTextAppend->getEnd()) - i.e., that last (maybe empty, maybe extra) paragraph. 3. In many places, and in particular, in DomainMapper_Impl destructor, DomainMapper_Impl::RemoveLastParagraph is called; and the latter uses one of the two techniques to remove that last paragraph: 3.1. It either obtains the paragraph's lang::XComponent interface, and calls its dispose (SwXParagraph::dispose), which eventually calls DocumentContentOperationsManager::DelFullPara; 3.2. Or it uses cursor to select 1 ch back, and replace the resulting selection with nothing. 3.1 has an advantage of keeping the formatting of the remaining (second- to-last) paragraph, but DocumentContentOperationsManager::DelFullPara, among other things, removes all anchored objects, thus this mode is not used for the end-of-document case (e.g., see commit message of commit e521930ea1c855c236efb67793e540d07c201d35 "fdo#58327: writerfilter: RemoveLastParagraph is tricky:", 2013-01-10); 3.2 keeps the anchored objects, but needs workarounds to keep bookmarks, and destroys the remaining paragraph character formatting. Let me try to use #3.1 also in the end-of-document case, by introducing code to move anchored objects to previous paragraph before calling XComponent::dispose. Indeed, it may happen that more processing could be needed, if more properties would happen to be bound to the very last extra paragraph. This change adds a call to DocumentRedlineManager::CompressRedlines in DocumentContentOperationsManager::DelFullPara, because previously, this was called during #3.2 inside setString. testTdf150086 failed without this change. testTdf131386 and testTdf152872 were changed to the now-correct import of last paragraph properties (previously both of them relied on the hidden property not present there, while it is there in Word). In DomainMapper_Impl::RemoveLastParagraph, the check of the content of selection made by moving backward one character was generalized to be run before both cases, because RTF sometimes has only one paragraph after a table (see e.g. testTdf148515), which now could be removed in the absence of the check. testTdf104390 was changed to not check the number of runs, because now the paragraph keeps the trailing "paragraph mark formatting" empty run, which previously was dropped using setString path. Also, the fix for tdf#148273 is re-implemented here, by dropping RES_PARATR_LIST_AUTOFMT in lcl_RstAttr. Likely keeping it was an unintended side effect of placing RES_PARATR_LIST_AUTOFMT inside RES_PARATR_LIST_BEGIN/END. After the change, explicit drop of it will be not needed at arbitrary boundary, which is section break; this property should only be applied where it's defined. This change can't be done separately, because of interrelated unit test failures left and right. In XMLParaContext::endFastElement, setting ListAutoFormat property must be set only after setting style now, because otherwise it will be reset in lcl_RstAttr when the style is set. Some test documents were modified, to drop font from the last paragraph properties, because their respective tests started to crash (see commit 172270a8f04388a8f8062f672f9c3f3144a01a1f "abort writer layout tests if a font isn't found", 2022-05-01). Before this change, these paragraphs had lost their formatting, so those fonts weren't used in layout. Change-Id: I7e41c20e68e24c78fae1d2005c3fd75fb146ba2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153481 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit fc1b9ab2913bc8c2d8414b6d8de3ceed3910c5d8) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153520 Tested-by: Jenkins Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154104 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-06-30xmloff: ODF import: adapt generator parsing to 2-digit major versionsMichael Stahl
DocumentInfo currently assumes that a LO version encoded in "BuildId" property has only 1 digit major version, which is now wrong and would start to give incorrect results when major version "30" will be detected as LO_3x. Add the dots as separators into the BuildId because it's not going to work without. Change-Id: I8918afe3642cbefa8488c57658f1505c9a20eddd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153649 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit b1ce8bb078904db1df542f7a1c2ed527dde1a2d3) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153689 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2023-06-18tdf#155823: Improve the check if the list id is not requiredMike Kaganski
The implementation introduced in commit 8f48f91009caa86d896f247059874242ed18bf39 (SwNumRule::HasContinueList) was a bit naive: it assumed that maTextNodeList is sorted (it is not, and so, valid cases to avoid the id were missed); it assumed that a given list can only consist of items of a single numbering style, and so only tested the list of nodes referenced from maTextNodeList of given SwNumRule. I.e., this implementation targeted a special case of a list style fully covering a single continuous list. This skipped ids for list items with list styles, in which maTextNodeList passed the check in HasContinueList, but which were followed by items with a different list style, continuing the same list. This constellation outputs continue-list attribute in the following items (see XMLTextParagraphExport::exportListChange), which references the skipped id. The resulting ODF is an invalid XML (an xml:id is missing that is referenced), and also does not allow to continue such a list. The change tries to fix this, using a list of nodes in XMLTextParagraphExport, and analyzing if the list of the current paragraph has a continuation that needs to reference this list id. Two new hidden properties introduced in SwXParagraph and SwXTextDocument: "ODFExport_NodeIndex" and "ODFExport_ListNodes", resp. They allow to pipe the data to the export. The previous special casing of property state for "ListId", used in SwNumRule::HasContinueList, is removed together with the mentioned function. The intention is to have a logic allowing to detect 100% cases where the list id is required, and where it's not required. A related unit test for tdf#149668 was fixed to not rely on the mentioned ListId property state workaround, and moved from sw/qa/core/unocore to xmloff/qa/unit. Change-Id: If6a6ac7a3dfe0b2ea143229678a603875153eedb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153044 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153065 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-06-07CppunitTest_xmloff_style: fix testAxialTransparencyCompatible on this branchMiklos Vajna
master gave up on validating DOCX files in commit 58ab2f002fd27974b474151b01287dac221dc102 (SwModelTestBase: get rid of mustValidate, 2023-05-31), manual skip is still needed on this branch. Change-Id: I74cc344fafd4ec5f2e829f36463b1a84acfbb7f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152702 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2023-06-07tdf#155549 MCGR: Recreate 'axial' from symmetric 'linear'Regina Henschel
When exporting a shape with an axial gradient fill to OOXML, it is converted to a linear gradient with multiple color stops. Versions before MCGR had recreated it as axial gradient on import from OOXML. But now LO is able to handle multiple color stops and so the linear gradient from OOXML is imported as linear gradient in LO. When such file is then written as ODF, the multiple color stops are in elements in extended namespace and versions before MCGR do not understand them. They show only the first and last color (which are equal) and the gradient is lost. With this patch LO converts the linear gradient back to an axial gradient on export to ODF. The exported axial gradient is rendered in a version with MCGR same as the linear gradient when opening the OOXML file. The difference is, that versions without MCGR now render an axial gradient with two colors. Change-Id: I2b416b4cdca75d8327107a4f259d63c2e6e97ac3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152574 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-06-04MCGR: Use tryToRecreateBorder too for transparencyRegina Henschel
This is similar to 'Use tryToRecreateBorder for better BW comp with LO' (see commit 8259a99f41367a1d8326c9157fe1902915715879), but now for transparency gradients. Change-Id: I1c2e11562fa998c364896d517f4ed3bfe92f6c15 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152508 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-06-04MCGR: Unit test for 'Use tryToRecreateBorder for...'Regina Henschel
Unit test for commit 8259a99f41367a1d8326c9157fe1902915715879. Change-Id: Iba3367fe42b5014b98cf575f53006fc09a79d6ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152428 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-06-04Fix typoAndrea Gelmini
Change-Id: I9c58980de73dc2f00802f0d589d0c6fafe11d16a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152460 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-06-04MCGR: Use tryToRecreateBorder for better BW comp with LOArmin Le Grand (allotropia)
For better compatibility with LO versions before MCGR, try to re-create a 'border' value based on the existing GradientSteps. With MCGR we do not need 'border' anymore in quite some cases since no Start/EndColor at 0.0 resp. 1.0 is explicitely needed. Since we (unfortunately need to) internally continue to support border anyways it does no harm to fallback to use the border value - if there is an equivalent representation as this helper checks for. For exports that do not support 'border' this will be adapted as needed (see tryToApplyBorder()) Change-Id: If98c64039ff97143d4b5c92ac2a950e70f5bb70a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152395 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-06-04sw: prefix members of XMLGradientStyleExport, XMLGradientStyleImport, ...Miklos Vajna
... XMLHatchStyleExport and XMLHatchStyleImport See tdf#94879 for motivation. Change-Id: I2dd4c97c6e234447190e46bd6f6a6354e16911bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152077 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-06-04xmloff: add color-type attribute to complex colorTomaž Vajngerl
We need to identify what the color type of the complex color is. For now we mostly use "theme", but in the future we can also have other types like "rgb",... when the infrastructure for that is built. Change-Id: I38c91d294a191ca3124be4e99050977c9815d23e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152253 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 38e0e78998153463caf9c3c72ef7f4549ddff0e8) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152516 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2023-06-02xmloff: rename theme color names and color-table to theme-colorsTomaž Vajngerl
For ODF it's not needed to abbreviate names and we prefer to use full names. The theme color names in OOXML are abbreviated and the same names were used also for ODF - this was changed now. "color-table" used in "theme" element has reused the already existing "color-table" element name in ODF, but they don't relate to each other. The name was changed to "theme-colors", which makes more sense anyway. Change-Id: I61ec91895d301ad4343f2b977d5cbcf38e360b99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152252 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 9747d9a6ea954dfca4152d36fdb28a8b77fec84b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152266 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2023-06-01xmloff: rename *-color-theme-reference to *-complex-colorTomaž Vajngerl
Change-Id: I63dd83522da7699162eb06a019a679d4b8750d10 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152053 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 68c4d1ca207a82015120a770fbbc5c12fbe1abda) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152263 Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-01xmloff: rename XMLThemeColorHandler to XMLComplexColorHandlerTomaž Vajngerl
Change-Id: Ib24c4b819c31cdc6a9626b09a5b2acd10389ad7a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152051 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit f8cd1d5f0a6f515d8c06b8d4b189eade800d9b5d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152241 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2023-06-01xmloff: rename XMLThemeColorExport to XMLComplexColorExportTomaž Vajngerl
Change-Id: I3d943f20e76b8f3e0409d307d11e3bf16489bf02 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152050 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 66fff7efab4dd1ff08b43ed6d2d557ecad578509) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152240 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2023-06-01xmloff: rename XMLThemeColorContext to XMLComplexColorContextTomaž Vajngerl
Change-Id: I039aea6656cc8dedd74782f4fda8b0e1c25d3910 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152029 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit e1cc0f3e7adc9d4c930a1c37bbe45c69dd3725ab) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152239 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2023-06-01use ComplexColor instead of ThemeColor for better OOXML compat.Tomaž Vajngerl
In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 1df0565fb92972bd410e7db85eef1e4bec3fcc31) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152234 Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-01change model::ColorSet to be stored in a shared_ptr in model::ThemeTomaž Vajngerl
Change-Id: Ic3067f1681c047cd944e64179c568f4e972e0c95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151447 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 8bafae3656f7a0a6b74bb0985403a96f9a3f61be) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152232 Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-31sw floattable: add a DoNotBreakWrappedTables compat flagMiklos Vajna
RTF doesn't break floating table across pages, and there is a matching DOCX compat flag to handle such documents. We can ignore floating table info on the model as a workaround, but that would mean the info is lost on save, so that's not ideal. Instead add a new compat flag that disables fly split at a layout level, which allows both not splitting tables & retaining the model-level info. This commit does the doc model, UNO API, layout & ODT filter, the Word filters are not yet updated. This compat flag is probably quite rare, so introduce a mechanism to only write the compat flag when it's true: this way the majority of the documents don't need to say anything about it and we can assume "false" for them. Also fix two missing xmlTextWriterEndElement() calls in the xml dumper. (cherry picked from commit 08fa2903df1a7cf9a1647fcf967e4c8b57dad793) Change-Id: I32321ec204d7bfe011fcf024b97c906da0db8aae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152260 Tested-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-05-28tdf#148142 chart: fix export of modified On/Between tick marksTünde Tóth
Reset the MajorOrigin property after import to avoid of the bad export of the modified document, which reset the original On tick marks/Between tick marks value. Follow-up to commit 40d83914d43f60a196dfabddea0b52e2046b333a "tdf#127792 implement UNO chart attribute MajorOrigin". Change-Id: I0e3915b7d1b601abd40fbd1ba9d01fc05a8fb7c1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151885 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152009 Tested-by: Jenkins
2023-05-15MCGR: Correct import for Gradient presets/templatesArmin Le Grand (allotropia)
Change-Id: I1424ad5deb65f6c72f414a51a40fbd1138c284d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151432 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-15WIP ODF import and export for MCGRRegina Henschel
Current state uses: Element loext:gradient-stop with the attributes svg:offset, loext:color-type with value 'rgb', and loext:color-value with values of kind #rrggbb. Element loext:opacity-stop with the attributes svg:offset and svg:stop-opacity, both with datatype double. With MCGR enabled testColorGradientWithTransparencyDOCX in CppunitTest_chart_export3 has the value 90000 instead of 90196. That is same value as in original file. Thus I have adapted the test. Change-Id: I976934f9b8fb79be4f74adb180b3285486dce31f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150060 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-13tdf#155238: Reimplement how ListAutoFormat is stored to ODFMike Kaganski
This reimplements commits 6249858a8972aef077e0249bd93cfe8f01bce4d6 (sw: ODT import/export of DOCX's paragraph marker formatting, 2022-12-19) and 209dce614c43f63f63f5b42a746665c0ec1cbfe3 (sw: fix ODT import of paragraph marker formatting, 2022-12-20). Instead of using an empty trailing span for the ListAutoFormat data, introduce a new loext:marker-style-name attribute for text:p element, referencing a text autostyle. The problems with the previous implementation were that (1) it was impossible (or very difficult) to disambiguate several empty trailing spans, in case it was needed; and (2) this was incompatible change, with other ODF implementations treating the trailing span normally. I couldn't manage to incorporate the attribute to paragraph autostyle, because of problems referencing different autostyles one from another, so put it directly to the paragraph attributes. Change-Id: I33473147f1f774c24cbbc57bf0c4f3a1d83ce5bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151645 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151681 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-05-13put floating frames under managed links controlCaolán McNamara
like we do for sections and ole objects that link to their content individual commits in trunk are: extract a OCommonEmbeddedObject::SetInplaceActiveState for reuse no behaviour change intended Change-Id: Ia1d12aa5c9afdc1347f6d4364bc6a0b7f41ee168 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150341 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 183e34a3f8c429c0698951e24c17844e416a3825) use parent window as dialog parent it makes no odds, but is more convenient for upcoming modification Change-Id: Ibc5333b137d2da089b3b701ff615c6ddf43063d0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150342 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit f93edf343658abd489bde3639d2ffaefd50c0f99) adjust IFrameObject so it could reuse mxFrame for a reload of content Change-Id: I7eec3132a23faafd9a2878215a0a117a67bc9bf2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150343 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 3a727d26fd9eb6fa140bc3f5cadf3db079d42206) query getUserAllowsLinkUpdate for the case of content in a floating frame similarly to how it works for the more common "normal" embedded objects Change-Id: I83e38dfa2f84907c2de9680e91f779d34864a9ad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149971 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 52aa46468531918eabfa2031dedf50377ae72cf7) add a route to get writer Floating Frame links under 'manage links' Change-Id: If90ff71d6a96342574799312f764badaf97980eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150349 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 8b8a2844addbd262befb1a2d193dfb590dfa20be) allow SvxOle2Shape::resetModifiedState to survive having no SdrObject Change-Id: Iea059262c124e3f44249e49b4189732310d28156 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150538 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 02379929bd0e1d1676635f0ca1920422702ebb7c) create the FloatingFrameShape in a separate step to inserting it this is derived from the path taken by the AddShape(const OUString&) function for this case. No change in behavior is intended. Change-Id: Id09ae0c65a55a37743ad7c184070fb8dd97d8a7f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150526 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit bafec47847a0b9697b3bbe9358e53f8118af3024) add a route to get calc Floating Frame links under 'manage links' much harder than writer because the organization and ordering of properties and object activation etc is different. This ended up ugly, but functions. We set FrameURL before AddShape, we have to do it again later because it gets cleared when the SdrOle2Obj is attached to the XShape. But we want FrameURL to exist when AddShape triggers SetPersistName which itself triggers SdrOle2Obj::CheckFileLink_Impl and at that point we want to know what URL will end up being used. So bodge this by setting FrameURL to the temp pre-SdrOle2Obj attached properties and we can smuggle it eventually into SdrOle2Obj::SetPersistName at the right point after PersistName is set but before SdrOle2Obj::CheckFileLink_Impl is called in order to inform the link manager that this is an IFrame that links to a URL Change-Id: I67fc199fef9e67fa12ca7873f0fe12137aa16d8f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150539 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 07179a5a5bd00f34acfa8a3f260dd834ae003c63) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150753 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-05-13crashreporting: getUsedFontList() crashCaolán McNamara
e.g. https://crashreport.libreoffice.org/stats/crash_details/3a3c07aa-0f96-4efa-b55b-c3fe4e4b6ed8 ... Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x0 ... XMLFontAutoStylePool::getUsedFontList() xmloff\source\style\XMLFontAutoStylePool.cxx:334 XMLFontAutoStylePool::exportXML() xmloff\source\style\XMLFontAutoStylePool.cxx:408 Change-Id: I5d057b8e639260f6d00e731c3af7bab7203a8814 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150152 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-04-27xmloff: ODF import/export for style:overflow-behavior "clip"Sarper Akdemir
Adds initial support for style:overflow-behavior According to OpenDocument-v1.3-part3 style:overflow-behavior can take values of: - "clip" - "auto-create-new-frame" This patch doesn't properly implement support "auto-create-new-frame", only "clip". If "clip" is set, TextClipVerticalOverflow is set to true, causing the vertical overflowing text to be clipped. "auto-create-new-frame" is treated the same as omitting the style:overflow-behavior attribute, setting TextClipVerticalOverflow to false. Change-Id: Iea298f41fbf0cf18dc07f41788ba0b665515db8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150122 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-04-27sc: pivot table compact layoutDennis Francis
This implements compact layout for pivot tables. In ooxml each row field can have a compact layout setting. Support for any such "mixed" layout of tabular/outline/compact per field is also implemented. This also implements expand/collpse toggle buttons to field labels to make pivot tables with compact layout more usable. Such buttons are also available if other layouts are used. Change-Id: Ieaa1f3bd282ebdec804d0b45a0af7b3d95a2027f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150344 Tested-by: Dennis Francis <dennis.francis@collabora.com> Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
generated by cgit (git 2.34.1) at 2024-06-02 19:06:16 +0000