summaryrefslogtreecommitdiff
path: root/include/svx/xmlgrhlp.hxx
AgeCommit message (Collapse)Author
2022-09-22use more string_view in svxNoel Grandin
Change-Id: I672f6cc93f3f00c54eb2be7fa490d656bb5f0b02 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140407 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-24use comphelper::WeakComponentImplHelper in SvXMLGraphicHelperNoel Grandin
and remove unused disposing() override Change-Id: I6423d9c3c418bb07f84e1622c8df6eac8ad762c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127406 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-20use cppu::BaseMutex in SvXMLGraphicHelperNoel Grandin
because passing a ref of a local member to a parent class means passing uninitialised data Change-Id: I1171c3e5f5df148c7e63dad451bf54dff23fe2aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127119 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-16tdf#92796 ODF import: remove unused bitmap fillsMichael Stahl
With CWS impress64 a partial fix for this was implemented to drop unreferenced named items including all non-color fills after ODF import, but this is only done in sd so move the code that does that to svx and call it from sc and sw as well. Implement some UNO interface for this, it's at least better than a magic string, and not obvious how a better solution would look like since it's known only at the end of the import if a bitmap is used or not. Another problem: when the Area tab is used to change to a different kind of fill, the items with the details for the previous fill aren't cleared, and so they are written to ODF files. Hence bitmaps in the file can be referenced even if they aren't actually used, and bloat up the files. Fix this by dropping all unused draw:fill-image-name attributes in ODF import. Also do the same for Gradient and Hatch fills; Transparency gradients can be combined with anything so leave them as they are. Change-Id: I0b591fd9f963d974d0c3e7208b99621ad61dd93c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118950 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
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-07-30inline some use-once typedefsNoel Grandin
Change-Id: I66400bcfef1d609662f44cc25a4984b68efb4b44 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99801 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-17pdfium: Make Insert -> Image... use VectorGraphicData for PDF.Jan Holesovsky
In principle, the current Svg/Emf/Wmf and PDF handling is trying to achieve the same thing: Keep the original stream untouched, provide a replacement graphics, and a kind of rendering. To hold the data, the Svg/Emf/Wmf and PDF were using different structures though. This commit consolidatates that, and makes the Insert -> Image... (for PDF) actually using the VectorGraphicData to hold the original stream. This breaks loading the PDF as a document via PDFium - I'll fix it in the next commit(s). Change-Id: Iac102f32b757390a03438c165e430283851cc10b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90561 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-02-02tdf#128302: Split SVXCORE_DLLPUBLIC from SVX_DLLPUBLICStephan Bergmann
Using SVX_DLLPUBLIC for both Library_svxcore and Library_svx had started to cause failures with clang-cl on Windows now, presumably due to devirtualization: > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::DataChanged(class DataChangedEvent const &)" (?DataChanged@SvxMetricField@@MEAAXAEBVDataChangedEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::PreNotify(class NotifyEvent &)" (?PreNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::EventNotify(class NotifyEvent &)" (?EventNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::Modify(void)" (?Modify@SvxMetricField@@MEAAXXZ) > linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::PreNotify(class NotifyEvent &)" (?PreNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::EventNotify(class NotifyEvent &)" (?EventNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z) > C:\lo-clang\core\instdir\program\svxcorelo.dll : fatal error LNK1120: 6 unresolved externals Replacing certain uses of SVX_DLLPUBLIC with the newly introduced SVXCORE_DLLPUBLIC (include/svx/svxdllapi.h) has been done on Linux as follows: > git grep -w --line-number -e SVX_DLLPUBLIC --and --not -e '#define SVX_DLLPUBLIC' >LINES to produce a file LINES containing all 640 uses. (Conveniently, all uses happen to be on different lines.) Manually create a file TOKENS with 640 corresponding lines, each containing the (class or function) name that is made SVX_DLLPUBLIC by in the corresponding line in LINES. Then > nm -D --def instdir/program/libsvxcorelo.so | grep -ivw '[vw]' | c++filt >SVXCORESYMS > nm -D --def instdir/program/libsvxlo.so | grep -ivw '[vw]' | c++filt >SVXSYMS > n=$(cat TOKENS | wc -l) > for ((i=1;i<="$n";++i)); do > tok=$(head -n "$i" TOKENS | tail -1) > printf @ > grep -Fw "$tok" SVXCORESYMS >/dev/null && printf svxcore > printf @ > grep -Fw "$tok" SVXSYMS >/dev/null && printf svx > printf '@ ' > head -n "$i" LINES | tail -1 > done to generate 640 output lines detailing for each SVX_DLLPUBLIC name occurrene whether it is mentioned in exports from neither (@@@), only from svx (@@svx@), only from svxcore (@svxcore@@), or from both libraries (@svxcore@svx@). The numbers that gives is 10 @@@ 180 @@svx@ 424 @svxcore@@ 26 @svxcore@svx@ The 10 @@@ ask for follow-up clean up, but most of them are just left as SVX_DLLPUBLIC for now. The exceptions are sxv::ITextProvider (include/svx/itextprovider.hxx) and SdrCustomShapeGeometryItem::PropertyPairHash (include/svx/sdasitm.hxx, where PropertyPairHash is a member struct of SVXCORE_DLLPUBLIC SdrCustomShapeGeometryItem). Keeping them as SVX_DLLPUBLIC would cause "unresolved externals" errors when linking Library_svxcore on Windows. The 180 @@svx@ are fine to keep as-is, and the 424 @svxcore@@ need rewriting. The 26 @svxcore@svx@ needed manual inspection to decide (in some cases, the chosen name in TOKENS was a too generic function name like Fill, in other cases it was the name of a class exported from one library but also mentioned in the arguments of a function exported from the other). And for sdr::table::SdrTableObj the class itself is defined in svxcore while the static member functions ExportAsRTF and ImportAsRTF are defined in svx. But MSVC does not allow to mark the class as SVXCORE_DLLPUBLIC and the two static member functions as SVX_DLLPLUBIC, so move the two functions out of the class. (There appears to be no real necessity that they were static member functions in the first place; they don't even need to be friends of the class. Nevertheless, this mixture of functionality from svxcore and svx in include/svx/svdotable.hxx may ask for follow-up clean up, one way or another.) All the output lines that need rewriting (all the @svxcore@@ ones, and the manually picked subset of @@@ and @svxcore@svx@ ones) are copied into a new file CHANGE (containing 451 lines). Then > sed -E -e 's|^@.*@.*@ ([^:]+):([0-9]+):.*$|sed -i -e "\2 s/SVX_DLLPUBLIC/SVXCORE_DLLPUBLIC/" \1|' <CHANGE >COMMANDS > . COMMANDS to do the changes. Change-Id: If9b6dd1c9e9ba2eb883dbdac4385d28c6fc8a203 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87794 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-03tdf#42949 Fix IWYU warnings in include/svx/x*Gabor Kelemen
New IWYU and recent developments in f-u-i helped to identify some non self contained files, those were fixed too. Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I5b91a82d25601041b73444f602d033ef62484ba8 Reviewed-on: https://gerrit.libreoffice.org/74563 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-11-27tdf#42949 Fix IWYU warnings in include/vcl/[f-h]*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ice2eb8c5994bf2ccb88972332ca4a1d3ed41752a Reviewed-on: https://gerrit.libreoffice.org/63826 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-06-12loplugin:constantparamNoel Grandin
Change-Id: Ia769b3176aea287cd57414d7ce8e88c6da43883e Reviewed-on: https://gerrit.libreoffice.org/55622 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-06-08Removed duplicated includeAndrea Gelmini
Change-Id: I41e32c7a792852351259cd37b37740db5c3f2aaa Reviewed-on: https://gerrit.libreoffice.org/55441 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins <ci@libreoffice.org>
2018-06-07vcl: svx: misc improvements to pdfium importingAshod Nakashian
Change-Id: I58f2fd973a731b148f40b37139cd74bac097a7d2
2018-06-07svx: share PDF stream when saving imported PDF as imagesAshod Nakashian
Still needs work, incomplete. Change-Id: Ide0c3f0792e816d64a81922a653a8afd77c7511a
2018-03-31loplugin:unusedfieldsNoel Grandin
Change-Id: Id2dea1d3a56d5d3be03c5a2a4f2ef530a05f9b19 Reviewed-on: https://gerrit.libreoffice.org/52185 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-03-29loplugin:unusedmethodsNoel Grandin
Change-Id: I7805ac9bc6f8c0aa5ba4804777e7d7c2c29a78f3 Reviewed-on: https://gerrit.libreoffice.org/52066 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-03-11Move (and rename) graphic stuff from svtools to vclTomaž Vajngerl
This is preparing to change how GraphicManager works where it won't base itself around GraphicObject anymore but Graphic. No functional or cosmetic change was made to the classes, only changes that were needed because of the move and rename. The only thing that wasn't moved is the GraphicRenderer as it is not needed in vcl for now (but makes sense to move it in the future to keep graphic stuff together). grfmgr was renamed to GraphicObject as the GraphicManager will be changed a lot and most likely moved out, so the name grfmgr won't make any sense anymore. All the UNO implementations were renamed with a prefix Uno and used the same name as the class name. This is made to be more specific which are the Uno objects (for example graphic.cxx contained the implementation of XGraphic, which is similar to graph.cxx contains Graphic). Change-Id: I54a2fa6c7e997469aaa7770db05244adb9f64137 Reviewed-on: https://gerrit.libreoffice.org/51068 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2018-03-07cache location and mime type when saving a graphic to a storageTomaž Vajngerl
Change-Id: If27a5f617a103da235d6690ea0447d6c64538dea Reviewed-on: https://gerrit.libreoffice.org/50810 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2018-02-21report the saved mimetype when saving graphic + mime from streamTomaž Vajngerl
When saving we need to determine which mime type to use for the graphic. Return this information back to the caller so the metadata can be written into the file if necessary. Also add function to determine the mime type from the XGraphic by converting it to a stream first (only then we can determine the format that will actually be used and written to the storage file. Change-Id: I796da715e47f29d77dea605a2769a2217ecd6ba5 Reviewed-on: https://gerrit.libreoffice.org/49992 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2018-02-13XGraphicStorageHandler: support loading graphic from streamTomaž Vajngerl
Needed for all the loading of images from base64 strings.. Change-Id: Ic1cb262b5d064e91690b0dc3bb3ab0e9ca0cda53 Reviewed-on: https://gerrit.libreoffice.org/49556 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2018-02-11extend XGraphicStorageHandler with saveGraphicByNameTomaž Vajngerl
We want to save the graphic with a specific name, usually this is when we want to use the same name that was used when reading the image from the document. Change-Id: I7419f0593dea333a60ce513190211e0409480e66 Reviewed-on: https://gerrit.libreoffice.org/49553 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2018-02-01add XGraphicStorageHandler interfaceTomaž Vajngerl
This is a XGraphicObjectResolver (future) replacement as it will not be needed anymore. All resolving from URL to URL will be replaced by loading, saving and serialization of XGraphic objects (when appropriate), which is covered by this interface and implementation by XmlGraphicHelper - the same that implements the XGraphicObjectResolver. Change-Id: I227634e443ce336218c2a2effaf34f9ef3576382 Reviewed-on: https://gerrit.libreoffice.org/49073 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2017-12-19inline use-once typedefsNoel Grandin
Change-Id: I5c3ffc03c26b3428f1f336e6ecba7838a1cf1157 Reviewed-on: https://gerrit.libreoffice.org/46764 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-28tdf#109202: Convert images to desired format in (f)odt filterKatarina Behrens
Pass down mimetype to SvXMLGraphicHelper Change-Id: I9c81c06d2a1d6168704440094081e99d0bcbbff9 Reviewed-on: https://gerrit.libreoffice.org/41893 Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2017-10-24loplugin:finalclasses in svxNoel Grandin
Change-Id: I74296e2185902498cd569ecde83905f718a41e84 Reviewed-on: https://gerrit.libreoffice.org/43715 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-16use rtl::Reference for SvXMLGraphicHelperNoel Grandin
Change-Id: I0052b29660fb6157f7e98c4e124f030ba439d304 Reviewed-on: https://gerrit.libreoffice.org/43417 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-07-27loplugin:constparams in svxNoel Grandin
and fix a bug in the plugin itself when calling operator's like the one on std::function<> Change-Id: I1617607107eeff06785c1841f69e13ad2926218e Reviewed-on: https://gerrit.libreoffice.org/40446 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-01-26Remove dynamic exception specificationsStephan Bergmann
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html> "Dynamic Exception Specifications" for details. Most changes have been done automatically by the rewriting loplugin:dynexcspec (after enabling the rewriting mode, to be committed shortly). The way it only removes exception specs from declarations if it also sees a definition, it identified some dead declarations-w/o-definitions (that have been removed manually) and some cases where a definition appeared in multiple include files (which have also been cleaned up manually). There's also been cases of macro paramters (that were used to abstract over exception specs) that have become unused now (and been removed). Furthermore, some code needed to be cleaned up manually (avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no configurations available that would actually build that code. Missing @throws documentation has not been applied in such manual clean-up. Change-Id: I3408691256c9b0c12bc5332de976743626e13960 Reviewed-on: https://gerrit.libreoffice.org/33574 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-12-04tdf#88206 replace cppu::WeakImplHelper* in svtools and svxJochen Nitschke
and remove unused implbase*.hxx and compbase*.hxx includes Change-Id: Iedf6b6dce09b5baf714a1b3394bb7fb3526cca82 Reviewed-on: https://gerrit.libreoffice.org/31594 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-10-07loplugin:staticmethods: svxStephan Bergmann
Change-Id: If03d9797fddd88662cf7d0ba2a70c2841983b37b
2016-09-13loplugin:override: No more need for the "MSVC dtor override" workaroundStephan Bergmann
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark overriding destructors as 'virtual'" appears to no longer be a problem with MSVC 2013. (The little change in the rewriting code of compilerplugins/clang/override.cxx was necessary to prevent an endless loop when adding "override" to OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager(); in chart2/source/inc/LifeTime.hxx, getting stuck in the leading OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.) Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
2016-08-17convert SvXMLGraphicHelperMode to scoped enumNoel Grandin
Change-Id: Ib0360b395fafe3c8123a0cc0fd0cbfd581fa5414
2016-03-17loplugin:constantparam in svxNoel Grandin
Change-Id: I50fa7e4c7525d2f8107a11d8203957a47680eb80 Reviewed-on: https://gerrit.libreoffice.org/23303 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
2015-10-23com::sun::star->css in include/sot to include/typelibNoel Grandin
Change-Id: I9cd92b53370a6b6018d2f7c648890f9c014a27de
2015-10-12Replace "SAL_OVERRIDE" with "override" in LIBO_INTERNAL_ONLY codeStephan Bergmann
Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
2014-04-01Explicitly mark overriding destructors as "virtual"Stephan Bergmann
It appears that the C++ standard allows overriding destructors to be marked "override," but at least some MSVC versions complain about it, so at least make sure such destructors are explicitly marked "virtual." Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
2014-03-27Second batch of adding SAL_OVERRIDE to overriding function declarationsStephan Bergmann
...mostly done with a rewriting Clang plugin, with just some manual tweaking necessary to fix poor macro usage. Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
2014-03-14svx: sal_Bool->boolNoel Grandin
Change-Id: I673d022c01b7d076120c026b236a37735b5043b0
2014-02-26cppuhelper: retrofit std::exception into overriding exception specsStephan Bergmann
Change-Id: I56e32131b7991ee9948ce46765632eb823d463b3
2013-12-31svx: Use constructor feature for SvXMLGraphicImportExportHelper.Matúš Kukan
Change-Id: Icc281ece80b81cdd95b6660c6a82077d283f5a62
2013-12-20Revert "svx: split into direct implementation getFactories"Matúš Kukan
Also reverts "These services are in fact implemented in svxcore library." This reverts commit 090674dcb085cd41f4628e4f07c9a2268a18e862 and commit 4a969ac35174520f1ffeb4f919f5d7bb6d99a628. This is embarrassing; needs more work.
2013-12-20svx: split into direct implementation getFactoriesMatúš Kukan
Change-Id: I888f10a923dc2b97247b2a66cc6bd116eee280a7
2013-11-09fdo#65108 inter-module includes <> include/svxNorbert Thiebaud
Change-Id: I5335182ea16695c77c2855b34c98220aea2befa1
2013-10-23fixincludeguards.sh: include/svxThomas Arnhold
Change-Id: I2c280be12f36c1538e922286745aabc62482423d
2013-09-05convert include/svx/xmlgrhlp.hxx from String to OUStringNoel Grandin
also fix the string comparison in SvXMLGraphicHelper::ImplGetGraphicMimeType which was previously comparing pointers. Change-Id: Icd1e76bcf60ec3af5b10cb48adfc97548a2bf4f1
2013-04-23execute move of global headersBjoern Michaelsen
see https://gerrit.libreoffice.org/#/c/3367/ and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
generated by cgit (git 2.34.1) at 2024-06-16 11:35:09 +0000