summaryrefslogtreecommitdiff
path: root/include/oox
AgeCommit message (Collapse)Author
2020-03-12Revert "loplugin:constfields in oox"Noel Grandin
This reverts commit a84e3df74eecc8778e3d5be5dd80ad4ddb511edf. Now that we know that making fields has negative side effects like disabling assignment operator generation. Change-Id: I7b45b7ead281cf3a9202ca6aabc55ee5033e5331 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90332 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-09tdf#131143 OOXML chart: fix missing data points of scatter chartBalazs Varga
If "values-x" property is empty, export X-Y (scatter) chart category labels in c:xVal/c:strRef/c:strCache/c:pt/c:v to avoid missing data points at next import. Change-Id: Ib5ed99bd1186bd1cfa3e2559aff1c8d214547017 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90011 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-03-03tdf#101181 Implement glow effect on shapesTamas Bunth
Glow effect is a color-blurred outline outside of the shape. In ooxml document it is specified with the <a:glow> element. The commit contains the following: - Add support for importing and exporting <a:glow> from ooxml documents. - Assign new properties to XShape which stores glow-related attributes. - A new 2D primitive is introduced in module 'drawinglayer' which is responsible for representing the glow primitive which is to be rendered. + A glow primitive is a clone of the original shape which has been scaled up slightly and a new color has been assigned to it. The radius of the glow effect and the color is defined in the <a:glow> element being imported. - A blur algorithm is introduced in module 'vcl', which is called during rendering the primitive. + The blur algorithm works on a bitmap. + Since the algorithm is CPU-intensive, the result is cached in the processor and it is recalculated only if needed. - Add support for importing and exporting glow effect to ODF format. For that, new attributes of element <style:graphic-properties> has been added: + loext:glow, which can have the values "visible" or "hidden" + loext:glow-radius: which holds the radius of the glow effect in cm. + loext:glow-color: holds the color of the glow effect - Tests have been added to assert properties after pptx import and export. Change-Id: I836aeb5e0f24e2c8d5725834c8c0f98083bc82e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89125 Tested-by: Jenkins Reviewed-by: Tamás Bunth <btomi96@gmail.com>
2020-03-03tdf#84399 VML import: map <v:shape o:spt="202"> to TextShapeMiklos Vajna
This partially reverts commit 81f9fe3a14f0fc99afbfa7ce3a26a9c7855d0919 (fdo#74401 VML groupshape import: only handle v:rect as TextShape, 2014-03-19), which wanted to map triangles to custom shapes. It was overlooked that we can have not only explicit rectangles and custom shapes, but also <v:shape> elements which have their shape type explicitly set to TextBox. The later is now again handled similar to rectangles. This keeps the triangle case working, but fixes the <v:shape o:spt="202"> case. We need to make this decision while parsing the XML, so some rework is needed to have earlier access to its container (group shape or draw page) and also to its shape type. Change-Id: I33a4b3cd03b0df5d93cffa19e7ea834113df2bdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89852 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-02-21Drop o3tl::optional wrapperStephan Bergmann
...now that macOS builds are guaranteed to have std::optional since 358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to Xcode 11.3 and macOS 10.14.4". The change is done mostly mechanically with > for i in $(git grep -Fl optional); do > sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \ > -e 's/\<o3tl::optional\>/std::optional/g' \ > -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i" > done > for i in $(git grep -Flw o3tl::nullopt); do > sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i" > done (though that causes some of the resulting #include <optional> to appear at different places relative to other includes than if they had been added manually), plus a few manual modifications: * adapt bin/find-unneeded-includes * adapt desktop/IwyuFilter_desktop.yaml * remove include/o3tl/optional.hxx * quote resulting "<"/">" as "&lt;"/"&gt;" in officecfg/registry/cppheader.xsl * and then solenv/clang-format/reformat-formatted-files Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-28New loplugin:unsignedcompareStephan Bergmann
"Find explicit casts from signed to unsigned integer in comparison against unsigned integer, where the cast is presumably used to avoid warnings about signed vs. unsigned comparisons, and could thus be replaced with o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx) o3tl::make_unsigned requires its argument to be non-negative, and there is a chance that some original code like static_cast<sal_uInt32>(n) >= c used the explicit cast to actually force a (potentially negative) value of sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the cast to avoid a false "signed vs. unsigned comparison" warning in a case where n is known to be non-negative. It appears that restricting this plugin to non- equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=) is a useful heuristic to avoid such false positives. The only remainging false positive I found was 0288c8ffecff4956a52b9147d441979941e8b87f "Rephrase cast from sal_Int32 to sal_uInt32". But which of course does not mean that there were no further false positivies that I missed. So this commit may accidentally introduce some false hits of the assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan --enable-dbgutil) `make check && make screenshot`. It is by design that o3tl::make_unsigned only accepts signed integer parameter types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in include/oox/helper/helper.hxx is used with both signed and unsigned types, so needs a little oox::detail::make_unsigned helper function for now. (The ultimate fix being to get rid of the macro in the first place.) Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-24loplugin:makeshared in ooxNoel Grandin
Change-Id: I6502e7be4881834b143ec7207c432881b2ae263c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87322 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-10use more std::make_sharedNoel Grandin
found using 'git grep', I tried using clang-tidy, but it only successfully found a tiny fraction of these Change-Id: I61c7d85105ff7a911722750e759d6641d578da33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86526 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-28Revert "tdf#46037: remove configurationhelper in oox/vbaproject"Julien Nabet
This reverts commit 276a90c6b3fb046df13ae85dcdec5f28f23ee527. Reason for revert: as requested here https://gerrit.libreoffice.org/c/core/+/85759 Change-Id: Ib6a1cedf758deadff4e8949e8ecf35d25565dcc7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85927 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-12-23tdf#46037: remove configurationhelper in oox/vbaprojectJulien Nabet
Change-Id: I431216749e70f531a26432cb25909ff3c7fb3de5 Reviewed-on: https://gerrit.libreoffice.org/85715 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-19sal_Char->char in oox..registryNoel Grandin
Change-Id: Icc7f2a32696c30317c1ee77ef39d682d5f5a80b9 Reviewed-on: https://gerrit.libreoffice.org/85512 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-05make some classes module privateNoel Grandin
Mark some stuff SAL_DLLPUBLIC_RTTI in include/vcl/metaact.hxx in order to make ASAN happy. Change-Id: I97febe0968bf58b9cbe60ce647f0ada25e6f4bb0 Reviewed-on: https://gerrit.libreoffice.org/84202 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-01Introduce o3tl::optional as an alias for std::optionalStephan Bergmann
...with a boost::optional fallback for Xcode < 10 (as std::optional is only available starting with Xcode 10 according to <https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS and macOS is still Xcode 9.3 according to README.md). And mechanically rewrite all code to use o3tl::optional instead of boost::optional. One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per fed7c3deb3f4ec81f78967c2d7f3c4554398cb9d "Slience bogus -Werror=maybe-uninitialized" should no longer be necessary (and whose check happened to no longer trigger for GCC 10 trunk, even though that compiler would still emit bogus -Wmaybe-uninitialized for uses of boost::optional under --enable-optimized, which made me ponder whether this switch from boost::optional to std::optional would be a useful thing to do; I keep that configure.ac check for now, though, and will only remove it in a follow up commit). Another longer-term benefit is that the code is now already in good shape for an eventual switch to std::optional (a switch we would have done anyway once we no longer need to support Xcode < 10). Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses boost::property_tree::ptree::get_child_optional returning boost::optional, so let it keep using boost::optional for now. After a number of preceding commits have paved the way for this change, this commit is completely mechanical, done with > git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g' (before committing include/o3tl/optional.hxx, and relying on some GNU features). It excludes some files where mention of boost::optional et al should apparently not be changed (and the sub-repo directory stubs). It turned out that all uses of boost::none across the code base were in combination with boost::optional, so had all to be rewritten as o3tl::nullopt. Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b Reviewed-on: https://gerrit.libreoffice.org/84128 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-22make some classes module-privateNoel Grandin
Change-Id: If7303a082e06f6937fca911c578a40475546cda2 Reviewed-on: https://gerrit.libreoffice.org/83442 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-22tdf#128153 docx/VML: apply style properties to shape textJustin Luth
This replaces LO 4.3 commit 8766011bccfd0f12f8dd77d2f94eb16e2e8c3471 DOCX import: set document-level font size default based on default para style ...and is needed for tdf#118947, since bogus DEFAULT_VALUEs really hinder determining what a table style should override. Shape text should inherit the font size from the style that is specified. In many cases, it will not be specified, and therefore the default style was appropriate, but in cases where a style IS specified, then of course use that fontsize ... and every other character and paragraph property. HOWEVER, I only added the properties used in vml import for now, and I skipped asian/complex fontnames since VML only handles CharHeight, and not CharHeightAsian/Complex. -note: this does not affect direct formatting - it just sets default value at the shape level, not at the paragraph level. So far I have only looked at DOCX:VML - which satisfies the unit tests. There are other codepaths that lead to PushShapeContext though, and this should be easy to expand to other import situations. I've tried lots of asserts to find unit tests that should be modified, and so far they all seemed to point to VML - although round-tripping doesn't use VML and still requires at minimum the CharHeight property to be overridden, so limiting non-VML to that to maintain backward compatibility, and reduce regression footprint. Since we have to emulate here (since paragraph styles are not supported on Draw text), a perfect solution cannot possibly be found - specifically in cases where multiple paragraphs exist in one shape with different styles applied, or where some pararaphs apply a paragraph property and others do not. Compromise 1: For ambiguous paragraph styles, fallback to the default paragraph style. Rationale: Normally, most styles inherit from default and only change a couple of properties. So MOST of the properties will match the normal style. The chances that the default style will be correct are more likely than that some other random default would be. -note: no existing unit tests were ambiguous Compromise 2: Ideally, each paragraph could report whether it had DIRECT formatting, and the paragraphs could be walked through instead of the shapes. But I don't think that is reasonably possible in this SyncProperties situation. At first I had a grabbag framework setup that monitored when a paragraph property was set, and then skipped applying that property. But I later noticed that the PropertyState for paragraph properties actually did seem to reflect that - which is a better solution if it works properly. Regression potential: -for VML: should be limited to non-charheight properties where the default style sets some weird default, and an ambiguous style sets it back to the program default. Prior to this patch, the default style value wouldn't apply. On the flip side (and more likely scenario), non-ambiguous cases will use the correct value and look more like MSWord, as seen in many existing unit tests that now use corrected fonts. -for non-VML: should be none since I limit it to only CharHeight which was previously emulated by changing the program default. Change-Id: I8f1fb7ed01f990dbf998ebe04064c2645a68e1aa Reviewed-on: https://gerrit.libreoffice.org/81365 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-13tdf#117658 PPTX import: fix duplicated math object handlingMiklos Vajna
We used to recurse into both arms of <mc:AlternateContent>: while the intention is that an importer either reads <mc:Choice> or <mc:Fallback>. Fix this by converting PPTShapeGroupContext to be a FragmentHandler2, this way FragmentHandler2::prepareMceContext() is invoked, which knows how to do this correctly. This requires declaring "a14" as a supported namespace, e.g. SdOOXMLExportTest2::testMathObject() would fail without it. This also requires keeping "a14" unsupported in the Calc case, e.g. ScFiltersTest::testControlImport() would fail without it. Finally the "Convert this to FragmentHandler2" TODO in SlideFragmentHandler::onCreateContext() from 2011 can be removed with this. Change-Id: I883237902c71cb515e810a8e34443c9eeaca48b0 Reviewed-on: https://gerrit.libreoffice.org/82623 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-11-05tdf#108065 tdf#128609 OOXML chart export: fix transparent color gradientBalazs Varga
Linear and axial color gradients keep their solid or gradient transparencies. Change-Id: I37dfe016864bded49c767cea5c8c865455281de0 Reviewed-on: https://gerrit.libreoffice.org/81308 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2019-10-29loplugin:finalclasses in ooxNoel Grandin
Change-Id: I95f69d99194f91851b2ef86bebf20006fa32fef3 Reviewed-on: https://gerrit.libreoffice.org/81656 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-15tdf#127964 PPTX import: fix shape fill handling: style vs slide backgroundMiklos Vajna
Regression from commit 943a534ac7cb3df513583e226c986dafd8ba246b (tdf#123684 PPTX import: fix wrong background color for <p:sp useBgFill="1">, 2019-04-23), the problem was that we didn't handle the case when a shape had an XML fragment like this: <p:sp useBgFill="1"> <p:style> <a:fillRef idx="1"> <a:schemeClr val="accent1"/> </a:fillRef> </p:style> </p:sp> i.e. the shape both wants to use background fill and it has a style declaring how to fill it as well. We gave the style a priority, while PowerPoint gives the background fill a priority. Fix the problem by not setting the fill from the style in case the background fill is already set. Change-Id: Ie1b56e5615219138a5b7ddd7a2b25295b991bc05 Reviewed-on: https://gerrit.libreoffice.org/80804 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-10-14New loplugin:getstrStephan Bergmann
...to find matches of ... << s.getStr() (for the rtl string classes) that can be written as just ... << s Some notes: * The OUStringToOString(..., RTL_TEXTENCODING_UTF8) is left explicit in desktop/source/app/crashreport.cxx (even though that would also be done internally by the "<< OUString" operator) to clarify that these values are written out as UTF-8 (and not as what that operator << happens to use, which just also happens to be UTF-8). * OUSTRING_TO_CSTR (include/oox/helper/helper.hxx) is no longer used now. * Just don't bother to use osl_getThreadTextEncoding() in the SAL_WARN in lingucomponent/source/hyphenator/hyphen/hyphenimp.cxx. * The toUtf8() in the SAL_DEBUG in pyuno/source/module/pyuno_module.cxx can just go, too. Change-Id: I4602f0379ef816bff310f1e51b57c56b7e3f0136 Reviewed-on: https://gerrit.libreoffice.org/80762 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-14loplugin:stringadd look for unnecessary temporariesNoel Grandin
which defeat the *StringConcat optimisation. Also make StringConcat conversions treat a nullptr as an empty string, to match the O*String(char*) constructors. Change-Id: If45f5b4b6a535c97bfeeacd9ec472a7603a52e5b Reviewed-on: https://gerrit.libreoffice.org/80724 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-10tdf#98603 export runs with correct lang attribute (2/2).Mark Hung
Obtain lang attribute of rPr element from CharLocale, CharLocaleAsian, or CharLocaleComplex based on the script type of exported text. There are several other call sites of WriteRunProperties, like those in chartexport, and those for text fields, Here I leave the default to CharLocale so it fallback to western locale as it did before. Change-Id: I33679517dd88f9e415933decc02f10afc807ad3b Reviewed-on: https://gerrit.libreoffice.org/79973 Tested-by: Jenkins Reviewed-by: Mark Hung <marklh9@gmail.com>
2019-10-01tdf#127777 OOXML chart export: fix X axis position setting "CrossBetween"Balazs Varga
Export ShiftedCategoryPosition value into the CrossBetween OOXML tag. Change-Id: I3d8b298ed47c5326ee4faf0e8663c8c79d5a1d86 Reviewed-on: https://gerrit.libreoffice.org/79502 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-09-19improve and enable loplugin:fragiledestructorNoel Grandin
Where the problem was benign and the class was not extended, I marked the class as final. Where the problem was benign and the class was extended, I marked the relevant callee methods as final. Other cases were excluded in the plugin. Change-Id: Idb762fb2206af4e8b534aa35ff77f8368c7909bc Reviewed-on: https://gerrit.libreoffice.org/79089 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-05tdf#127166, tdf#123903 improve import/export of line stylesRegina Henschel
I have added import and export of prstDash line styles, for OOXML and for binary MS Office formats. This includes: Corrected Dot <--> Dash confusion, corrected some wrong defaults, added support for hairlines tdf#127267, take care of treating length 0 as 100%. tdf#108064 has introduced some mapping from our standard line styles to OOXML prstDash. I have removed that and implemented to export our styles as custDash and recover them back on import. That way the dashing looks initially the same in MS Office. I have removed the now wrong test. Binary MS Office formats have no custom dash styles AFAIK, therefore I have not changed the export of our styles there, but only added support for prstDash styles. Change-Id: Ia8cc8f90df6fdbe42adfc0236cc52becc670b333 Reviewed-on: https://gerrit.libreoffice.org/78372 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2019-09-02loplugin:constmethod in ooxNoel Grandin
Change-Id: Ie6c9c60288accf7096288aa67d091548e43687cd Reviewed-on: https://gerrit.libreoffice.org/78397 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-26loplugin:unusedmethodsNoel Grandin
Change-Id: I9d1abe62e7e0ae3434e0b2d440d6ccf0435e97cc Reviewed-on: https://gerrit.libreoffice.org/78131 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-23loplugin:returnconstval in ooxNoel Grandin
Change-Id: Id83744fcb90d1bf6e6fe048858f48a4944351494 Reviewed-on: https://gerrit.libreoffice.org/78013 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-21tdf#101322 Chart OOXML Export: fix missing subtitleBalazs Varga
Concatenate subtitle and main title texts, if both exist, just like at the XLS/DOC export, because OOXML does not support subtitles. If we only have a subtitle, export the whole subtitle shape instead of the title shape, keeping its properties. Change-Id: If6a27c023fcce58f4549a0edad44027bb0348b93 Reviewed-on: https://gerrit.libreoffice.org/77499 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2019-08-18Revert "loplugin:unusedmethods"Noel Grandin
This reverts commit 7990680e92e4fba376ef4f9346d1bc53661bde30. screenshot build is failing Change-Id: Idfe4cac73edaf9be1e704c0bd734e858643defda Reviewed-on: https://gerrit.libreoffice.org/77654 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-17loplugin:unusedmethodsNoel Grandin
Change-Id: I781a514787c83063dadd549ee043bbb264eee060 Reviewed-on: https://gerrit.libreoffice.org/77619 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-15tdf#126746 Add support for import/export line caps for .pptx formatBartosz Kosiorek
With this commit I have added importing and exporting line caps, which could be (for pptx format: rnd Round Line Cap sq Square Line Cap flat Flat Line Cap Also exporting of these caps are added. Change-Id: I799485048a2a7ac8df89f004e177d507f86ce99d Reviewed-on: https://gerrit.libreoffice.org/77233 Reviewed-by: Regina Henschel <rb.henschel@t-online.de> Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl> Tested-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2019-08-13warn on load when a document binds an event to a macroCaolán McNamara
a) treat shared/Scripts equivalently to document scripts This doesn't automatically warn/block running those scripts when used in a freshly loaded document on its own however because DocumentMacroMode::checkMacrosOnLoading will see at... if ( m_xData->m_rDocumentAccess.documentStorageHasMacros() || hasMacroLibrary() ) that the document contains no macros and flip the allow macros flag to true so that potentially new uses of macros added by the user during the edit are allowed to run b) so, add an additional flag to indicate existence of use of macros in a document c) for odf import, set it when a script:event-listener tag is encountered d) for html import when registerScriptEvents or SwFormatINetFormat::SetMacroTable is called e) for doc import when Read_F_Macro or StoreMacroCmds is called as well for good measure f) for xls import when registerScriptEvent or ScMacroInfo::SetMacro is called g) for oox import when VbaProject::attachMacros is called Change-Id: Ic1203d8ec7dfc217aa217135033ae9db2888e19b Reviewed-on: https://gerrit.libreoffice.org/77131 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-08-09tdf#126746 Fix exporting closed Polylines to PPTXBartosz Kosiorek
In previous implementation the closed shapes was imported as a polylines without closing joint. As a result the joint style was not applied. This patch fixes that, and allow proper PPTX export. TODO The same issue needs to be fixed for PPT export Change-Id: I557daac1ba02330d8923f7eda3476e67d8711384 Reviewed-on: https://gerrit.libreoffice.org/77179 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2019-08-05SmartArt: store diagram data model in SdrObjectGrzegorz Araminowicz
It will allow modifying loaded diagram and exporting it. This data is used for regenerating diagram instead of parsing xml fragment every time. Also provided an interface for UI that can be extended to show, add and remove nodes from data model. It is stored as SdrObject field because diagram top-level shape is group shape. Item set doesn't exist for them and storing data in child shapes is not possible here because children are removed and recreated on every diagram reload. Change-Id: I84e5ec955f638b254fef9ef9d1731ca7938982b7 Reviewed-on: https://gerrit.libreoffice.org/76121 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-07-24tdf#114166 DOCX chart import: fix missing complex categoriesBalazs Varga
Now complex category labels are visible, and the inner data table contains the correct texts of the category columns. Note: repeating call of createDataSequenceByValueArray() API function can create all columns of the complex categories. See also commit 6c4e21a234f12e1310ba06f9859e08b424acf8bf "bnc#812796: Correctly handle static value array for OOXML charts." Change-Id: I333b79be35a24a912bb9e662116d0c85809a8fb2 Reviewed-on: https://gerrit.libreoffice.org/75776 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2019-07-17tdf#42949 Fix IWYU warnings in include/ooxGabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I89303217fd1141b2cfe248e5e6c0818ba01cf9d9 Reviewed-on: https://gerrit.libreoffice.org/75178 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-07-15tdf#126193 Chart OOXML: Export Multi-level category labelsBalazs Varga
Fix export of Multi-level category axis labels with the correct OOXML tags (as the OOXML Standard requested) in the correct order. Also fix tdf#126195: but only the export part of the whole fault, which combined (united) the text of the category axis labels at different levels. Change-Id: Iefcef00818a3bb2ee1671bf693335904be471722 Reviewed-on: https://gerrit.libreoffice.org/75299 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2019-07-14Fix typoAndrea Gelmini
Change-Id: I14151a92ce51f2228534f9eab69959a182a4dfed Reviewed-on: https://gerrit.libreoffice.org/75581 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-07-14Fix typoAndrea Gelmini
Change-Id: Iac526c1a210276e6b8c752e3028d0b911be0795b Reviewed-on: https://gerrit.libreoffice.org/75582 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-07-09SmartArt: improve organization chart layoutGrzegorz Araminowicz
layout shapes in two steps: * first calculate vertical child shapes count for every shape (taking into accout hierBranch alg variable) * then actual layout using that count to calculate size for subtrees Change-Id: I2e5ca34ed3383aa9502c52511cc1fb2bee215572 Reviewed-on: https://gerrit.libreoffice.org/75195 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-07-02SmartArt: make if-node functions relative to current presentation nodeGrzegorz Araminowicz
* maxDepth calculates maximum depth of associated data node children (instead of per-diagram max depth) * cnt counts children of associated data node (instead of looking up presOf node and if not found counting presentation node children) Change-Id: Ifb50510acb9e6a3d2655197102060ec1c207075b Reviewed-on: https://gerrit.libreoffice.org/75000 Tested-by: Jenkins Reviewed-by: Grzegorz Araminowicz <grzegorz.araminowicz@collabora.com>
2019-07-02tdf#125554 PPTX export: handle gradient transparency for gradient fillMiklos Vajna
Regression from commit cfc1f4ea4889f768d689a0df71519e9bcb707bc0 (oox: disable gradient fill grab-bag for PPTX, 2019-02-05), the problem was that in the past grab-bag roundtrip worked (in some cases) for this shape fill case, but true roundtrip did not. So when the commit disabled grab-bags (since their color pointers in the theme don't work in the PPTX case), a previously not implemented feature now started causing a real problem. Fix the bug by adding support for transparent linear gradients on the exports side. This means that in case the import creates both a fill gradient and a transparency gradient, then now the export creates markup based on both, not only based on the fill gradient. Change-Id: I99fa3caba2b2884c2acb7e0704bbeb0b6cffd4a4 Reviewed-on: https://gerrit.libreoffice.org/74968 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-06-28tdf#126115 Chart OOXML Export: fix individual markerBalazs Varga
Export linechart custom (individual) datapoint marker settings into a <dPt> tag, as the OOXML Standard requires. Change-Id: I939196c9ea6e091ac9dadb4d62dd85d5408d599c Reviewed-on: https://gerrit.libreoffice.org/74837 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-05-20Use DBG_UTIL instead of OSL_DEBUG_LEVEL for the OOX dumping stuffTor Lillqvist
We want it to be possible to compile an arbitrary subset of the source files for debugging. DBG_UTIL, on the other hand, has to be consistent across the whole build. We should not use OSL_DEBUG_LEVEL to switch (internal) API on/off. Change-Id: Ia5111a36326ad7ad4c72d9e8f7ad88c8dbe8e272 Reviewed-on: https://gerrit.libreoffice.org/72616 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2019-05-20tdf#125360: PPTX: Shape fill transparency is not exportedTamás Zolnai
.. if the original shape fill is defined with a theme Override the alpha value with the current value get from FillTransparence API attirbute even if the color is defined with a style or a color scheme. Change-Id: I09d26238a9c2b501279e6749687dc535e614bbd6 Reviewed-on: https://gerrit.libreoffice.org/72596 Tested-by: Jenkins Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2019-05-18tdf#125346: PPTX export: Shape has wrong fill color comming from themeTamás Zolnai
Write the correct theme path to the InteropGrabBag, the same path what is generated and checked in the export code. Change-Id: I32617c1a11cf3bafb142f7c8839b498aaac49aa0 Reviewed-on: https://gerrit.libreoffice.org/72500 Tested-by: Jenkins Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2019-05-14SmartArt: regenerate diagram commandGrzegorz Araminowicz
It removes diagram content and rebuilds shape tree from diagram markup. Diagram should appear unchanged - editing will be added in future commits. Change-Id: I6bfc21956a1a23e55d3c7a74384db71d957d690d Reviewed-on: https://gerrit.libreoffice.org/71584 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-05-10SmartArt: support diagram backgroundGrzegorz Araminowicz
Solved by adding additional shape filling whole diagram. MS PowerPoint does the same when converting SmartArt to shapes. Background shape is also copied when loading from drawingML fallback, appearently there is no background information. Corrected SmartArt import tests, so that they are aware of extra shape. Change-Id: I6154f8e1b34e5867ab582d6fc54459c7c93edbac Reviewed-on: https://gerrit.libreoffice.org/72012 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-05-03The -fvisibility-ms-compat hack is no longer needed for UBSan on Linux...Stephan Bergmann
...with latest Clang trunk towards Clang 9. All the no-longer necessary hacks are made conditional on new NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY, which is still set for UBSan builds with older Clang on Linux (but which should eventually be purged). Various classes needed additional SAL_DLLPUBLIC_RTTI annotations, as building with UBSan instrumentation can generate references to RTTI symbols from additional places like outside a dynamic library that used to hide those symbols by default (but used to not hide them for old UBSan builds thanks to the -fvisibility-ms-compat hack). The odr-violation suppressions in solenv/sanitizers/asan-suppressions (which is not referenced from anywhere in the code base, but meant to be included in an ASan/UBSan build's ASAN_OPTIONS env var) are also no longer needed when NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY is false. Change-Id: I24ec3e388b0cbab50dbe2bf008d9569bff7bf25a Reviewed-on: https://gerrit.libreoffice.org/70829 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>