summaryrefslogtreecommitdiff
path: root/oox
AgeCommit message (Collapse)AuthorFilesLines
2021-10-05drop 'using namespace std' in o* r* x*Julien Nabet1-1/+0
Change-Id: I15d56d133cf464a3cb6483be785b1259c7f35b43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123120 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-03A more lightweight O[U]StringConcatenationStephan Bergmann4-15/+15
...compared to a full-blown O[U]String, for temporary objects holding an O[U]StringConcat result that can then be used as a std::[u16]string_view. It's instructive to see how some invocations of operator ==, operator !=, and O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit materialization of an O[U]String temporary, and how that expensive operation has now been made explicit with the explicit O[U]StringConcatenation ctor. (The additional operator == and operator != overloads are necessary because the overloads taking two std::[u16]string_view parameters wouldn't even be found here with ADL. And the OUString-related ones would cause ambiguities in at least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with RTL_STRING_UNITTEST, so have simply been disabled for that special test-code case.) Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-01tdf#144616 PPTX import: fix hyperlinks on shapesTibor Nagy1-1/+1
Follow-up to commit 6e200689eb309cdbe1e4f08311a400835de19bfb "tdf#141704 PPTX import: fix hyperlinks on images" Change-Id: Ie9f1ba56d03462bb8d7ab376e23c89c921a8bcd6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122610 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-09-30loplugin:constparams improve handling of pointer paramsNoel Grandin2-3/+3
Change-Id: I4c0002e72703eded435bfe4985f5b0121bf8524b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122843 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-28vcl: rename OutDevState to StackChris Sherlock1-6/+13
I have moved the header file to include/vcl/rendercontext as this will eventually be part of the RenderContext split from OutputDevice. State and associated enums have also been moved to the vcl namespace. I have also moved ComplexTextLayoutFlags into the vcl::text namespace. Change-Id: I0abbf560e75b45a272854b267e948c240cd69091 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121524 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-09-27tdf#141704 PPTX import: fix hyperlinks on images added via placeholderTibor Nagy2-3/+6
Note: see "Interaction..." in the local menu of the image of the first slide for manual checking of the fix. See commit 9bb91441b46d677860530d8bf9597c96561a1b0a "tdf#141704 PPTX import: fix hyperlinks on images" Change-Id: Iba372c095f76b263575d261a7a0fc98eda449bce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122429 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-09-22Extend loplugin:stringviewparam to starts/endsWith: ooxStephan Bergmann2-23/+29
Change-Id: I02b4352f02fe32f40c4fe0ab198d8ac094381c7a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122491 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-21tdf#142602 DOCX: export adjustment points of custom shape arrowsDaniel Arato (NISZ)3-26/+516
When exporting custom shape arrows LO used to fall back to writing out their plain vertex coordinates, losing the customizability of the shape after loading from file. This commit changes the export of some of the most commonly used arrow custom shapes to proper adjustment value export. Follow-up to commit 63cd67e5e18f01aca303131e148c80398a181a41 "tdf#92525 tdf#142398: fix export of simple custom shapes". Change-Id: If248556764bdb7e00cfde4ebe5b32bb380b1fa19 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121901 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-09-20clean up ambiguous confusing rectangle APIs like IsInside()Luboš Luňák1-1/+1
Reading 'rectA.IsInside( rectB )' kind of suggests that the code checks whether 'rectA is inside rectB', but it's actually the other way around. Rename IsInside() -> Contains(), IsOver() -> Overlaps(), which should make it clear which way the logic goes. Change-Id: I9347450fe7dc34c96df6d636a4e3e660de1801ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122271 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2021-09-17Some more uses of rtl_math_(u)StringToDoubleStephan Bergmann1-1/+4
...to avoid construction of temporary O(U)Strings, in anticipation of using C++17 std::from_chars once that is available in all our baselines, similar to 99a1290b3f2c8584db0a33fe48adf93dccce3a92 "Use existing rtl_math_stringToDouble" Change-Id: Ib92504341c3ae9dd599f91725b0af5b7219a201d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122219 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-16tdf#115933 XLSX import: fix permission for editingTünde Tóth1-0/+1
The passwords for editing in XLSX documents created with Excel weren't asked and verified. Note: LibreOffice supports only a subset of the hashing algorithms specified in MS-OE376, according to DocPasswordHelper::GetOoxHashAsVector() and https://docs.microsoft.com/en-us/openspecs/office_standards/ms-oe376/f70a4140-340b-4e94-a604-dff25b9846b1. Also the documents encrypted with unsupported algorithms got edit protection now, but it's not possible to add permission to edit them (copy of these documents are still editable). Change-Id: Iabc90f6bba4ed071dd2c60e9dea905481816964b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121497 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-09-15loplugin:constvarsNoel Grandin2-2/+2
Change-Id: I9b35d6333afa6b305bf73fc55a7e60c8365674e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122134 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-15Use <comphelper/servicehelper.hxx> implementing XUnoTunnel part 1Mike Kaganski1-1/+1
The header got some changes: 1. Move UnoTunnelIdInit and isUnoTunnelId into 'comphelper' namespace 2. Rename UnoTunnelIdInit to UnoIdInit, as a precondition to replace of uses of OImplementationId with it, including in XTypeProvider 3. Introduce convenience functions 'getSomething_cast' to cast between sal_Int64 and object pointers uniformly. 4. Rename getUnoTunnelImplementation to getFromUnoTunnel, both to make it a bit shorter, and to reflect its function better. Templatize it to take also css::uno::Any for convenience. 5. Introduce getSomethingImpl, inspired by sw::UnoTunnelImpl; allow it handle cases both with and without fallback to parent. 6. Adjust UNO3_GETIMPLEMENTATION_* macros TODO (in separate commits): - Drop sw::UnoTunnelImpl and sw::UnoTunnelGetImplementation - Replace all uses of OImplementationId in core with UnoIdInit - Deprecate OImplementationId in <cppuhelper/typeprovider.hxx> - Change implementations of getSomething to use getSomethingImpl - Revise uses of getSomething to use getFromUnoTunnel Change-Id: If4a3cb024130f1f552f988f0479589da1cd066e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122022 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-14tdf#141704 PPTX import: fix hyperlinks on imagesTibor Nagy1-0/+80
Hyperlinks on images pointing to the "first/last/ previous/next" slides and "exit presentation/go to the website/go to the slide" weren't imported. Note: images added via the Content placeholder will be fixed later. Change-Id: Idda1ff6fd3243b06262637c7c8e579e78309e317 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121369 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-09-12clang:optin.performance.PaddingNoel Grandin1-5/+5
Excessive padding in 'struct chart::TickInfo' (11 padding bytes, where 3 is optimal). Excessive padding in 'class EscherBlibEntry' (10 padding bytes, where 2 is optimal). Excessive padding in 'struct oox::drawingml::ConditionAttr' (8 padding bytes, where 0 is optimal). Excessive padding in 'struct oox::drawingml::Constraint' (12 padding bytes, where 4 is optimal). Excessive padding in 'struct (anonymous namespace)::Number' (10 padding bytes, where 2 is optimal). Change-Id: If7573afa8a794497c9a2bf1c7c15e8f11ff11407 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121993 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-11cid#1454626: Uninitialized scalar field (oox/chartexport)Julien Nabet1-0/+1
Change-Id: If3c623f04cd912ea419bb720178553a43cb713e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121933 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-09-10tdf#126426: support for hyperlinks in TextParagraphContextVasily Melenchuk2-1/+18
Usually hyperlinks are processed by TextBodyContext, but for grouped shape we accidentaly gone into TextParagraphContext It has almost all possibilities to process txbxContent, but not hyperlinks. Additionally some hyperlink char attributes (color and underline) can expand to follow up ordinal text. Additional small hack applied to avoid this. Unfortunately this is not a final solution: such document fails roundtrip and hyperlinks are lost after saving to DOCX. Change-Id: Ie954f53696bd872cb1f59cb586fb55f6cd7c73bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121172 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-09-08convert some OSL_ENSURE -> assertNoel Grandin1-1/+1
where we are just provide checking for a following static_cast. I'd rather have an explicit assert failure than a random crash Change-Id: Iab6c6b056341018deaa74b78b075e564f72c58d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121814 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-06[API CHANGE] oox: fix import of chart date categoriesDennis Francis5-19/+61
Before this fix, date categories imported in oox's DataSourceContext were stored as formatted strings according to number format code in <c:formatCode> under the <c:cat> tree. As a result chart2 could not recognize them as dates. This causes problems like: * The axis that is linked to date categories cannot use the scaling/range-selection(min/max)/increments specs mentioned as axis properties. This results in distorted/unreadable chart renders w.r.t the date axis. * No re-formatting is attempted as per the number format provided for axis. This patch introduces a role qualifer argument to the XDataProvider interface method createDataSequenceByValueArray to support categories of date type via this method. When exporting to oox, write date categories and format code under <c:cat> <c:numRef> <c:numCache> This patch also fixes some discrepancies in date axis interval computation (auto mode) found by already existing unit tests. Change-Id: Ibc53b0a56fdddba80ba452d5567ce98d80460ea7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121525 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-09-01tdf#143127 tdf#143130 ooxml export: fix lost image/shape in chartBalazs Varga2-39/+41
tdf#143127: Add officeRel namespace to XML_userShapes to fix invalid file error in MSO. tdf#143130: Add mbUserShapes variable to ShapeExport class to fix export of embedded shapes of charts in DOCX. Change-Id: I10c1dbf905af96d6a63a9243514b32a6440e63f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121035 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-09-01clang-tidy:readability-redundant-member-initNoel Grandin5-13/+3
Change-Id: I78339f1df1f0c55c7edaa552940b07d1ada3aeb5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121386 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-01tdf#143942: oox: import/export labels from <c15:datalabelsRange>Dennis Francis8-23/+239
When <c15:showDataLabelsRange> boolean flag is present, the imported label texts are added as the first text field in oox data label model. The cell-range associated is also preserved. The export part preserves the how labels were store originally in <c15:datalabelsRange>. However in order to make the custom labels reflect the contents of the cells in the associated cell-range, more work needs to be done. For this the labels present in <c15:datalabelsRange> needs to be made available as a data-sequence with a new "role" like "point-labels" in XInternalDataProvider implementation and and make the label renderer read this data source rather than consulting the custom label fields property which is static after import. Change-Id: Ibc7045fa5ea209d463680c96efb49a06662d2500 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121313 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-08-31tdf#142645 PPTX import: convert "ctrTitle" text to slide nameTibor Nagy1-1/+1
(i.e. centered title) similar to <p:ph type="title"/>. See commit 7eb0e52527e729a21973e70d5be8e0a6779ec748 "tdf#142648 PPTX: import long slide names to avoid broken link export", commit 253bee65bc24d999c3629a4d503d0fa01b355cfc "tdf#142646 PPTX import: count repeating slide names" etc. Change-Id: I5f25f04f23981ce2ff64dc792fe8464682d749a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121295 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-08-27tdf#112450 correct points and size for polyline in VML importRegina Henschel5-10/+145
The points in file source might have units. Decode was missing. maWidth and maHeight are used in ShapeBase::convertAndInsert(), and moCoordSize is used in PolyLineShape::implConvertAndInsert(). So ShapeContext needs to provide both in case of importing a polyline. That was missing. Word writes the size into the coordsize attribute of the v:polyline element. But from VML specification it need not exist, but bounding rectangle of points has to be used. That is added too. Unclosed polyline cannot be filled in LO and ODF, a fill is only possible for a closed polygon. LO defines a sequence of points as being closed, if first point == last point. The import is adapted to that behavior. Word allows an unclosed polyline to have filling. That cannot be represented with a simple PolyPolygonShape but would need a CustomShape. Because the user cannot yet edit points in a CustomShape but can do that in a PolyPolygonShape, the v:polyline element is not converted to a CustomShape on import and not to DML on export. LO would first need an UI for editing points of a CustomShape. Change-Id: I23d08fda2005f8b36488e1d9ba32e565d8a0f803 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121042 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-08-25i#114206 sd: unshare shape properties for the same type before insertionMiklos Vajna1-8/+0
Regression from commit 9bd99c08e8662becdd5ac8b47ef6f953c14e65fc (CWS-TOOLING: integrate CWS os128, 2009-06-03), the problem was that the SvxItemPropertySet was both used to store a property map (information about UNO properties) and also as a descriptor for a not yet inserted shape. The above commit improved performance by sharing a single instance of an SvxItemPropertySet for the same shape types: this works for the property map, but doing the same for property values is problematic. In practice, this eliminates the need for a workaround in oox/, the user-visible problem was that loading a document with smartart, then loading a document with group shapes (but without smartart) and saving it would copy information from the first, closed document (!) to the second document. Just removing the oox/ workaround would make make -C oox -sr CppunitTest_oox_drawingml CPPUNIT_TEST_NAME="testGroupShapeSmartArt testTdf131082" fail, unsharing the descriptor piece makes it pass again. Change-Id: Icdff2108ad0da18ce0ade081b1938dd74bc0ae90 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120996 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-08-25Introduce o3tl::saturating_cast for floating-point->integer conversionMike Kaganski1-8/+1
Change-Id: I73191e5ab25fdd9fd8a788db9858b5eb9d3ab955 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120885 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-08-24Avoid overflowing floating-point -> integer conversionStephan Bergmann1-1/+10
...seen at <https://ci.libreoffice.org/job/lo_ubsan/2113/> with recently- introduced sw/qa/core/data/ooxml/fail/ofz37458-1.docx during CppunitTest_sw_filters_test, > /oox/source/vml/vmlformatting.cxx:202:38: runtime error: 6.40969e+23 is outside the range of representable values of type 'long' > #0 0x2b40e7a68a1e in oox::vml::ConversionHelper::decodeMeasureToEmu(oox::GraphicHelper const&, rtl::OUString const&, int, bool, bool) /oox/source/vml/vmlformatting.cxx:202:38 > #1 0x2b40e7a68cf1 in oox::vml::ConversionHelper::decodeMeasureToHmm(oox::GraphicHelper const&, rtl::OUString const&, int, bool, bool) /oox/source/vml/vmlformatting.cxx:208:47 > #2 0x2b40e7bc3bb7 in oox::vml::TextBoxContext::TextBoxContext(oox::core::ContextHandler2Helper const&, oox::vml::TextBox&, oox::AttributeList const&, oox::GraphicHelper const&) /oox/source/vml/vmltextboxcontext.cxx:190:39 > #3 0x2b40e7b3190f in oox::vml::ShapeContext::onCreateContext(int, oox::AttributeList const&) /oox/source/vml/vmlshapecontext.cxx:526:24 > #4 0x2b40e7b34ee9 in oox::vml::RectangleShapeContext::onCreateContext(int, oox::AttributeList const&) /oox/source/vml/vmlshapecontext.cxx:639:26 > #5 0x2b40e7b34f42 in non-virtual thunk to oox::vml::RectangleShapeContext::onCreateContext(int, oox::AttributeList const&) /oox/source/vml/vmlshapecontext.cxx > #6 0x2b40e5fdae26 in oox::core::ContextHandler2Helper::implCreateChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) /oox/source/core/contexthandler2.cxx:100:34 > #7 0x2b40e5fddffb in oox::core::ContextHandler2::createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) /oox/source/core/contexthandler2.cxx:204:12 > #8 0x2b40e5fdfb32 in non-virtual thunk to oox::core::ContextHandler2::createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) /oox/source/core/contexthandler2.cxx > #9 0x2b40fe645540 in writerfilter::ooxml::OOXMLFastContextHandlerWrapper::lcl_createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) /writerfilter/source/ooxml/OOXMLFastContextHandler.cxx:2006:38 > #10 0x2b40fe60a6a4 in writerfilter::ooxml::OOXMLFastContextHandler::createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) /writerfilter/source/ooxml/OOXMLFastContextHandler.cxx:254:21 > #11 0x2b40fe60a942 in non-virtual thunk to writerfilter::ooxml::OOXMLFastContextHandler::createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) /writerfilter/source/ooxml/OOXMLFastContextHandler.cxx > #12 0x2b40ca28e9de in (anonymous namespace)::Entity::startElement((anonymous namespace)::Event const*) /sax/source/fastparser/fastparser.cxx:465:44 > #13 0x2b40ca2899ed in sax_fastparser::FastSaxParserImpl::callbackStartElement(unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, unsigned char const**) /sax/source/fastparser/fastparser.cxx:1306:21 Apparently lacking a general concept to report failure for too-large input values here, just silently do a saturating conversation, as seems to be the general approach for this kind of filter code. Change-Id: I4511a5dd63bdbc973d60a521bd3aef445dea3fb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120941 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-23tdf#142351 chart ooxml import: fix category axis cross positionBalazs Varga1-2/+2
Set PROP_CrossoverPosition value regardless of the mrModel.mbAuto value, which is a different thing. This element specifies that this axis is a date or text axis based on the data that is used for the axis labels, not a specific choice. Change-Id: Ifa291aac2f4bb3981d968de3489b23f1af485104 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120592 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-08-20Make some scripts more portableIlmari Lauhakangas1-1/+1
Change-Id: Ia89059eea51ca396a7c74143625ac9a6706de198 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120773 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2021-08-19loplugin:constmethodsNoel Grandin2-5/+5
Change-Id: I786096b989daa6004a6527aafbe825b6f0a22d90 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120710 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-19Fix typosAndrea Gelmini1-1/+1
Change-Id: I45243c6312545d51409574447e27f5320d4da79c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120493 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-08-19Drop GetSdrObjectFromXShape and use SdrObject::getSdrObjectFromXShapeMike Kaganski4-12/+12
Change-Id: I0d233878ee49fcdc1338ec3bd700e5482d558163 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120694 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-08-18loplugin:constparamsNoel Grandin2-3/+3
Change-Id: Ic7410f836e584df45101e78e345c8b3c8d355e09 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120680 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-18loplugin:passstuffbyrefNoel Grandin2-6/+6
Change-Id: I4f01eb3842ef198f02af274f54afb2760c820a4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120655 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-16tdf#130924 : replace debugging printf calls with SAL_INFO/SAL_WARNEmircan Agac1-4/+1
Change-Id: I4ca3a3a7ced1dac90ae896cc8a0abb08f830744e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120551 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2021-08-16Drop tools::Rectangle::getX/getY, which are just duplicates of Left/TopMike Kaganski2-5/+6
The change allowed to simplify many places where previously this API was used, to avoid inefficient calculations (e.g., moving rectangle keeping its size, and then immediately changing the size). Change-Id: Ica2dc594d91cae83e2c2740c1f4fb23f44998916 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120461 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-08-16pass OutlinerParaObject around by valueNoel Grandin2-16/+8
since it uses o3tl::cow_wrapper, so it is really just a wrapper around a pointer, no point in allocating it on the heap Remove assert in SdrText::SetOutlinerParaObject, which was bogus anyhow, because it was comparing pointers, not deep equality. And since we are now being more efficient and avoiding copying of the internal data in OutlinerParaObject, we hit this assert. Change-Id: I6dbfaab5ee2ca05b2001baf63110041e469df9c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120510 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-15tdf#143860 non-primitive needs custGeom not prstGeomRegina Henschel1-1/+2
Error was, that for a custom shape with type 'non-primitive' method DMLPresetShapeExporter::WriteShape() was called. For such shapes the method GetOOXMLPresetGeometry() returns preset type 'rect' and in case the shape had no handles, that preset geometry was written. In my solution I exclude shapes of type 'non-primitive' from using DMLPresetShapeExporter, because such shapes never belong to a OOXML preset shape. Change-Id: I714f69c98fe15c2b7e70dc0a474a7f85ad757034 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120511 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-08-14tdf#142605 use frame size in oox export of BezierCurveRegina Henschel4-2/+118
The export had used the bound rectangle of PolyPolygonBezier. But that contains control points. Use API position and size instead. I have not incorporated the changes into existing WritePolyPolygon, but have made an own version for SdrPathObj, because I find it easier to read and maintain, than having a lot of case distinctions depending on the shape type. Change-Id: I2e646c4f5fa37174c4979855212ca72f2dfa447e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120407 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-08-14Fixed documentation references to the custom shape generate scriptHossein3-19/+34
* Fixed references to the custom shape generation script in the oox/README.md to use generate.sh instead of README.md * Added README.md to oox/source/drawingml/customshapes folder * Moved documentation parts from the script to the README.md The README script was renamed to generate.sh before in the commit 59577dbb84fae18a3216d57ffec6008af157ce9b Change-Id: Id167b32c7a101806c33126ea1642a0194d693231 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119376 Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2021-08-13tdf#143852: Revert "Move ActionLockGuard up a bit"Mike Kaganski1-2/+2
This reverts commit b791974837a99ead793b4ead6760b2f4e5237de2. Change-Id: I4bb95c915aa27b509ea2a41602ba2198c2f20cea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120370 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-08-13split SvNumberFormatter into it's own headerNoel Grandin3-0/+4
so I can make changes without running into cyclic dependencies between header files Change-Id: I98a91c7cc66002ba745cdb8239e5cc267922a45c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120412 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-09tdf#64086 tdf#143623 tdf#66250 XLSX: fix named ranges in chartsBalazs Varga2-0/+3
tdf#64086: fix broken XLSX import of named ranges in charts Do not create inner data table in Calc for charts, if the data source contains named ranges. Use the named ranges (local sheet names and global names) to find the data source of charts, so it will be updated correctly if we modify the values in cells. Second part: tdf#143623: chart OOXML, offapi: export the named ranges in charts with the proper special (non-ooxml-standard) Excel syntax. We need to add "[0]" characters before a global named range for proper refreshing of chart data. Also we have to add the sheet name to the local named ranges even if it's on the same sheet, but only in case of charts. Because of this, add property RefConventionChartOOXML to com::sun::star::sheet::FormulaParser, which specifies that use special OOXML chart syntax in case of OOXML reference convention, when parsing a formula string. Third part: tdf#66250 ODF chart: export the reference of named ranges in case of charts, if the named range contains a valid reference. Note: maybe export the name of named ranges would be a nicer solution in the future. Follow-up of commit 3c766512984feff739377d0f0af46558ee7139fd "Related: tdf#64086 Add FormulaGrammar::isRefConventionOOXML()". Thanks to Eike Rathke for his help. Change-Id: I10d8563fb436092e833682f331c25b0c0829ef86 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118862 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-08-07Fix typoAndrea Gelmini1-1/+1
Change-Id: I4fa33b3c1cc9e1dc666777dd2ceaf2432f2374b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120131 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-08-06tdf#132696 PPTX import: fix missing SmartArt when it's part of a group shapeMiklos Vajna3-1/+35
Regression from commit e9986153e44d7ec6ca9c5f1373971de74dcbacda (PPTX import: import SmartArt drawing into single GroupShape, 2019-03-14), the problem was that oox::ppt::PPTShape::addShape() and oox::drawingml::Shape::addShape() were not in sync. PPTShape unconditionally maps SmartArt to shapes, while the shared Shape class defaults to converting it to a non-editable metafile. The above commit changed the handling of in-groupshape SmartArts to go via Shape::addShape() instead of PPTShape::addShape(), which exposed the underlying problem that the convert-to-metafile mechanism is currently only working in the DOCX case. Fix the problem by again ignoring the convert-to-metafile flag for the PPTX import case. This also exposed a previously hidden problem: make -C oox -sr CppunitTest_oox_drawingml CPPUNIT_TEST_NAME="testGroupShapeSmartArt testTdf131082" started to make testTdf131082 fail. The tweak in Shape::createAndInsert() fixes the testcase failure, but likely there is a deeper problem there, unrelated to the regression. Change-Id: I4e1e9645eaa266d0d7560767c3c59ba9549ccdb4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120122 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-08-06Move ActionLockGuard up a bitMike Kaganski1-2/+2
Change-Id: Iaa1f3a5e2b9ad0605c53efa6a17d467159597927 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119991 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-08-05Pass context and resource string down to boost::locale separatelyNoel Grandin3-6/+6
because this is often on a hot path, and we can avoid the splitting and joining of strings like this. Change-Id: Ia36047209368ca53431178c2e8723a18cfe8260a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119220 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-05tdf#123643 Import/Export for hyperlinks on text boxesSamuel Mehrbrodt3-8/+13
Change-Id: Ied436c4a619985f27e5854369d319d76c05890d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120028 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2021-08-04Duplicating checksMike Kaganski1-2/+0
Change-Id: Ie4df9a0287876d12d320060468f635cea759d305 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119978 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-08-04tdf#143476 improve import of lockedCanvasRegina Henschel2-17/+51
A lockedCanvas is used in Word 2007 to include dml-shapes. It is treated similar to a group, only that its content is not editable. This patch changes the implementation so, that the lockedCanvas is imported as group. Prior only content was imported in the case the content was a single custom-shape or a single group. That has resulted in these errors: Image or line in a lockedCanvas were not imported at all. Only one of several shapes in a lockedCanvas was imported. I have changed mpShape to mpShapePtr to reflect the data type and be consistent with ShapeContext. The patch changes GraphicImport so, that lockedCanvas as special version of a group is detected and handled. That solves regression from commit 3262fc5ef3bde5b158909d11ccb008161ea95519 Change-Id: I57005e64ff073bca6ebb46a404486203fb6802ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119684 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-07 05:27:08 +0000