summaryrefslogtreecommitdiff
path: root/xmloff
AgeCommit message (Collapse)Author
2020-11-05clean up some temp files after running testsAndras Timar
Change-Id: Ia28e96cf1f6ec476f202e99877fa80e93d691278 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105314 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-11-05loplugin:unusedenumconstantsNoel
Change-Id: I9a2eb83647d6620b3c5b5ed5642227be47a657f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105303 Tested-by: Jenkins Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-04use fastparser in XMLEmbeddedObjectImportContextNoel Grandin
Change-Id: I5fc61239e60a3129b350895293760a345baf3ce5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105260 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-02create common macro and method for logging unknown attributesNoel
instead of repeating the code everywhere Change-Id: Idb94054b392ed256e64259cdb17d1522bf3c52b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105184 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-02drop the SvXMLExport::EndElement method..Noel
in favour of just using the endFastElement() method Change-Id: Id95abb0b9e78bc44278c5e9e3cc8dee15185e2e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105175 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-02drop the SvXMLExport::Characters method..Noel
in favour of just using the characters() method Change-Id: Iecb2773d488fcf4fa3c2202d0e889015a288fe2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105174 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-02-Werror=parenthesesStephan Bergmann
Change-Id: I6f4214a235dbeaade8e58597f784a0e435616682 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105166 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-11-02make SvXMLImport capable of mixing fast- and slow- contexts adhocNoel
so I can convert even *ImportContext subclasses in the middle of a context stack, and thus break the cyclic dependency nature of the writer import. and adjust the xmlimport loplugin for the new rules. As a consequence of the loplugin:xmlimport's checking, we remove a bunch of now unnecessary overrides of startFastElement. Change-Id: I97464522ede8ec5e345e928cdafa4b18364b1b80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104730 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-31rename to NotifyContainsEmbeddedFontCaolán McNamara
to indicate better what its users do with this notification. This reflects better the reality that while the embedded font has been read at this point, vcl hasn't been informed of its existence yet. Change-Id: I87f4d0a0361192dac972f6146d3721a69e11ac27 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105086 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-31remove pimpl from SdXMLShowsContextNoel Grandin
Change-Id: I54d4103d3a53300e9ed018b0d7f9a25e177722de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105027 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-29tdf#137627 sw top page border orientation: add ODFSzabolcs Toth
Map between RelOrientation::PAGE_PRINT_AREA_TOP and loext:vertical-rel="page-content-top". Follow-up of commit 1c593e1916c9164c7db71da2017cfc26972f8e9f (tdf#133045 sw: add shape alignment to the top page border). See also commit 65b7873aab5deec7157328047e869a6385e0a74a (sw from-bottom relative orientation: add ODF filter). Change-Id: I9bff7a9507152262dda7d126fa3e7e1bee6a8276 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104554 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-10-29tdf#137643 alternative solution to activate embedded fonts in one batchCaolán McNamara
Change-Id: Ib5ffb2b8a31f237d5d2e465bf3f777590e0bfade Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104947 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-28std::set->o3tl::sorted_vector in xmloffNoel Grandin
Change-Id: Iba07a9905f37c2fb00d59ac00703744e5f81b1c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104906 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-26switching long to a 64-bit type on 64-bit windowsNoel
(*) create a rewriting plugin to do most of the work, heavily based on the fakebool plugin (*) but there are still a number of "long"s in the codebase that will need to be done by hand (*) the plugin needs lots of handholding, due to needing to add #include and update macros Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-23remove debug code from SvXMLImportNoel Grandin
accidentally committed in commit fe2b4e7dc6533535736a8f08496f316427386179 Date: Tue Oct 6 18:27:27 2020 +0200 make SvXMLImport fast-parser only Change-Id: I5fb46399f6e562cc289859ef13998dfafaae6a7d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104693 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-22only need to check the version onceNoel
Change-Id: Ie02ce5e7823a7564da919525f9cbdf4fc92072dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104649 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-22make SvXMLImport fast-parser onlyNoel Grandin
so I can simplify its logic and convert the rest of the context classes. Change-Id: I671ba63724a153a5c715153a8149bdd045040193 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104038 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-22XmlFilterAdaptor: use the fastparser API when possibleNoel
part of the process of making SvXMLImport fastparser-only Which uncovered several bugs because I end up stacking fast and slow parsers, not once, but twice. Specifically, we have a problem here with default namespaces e.g. <math xmlns="http://www.w3.org/1998/Math/MathML" display="block"> <semantics><mrow><mstyle mathsize="12pt"> where going from slow- to fast- parser loses this information, because there is no way to represent this in the fastparser world, so we end up with nastiness when we transition back to slow-parser, and then back-again to fast-parser. So I fixed a couple of places XMLEmbeddedObjectImportContext and in SvXMLLegacyToFastDocHandler, and then worked around some of it by introducing an new XImporter2 interface so I could strip out out one of the slowparser -> fastparser transitions. Change-Id: I491487b99271898da50dc999d3b9b9c39cbd97fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104514 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-19tdf#137585 Chart ODF: fix export of DataLabelPlacement::CUSTOMTünde Tóth
Saving .ods, the DataLabelPlacement::CUSTOM converted to the default "avoid-overlap" instead of the requested "outside". Follow-up of commit 20da1a5dd37c7edac620566c992d5a53b23a5f12 (tdf#134978 Chart OOXML Import: fix pie chart label custom position) Change-Id: Ib15c7f24e0a650c84e6afce08b84e7eece8dafea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104430 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-10-17OOo2Oasis: use the fastparser API when possibleNoel Grandin
part of the process of making SvXMLImport fastparser-only Change-Id: Ib8b4a02fff94653adf9d48ac07404d392572b1f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104464 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-17TransformerBase: use the fastparser API when possibleNoel Grandin
part of the process of making SvXMLImport fastparser-only Change-Id: Ie93e846e745b4388b891a68740c17742bbd62e82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104465 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-17fix fastparser namespace handling when...Noel Grandin
dealing with unknown attributes, in SvXMLLegacyToFastDocHandler::startElement SvXMLImportPropertyMapper::importXML which show up with some work I'm doing to make SvXMLImport fastparser-only. Change-Id: I71197c1659a5f072c2b186892be1f88ca6b2a764 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104140 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-17xmloff: use the fastparser API when possibleNoel Grandin
part of the process of making SvXMLImport fastparser-only Change-Id: If80ba22f370d5da6f268d6456ab0c974e6ff4209 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104455 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-04use more TOOLS_WARN_EXCEPTIONMike Kaganski
Change-Id: I269f88d82680f6a969a8bf582f0ae00cc7636509 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103925 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-10-04use more TOOLS_WARN_EXCEPTIONMike Kaganski
Change-Id: Iaa8f006526be2b16767f34ac0d7cd567314a50e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103908 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-10-03use more TOOLS_WARN_EXCEPTIONNoel
Change-Id: Id83c478af5d04ad548c7cf4239fe2fb3ee154dc9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103861 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-03use more TOOLS_WARN_EXCEPTIONNoel
Change-Id: I8b5cde993c13e0b7c8c830b1ff698933a6b7cfd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103863 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-01loplugin:reducevarscope in xmloffNoel
Change-Id: Ib67311f84a6a7a490afb392e642d74693fde3113 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103747 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-22OUStringLiteral/OStringLiteral coverity PARSE_ERROR workaroundCaolán McNamara
do more like commit 121771e37f7e2de41cd5643475861062bf25627b Date: Mon Sep 21 09:17:54 2020 +0200 Make some OUStringLiteral vars constexpr cause coverity can live with that Change-Id: I9efd7f848289c4865997a44c6780373068422227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-22tdf#132970 SMP bullets mangledCaolán McNamara
working: a) bullet preview b) writer rendering c) save to odt a) load from odt Change-Id: I2f85576389fe4f0437f81799c14dfd98c8c40b2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103129 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-21Make some OUStringLiteral vars constexprStephan Bergmann
...to see if that helps silence cid#1467018 PARSE_ERROR. (Plus, it is arguably the better choice to have OUStringLiteral vars be constexpr than just const, so they themselves can take part in larger constant expressions. I just thought it wouldn't make much difference in practice for now, so I didn't do that wholesale in e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString" to not make that change bigger than it already was. Similarly for 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String".) Change-Id: I6deca7bc1731239216fc87cf35984668c3346683 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103085 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-20Removed executable bits from source fileAndrea Gelmini
Change-Id: Idc8fd27820cd807db81a89856f9aef567decc206 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103044 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-19tdf#135366 Save line and fill of data labels to ODFRegina Henschel
LibreOffice has line and fill properties of data labels in charts as loext attributes in the style of the <chart:series> or <chart:data-point> element. For ODF there has to be a <chart:data-label> element with line and fill properties in its style. This patch adds the needed <chart:data-label> elements and their associated <style:style> elements. The element <chart:data-lable> exists in ODF since version 1.2. The solution requires no extended namespace. The check is adapted in lcl_getCustomLabelField. Import was already done in commit 87d1ebeb11a00301745ee3c3c03fffb7033ab59d Change-Id: I829dae5433e8257c775aa4f08e511d514df4e936 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102381 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2020-09-18xmloff: remove dead com.sun.star.comp.Draw.XMLSettingsExporterMiklos Vajna
And test com.sun.star.comp.Draw.XMLOasisSettingsExporter instead in JunitTest_xmloff_unoapi. Note that the test code is also dead at the moment, because xmloff/qa/unoapi/xmloff.sce disables the xmloff.Draw.XMLSettingsExporter line, but let's not regress even more in that code. Change-Id: I2152f32fd798b7a7df7086b125e77fe804185157 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102973 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-12tdf#133502 annotation has wrong positionNoel Grandin
regression from commit 20c5a2abb61c4246c6001b7b6d5bd69cd5882cfd use FastParser in DrawAnnotationContext Change-Id: Ifc4a8d6390d37edfb375f37d513418b77f38d842 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102515 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-11Fix the minimal build-tools targetJan-Marek Glogowski
The revert commits change the build-tools target for a DESKTOP build to build the complete LO. This restores the original, minimal one and also adds a whitelist of allowd build types. OpenCL needs a configure switch, as it's status is also stored in a config header, so preventing the build is not enough. This also reverts: - commit 802161a505272732566210e9ebbd8fe1b23fb86d - commit 02d931a59e2966d0c2736db8dee7be3e3dcd6bae Change-Id: Ibfcb0c54e72da1b7c2e63c082ea6586520a787fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102480 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-11remove duplicate XML_TOK_TEXT_FRAME_FILTER_NAMENoel Grandin
which has been there ever since commit fd069bee7e57ad529c3c0974559fd2d84ec3151a Date: Mon Sep 18 16:07:07 2000 +0000 initial import And add assert to prevent more duplicates Change-Id: I371a117896c1ab36fabf69da41229a7bcf5459d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102366 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-11optimisation: use o3tl::sorted_vector in XMLPropertyStates_ImplNoel Grandin
Change-Id: I9774e0d3f29decedd910fafe3c3174bab930f521 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102438 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-11optimisation: used std::vector for list of integersNoel Grandin
Change-Id: I98b211d632f0282faeaa30e971841faae89bfeff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102440 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-11xmloff: remove dead com.sun.star.comp.Draw.XMLContentExporterMiklos Vajna
And test com.sun.star.comp.Draw.XMLOasisContentExporter instead in JunitTest_xmloff_unoapi. Change-Id: I22bf816d08bcd04b277e461a5055883b730811b4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102401 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-10tdf#136645 FILEOPEN: ODT: Incorrect section sizeNoel Grandin
regression from commit 36914a8b3a07391d225bce593236d6fcf0cc61d2 (patch) use fastparser in XMLElementPropertyContext subclasses Change-Id: I31dc4ce73da88fbd2fbf0f5066c58ac8acfc2731 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102384 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-09Remove unnecessary search before insertMuhammet Kara
Change-Id: Ie6ba54a61b59879bd047343cc9857d9937cc76c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102269 Tested-by: Jenkins Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
2020-09-09improve loplugin:unusedvarsglobalNoel Grandin
to find any global variable, was checking the wrong property of VarDecl Change-Id: I454b4e0c1701bb0771768a1ee10cd738c4ab0726 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102278 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-08cid#1186122 Big parameter passed by valueCaolán McNamara
Change-Id: Ifbc7129280a172407997c56aaab41c33433f99a8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102230 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-08cid#1466654 Uninitialized scalar fieldCaolán McNamara
Change-Id: Ic8760df2b5ddbe281aa8e6c21a79eb5675274650 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102228 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-07loplugin:constantparamNoel Grandin
Change-Id: I83722d99fa0d5919a7e878d32311dbb6de1c6714 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102175 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-07loplugin:unusedfieldsNoel Grandin
Change-Id: Id1b1c07ddcacca8eef8af71890d9392f29b6be6d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102172 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-05tdf#135366 ODF import of line and fill of data labelsRegina Henschel
LibreOffice has line and fill properties of data labels in a chart in properties of kind "LabelBorderWidth" or "LabelFillColor" at a data point or, as defaults for the points, at a series. But ODF has such information in a <style:style> element, which is refered by a <chart:data-label> element. That one can be child of a <chart:data-point> and child of a <chart:series> element. Microsoft Office correctly uses the <chart:data-point> element and its style for the line and fill properties of data labels. Up to now LO cannot import such information and does not write the ODF elements. Instead LibreOffice reads and writes attributes in 'loext' namespace. Using the "LabelFoo" properties was implemented by Kohei Yoshida, July 2014. Although there is no published service, these properties can be used in macros. Because they are now available since six years, the decision was to keep this internal model and convert on import and export. This patch implements the import of the ODF fill and line properties from the <chart:data-label> element and converts them to the internal used properties. LibreOffice has currently only implemented a few of the possible line and fill properties. When more are implemented, their <ODF,LabelFoo> pairs need to be added to the array aApiToLabelFooPairs, further adaptions are not needed. The <chart:data-label> contains in addition the absolute position of a data label. LibreOffice has internally only a position offset relative to the regular position of the label. The conversion of the position is not included in the patch. Change-Id: I5fd868945585971dac3dd945804a4a2951b8c12d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101194 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2020-09-04xmloff: remove dead com.sun.star.comp.Draw.XMLStylesExporterMiklos Vajna
And test com.sun.star.comp.Draw.XMLOasisSettingsExporter instead in JunitTest_xmloff_unoapi. Note that the test code is also dead at the moment, because xmloff/qa/unoapi/xmloff.sce disables the xmloff.Draw.XMLSettingsExporter line, but let's not regress even more in that code. Change-Id: I04eb38aad193dfbfde5df42f3e367aa47dfd12ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102019 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
generated by cgit (git 2.34.1) at 2024-08-02 03:56:04 +0000