summaryrefslogtreecommitdiff
path: root/oox
AgeCommit message (Collapse)AuthorFilesLines
2020-09-22tdf#136247 Change element order of data labelsGülşah Köse1-2/+2
Reference OOXML (Appendix B.5.1, line 248) Change-Id: Idf5c2546b4ad65c8e78ca03e18ecfa575ef17fe8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103005 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com> (cherry picked from commit de59062d95605e5c91d687e3441399ffb05ff2dc) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103051 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2020-09-22tdf#129685 PPTX import: fix unexpected centering of shape textMiklos Vajna4-1/+27
Regression from commit 89f0af144c18efafe2573801641689a1432c0cae (tdf#113198 set default shape paragraph alignment.., 2019-11-19), the old bugdoc had this markup: <a:bodyPr ... anchor="ctr"/> (centered) The new bugdoc has 2 shapes with text: <a:bodyPr .../> (aligned to left) <a:bodyPr ... anchorCtr="1"/> (should be centered) "anchor" is about vertical, "anchorCtr" is about horizontal centering of text. Checking what the binary filter does, it maps horizontal centering to TextHorizontalAdjust, so fix the original bug differently, by leaving ParaAdjust alone, and tweaking TextHorizontalAdjust intead: this keeps the old bugdoc working but fixes the new one. This caused a number of "change detector" XML-based tests to fail: all of them are unchanged visually, so the XML files are adapted to the new state. The tdf#113198 fix itself was fixing a regression from tdf#104722, and that commit had no testcase, I tested that we don't regress there, manually. (cherry picked from commit 10bb02efd8afd42e633e370480104e2575546d8e) Change-Id: I81a7b3e8c76bfbce5c5569d16d5238958ac20f75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103136 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-22tdf#136247 OOXML export data label background color.Gülşah Köse1-6/+25
Change-Id: Ie3e00e8195239e6570bfe76c2451bae11c209145 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102999 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com> (cherry picked from commit a11bb74d4f464e9639ddb5b8d87dc4770663fea8) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103045 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2020-09-15oox smartart: handle <dgm:prSet ... custT="1"/>Miklos Vajna1-1/+55
Which defines that a data node has text properties as direct formatting, so autoscale should not happen. We decide autofit at a shape level, smartart defines custom text props at a data node level. So take the shape, go to its first presentation node, get its data node and see if it has custom text props. If not, continue to scale text down till it fits. smartart-autofit-sync.pptx is extended to contain a 3rd shape: the first two have their autofit scaling synchronized, while the 3rd has a fixed font size of 10pt. (cherry picked from commit 89b385c2336e5b3868d2a040e11134b349b7d010) Change-Id: I6caacdaab9a36072b9ad5021bd217c955b09b790 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102727 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-15oox smartart: add support for syncing font heights of multiple shapesMiklos Vajna7-11/+126
When 2 or more shapes have their text set to autofit and they have a constraint like: <dgm:constr type="primFontSz" for="des" forName="node" op="equ"/> Then make sure that the automatic font size is the same for all shapes and all content fits, by using the smallest scaling factor from all relevant shapes. Some rework is needed, because normally oox::drawingml::Shapes don't have access to their parents, at the same time there can be multiple SmartArts on a single slide, so storing the grouping info in the filter is problematic, too. Solve this by storing the grouping in the toplevel oox::drawingml::Shape and exposing them in XmlFilterBase just during the time the children of the toplevel shape of the SmartArt are added. This works, because we know SmartArts can't be nested. (cherry picked from commit 1bd3474c7c7945e1182dfbaca89be05ea98dd3e8) Conflicts: include/oox/core/xmlfilterbase.hxx oox/source/drawingml/diagram/diagram.cxx Change-Id: I6c591eadc7166c7c42752650afdb7ee1e416cff6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102726 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-25Revert tdf#127777 fix due to reggressionco-6.4-3Gülşah Köse1-0/+2
This reverts commit 111c260ab2883b7906f1a66e222dbf4dc3c58c4f. Change-Id: I60c54b506f6721f08a21ebcfb306f38dd9ebff62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101328 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-08-25tdf#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> (cherry picked from commit 9fe881410909c5273cef517433411bc4eceee294) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101161 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-08-19tdf#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. (cherry picked from commit b2d834d6727626f070bb4dde3e1c65da1169f729) Conflicts: oox/qa/unit/vml.cxx oox/source/vml/vmlshape.cxx Change-Id: I4ab43b4c6d40d9f43caad22b85f5b885fa8b4ef1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100972 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-18tdf#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> (cherry picked from commit 33696b2820ce3c8b21b753d2c2bf92345ecb9276) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100356 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2020-08-16tdf#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> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100828 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2020-08-16tdf#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> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100827 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2020-08-16tdf#133015 Fix duplicated row and column problem.Gülşah Köse5-10/+53
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> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100826 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2020-08-07tdf#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. (cherry picked from commit 73993fdb5d4b507694cd0edf80887d19f7e2bf9a) Conflicts: oox/source/drawingml/fillproperties.cxx Change-Id: I11d593c01a6a4b16149ce74c1408c2a39895e941 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100287 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-07tdf#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. (cherry picked from commit d187f22b7ff73954e1da39fb954c64bc315298cb) Conflicts: oox/source/drawingml/fillproperties.cxx sd/qa/unit/export-tests-ooxml1.cxx Change-Id: I4243656821629f90125d0408a38165a8a29e6e24 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100286 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-06tdf#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> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100097 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-08-05oox 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. (cherry picked from commit 3c185bf386b4c9609ab32d19bf95b83fe0eeeea3) Change-Id: I433f92c620149ef5590aebc8cbf43110e1d2fb85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100115 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-05oox 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. (cherry picked from commit b7481a026348c3417fa13a440312521dccee9ec8) Change-Id: Id67a8740f1eff506e4beae0c797ad50e0218dfe6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100114 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-05oox 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). (cherry picked from commit 880673412143a7db7ea1bf4766040662dfc085dc) Change-Id: I59f237c582053067e890180a1ae40471e5f46dea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100113 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-05oox 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. (cherry picked from commit 91f0f7e5e0a55cb1dbd729a1d7de52388b1cfb15) Change-Id: I0a007d82f49f18951215afb1bfe8c0f1328ecd41 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100111 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-05oox 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. (cherry picked from commit 0024c48b4822062995effed7db4f1281196384bb) Conflicts: sd/qa/unit/import-tests-smartart.cxx Change-Id: I352443277e88be0eb711659489587127727a258f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100110 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-04oox 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. (cherry picked from commit 6ca5412bac9e3da5cd20f315fc853c7733f10858) Change-Id: I5f0f9ffcaff75a804796851e48a9ce10583ec362 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100109 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-04Avoid 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 :) (cherry picked from commit ae4a69d7559a537e86630b2890d28b0d8f6f47d0) Change-Id: I0ee11dbab568af788f9e2786c3dca2c1a5e1ee08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100112 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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). (cherry picked from commit 8a43bfeffab9009c9f373e883fef87af1a7b3843) Change-Id: Iebac5ce0be31a59bafb0f9fe7636330585e33822 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98810 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-07-15Related: tdf#131175 OOXML chart: insert hatch definition into the right tableMiklos Vajna2-2/+19
Both the chart and the containing document has one, but the intention is to insert this into the chart one. This is needed, but not enough to render the right hatch for data labels. (cherry picked from commit e18bc316efbd815b047f4e19ebd033e7a842d10d) Conflicts: oox/source/drawingml/chart/seriesconverter.cxx Change-Id: I485d84e2ae33728963b648c05e730d418567fc0e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98809 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-07-15Related: tdf#131175 OOXML chart: import data label fill patternGülşah Köse4-71/+321
(cherry picked from commit 6f752061d5153da50d6f536d506358c8f512a397) Conflicts: oox/source/drawingml/chart/seriesconverter.cxx Change-Id: I2db64489c86e4381167eb13af4ab5118113960d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98808 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-07-15tdf#131175 Import data label solid fill and color.Gülşah Köse2-1/+24
(cherry picked from commit 603df08a1e0211099ce2cf258cfe64a74ed6ded9) Conflicts: oox/source/drawingml/chart/seriesconverter.cxx Change-Id: I8a3ef6e60d4f2a13310bb9a8fc4eb873df3f9b4f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98807 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-06-15PPTX export, custom shape, bitmap fill: fix source vs fill rect confusionMiklos Vajna1-0/+13
Commit 682ab832522b1349f1714bcb16f6e83468ea2920 (drawingML export\import: cropping of shape's fill texture, 2014-02-12) improved the DOCX filter, so the fill rectangle of a custom shape with bitmap fill is handled. The problem is drawingML has a source rectangle (similar to our crop rect) to limit the usage of the bitmap, and also it has a fill rectangle in case some margin is wanted around a stretched bitmap. We don't have a mapping for the later. Fix the problem by limiting the above work for DOCX, this way PPTX's source rectangle won't be turned into a stretch's fill rectangle. This way no unwanted margins will appear around the image -- those margins can be large enough that the image effectively disappears on export. (cherry picked from commit b00e43fa5848be0cc7ba81b185021511d94cdc00) Change-Id: Ic35063545a56eec9eaf885bbd397a854705d134f
2020-06-11tdf#106181 XLSX export: output form controlsSerge Krot1-0/+1
Prepared general algorithm to ouput form controls into XLSX. For now only CHECKBOX is supported with a possibility to link withem to any worksheet/cell. Change-Id: Ide8739d81ffb755aeae074c4ebecf24251383e34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94161 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit fd238380ae7820f12ac1f7c52d0f7180a93f3ba3) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94835
2020-06-10PPTX import: handle adjust values from both the shape and its placeholderMiklos Vajna4-2/+39
The direct problem is a crash in CustomShapeProperties::pushToPropSet(), the code just hoped that the input file doesn't have more adjust values than the # of adjust values we allocate based on the preset type. Fix the crash, but there is a deeper problem here... The shape can inherit custom shape properties from a placeholder, then later it can have its own custom shape properties. When it comes to adjust values specifically, we used to just append own adjust values to the end of the list. This way we got the double of expected adjust values. And later rendering took the N expected adjust values from the start of the 2N element list, so we used the adjust values of the placeholder, not of the actual shape. Fix this by clearing the custom shape geometry once we know we have our own preset geometry. (cherry picked from commit 408ec7a4470741edbedbb034de07a2d776348593) Change-Id: I09f669bf59c33b552b906733d323eba7af5548e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96066 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-06-10tdf#131082 fix missing fill property of grouped shapesnd1013-0/+44
When shapes are grouped together, and fill property is specified at the group level in MSO, it fails to work in IMPRESS. This fix is to set the fill property when it is being imported. Change-Id: I89920e71fc558f54d49ef7b065c549a732bc2b10 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89862 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96065 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-06-02tdf#132594 Chart XLSX import: fix legend entries in pie chartsTünde Tóth1-1/+1
Legend entry text of pie chart wasn't imported correctly in XLSX documents created with Excel 2007. Regression from commit: e0b0502516a10181bbd1737b93b38b2bba4c98e8 (tdf#128016 Chart OOXML Import: fix duplicated category labels) Change-Id: I4567437a41fe66e124dccbd148c0c49196d5c007 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94864 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95294
2020-05-27oox smartart import, composite alg: implement vertical centeringMiklos Vajna1-0/+23
The bugdoc's case was that the total height would be used by 2 shapes, but then a constraint decreases the height of one shape, so not all vertical space is used. We used to just count from the top, need to center vertically, as PowerPoint does it. (cherry picked from commit acdde3c643fde015214c546b1567727272ea799e) Change-Id: I436019e9e837b73130e387c9bcd309e20045b0f9
2020-05-27oox smartart import: fix aspect ratio of shape with composite algoMiklos Vajna1-20/+99
The layout node has alg=composite, then a parTx and a desTx child layout nodes. No matter what order is used (parent first, child first), the result will be wrong, as the constraints refer to each other. I did not spot any description in ISO 29500-1 that would describe what is the expected behavior. Researching this, found "One other consideration when specifying composite constraints is that the constraints must be specified in the same order as the nested layout nodes." at <http://web.archive.org/web/20111015151600/http://msdn.microsoft.com/en-us/magazine/cc163470.aspx>, which suggests to handle constraints for each shape in a parent -> child order, but keep a shared state when iterating over the children which gives us: - parent node, all direct constraints - for each child node: - child's constraints from parent - child's own constraints This way the desTx top value can depend on the parTx's height, and it's supported to define parTx's height only in the parTx layout node, not in the composite parent. And after all, it matches what PowerPoint does, so the column headings in the bugdoc have a 4:10 height:width aspect ratio. (cherry picked from commit 414586649582e182b2603702f4f586f4beeed8a9) Change-Id: Ideb76c1ddd1ffff8d2a217cddf81106d1bb97eb9
2020-05-27smartart import: handle multiple <a:schemeClr> in <dgm:fillClrLst>Miklos Vajna8-29/+86
The TODO in the ColorFragmentHandler ctor was right: we only handled the last <a:schemeClr> child, but there can be multiple one. Use them based on the index of a shape in a <dgm:forEach> loop. Move the TODO to the only place which still assumes a single color in the color list. (cherry picked from commit 12bea6c897822964ad4705418da54411cb15749e) Conflicts: oox/source/drawingml/colorchoicecontext.cxx oox/source/drawingml/diagram/diagram.cxx sd/qa/unit/import-tests-smartart.cxx Change-Id: I1c5c4f82e621f1110ef06b0490ff79f82f60f214
2020-05-12tdf#130058 Import shadow size.Gülşah Köse5-1/+25
Change-Id: Ie1cee377a33567088fb76ea47f0e6fc51d47f0fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92188 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93419 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Miklos Vajna <vmiklos@collabora.com>
2020-05-11oox: add PPTX import/export for semi-transparent shape textMiklos Vajna7-2/+167
And start a drawingml test suite in oox, so the test and the tested code is close to each other (just like how it's done in chart2/ already). (cherry picked from commit 1e64d9ebaa231caef5fb062009b8f76465e415f4) Conflicts: oox/Module_oox.mk Change-Id: I9a2810691f12604d240e4394e6a5ff4e7f52f1c1
2020-05-07tdf#79082 Export paragraph tab stops to ooxmlSamuel Mehrbrodt2-0/+41
Change-Id: I7d25dc1ab3c960aafc07a3be69b54f5aceef23fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93462 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit 2c14bbd5820f854be3a4b1c0f49b9d9afa05b08c) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93526 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-05-06tdf#132282: Revert fix for tdf#131554Xisco Fauli1-3/+1
912217285b3058efa54c2336f91fda4efdad6ff0 fixed the root cause of tdf#131554 and 69b83dc2d3014dd9b18402534e15c937dc082464 is no longer needed The unittest still passes Change-Id: I7c723b0c3cc2b56022978bbeb8bf6b3f6f93f1c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93063 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93073 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-04-29tdf#119087 Don't treat OOXML strict namespace as custom XMLSamuel Mehrbrodt1-1/+2
Change-Id: I5037ac09f57c92e02e330cbc906da3afbe4c747c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93056 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit 9be543a27ab18427a1c4e66a70cc49b0332b6aa1) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93128 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-04-28tdf#132174 Chart DOCX import: fix label number formatBalazs Varga1-0/+4
The inner data table of charts has no own cell number format, unlike the MSO embedded XLSX, so we always have to set the link number format to false, if we have an inner data table. Regression from commit: 9c1063ba13028244346528e307d5563d6faf949d (tdf#129173 tdf#129175 Fix number format of data labels) Change-Id: I5e7865cb8c19fc6fae5b68305c7dc302516c0ad4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92695 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: Tünde Tóth <tundeth@gmail.com> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit e0da00d655ecca5986eea3812a8a670c6adbc40f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93007 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-04-28tdf#78749 DOCX: import VML background imageAttila Bakos1-2/+7
of text boxes. DOCX relationship identifier wasn't handled earlier, only XLSX. Co-developer: Tibor Nagy Change-Id: I72f246e6f69d70d1e203087516ee93a57563f777 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91933 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 9283cd9e13cd3e0dd7d6b831d930128931862a40) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92771 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-04-27tdf#131936 Correctly detect OOXML variant on importSamuel Mehrbrodt2-2/+34
Change-Id: I29a6b0454bf741ce8ad49078597b3412a83dedb9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92278 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit ff93e4977cb1e23f355d248a77e8d0e56bb0f4b9) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92766 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-04-23tdf#119187 fix: Top-aligned text in PPTX becomes bottom-alignednd1011-44/+81
Change-Id: Ic6c03e512ce3f6e240d86186fb16e24c86942343 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92051 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92725
2020-04-02tdf#131554 placeholder iteration fails to stop when a match is foundnd1011-1/+3
Wrong placeholder is returned due to iteration not stopping when a match is found. It causes a text element position to be incorrectly set. Change-Id: I58be6825cec7a61f48b46418bdf28964c1afe4ce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91023 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org> Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Jenkins Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91472 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-04-01tdf#100751 DOCX VML shape import: fix arrow directionSzabolcs Toth1-13/+6
Flips along both the y- and x-axis weren't imported, resulting wrong direction of arrow and other shapes. Co-Author: Balázs Regényi Change-Id: Iac222ac2a6a6110289969c32b40828b83da0aefd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90646 Tested-by: Jenkins Reviewed-by: Balazs Varga <balazs.varga991@gmail.com> (cherry picked from commit cb441c4d0adf698e6af9073c6c3285a66b76871e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91391 Tested-by: Xisco Faulí <xiscofauli@libreoffice.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-03-25tdf#131553 a null pointer crashes Impressnd1011-5/+8
When constructing a shape object from property EmbeddedObject, it may return null object. Check the returned value first. Change-Id: I9d7a2d9c0c919007ae2a34a0af86dea5639b1bd6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91024 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> (cherry picked from commit df1be683ab935fe5362750360508ba69eb415afb) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90959 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-03-24Fix build with boost < 1.68Rico Tzschichholz1-2/+2
Follow-up fix for 73cac1031131021819a0fbd4d60554196aea230c "tdf130839: Corrects second level left margin in Smartart" Change-Id: Ie194062ba33cf505ad33fbfdc73c2f764b61d0aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90770 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-03-18tdf#131118 VML import: fix size of non-autosize shapes containing textMiklos Vajna3-3/+21
Regression from commit b92293b3943423324064a8513c2e114d18817179 (tdf#103983 VML import: handle <v:textbox style="mso-fit-shape-to-text:t">, 2020-01-20), the problem was that in case we disable autosize too late, then the size will be already set during adding text to the shape. Do it before adding text, this way adding text won't change the shape size, so it'll be correct at the end of the import. (cherry picked from commit 4ee7ee1c4a515479bc174543af4dbc400035c0ba) Change-Id: I9410fc695c3edfa5089d845864bf237e71c533c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90602 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-03-11tdf#130986 Chart OOXML export: fix number format of custom labelBalazs Varga1-0/+3
Export correct sourceLinked attribute in c:dLbls/c:dLbl/c:numFmt, as in c:dLbls/c:numFmt. Change-Id: I0e52720b3cb2c99550a779763f01ba12f762050d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89638 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89947 Tested-by: Jenkins
2020-03-04tdf#84399 VML import: map <v:shape o:spt="202"> to TextShapeMiklos Vajna5-1/+48
This partially reverts commit 81f9fe3a14f0fc99afbfa7ce3a26a9c7855d0919 (fdo#74401 VML groupshape import: only handle v:rect as TextShape, 2014-03-19), which wanted to map triangles to custom shapes. It was overlooked that we can have not only explicit rectangles and custom shapes, but also <v:shape> elements which have their shape type explicitly set to TextBox. The later is now again handled similar to rectangles. This keeps the triangle case working, but fixes the <v:shape o:spt="202"> case. We need to make this decision while parsing the XML, so some rework is needed to have earlier access to its container (group shape or draw page) and also to its shape type. (cherry picked from commit 198685ded79d64b21023ee85e9a15fa1b32705a0) Conflicts: include/oox/vml/vmlshapecontainer.hxx Change-Id: I33a4b3cd03b0df5d93cffa19e7ea834113df2bdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89876 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-15 04:27:26 +0000