summaryrefslogtreecommitdiff
path: root/oox/source/shape
AgeCommit message (Collapse)Author
2021-02-11loplugin:refcounting generalise type checkingNoel
Change-Id: Ia013878ac9c2918d8eaf9aab16b291d8211e708f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110700 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-02introduce Degree100 strong_int typeNoel
Change-Id: I78f837a1340be0ca5c49097f543a481b7b43a632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108367 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-03tdf#128877 DOCX import: fix lost position of image cropped to shapeMiklos Vajna
Regression from commit f4ba484183a1e7b9824f10580d633466c266828f (ooxml import: supprt cropping to shape, 2019-05-13), which changed the type of a cropped-to-shape image from drawing.GraphicObjectShape to drawing.CustomShape. drawing.GraphicObjectShape worked because GraphicImport::lcl_attribute() in writerfilter/ had a check for drawing.GraphicObjectShape and did an explicit setPosition(). Doing the same for bitmap-filled custom shapes would be an option, but it would be ugly: scaling/translation/rotation/mirroring can only work together if they are only applied once, and that should happen in oox/, that's why we already have a mechanism to send the position from writerfilter/ to oox/ for WPS shapes. (<a:xfrm> contains the size, but not the position of the shape, so oox/ in itself could not know the position.) Fix the problem by improving ShapeContextHandler instead the pass the position from writerfilter/ to oox/ for <pic:pic> as well, the same is done for <wps:wsp> already since commit 6c4f737ec88a4f4dc5da8b2295ca5e7de2d4c24f (DOCX drawingML shape import: fix position when CustomShapeGeometry is set, 2013-11-21). Change-Id: I74a60136d0ca8383e58948711b47858823f42437 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105263 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-10-22long->tools::Long in hwpfilter..ooxNoel
Change-Id: I9ab8876aac7b2f8b488db6dfa9c6fd0cecd2238b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104626 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-29tdf#80526 DOCX: import word-wrap textbox settingRegényi Balázs
See option "Word wrap text in shape" in Format->Text Box and Shape->Text Attributes... of the selected textbox. Co-authored-by: Szabolcs Toth Change-Id: I7f2ca392089043c4bec20b943aa8c1975de72e5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103109 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-25fix Graphic duplication in import and add GraphicMapperTomaž Vajngerl
When importing writerfilter, we change to oox when importing images. This transition doesn't store any previous contexts and all instances are reset. The problem occurs when we have identical images because the transition erases all caches we have to determine if an image has already been imported or not, which causes that we import the same image multiple times which create unnecessary copies. This introduces the XGraphicMapper, which can be used to store the XGraphic for a key and can be transferred between writerfilter to oox. With this we can remember which images were already imported and don't create unnecessary internal copies which decreases memory. This also includes a test which checks that the import and export doesn't produce unnecessary copies of identical images. The test checks that for OOXML, ODF and MS Binary formats. Change-Id: I33dc19218c565937fab77e132b3a996c51358b6e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103283 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-22tdf#123610 DOCX shape import: keep text uprightSzabolcs Toth
Grab-bag attribute upright to keep text upright regardless of shape rotation, fixing the text direction in MSO after a round-trip. Co-authored-by: Balázs Regényi Change-Id: If18a12c7728317a7af093048b07bc392d2964389 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102690 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-07-19compact namespace: ooxNoel Grandin
Change-Id: I9ea016adcec334437da45296ee325453347836ae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99002 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-03loplugin:simplifypointertobool improveNoel Grandin
to look for the x.get() != null pattern, which can be simplified to x I'll do the x.get() == nullptr pattern in a separate patch, to reduce the chances of a mistake Change-Id: I45e0d178e75359857cdf50d712039cb526016555 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95354 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-26Fix loplugin:simplifypointertobool for libstdc++ std::shared_ptrStephan Bergmann
...where the get member function is defined on a std::__shared_ptr base class, so loplugin:simplifypointertobool used to miss those until now. (While e.g. using libc++ on macOS found those cases.) 366d08f2f6d4de922f6099c62bb81b49d89e0a68 "new loplugin:simplifypointertobool" was mistaken in breaking isSmartPointerType(const clang::Type* t) out of isSmartPointerType(const Expr* e); c874294ad9fb178df47c66875bfbdec466e39763 "Fix detection of std::unique_ptr/shared_ptr in loplugin:redundantpointerops" had introduced that indivisible two-step algorithm on purpose. The amount of additional hits (on Linux) apparently asked for turning loplugin:simplifypointertobool into a rewriting plugin. Which in turn showed that the naive adivce to just "drop the get()" is not sufficient in places that are not contextually converted to bool, as those places need to be wrapped in a bool(...) functional cast now. If the expression was already wrapped in parentheses, those could be reused as part of the functional cast, but implementing that showed that such cases are not yet found at all by the existing loplugin:simplifypointertobool. Lets leave that TODO for another commit. Besides the changes to compilerplugins/ itself, this change has been generated fully automatically with the rewriting plugin on Linux. Change-Id: I83107d6f634fc9ac232986f49044d7017df83e2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94888 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-05-19oox, svx, sw, xmlsecurity: clang-format these filesMiklos Vajna
I added these files more or less recently and they have long lines. Use clang-format to break at a sane column limit. Change-Id: Id4ef832e4843fc81f4a497385e49ccb835a7197f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94503 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-05-09compact namespace in i18npool..ooxNoel Grandin
Change-Id: I1de87468b56b86a1eeee09a612551ab119a1be8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93857 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-27Make upcasting css::uno::Reference ctor require complete typesStephan Bergmann
The main reason for the "home-grown" UpCast introduced with 904b3d1fceee5827076758ed2a81f80cb73493ca "Up-cast conversion constructor for css::uno::Reference" in 2013 was probably that we could not yet rely on C++11 std::is_base_of back then. A (welcome) side effect was that the derived class could be incomplete. However, specializations of UpCast relying on whether or not T2 is incomplete are obviously an ODR violation if the type is incomplete in some TUs and complete (and derived from T1) in others. And even if UpCast had internal linkage, it would still be brittle that its behavior depends on the completeness of T2 at the point of the template's instantiation, and not necessarily at the point of use. That means we should better base that ctor on std::is_base_of (which we can do now since 39a1edd6fec902ef378acce8af42c4d7fba280d0 "Make css::uno::Reference upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on Clang and GCC if the completeness requirements are not met. This change fixes all the cases where types need to be complete now, plus any resulting loplugin:referencecasting warnings ("the source reference is already a subtype of the destination reference"). Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-03loplugin:flatten in ooxNoel Grandin
Change-Id: Ia57944653fa10e864822518372acab83555e0f20 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91618 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-20tdf#42949 Fix IWYU warnings in oox/source/[e-v]*/*cxxGabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I6cd335e3055ca1dcebcaf0b26ec843b1937f0bce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90773 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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#42949 Fix IWYU warnings in oox/*/*hxxGabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I3d34eb4933ad574321c0de6a650fc89dd0aa353f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90144 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-26remove some unused local varsNoel Grandin
found by a more aggressive variant of loplugin:unusedvariables. This is my first pass, committing the simplest and most obviously unnecessary vars Change-Id: I9676a6e39a101937097788548764506c93811c57 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87414 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-15clang-tidy modernize-concat-nested-namespace in ooxNoel Grandin
Change-Id: I9877be75e1f7dcefdf7172d05dfbb0a63d06ced1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86803 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-14tdf#128304 export TB_RL writing mode as eaVirtMark Hung
and import eaVirt to TextWritingMode instead of TextPreRotateAngle (-90) degree of CustomShapeGeometry. CJK text in TB_RL writing mode are upright in Writer. It corresponds to eaVirt by its defintion. Change-Id: I2a8bc6676ad6af06b06e023adaa2f201a028d426 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86637 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-01-14tdf#129516 DOCX import: fix incorrect z-order with textboxesMiklos Vajna
Commit 3272c1eb5563f3bda2caa24f32b1018372622109 (related tdf#100074: prepare group shapes text input via writerfilter, 2018-10-01) tweaked the oox code, so that later it'll be able to call back to writerfilter to parse group shape text. That makes sense, but it also removed the reset of the group shape context, which means that two subsequent group shapes are now imported as a single group shape with a merged child list. Reset the group shape context again when writerfilter asks for the XShape from oox. If this causes a problem for the above scenario later, then it could be considered to handle this in ShapeContextHandler::endFastElement(). Change-Id: I14f7f0bab2c66c8430313d5b2daffe3160a58c27 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86712 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-01-13tdf#88205 Adapt uses of css::uno::Sequence to use initializer_list ctorMesut Çifci
Change-Id: I1c1e7b42211c51f572698efd3135e388f8fb2979 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86648 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-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-22Extend loplugin:external to warn about classesStephan Bergmann
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.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-08-27Simplify Sequence iterations in ooxArkadiy Illarionov
Use range-based loops, STL and comphelper functions Change-Id: Ic3a186e7381bd8391ab85a2602a30f06fe5db740 Reviewed-on: https://gerrit.libreoffice.org/78089 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Arkadiy Illarionov <qarkai@gmail.com>
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-07-31Improved loplugin:stringconstant (now that GCC 7 supports it): ooxStephan Bergmann
Change-Id: I177f9dd57fb3195db87a6b5ce3a231ab602b61f9 Reviewed-on: https://gerrit.libreoffice.org/76662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-20loplugin:referencecasting in oox..pyunoNoel Grandin
Change-Id: Ie920c154aef3074016704c632b15d99110b219aa Reviewed-on: https://gerrit.libreoffice.org/75974 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-06-19connectivity, oox: remove some unused includesMiklos Vajna
Change-Id: I8b39caafc157e309e638eec1a66d9302f1a11a73 Reviewed-on: https://gerrit.libreoffice.org/74307 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-06-12sw: merge some indentical switch-case branchesMiklos Vajna
Change-Id: I9c247f6d5b3d1309b6831a87c041de0a9cf6affc Reviewed-on: https://gerrit.libreoffice.org/73840 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-06-11tdf#42949 Fix IWYU warnings in include/svx/[sS][v-Z]*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ie2a4122d67d2d40732e6fd00b584f33edd802c5b Reviewed-on: https://gerrit.libreoffice.org/73476 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@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-14tdf#124754 sw docx import: do not override text color with -1 (auto) colorSerge Krot
Change-Id: Id821b0d8bef69a7124ee41558e822cf8b025df9d Reviewed-on: https://gerrit.libreoffice.org/72232 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
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-04-29tdf#124398 DOCX drawingML import: handle charts in group shapesMiklos Vajna
Regression from commit 8c73b16f5f18f3bc1dbf9ff6c1475db56b44d304 (DOCX import: declare wpg as a supported feature, 2013-12-05), the problem was that <wpg:graphicFrame> did not forward to to the relevant oox context, and also Writer had no idea how to create a com.sun.star.drawing.OLE2Shape. Fix the later by using the same service name that's in use for the non-groupshape case. Change-Id: Id3536854da7c1f01525bb38d801496ecebd4c161 Reviewed-on: https://gerrit.libreoffice.org/71505 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-04-26sw btlr writing mode: implement DOCX shape import for tbrlMiklos Vajna
Now that the btlr writing mode works reasonably well in table cells, the next context is shape text. But turns out that DOCX shape text lacked support in the easier tbrl case, so add that first. Also remove the char-level text rotation code in oox, that is effectively dead code since we import drawingML shapes as shape + Writer TextBox. Change-Id: I30c7793221cc3aceedfcfd9e4e1725634ebb3309 Reviewed-on: https://gerrit.libreoffice.org/71329 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-03-31tdf#120703 PVS: remove redundant static castsMike Kaganski
V572 It is odd that the object which was created using 'new' operator is immediately cast to another type. Change-Id: I54976062dc3f62eaaa79f89eff54454f0b24ac2c Reviewed-on: https://gerrit.libreoffice.org/69989 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-03-18PPTX import: save also OOXDrawing in InteropGrabBagGrzegorz Araminowicz
Change-Id: Ieaf341dd13e06046044f3523c3aad74476160402 Reviewed-on: https://gerrit.libreoffice.org/69328 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-01-25oox: turn on clang-format for WpsContextMiklos Vajna
This had manual consistent formatting. Recently it was broken, so bring back consisency by using clang-format. Change-Id: I742f9a4f328a7455f2e2c7dde4e3cb2624eb9178 Reviewed-on: https://gerrit.libreoffice.org/66885 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-01-08convert "*xxx.get()" to "*xxx"Noel Grandin
Change-Id: Ic307226591ff9702957ccdec486ccf70357eb6d9 Reviewed-on: https://gerrit.libreoffice.org/65951 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-01-07related tdf#100074: prepare group shapes text input via writerfilterThorsten Behrens
Put various preps into place, that enable us to read txbxContent from group shape children via the writerfilter parser, which gets us much more features Also: - store shapecontexthandler on wrapper class in writerfilter - move adding children shapes to ctor, not dtor - remove RuntimeException in Writer's XShapes::add(), aligns this with Draw/Impress API semantics, and helps here when trying to add the same shape a 2nd time (which we then simply ignore) - make oox's Shape notion of 'inside group' less ad-hoc - make SwTextBoxHelper::getTextRectangle() cope with more than CustomShape - so passing in a group shape will also yield some sensible bounding box - have SwTextBoxHelper handle group content, too - derive WpsContext from ShapeContext, so we can later substitute it for that inside WpgContext - keep WpgContext::onCreateContext() _for the moment_ with the old delegation to ShapeContext (needs to use WpsContext to enable writerfilter text input) Change-Id: I2b0f0583e21137f3321a8dc13823058b14d19773 Reviewed-on: https://gerrit.libreoffice.org/65914 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-11-02fix signatures of deleted copy/assign operatorsNoel Grandin
Change-Id: Id1a0749b78a7021be3564487fb974d7084705129 Reviewed-on: https://gerrit.libreoffice.org/62718 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-10-19oox WpsContext: bTextFrame is always falseMiklos Vajna
Since commit d379d18666aa42031359ca8eb34b0021960347ae (oox: import WPS shape with text as shape with textbox, 2014-06-18). Change-Id: I5cc1f9938a2c091c868e6e1572e7ae35e87109a7 Reviewed-on: https://gerrit.libreoffice.org/62016 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins
2018-10-15loplugin:constfields in ooxNoel Grandin
Change-Id: I1e110d193ebfa30ab1ab0d85bfb6dc409e341439 Reviewed-on: https://gerrit.libreoffice.org/61728 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-09-28oox: create ShapeContextHandler instances with an uno constructorMiklos Vajna
Change-Id: Ie780ff9f3a8c61d13ad10cc2dbe24d3ec165470e Reviewed-on: https://gerrit.libreoffice.org/61063 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins