summaryrefslogtreecommitdiff
path: root/xmloff
AgeCommit message (Collapse)Author
2024-07-12Merge tag 'libreoffice-24.2.5.2' into feature/cib_contract49cThorsten Behrens
Tag libreoffice-24.2.5.2 Change-Id: I351787f986a445eec887dfac353a880f9c5b67e4
2024-07-10tdf#161833 treat semi-transparent pixels as opaquePatrick Luby
Limiting the contour wrapping polygon to only opaque pixels causes clipping of any shadows or other semi-transaprent areas in the image. So, instead of testing for fully opaque pixels, treat pixels that are not fully transparent as opaque. Also, tdf#161833 would cause semi-transparent pixels to be treated as fully transparent pixels when calculating the wrap contour for an image. To force the correct contour when loading a document, force the contour to be recalculated by ignoring the saved polygon if the contour is set to "recreate on edit". Change-Id: Ibe256f54e1c82de30c2b7d5b92a69344b4a7ba10 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169745 Reviewed-by: Patrick Luby <guibomacdev@gmail.com> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins (cherry picked from commit 3da1d8a791cff6cf2dad29b64c9ad15b1a65d5b3) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169957 Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-06-20Revert attempted clipboard fixes on branchcib_contract49c-24.2.4.2.M2Thorsten Behrens
This is a squashed revert, consisting of: * Revert "tdf#161054: drop support of last empty span as paragraph mark format" * Revert "tdf#161023: Empty spans may only define paragraph marks in text documents" * Revert "This block seems obsolete now, try to drop it" * Revert "Make sure to export autostyles from inside frames anchored to page" * Revert "tdf#160253: fix list identifier export decision code"
2024-06-18tdf#161054: drop support of last empty span as paragraph mark formatMike Kaganski
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) introduced support for paragraph marker formatting in ODF, using an empty trailing span. Later, commit 1a88efa8e02a6d765dab13c7110443bb9e6acecf (tdf#155238: Reimplement how ListAutoFormat is stored to ODF, 2023-05-11) changed how the data was stored in ODF. Then, in commit 69ed893087f89d176a5ec4b263ce8d75774be72b (tdf#160253: fix list identifier export decision code, 2024-04-24), some remnants of the older "trailing empty spans" were removed, but a code was added in XMLParaContext::endFastElement, to keep backward compatible with documents created in the frame between December 2022 and May 2023. The said compatibility code brings own problems, requiring new hacks like commit 2ca93eb5df7ddb8641ff7d884a109261c9700aca (tdf#161023: Empty spans may only define paragraph marks in text documents, 2024-05-13), and keeping the code would need more hacks on top, e.g. to fix the case in ODT documents. Instead, let's bite the bullet, and drop the compatibility with this initial implementation, because it was only a brief period during which the documents could be created, which can be affected by this drop. This makes the code simpler. A testdoc for testNumberPortionFormat was edited to use the new markup for the paragraph marks formatting. Change-Id: I053e72dd1cc2ead83baa6ce7d24c8522b494c8fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167583 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-06-18tdf#161023: Empty spans may only define paragraph marks in text documentsMike Kaganski
Change-Id: I40607652a0fd8e31c609732daa54bb796e3fffa0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167557 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-06-18This block seems obsolete now, try to drop itMike Kaganski
... and see if something breaks. Unit tests pass. Likely obsoleted by commit 69ed893087f89d176a5ec4b263ce8d75774be72b (tdf#160253: fix list identifier export decision code, 2024-04-24). Change-Id: I4fde19e1047104686df22053c9b140819ea72963 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166651 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-06-18Make sure to export autostyles from inside frames anchored to pageMike Kaganski
These frames need to export content when collecting autostyles, too. Regression after commit 69ed893087f89d176a5ec4b263ce8d75774be72b (tdf#160253: fix list identifier export decision code, 2024-04-24). Change-Id: If036cab9327e33d32f494fc765bae8e2d685907c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166650 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-06-18tdf#160253: fix list identifier export decision codeMike Kaganski
Commits 8f48f91009caa86d896f247059874242ed18bf39 (ODT export: omit unreferenced <text:list xml:id="...">, 2022-03-10) and 82bbf63582bdf28e7918e58ebf6657a9144bc9f3 (tdf#155823: Improve the check if the list id is not required, 2023-06-14) tried to improve deterministic ODF output, by omitting the list identifiers in case when those identifiers were unreferenced. The latter of these used document model node numbers to check if other lists appeared after the last occurrence of the list that is continuing in the current node. But it turned out, that this isn't robust. Consider this ODF: <text:list xml:id="list1" text:style-name="L1"> <text:list-item> <text:p>a</text:p> </text:list-item> </text:list> <text:p>b<text:note text:id="ftn1" text:note-class="endnote"><text:note-citation>i</text:note-citation><text:note-body> <text:list text:style-name="L2"> <text:list-item> <text:p>x</text:p> </text:list-item> </text:list></text:note-body></text:note></text:p> <text:list text:continue-list="list1" text:style-name="L1"> <text:list-item> <text:p>c</text:p> </text:list-item> </text:list> The paragraphs a, b, and c are all in the main document body, and have sequential document model node numbers (say, 15, 16, 17). If these numbers are checked, there is no node between node 15 ("a") and node 17 ("c") with a different list (both 15 and 17 belong to a list with style "L1" and identifier "list1", and node 16 doesn't belong to any lists). That suggests that the list identifier isn't needed in this case. Bug when the actual output of node 16 is done, it includes a node from an endnote ("x"), which is located in a different place in the document model, and has a node number like 7 (so not between 15 and 17). The paragraph "x" belongs to another list with style "L2", and is output to ODF between paragraphs "a" and "c". Here, we must refer from paragraph "c" to the list of the paragraph "a" using the list id, but this is not obvious when only considering node numbers, and requires the prior knowledge of the actual order of appearance of lists in the ODF. Unless we build a DOM, this is only possible, if we do a two-pass output, and collect the nodes order in the first pass. The output already does that in a "collect autostyles" pass. The problem here is that the "collect autostyles" pass used an optimized function, XMLTextParagraphExport::collectTextAutoStylesOptimized, introduced in commit 8195d7061ed52ebb98f46d35fe5929762c71e4b3 (INTEGRATION: CWS swautomatic01 (1.126.4); FILE MERGED, 2006-12-01) for #i65476# and which used style::XAutoStylesSupplier for optimization to get the autostyles. This drops XMLTextParagraphExport::collectTextAutoStylesOptimized, and reverts to use of collectTextAutoStyles, which handles nodes in the same order as when writing to ODF. There, we build a vector of the node numbers sequence, used later to sort DocumentListNodes. This uncovered an omission from the work on paragraph mark (commit 1a88efa8e02a6d765dab13c7110443bb9e6acecf tdf#155238: Reimplement how ListAutoFormat is stored to ODF, 2023-05-11). Turns out, that the code in SwTextFormatter::NewNumberPortion introduced in commit cb0e1b52d68aa6d5b505f91cb4ce577f7f3b2a8f (sw, numbering portion format: consider full-para char formats as well, 2022-10-20) was left behind when re-implementing paragraph marks to use dedicated property; empty trailing spans still affected how the lists were rendered, and that allowed to overlook import defects, where the paragraph mark properties weren't properly set. In ODF import (XMLParaContext::endFastElement), for compatibility, this treats empty trailing spans as defining paragraph mark (when the paragraph mark wasn't set explicitly). This way, the trailing spans get converted to the paragraph mark. In WW8 import, last cell paragraphs didn't call the code handling the paragraph marks. This is also fixed now. The changes result in slightly different numbering of autostyles in the ODF. It seems, that the new numbering more closely follows the order of appearance of the autostyles in the output; and some cases of autostyles that were written, but unreferenced, are now eliminated. The unit tests were updated accordingly. I hope that the performance impact on the export time would not be too large. It is unclear why outline numbering exports a list element at all. Fixing that to not emit the list element is a separate task / TODO. Change-Id: I5c99f8d48be77c4454ffac6ffa9f5babfe0d4909 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166572 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-06-10tdf#161488: allow failed image loading in repair modeMike Kaganski
Change-Id: I19a68f2f016b5ab95565c7fbcc4c435cf13c6b48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168596 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins (cherry picked from commit bf02c5fa586d2ff7dbfac37d3ea0a07675efc15e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168615 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-05-22Related: tdf#145972 sw images: fix rounding error in relative size calculationMiklos Vajna
Open the bugdoc, see that the image is roughly half of the page width, right click, properties, UI shows that the width of the image is 5% of the width of the entire page. This only happens if tools -> options -> writer -> general sets the UI units to points, the default cm case is fine. This went wrong with commit 9e8712ed6f9fb5dbd971e352a5709bd45fadc74f (sw image dialog: fix fallback width/height for images with relative sizes, 2022-03-17), because the layout size started to matter more after that commit. This lead to the nWidth != m_xWidthED->get_value(FieldUnit::TWIP) check in SwFramePage::Init() to be true, because 11906 * 0.48 is 5714.88, so you got 5714 in the layout, but got 5715 with rounding in SwFramePage::Reset() (which tries to calc the page width based on the 48% and the fly width). And once we had that mismatch, we went down the wrong path. Fix the problem by using rtl::math::round() in SwFlyFrame::CalcRel(), so the relative width twips value is 5715 everywhere: once we have consisteny, the UI value is correct, too. Note that the original bugdoc needs more fixing, this just fixes the bugdoc where KeepRatio is false. Change-Id: I1e8782c95a0cf9d97375c36d41134735c01f3e46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167916 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167926
2024-05-09tdf#160517 - chart odf: import/export formatted chart titlesBalazs Varga
(main, sub, axis titles) texts properly to/from odf format. Fix odf export of formatted chart titles. The exported data structure will look like: <chart:title svg:x="3.304cm" svg:y="0.285cm" chart:style-name="ch2"> <text:p> <text:span text:style-name="T1">This</text:span> <text:span text:style-name="T2"> is</text:span> . . . <text:span text:style-name="T3">3</text:span> <text:span text:style-name="T2"> a </text:span> </text:p> </chart:title> Fix import of formatted chart titles. Put the properties and related texts into the chart2::XFormattedString2 uno objects. Follow-up commit of: 55e9a27afd2d6a13cf76b39641bf121c3ec4b45c Related: tdf#39052 - chart ooxml: export formatted chart titles 4f994cec388377cc5c2bddb804bd92eb4cd7dc8d tdf#39052 - Chart: make characters formatable in editable chart textshapes -- TODO: chart data point / dataseries labels are handled differently since those are not editable objects, but that is a completily different issue. -- Change-Id: I1842f2c69c132bdf578bb2d354f451cc9d49c63c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166122 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2024-05-02tdf#114287 tdf#159366 xmloff: ODF import: revert text:list overrideMichael Stahl
This reverts commit ade0a153f453500f15343380ac937252992733e0 "tdf#114287 xmloff: ODF import: fix text:list override of list style" and subsequent commits 7cf5faec6fdbc27dd77d2d36fb2ff205322cba0d and 1b2a6b98291cf8b7022951be19b915fe2a9e18e6. It turns out that there is actually a paragraph in ODF 1.2 and later that gives paragraph's indent priority over the list style's, which i unfortunately missed when investigating the above issues: 17.20 <style:list-level-label-alignment> ... The fo:text-indent and fo:margin-left attributes are evaluated only for paragraphs inside list items whose paragraph styles do not specify them. If one of the two properties, or both, are specified by the paragraph style, the text indent and/or left margin are taken from the paragraph style. In this case the paragraph style's properties are used to determine the indent and margin for the text lines and thus also the alignment position. This is usually interpreted as "on the same level", so applying a list-style at a paragraph style overrides the indents inherited from a parent paragraph style, but if the style then specifies its own indents that overrides the list style's indents. Furthermore it turns out that Google Docs now imports this bugdoc the same way as LO 7.5 does; unclear if that changed recently (it shows it like Word does in the preview, but like LO 7.5 does after opening it). This means the way MS Word imports the bugdoc, which remains unchanged, now looks like a bug and we should not change LO to be compatible with it (when the same structure is created in Word, storing to ODF and loading again, it looks different too). Change-Id: I0c65bde38de9e6fcbccec55899c60c3245adb5ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166309 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins (cherry picked from commit 546741148863ae0b2a25cc994a7323c8113cb573) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166716 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-05-02tdf#159903 xmloff: ODF import: fix bug in margin compatibility overrideMichael Stahl
The check for the property being set was wrong: the state in a parent style may be DIRECT_VALUE but a derived style may have a list style set, which effectively overrides the ParaLeftMargin and ParaFirstLineIndent. Fix this so that the compatibility override only happens when required. (regression from commit 7cf5faec6fdbc27dd77d2d36fb2ff205322cba0d) Change-Id: I6c8ca493df946afcb48a63c01c132620bcd7b390 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166257 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 1b2a6b98291cf8b7022951be19b915fe2a9e18e6) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166217 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2024-04-30Related: tdf#39052 - chart ooxml: export formatted chart titlesBalazs Varga
texts properly to ooxml. Also adding "FormattedStrings" property for title objects to simplify the working of character formattings in editable chart shapes. TODO: odf import/export Change-Id: Ie27b4dee72c24fa6a2a4e2a7db8da7fa50eb8937 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165583 Tested-by: Jenkins Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de> Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2024-04-30Don't export printer name & config in privacy modeSamuel Mehrbrodt
Don't export printer name & printer config when RemovePersonalInfoOnSaving is enabled, as it might contain sensitive data such as printer location. Add an option to export printer settings even when RemovePersonalInfoOnSaving is enabled. Change-Id: I3d2ca91ad2032050c919d382c11c9ceabf331770 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162577 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2024-04-30Don't export personal metadata when user wishes not toSamuel Mehrbrodt
Currently the metadata is only reset to default when the option to remove personal metadata is active. And some metadata was still exported which might contain personal data. Now the following elements won't be exported anymore when the RemovePersonalInfoOnSaving option is set to true: * meta:initial-creator * meta:creation-date * dc:date * dc:creator * meta:printed-by * meta:print-date * meta:editing-duration * meta:editing-cycles * meta:template Change-Id: Ibad57fdbff04bf285881826820ec3ddb01ffbb36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162553 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2024-04-29tdf#114287 tdf#159366 xmloff: ODF import: revert text:list overrideMichael Stahl
This reverts commit ade0a153f453500f15343380ac937252992733e0 "tdf#114287 xmloff: ODF import: fix text:list override of list style" and subsequent commits 7cf5faec6fdbc27dd77d2d36fb2ff205322cba0d and 1b2a6b98291cf8b7022951be19b915fe2a9e18e6. It turns out that there is actually a paragraph in ODF 1.2 and later that gives paragraph's indent priority over the list style's, which i unfortunately missed when investigating the above issues: 17.20 <style:list-level-label-alignment> ... The fo:text-indent and fo:margin-left attributes are evaluated only for paragraphs inside list items whose paragraph styles do not specify them. If one of the two properties, or both, are specified by the paragraph style, the text indent and/or left margin are taken from the paragraph style. In this case the paragraph style's properties are used to determine the indent and margin for the text lines and thus also the alignment position. This is usually interpreted as "on the same level", so applying a list-style at a paragraph style overrides the indents inherited from a parent paragraph style, but if the style then specifies its own indents that overrides the list style's indents. Furthermore it turns out that Google Docs now imports this bugdoc the same way as LO 7.5 does; unclear if that changed recently (it shows it like Word does in the preview, but like LO 7.5 does after opening it). This means the way MS Word imports the bugdoc, which remains unchanged, now looks like a bug and we should not change LO to be compatible with it (when the same structure is created in Word, storing to ODF and loading again, it looks different too). Change-Id: I0c65bde38de9e6fcbccec55899c60c3245adb5ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166309 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins (cherry picked from commit 546741148863ae0b2a25cc994a7323c8113cb573) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166716 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-04-22tdf#159903 xmloff: ODF import: fix bug in margin compatibility overrideMichael Stahl
The check for the property being set was wrong: the state in a parent style may be DIRECT_VALUE but a derived style may have a list style set, which effectively overrides the ParaLeftMargin and ParaFirstLineIndent. Fix this so that the compatibility override only happens when required. (regression from commit 7cf5faec6fdbc27dd77d2d36fb2ff205322cba0d) Change-Id: I6c8ca493df946afcb48a63c01c132620bcd7b390 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166257 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 1b2a6b98291cf8b7022951be19b915fe2a9e18e6) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166217 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2024-04-15Related: tdf#160056 this can be staticCaolán McNamara
Change-Id: I1172854a1bf00e74adbe350c54e4e98ea38b0b35 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165072 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit 49189bb8823adc6a76d3f33b34c02d6a640df96a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165746 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2024-04-02add notify for script useCaolán McNamara
Change-Id: I84af197cec7755f6803a578e1e21c03966ad5f3e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165411 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-03-01tdf#146356 insert new paragraph before table of contentsOliver Specht
Alt+Enter inserts the new paragraph before the content section of a table of contents. At the same time protected indexes now also have the header protected. Change-Id: Iff267691d96796158c1593c4269b76226840c952 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164050 Tested-by: Jenkins Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit aebdc79dbc5bf059ee0921a00d2795e526a52c42) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164128
2024-01-24tdf#106733 sw: implement CharNoHyphenationLászló Németh
Implement CharNoHyphenation character property to disable automatic hyphenation of words in paragraphs with enabled hyphenation. Fix also fo:hyphenate mapping to CharNoHyphenation using automatic inversion of their boolean values defined by xmloff's XML_TYPE_NBOOL, as suggested by Michael Stahl. Update also the test for tdf#159102 to check the available hyphenation dictionary (also custom hyphenation patterns work only with supported locales of the hyphenator). Note: patch of thints.cxx contains also partial revert of commit 53b289eabb3d265b47bc7fb6cc430291c97f0c0b "use more TypedWhichId". Follow-up to commit 73bd04a71e741788a2f2f3b26cc46ddb6a361372 "tdf#106733 xmloff: keep fo:hyphenate in character formatting". Change-Id: If99b94ddcd44a5c2426e646be149078a3b9773b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162300 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/+/162283 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-01-22tdf#106733 xmloff: keep fo:hyphenate in character formattingLászló Németh
In the case of character formatting, map fo:hyphenate to the unused CharNoHyphenation character property to keep it during ODF import/export instead of losing it completely. This is the first step to disable hyphenation for single words or text spans in paragraphs with automatic hyphenation. Note: using fo:hyphenate as character property is part of the ODF standard. Note: the old workaround to disable hyphenation, changing the language of the text to None had got some serious fallbacks: losing spell checking and losing language-dependent text layout (supported by both OpenType and Graphite font engines in LibreOffice). Change-Id: I9565c3efbbb6e6d970fb03710e8c932ad72ab57e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162257 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 956f81ebc9d70507a4a976bfe42c99175dbf3632) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162272 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-01-10UnoApiTest::loadFromURL -> UnoApiTest::loadFromFileMike Kaganski
The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161888 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-01-09xmloff: ODF export: if there's no checksum, don't generate chaffMichael Stahl
Change-Id: I2e1bb6ed33df327ebd797edeca7ee82b75c524b4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161800 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 2184692bbe69a093368e959e1096cb7506feceee) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161767 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2023-12-19tdf#157740 FILESAVE PPTX: fix explosion of the number of master slidesBalazs Varga
- Export correctly the "supported" master slides with the actual slides names. - Set SlideLayout property at ODF import as well for MasterSlides layout type. - When we copy a slide with the master slide also copy the SlideLayout property value as well. Change-Id: Idb6b88ebe87a83818d8eb27a1fa087652a002c0c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160290 Tested-by: Jenkins Reviewed-by: Henry Castro <hcastro@collabora.com> Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de> (cherry picked from commit bff76421e234df7246a7f49c71a11432f86e09d1) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160869 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-12-07simplify and modernise ScopedBitmapAccessNoel Grandin
(*) Make all of it use a "Scoped" paradigm (*) pass by value, no need to allocate on heap (*) make all of the construction go via the *Access constructors, instead of it being some via the constructors and some via the Acquire*Access methods. (*) take the Bitmap& by const& in the constructor, so we can avoid doing const_cast in random places. Change-Id: Ie03a9145c0965980ee8df9a89b8714a425e18f74 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160293 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-12-07some cosmetic improvements, better warningsMichael Stahl
Change-Id: I05a7eeb74088c278aab94519c7f53b0482e38058 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160400 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-12-04cid#1546422 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1546416 COPY_INSTEAD_OF_MOVE cid#1546415 COPY_INSTEAD_OF_MOVE cid#1546391 COPY_INSTEAD_OF_MOVE cid#1546390 COPY_INSTEAD_OF_MOVE cid#1546317 COPY_INSTEAD_OF_MOVE cid#1546252 COPY_INSTEAD_OF_MOVE cid#1546251 COPY_INSTEAD_OF_MOVE cid#1546249 COPY_INSTEAD_OF_MOVE cid#1546243 COPY_INSTEAD_OF_MOVE cid#1546195 COPY_INSTEAD_OF_MOVE cid#1546193 COPY_INSTEAD_OF_MOVE cid#1546137 COPY_INSTEAD_OF_MOVE cid#1545738 COPY_INSTEAD_OF_MOVE cid#1545782 COPY_INSTEAD_OF_MOVE Change-Id: I10d5091aa72b682371764b8a18cc5062e272c031 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160285 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-04cid#1546476 COPY_INSTEAD_OF_MOVECaolán McNamara
Change-Id: Ic8133ebfb40c02eb95bdf95809aeca719f636acf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160276 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-04cid#1546325, cid#1546212: invalid iterator (xmloff/namespacemap.cxx)Julien Nabet
Change-Id: I7a3377326daa5a0d933a68b9d4f5a64983ba2ab8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160278 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-02remove printfTomaž Vajngerl
Change-Id: Ib83b5c3b0f80310cd11f7cd8cd83e82d11e12eb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160241 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-12-02tdf#123396 actually use the mimetype set in the from documentTomaž Vajngerl
In the document we set the mime type for the images stored, but at import we never actually used the mime types. We always did mime type detection from the filename extension. The problem with this is that files stored as base64 streams don't have a filename so it is also not possible to determine the mime type from the file name. The consequence of this is that we can't know which image to take if we have multiple images (fallback images) so we always take the last one, which could be the wrong one. This happend in the test document. This changes the behavior so that we always first use the document set mime type as there is no reason to not trust that. Only if the mime type isn't provided by the document we use other mime type detection methods. Change-Id: I175c509ce5f11eab2c0454d4d9901ca1fe975272 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160237 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-12-01Fix typoAndrea Gelmini
Change-Id: I9fae0349d8ecf4a4e11b23b46e5b593c07b05290 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160210 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-01[API CHANGE] Add OOXML way of curved connector routingRegina Henschel
The paths generated for curved connectors are basically incompatible between LibreOffice and OOXML. Thus it was not possible to render curved connectors the same way as MS Office. The patch adds an OOXML compatible method for calculating the path. The new method results in a different svg:d attribute when saved in ODF, but needs no change to ODF. The patch introduces the boolean connector property 'EdgeOOXMLCurve' to switch between the two methods. The property value is determined from the svg:d attribute in case of import from ODF. In case of missing svg:d attribute the property value is set to 'true', because Word currently does not write a svg:d attribute when it exports to ODF. The property value is set to 'true' for import of connectors on a drawing canvas in docx. Default value for new connectors is 'false'. The new property has no UI, but can be used via macro. Currently the new method is used for import of curved connectors on drawing canvas in docx documents. Change-Id: I53d99f44febe4d74c2b611f5fdb9de86628c4519 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159708 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-11-29Resolves: tdf#158265 Store more than 100th seconds precision in date+timeEike Rathke
e.g. office:date-value Change-Id: I9bb4b589cdb8c6f04fa39ba7ec4254207eaa3663 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160124 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2023-11-28sw floattable, per-frame wrap-on-all-pages mode: add ODT filterMiklos Vajna
See <https://issues.oasis-open.org/browse/OFFICE-4150>, map SwFormatWrapTextAtFlyStart to <style:graphic-properties loext:wrap-text-at-frame-start="..."> on export, and the opposite on import. Change-Id: I43ee4c014fbcef8e883ff08ea061cfd395399a98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160010 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-11-27tdf#158302 fix build against system-libxml-2.12Miklos Vajna
Seen in a fedora:40 container, using --with-system-libcmis, --with-system-liblangtag and --with-system-xmlsec. Change-Id: I9d748d3dc0b70dbfdfcb6b99c9ce8440bda6f326 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159980 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-11-20c++20: use std::erase(_if) instead of std::remove(_if)+erase (xmloff)Julien Nabet
Change-Id: Idb65092e79a9afc6195bce0dbd5b3861d83a01be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159711 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-19Extended loplugin:ostr: xmloffStephan Bergmann
Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-16comphelper: use c++20 contains() instead of find() and end()Miklos Vajna
Whether an element is contained inside a container is better to be checked with contains() instead of find() because contains() conveys the intent more clearly. Change-Id: I267d915c95fcf9c98b2e11daa89c8fe801e59a75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159484 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-11-10loplugin:fieldcast in XMLPageExportNoel Grandin
Change-Id: I07c5f2a6af46a3952d4fbc617d86174b1e23d518 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159222 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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/+/159226 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-11-07loplugin:fieldcast in xmloffNoel Grandin
Change-Id: Ic975c6344edb03e8bb8283a627fb70e05ca76239 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159075 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-07warn about exotic protocols as wellCaolán McNamara
Change-Id: I50dcf4f36cd20d75f5ad3876353143268740a50f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151834 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-11-01tdf#156449 Preserve '0' or '?' in exponentLaurent Balland
Exponent in scientific number may use '?' as blank like in format "0.00E+?0" This change: - adds interpreatation of '0' and '?' in exponent - adds "blank-exponent-digits" attribute to scientific number for import and export to ODF - prevents using exponent with only '?'. There must be at least one '0' in exponent - adds QA test of such format and test import/export/import to ODF and OOXML - corrects one basic test Change-Id: If52edc632a161f842270bb2fd77af535e2b978d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154986 Tested-by: Jenkins Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
2023-11-01tdf#153993 Extend ODF: lowercase for exponent charLaurent Balland
In scientific format, user may want to have clearer format such as: 0.000" "000" "e+" "0 This change - adds "exponent-lowercase" boolean attribute to scientific-number format to preserve "e" or "E" char - includes all positions up to exponent for embedded text of scientific number Add QA test Change-Id: Ie263f4ecf30a1a8dcd8046e1e048767020e54dc2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153824 Tested-by: Jenkins Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
2023-10-30Enable 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/+/158351 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-10-29tdf#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> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158611 Tested-by: Jenkins
2023-10-24xmloff: document the GutterAtTop Writer settingMiklos Vajna
Change-Id: Ic56d7b3333e50bd6cf0d32d19995b09bf612384c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158381 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
generated by cgit (git 2.34.1) at 2024-07-30 03:04:34 +0000