summaryrefslogtreecommitdiff
path: root/oox
AgeCommit message (Collapse)AuthorFilesLines
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann7-73/+73
This is a prerequisite for making conversion from OUStringLiteral to OUString more efficient at least for C++20 (by replacing its internals with a constexpr- generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount, conditionally for C++20 for now). For a configure-wise bare-bones build on Linux, size reported by `du -bs instdir` grew by 118792 bytes from 1155636636 to 1155755428. In most places just a u"..." string literal prefix had to be added. In some places char const a[] = "..."; variables have been changed to char16_t, and a few places required even further changes to code (which prompted the addition of include/o3tl/string_view.hxx helper function o3tl::equalsIgnoreAsciiCase and the additional OUString::createFromAscii overload). For all uses of macros expanding to string literals, the relevant uses have been rewritten as u"" MACRO instead of changing the macro definitions. It should be possible to change at least some of those macro definitions (and drop the u"" from their call sites) in follow-up commits. Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-27ofz#24934 practically infinite loop on eofCaolán McNamara1-2/+8
Change-Id: Iaa6121f3a0088978c57718610bc9baf9bcfe6fee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101489 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-27tdf#135653 OOXML import: fix OLE background colorAttila Bakos1-1/+8
When importing a .docx file Writer used to ignore the 'filled' and 'fillcolor' attributes in the 'shape' tag belonging to an OLE object. Now both these are imported and displayed correctly. Co-authored-by: Daniel Arato (NISZ) Change-Id: I2e6b880d88e4c46af6f3f2316ee966bac1a1f2e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100922 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-25GetProperty extracts property to mAny alreadyCaolán McNamara1-1/+1
so its already available to assign to nVal and doesn't need to be refetched Change-Id: Ie4ed1a63873847007c85fca24aff0724ee7e65c3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101338 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-24crashtesting: exception on reexport of fdo55178-3.xlsx to xlsxCaolán McNamara1-2/+3
since... commit acfd9e9ca2dfd76536c072e21c65cb3efc6aac80 Date: Mon Jul 27 00:31:04 2020 +0200 tdf#128345 PPTX: add transparence gradient for fill in chart use GetProperty which checks for exceptions and put result on success into mAny Change-Id: If327848031910f47eb05e5998fa2b3265e8e258a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101275 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-24tdf#134174 Fix the rotation of bitmap filled custom shapes.Gülşah Köse2-0/+28
During import we were rotating only custom shape. Not its bitmap. Custom shape and its bitmap rotated with same rotation value in that commit. Change-Id: I02d19c820670df7b4d1622836156c6bf8ed1c154 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101255 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2020-08-24GetProperty extracts property to mAny alreadyCaolán McNamara1-1/+1
so its already available to assign to nVal and doesn't need to be refetched Change-Id: Iecfa5e7546b0ef7915999335995e43d85692dfa9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101273 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-23tdf#134118 Chart OOXML import: fix gaps in month based dataBalazs Varga1-1/+10
Leave gaps instead of zeroes, like MSO does, if data ranges contain empty cells at month based time resolution. Change-Id: Ie934b56d9d5cb556bcca41e0e4ddce3ea65f7228 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100573 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-21Fix typosAndrea Gelmini2-2/+2
Change-Id: I8dc0cdcfe6bd90efc596df28e6c6d968b92618b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101098 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-08-21Fix typo in codeAndrea Gelmini1-2/+2
Change-Id: I77720baeb8d379589b9daee4ca10db56324051fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101123 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-19tdf#123647 Chart XLSX export: fix missing empty chartTünde Tóth1-0/+5
Save empty chart as empty bar chart, because a chart without chart type is invalid. Change-Id: Ieb9cc4300070b5280565fe814ba0343640dfff0a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100844 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-18tdf#132555 PPTX VML import: handle stroke properties of image shapesMiklos Vajna4-0/+49
ComplexShape::implConvertAndInsert() returns early in the graphic object shape case, so stroke model is not applied at all. Also fix a problem in ShapeBase::finalizeFragmentImport(), where the shape type had no stroke, but the shape itself had, and the later should win. The warning in OleObjectGraphicDataContext::onCreateContext() now points out that <mc:AlternateContent> is ignored as a child of <a:graphicData>, which probably should be addressed at some stage, but it's not required to fix the missing stroke. Change-Id: I4ab43b4c6d40d9f43caad22b85f5b885fa8b4ef1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100952 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-18tdf#134563 Add UNO API for custom leader linesBalazs Varga4-5/+11
If its ShowCustomLeaderLines=true, data series uses leader lines for labels with custom alignment. Add also OOXML import/export of custom data series setting. Change-Id: I8e6f7cb457c38b84aa40c917e69704862262a96e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98323 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-14loplugin:simplifybool moreNoel Grandin4-4/+4
look for expressions like !(a && !b) which can be expanded out Change-Id: I72515a9638762b050f9a258c08da39ebfa2ef8e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100579 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-13Remove some unused includesMiklos Vajna1-1/+0
Change-Id: Iea6b931b1f2328886354f70ad81a3e07367db717 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100669 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-13loplugin:stringstatic also look for local staticsNoel Grandin4-6/+6
Add some API to O*StringLiteral, to make it easier to use in some places that were using O*String Change-Id: I1fb93bd47ac2065c9220d509aad3f4320326d99e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100270 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-12SvTreeListBox can move into toolkit headers nowCaolán McNamara1-2/+1
Change-Id: I6b3b6ef1530a192f4b6bf87aa9688687063683ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100591 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-11loplugin:flattenNoel Grandin1-18/+18
Change-Id: I6560756eb63856a22b43e3e65a7b7843cd2d5376 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100447 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-10tdf#133015 Fix table position during import multicol textbox.Gülşah Köse1-1/+1
Change-Id: Ied1a03ff9f4556a551738b698ccb284fe74299da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100414 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2020-08-10tdf#133015 Inherit numCol from placeholder.Gülşah Köse1-0/+13
Change-Id: I402a40be7e8899ca017996f2bf77a2fb884b9462 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100372 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2020-08-10tdf#133015 Do not import multicol table text on master.Gülşah Köse3-3/+6
Change-Id: I0a1b1dc2f9b314858ed90347065407bcd1dbbb73 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100311 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2020-08-09tdf#128345 PPTX: add transparence gradient for fill in chartRegina Henschel2-6/+99
Export cases: Add transparence gradient on solid color fill by treating the color fill as gradient with identical start and end color. Add solid transparence on color gradient, by treating transparence as gradient. Import: Add missing property PROP_FillTransparenceGradientName to spnCommonPropIds so that it is available in spObjTypeFormatEntries. Otherwise transparence gradients will be skipped on import. Change-Id: I56218ec1afcc5bd1ce0324ca50c03e0b44f76c58 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99464 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2020-08-07Fix typosAndrea Gelmini1-1/+1
Change-Id: Ic28a1cdc779af9438555acd3bf85312e5e244fe6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100336 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-07oox: VML export: convert ESCHER_Prop_AnchorText to v-text-anchorMichael Stahl1-0/+41
Change-Id: I903cac8d7b02138680613b5a1b6dab4b1c448158 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100333 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-08-07oox: VML export: produce bottom-to-top in a better wayMichael Stahl1-10/+26
Replace code added in 090c61eb93db4302d4565d5f11f7673190835fdb with something that uses the already generated ESCHER property; this lets a warning about the unhandled property disappear too. Change-Id: Ieed83dd8e17e92eea9901124fce5e6da2a17196a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100332 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-08-07tdf#134977 Chart OOXML: fix import of custom data labelTünde Tóth1-0/+1
Use the data series properties for the default properties of the custom data labels. Change-Id: I651fa030276dfdec13b5801c0188bfd07c498b49 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99987 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-06oox: VML export: for rotated text shape, produce bottom-to-topMichael Stahl1-1/+16
This is for shapes that fail the lcl_isTextBox() check in VMLExport::StartShape(), they can be rotated too but with a different property than the "TextPreRotateAngle" that is used in VMLExport::EndShape(). Change-Id: I530aae8b7138f47bae8434e205632f5f4adbb231 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100249 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-08-06tdf#134183 PPTX: improve import of transparency in multi-step gradientsMiklos Vajna3-3/+60
Impress core only support a single step, improve the conversion from multi-step to single step to take transparency into account explicitly. Once we select the widest segment, look backwards and forward if there are other next segments which have the same RGB color, just different transparency and include them. This helps in general, because in case a 0% or 100% transparency is mishandled, that's very visible. Change-Id: I11d593c01a6a4b16149ce74c1408c2a39895e941 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100231 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-06tdf#135184 add linecaps in chartsRegina Henschel2-14/+15
Chart is currently not able to interpret property linecap. But in case of linecap 'round' or 'square', line dashes lengths are adapted so that they look same as in MS Office (tdf#134053). This does not work, if the corresponding linecap property is not interpreted. Dashed border of data labels is not fixed because of bug tdf#135366. In addition I have fixed errors in prstDash detection, which I have noticed while creating unit tests. The unit tests cover file text, not visual appearence. Change-Id: I8cf2d2b2fc0923c2882f8148b4550bc363270480 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99562 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2020-08-04oox smartart: add support for <dgm:layoutNode ... chOrder="t">Miklos Vajna3-1/+41
This changes the order of children, which matters when they have no explicit ZOrder. With this, the text shapes on the arrow shape are on top of the arrow, not behind it. The trick is that nominally chOrder can be "t"(op) or "b"(ottom), defaulting to bottom, but there is a difference between an explicit "b" and not setting it. When not setting it, the layout node is expected to inherit it from its parent layout node, recursively. This would probably make sense for other algorithms as well, but set it only for the linear algorithm for now, as that's where we have a bug document showing the PowerPoint behavior. Change-Id: I433f92c620149ef5590aebc8cbf43110e1d2fb85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100047 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-04loplugin:simplifybool a little more aggressiveNoel Grandin1-2/+2
with expressions like !(a && b) Change-Id: Id2acec2a8d0eaaa8e5e37dbd2cae7281be36572e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100040 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-03tdf#133687 Fix the placeholders priority order.Gülşah Köse1-2/+19
When we don't have type attribute on slide but have on slidelayout we have to use it instead of default type. Change-Id: Ibb874b5ee39c48641484fe1a8686f66c31695f76 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99904 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2020-08-03oox smartart, linear layout: limit height of children to parent sizeMiklos Vajna1-0/+12
Constraints are OK to request more, but it seems PowerPoint doesn't allow leaving the parent, which simplifies the layout as well. Change-Id: Id67a8740f1eff506e4beae0c797ad50e0218dfe6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99993 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-03oox smartart, linear layout: fix scaling of spacing without rulesMiklos Vajna1-3/+43
With this, finally the arrow shape has the correct horizontal position and width, even if the markup is as complex as the PowerPoint UI generates it (the previous version was a more minimal version). Change-Id: I59f237c582053067e890180a1ae40471e5f46dea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99894 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-03tdf#42949 Fix IWYU warnings in include/[t-x]*/*hxxGabor Kelemen1-0/+1
Recheck after 7-0 branchoff Also drop the now unused file include/vcl/field.hxx Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I9e54c82f50d1e02a0f99858939cac999fc66f7de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99261 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-01Avoid UBSan signed-integer-overflowStephan Bergmann1-1/+1
...during CppunitTest_sd_import_tests_smartart: > oox/source/drawingml/diagram/diagramlayoutatoms.cxx:656:50: runtime error: signed integer overflow: 1924451 - -2147483647 cannot be represented in type 'int' > #0 in oox::drawingml::AlgAtom::layoutShape(std::shared_ptr<oox::drawingml::Shape> const&, std::__debug::vector<oox::drawingml::Constraint, std::allocator<oox::drawingml::Constraint> > const&, std::__debug::vector<oox::drawingml::Rule, std::allocator<oox::drawingml::Rule> > const&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:656:50 > #1 in oox::drawingml::ShapeLayoutingVisitor::visit(oox::drawingml::AlgAtom&) at oox/source/drawingml/diagram/layoutatomvisitors.cxx:202:19 > #2 in oox::drawingml::AlgAtom::accept(oox::drawingml::LayoutAtomVisitor&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:386:14 > #3 in oox::drawingml::LayoutAtomVisitorBase::defaultVisit(oox::drawingml::LayoutAtom const&) at oox/source/drawingml/diagram/layoutatomvisitorbase.cxx:32:16 > #4 in oox::drawingml::ShapeLayoutingVisitor::visit(oox::drawingml::LayoutNode&) at oox/source/drawingml/diagram/layoutatomvisitors.cxx:243:5 > #5 in oox::drawingml::LayoutNode::accept(oox::drawingml::LayoutAtomVisitor&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:1452:14 > #6 in oox::drawingml::LayoutAtomVisitorBase::defaultVisit(oox::drawingml::LayoutAtom const&) at oox/source/drawingml/diagram/layoutatomvisitorbase.cxx:32:16 > #7 in oox::drawingml::ShapeLayoutingVisitor::visit(oox::drawingml::LayoutNode&) at oox/source/drawingml/diagram/layoutatomvisitors.cxx:245:5 > #8 in oox::drawingml::LayoutNode::accept(oox::drawingml::LayoutAtomVisitor&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:1452:14 > #9 in oox::drawingml::LayoutAtomVisitorBase::visit(oox::drawingml::ForEachAtom&) at oox/source/drawingml/diagram/layoutatomvisitorbase.cxx:98:20 > #10 in oox::drawingml::ForEachAtom::accept(oox::drawingml::LayoutAtomVisitor&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:167:14 > #11 in oox::drawingml::LayoutAtomVisitorBase::defaultVisit(oox::drawingml::LayoutAtom const&) at oox/source/drawingml/diagram/layoutatomvisitorbase.cxx:32:16 > #12 in oox::drawingml::ShapeLayoutingVisitor::visit(oox::drawingml::LayoutNode&) at oox/source/drawingml/diagram/layoutatomvisitors.cxx:245:5 > #13 in oox::drawingml::LayoutNode::accept(oox::drawingml::LayoutAtomVisitor&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:1452:14 > #14 in oox::drawingml::Diagram::addTo(std::shared_ptr<oox::drawingml::Shape> const&) at oox/source/drawingml/diagram/diagram.cxx:122:30 > #15 in oox::drawingml::loadDiagram(std::shared_ptr<oox::drawingml::Shape> const&, oox::core::XmlFilterBase&, rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, oox::core::Relations const&) at oox/source/drawingml/diagram/diagram.cxx:356:15 > #16 in oox::drawingml::DiagramGraphicDataContext::onCreateContext(int, oox::AttributeList const&) at oox/source/drawingml/graphicshapecontext.cxx:252:9 > #17 in non-virtual thunk to oox::drawingml::DiagramGraphicDataContext::onCreateContext(int, oox::AttributeList const&) at oox/source/drawingml/graphicshapecontext.cxx > #18 in oox::core::ContextHandler2Helper::implCreateChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) at oox/source/core/contexthandler2.cxx:94:34 > #19 in oox::core::ContextHandler2::createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) at oox/source/core/contexthandler2.cxx:191:12 > #20 in non-virtual thunk to oox::core::ContextHandler2::createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) at oox/source/core/contexthandler2.cxx > #21 in (anonymous namespace)::Entity::startElement((anonymous namespace)::Event const*) at sax/source/fastparser/fastparser.cxx:432:44 > #22 in sax_fastparser::FastSaxParserImpl::callbackStartElement(unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, unsigned char const**) at sax/source/fastparser/fastparser.cxx:1246:21 > #23 in (anonymous namespace)::call_callbackStartElement(void*, unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, int, unsigned char const**) at sax/source/fastparser/fastparser.cxx:305:18 > #24 in xmlParseStartTag2 at workdir/UnpackedTarball/libxml2/parser.c:9588:6 > #25 in xmlParseTryOrFinish at workdir/UnpackedTarball/libxml2/parser.c:11378:14 > #26 in xmlParseChunk__internal_alias at workdir/UnpackedTarball/libxml2/parser.c:12280:13 > #27 in sax_fastparser::FastSaxParserImpl::parse() at sax/source/fastparser/fastparser.cxx:1046:21 > #28 in sax_fastparser::FastSaxParserImpl::parseStream(com::sun::star::xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:866:9 > #29 in sax_fastparser::FastSaxParser::parseStream(com::sun::star::xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:1369:13 > #30 in oox::core::FastParser::parseStream(com::sun::star::xml::sax::InputSource const&, bool) at oox/source/core/fastparser.cxx:121:15 > #31 in oox::core::FastParser::parseStream(com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, rtl::OUString const&) at oox/source/core/fastparser.cxx:129:5 > #32 in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&, oox::core::FastParser&) at oox/source/core/xmlfilterbase.cxx:402:21 > #33 in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&) at oox/source/core/xmlfilterbase.cxx:331:12 > #34 in oox::ppt::PresentationFragmentHandler::importSlide(rtl::Reference<oox::core::FragmentHandler> const&, std::shared_ptr<oox::ppt::SlidePersist> const&) at oox/source/ppt/presentationfragmenthandler.cxx:610:17 > #35 in oox::ppt::PresentationFragmentHandler::importSlide(unsigned int, bool, bool) at oox/source/ppt/presentationfragmenthandler.cxx:348:13 > #36 in oox::ppt::PresentationFragmentHandler::finalizeImport() at oox/source/ppt/presentationfragmenthandler.cxx:499:17 > #37 in oox::core::FragmentHandler2::endDocument() at oox/source/core/fragmenthandler2.cxx:54:5 > #38 in sax_fastparser::FastSaxParserImpl::parseStream(com::sun::star::xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:872:36 > #39 in sax_fastparser::FastSaxParser::parseStream(com::sun::star::xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:1369:13 > #40 in oox::core::FastParser::parseStream(com::sun::star::xml::sax::InputSource const&, bool) at oox/source/core/fastparser.cxx:121:15 > #41 in oox::core::FastParser::parseStream(com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, rtl::OUString const&) at oox/source/core/fastparser.cxx:129:5 > #42 in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&, oox::core::FastParser&) at oox/source/core/xmlfilterbase.cxx:402:21 > #43 in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&) at oox/source/core/xmlfilterbase.cxx:331:12 > #44 in oox::ppt::PowerPointImport::importDocument() at oox/source/ppt/pptimport.cxx:145:17 > #45 in oox::core::FilterBase::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at oox/source/core/filterbase.cxx:485:49 > #46 in oox::ppt::PowerPointImport::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at oox/source/ppt/pptimport.cxx:223:24 > #47 in SfxObjectShell::ImportFrom(SfxMedium&, com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&) at sfx2/source/doc/objstor.cxx:2251:34 > #48 in sd::DrawDocShell::ImportFrom(SfxMedium&, com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&) at sd/source/ui/docshell/docshel4.cxx:399:39 > #49 in SfxObjectShell::DoLoad(SfxMedium*) at sfx2/source/doc/objstor.cxx:738:23 > #50 in SdModelTestBase::loadURL(rtl::OUString const&, int, std::shared_ptr<SfxAllItemSet>) at sd/qa/unit/sdmodeltestbase.hxx:181:30 > #51 in SdImportTestSmartArt::testText() at sd/qa/unit/import-tests-smartart.cxx:250:37 As discussed on IRC: > Jul 31 18:52:58 <vmiklos> sberg: yes, that looks reasonable, clearly the > expectation is that there is at least one element, in which case that > nVertMin grows from 0 and nVertMax shrinks from > std::numeric_limits<sal_Int32>::max() > Jul 31 18:54:43 <vmiklos> sberg: sounds like i made that mistake in > acdde3c643fde015214c546b1567727272ea799e, but recently i added a test that > now uncovered the problem :) Change-Id: I0ee11dbab568af788f9e2786c3dca2c1a5e1ee08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99902 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-31oox smartart, linear layout: correctly scale spacings wrt constraints and rulesMiklos Vajna1-8/+40
When constraints request a width which is larger than 100%, we scale down. Then rules decide which children should be scaled down and which ones stay as-is. This commit adjusts the size of children which have no rule, but their size has a constraint that they're a fraction of a scaled down child. Change-Id: I0a007d82f49f18951215afb1bfe8c0f1328ecd41 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99875 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-07-31oox smartart: consider rules when scaling in linear layoutMiklos Vajna3-11/+87
The bugdoc has an arrow shape which is 100% wide, and there are multiple shapes before it, which also have a 100% wide constraint. The reason PowerPoint scales down the shapes (but not the arrow) is because rules declare it should happen this way. So start taking rules into account in linear layouts. Change-Id: I352443277e88be0eb711659489587127727a258f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99855 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-07-25oox: remove commented code blockThorsten Behrens1-18/+0
Change-Id: I37efb4765a0322249c53723c33b90271b32caca4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99354 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-24throw if length of keys and values are differentXisco Fauli1-0/+4
See https://crashreport.libreoffice.org/stats/signature/%60anonymous%20namespace'::WriteAnimateValues This is expected to start rejecting broken files, instead of accepting invalid data silently, as it did before. This is not a regression, and should be indication of corrupted generator, which is the actual cause of the bug... Change-Id: I66dbb380e8b2d313e58cddf938d952aed4a635b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99327 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-07-24oox smartart: start parsing rule listsMiklos Vajna10-6/+172
I have a linear algorithm where some elements should be scaled down, but not all of them. These requirements are described using rules. This commit just adds the parsing for them, so that later AlgAtom::layoutShape() can create an improved layout, taking rules into account. Change-Id: I5f0f9ffcaff75a804796851e48a9ce10583ec362 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99377 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-07-24tdf#133015 Fix duplicated row and column problem.Gülşah Köse5-11/+54
LibreOffice imports multicolumn texboxes as tables. When document has numCols=2 (or more) attribute at slidelayout and slide, the table rows and columns duplicates. maPPTShapes vector holds our PPTShape objects, hasSameSubTypeIndex function finds the status that I mention above. So that we can prevent that duplication. Change-Id: Iee03d130452a16e9b46d471a9b6ed5910e6351ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99279 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2020-07-22ofz#24317 hash too shortCaolán McNamara1-1/+3
Change-Id: I6b2df62f0d18c6918a82a002f1e9a364c877caf1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99211 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-22tdf#134969 Add solid transparence in color gradientRegina Henschel1-3/+20
Converts a 'FillTransparence' percent value to a Gray color and stores it in a TransparenceGradient, so that it can be used by WriteGradientFill(). Use of third parameter rXPropSet is not possible, because it would overwrite a true transparency gradient. Causion, the property 'FillTransparenceGradient' might exist in an XPropSet of a shape with some default values. To detect, whether a gradient is actually used, you have to examine the property 'FillTransparenceGradientName'. Change-Id: Icbef599f02ebae2fcb5825fe64f546295eb78510 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99145 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2020-07-20fix --with-tls=openssl build with openssl upgradeCaolán McNamara1-9/+36
Change-Id: I0fece9f692637dc6948355c210534f5333fab7ed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99030 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-20fix some warnings with --with-tls=opensslCaolán McNamara1-3/+3
Change-Id: I17cc8919aeecaddb09f2fbf37611b672e4859ff0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99029 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-19compact namespace: ooxNoel Grandin47-249/+93
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-07-18tdf#128345 pptx export: add transparence gradient in solid fillRegina Henschel2-37/+75
In case of solid color fill a transparence gradient was not saved. OOXML has no separate element for gradient transparency but has transparency in color gradient stop elements. The patch detects a transparence gradient, combines it with the fill color and exports it as gradFill element. The import was already correct, besides a wrong start or end value in case of a symmetric gradient, which becomes AXIAL in LibreOffice. Change-Id: I4243656821629f90125d0408a38165a8a29e6e24 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98792 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2020-07-15tdf#134111 Chart OOXML Import: set text break to trueBalazs Varga1-1/+1
of category axis labels, even if the XML do not contain Text Properties of category axis labels. Change-Id: Ia0b154b2dfbfb00ffa0762af771423196586a5ae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96683 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-07-15tdf#131175 oox chart import: fix char color of <dLbl>, inherited from <dLbls>Miklos Vajna3-0/+80
There were two problems here: 1) Our chart model expects the char formatting of a data label as direct formatting, so in case <c:dLbl> has no such formatting, but <c:dLbls> has, oox has to explicitly inherit. 2) The data label char formatting is represented using chart::FormattedString, but the char format of it is not (yet) exported to ODF. Given that the char format of the series and the individual data labels is the same, restore the same formatting on import to please rendering. With these, finally the chart labels in the bugdoc are white, not black (and have a dark background, so they are readable). Change-Id: Iebac5ce0be31a59bafb0f9fe7636330585e33822 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98770 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-28 05:17:22 +0000