summaryrefslogtreecommitdiff
path: root/oox
AgeCommit message (Collapse)AuthorFilesLines
2021-04-26tdf#132472: do not set text color when table style is 'Themed-Style-2'Xisco Fauli1-3/+3
and it has no Accent Regression from 2c3f7d4ee0a0b2bf6efc41670645bd361f1b76ef < tdf#107604 Handle predefined table styles. > Change-Id: Id9ab5b20825e2eaf8cc138c108608fe446f33db4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114477 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit 54f7c32beca5a9c99d7316dc38818edad55f7415) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114497 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114649
2021-03-29tdf#122717: fix handling of zero width/height linesXisco Fauli1-3/+10
The code was introduced in 627c2469843c9461b665c4571f1214aca7fc36a4 < tdf#96674 drawingML import: fix handling of zero width/height lines > and later on removed by 36bade04d3780bc54c51b46bb0b63e69789658a5 < tdf106792 Get rid of SvxShapePolyPolygonBezier > with the comment "I doubt that the additional code to make a line not exactly hor/ver is needed. Checked and it is not needed, thus removed the change from tdf#96674 in shape.cxx." it turned out, it's still needed Change-Id: Ib64ee17227e3e588e94381abeabe5a2ff2e0b7d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113102 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 3e4eb070787d4d44b3bdc95046e5b231dbbef42b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113119 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit 11d344f6271e4171f8006c2cb29372f612cbdc00) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113123 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-03-18tdf#118693: no need to use convertMm100ToTwip() for line shapes anymoreXisco Fauli1-8/+1
It was introduced in 11129d89b152db54c86bb2bda58c24b8abb6c5a8 < tdf#85232 WPG import: fix handling of line shapes > and later in 36bade04d3780bc54c51b46bb0b63e69789658a5 < tdf106792 Get rid of SvxShapePolyPolygonBezier > ForceMetricToItemPoolMetric was added to SvxShapePolyPolygon::setPropertyValueImpl to convert from 100thmm to twips as can be read in the comment in testTdf85232 With this change, xShape->getPosition().X in testTdf85232 is 2267, which was already in twips Change-Id: I30b757885327a477213f96f8f84541971f435164 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112663 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit c9e5640c8fcad7beb42a66f9bee0252eee9fe323) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112619 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112671
2021-03-07tdf#139940 oox: mark end before growing largest segment backwardsJustin Luth1-1/+3
This fixes a regression in 7.1 (backported to 7.0.1) caused by commit 73993fdb5d4b507694cd0edf80887d19f7e2bf9a for tdf#134183. The largest segment has already been found, so we know where the next segment starts. Now if we grow it backwards, that shouldn't affect where it ends. So flag the end before growing the start, otherwise we would have to recalculate the end again. Change-Id: Iaae401d0438e533c7498be56f48fa153f7d3ff0a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110004 Tested-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 247963e53cce24c199a751c8ffb17f58b3a7d473) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111926 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112058 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-01-21tdf#128550 set sub item on the ancestor node.Mark Hung1-8/+49
The target of a animation node may resolved to a subitem. However it only has effect on a iterate container or animate node, not on any other containers. Subitem setting like background and paragraph got ignored, so everything were shown together. The patch find the ancestor node that is iterate container or animate, and set the subitem on it. Change-Id: Iaaa52aed3a34eb2d70b3b318b8336246e17e1e98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109444 Tested-by: Jenkins Reviewed-by: Mark Hung <marklh9@gmail.com> (cherry picked from commit 9b19bf0283b569a5c134de6b5cce1d72d8f37879) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109679 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109754
2021-01-13oox smartart: fix crash in pyra algorithm with a single child shapeMiklos Vajna1-1/+4
Regression from commit 14a56533ff2c9c859d22cd3039ada75b99e94bc0 (SmartArt Pyramid: Now lays out shapes, 2018-07-10), the added pyramid algorithm by first centering the topmost children, then decrementing the horizontal postion of each additional shape, with the end goal of having 0 horizontal position of the last children. This means that simply avoiding the division in the 1-child case leads to correct results, because in this case the only child is also the last child at the sane time. (cherry picked from commit f2e04fe98e313cffa3f98d55eae641415142a431) Change-Id: Ifd0027e9616b0909dbfde43e1555427b50de4dad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109120 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-11-23tdf#128213 Fix text camera z rotation import and export.Gülşah Köse9-24/+126
Text3DProperties is added to distinguish shape and text 3D effects. Before there was implementation error about text camera z rotation support. We were using shape effects for text. We already have not support shape 3D rotation but we have text camera z rotation. This patch includes import and export filter changes about text camera z rotation. Change-Id: I623392b82edf4585888d2f15ad91ffb2109d8f96 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106033 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com> (cherry picked from commit 72998fc859a83f063698c287d035f3fdc8b4481c) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106003 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-20tdf#138148 Protect aspect ratio of graphic bullets.Gülşah Köse4-2/+53
Change-Id: I166d547cdc01853fd81436c6cdc8d64b0fe817be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105618 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com> (cherry picked from commit c9619a5f6c351ede0dbfb3cf07df0ac9b74c2992) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105860 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-11-04tdf#128877 DOCX import: fix lost position of image cropped to shapeMiklos Vajna3-0/+32
Regression from commit f4ba484183a1e7b9824f10580d633466c266828f (ooxml import: supprt cropping to shape, 2019-05-13), which changed the type of a cropped-to-shape image from drawing.GraphicObjectShape to drawing.CustomShape. drawing.GraphicObjectShape worked because GraphicImport::lcl_attribute() in writerfilter/ had a check for drawing.GraphicObjectShape and did an explicit setPosition(). Doing the same for bitmap-filled custom shapes would be an option, but it would be ugly: scaling/translation/rotation/mirroring can only work together if they are only applied once, and that should happen in oox/, that's why we already have a mechanism to send the position from writerfilter/ to oox/ for WPS shapes. (<a:xfrm> contains the size, but not the position of the shape, so oox/ in itself could not know the position.) Fix the problem by improving ShapeContextHandler instead the pass the position from writerfilter/ to oox/ for <pic:pic> as well, the same is done for <wps:wsp> already since commit 6c4f737ec88a4f4dc5da8b2295ca5e7de2d4c24f (DOCX drawingML shape import: fix position when CustomShapeGeometry is set, 2013-11-21). (cherry picked from commit 80aba00e4945b106a276acf4ea28309b16e7c088) Change-Id: I74a60136d0ca8383e58948711b47858823f42437 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105279 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Jenkins
2020-10-22tdf#103987 Avoid duplication of the Custom Properties during OOXML exportBartosz Kosiorek2-37/+140
The MS Office is case insensitive for Properties. As a result properties names: ContentType and contentType are treated as the same properties. Additionally some Core and Extended File Properties does not exist in LibreOffice standard. To resolve that such properties are stored in LibreOffice Custom File Properties. For example: - category - contentStatus - contentType - identifier - version Unfortunately if user specify Custom Property which differ only with case, there will be conflict. To solve that the properties were renamed to be unique: - OOXMLCorePropertiesCategory - OOXMLCorePropertiesContentStatus - OOXMLCorePropertiesContentType - OOXMLCorePropertiesIdentifier - OOXMLCorePropertiesVersion Additionally if internal property have default value, then the value will not be imported into Custom File Property. During export to OOXML (eg. docx) The values which are already stored in Core or Extended File Properties, are not stored into Custom File Properties to avoid duplication. Change-Id: Ifc2b88ab74aa41d12ba968fff199062ce8dc96ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104384 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl> (cherry picked from commit a87af93ff874a55b81e55b46b63798fde4cefc4f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104504
2020-10-20tdf#137417 oox smartart: avoid considering rules in vertical linear layoutsMiklos Vajna1-0/+6
Regression from commit 0024c48b4822062995effed7db4f1281196384bb (oox smartart: consider rules when scaling in linear layout, 2020-07-31), the problem is that I only tested horizontal layouts and this is not working for vertical layouts. Just disable the vertical case for now, to avoid unwanted side effects. (cherry picked from commit c719db99166a7b4770855a9599ec65c70cd256c5) Change-Id: I31a894157996a2371b8d0ec482ee91dc4d5b053e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104550 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-10-17tdf#133377 OOXML Fix storage of date in Custom PropertiesBartosz Kosiorek1-1/+3
During exporting documents into OOXML formats (docx, xlsx, pptx), if custom properties have Date format, the day and year were switched. This commit fixes that. Change-Id: Id497602eb3354de78bfd52bf5ef61d32aafd957d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104450 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104463
2020-10-07tdf#105875 DOCX VML shape import: fix missing rotationRegényi Balázs1-11/+15
Also to avoid bad resizing of the rotated shape, remove obsolete(?) code part from commit 0423a6741fc08a35b123556f9b10219d090ee42a (Import bezier curves from .docx.). Co-authored-by: Szabolcs Toth Change-Id: I77266ba65e558cf9e6dd0e1c37fad85abd038819 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103693 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 3b6de95a0d59cf5942af5ecf4a402c224b76f8a3) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103976 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-10-06tdf#137023 PPTX import: fix unexpected center alignment of shape text, 2nd tryMiklos Vajna4-5/+35
Regression from commit 10bb02efd8afd42e633e370480104e2575546d8e (tdf#129685 PPTX import: fix unexpected centering of shape text, 2020-09-18), now the problem was that some text should be left aligned, but was centered. Fix the problem by reverting most of the above commit: XML changes, changes to SdImportTest::testTdf113198() (manual testing show that this change is not needed after all) and changes to the TextBodyPropertiesContext ctor in oox/ (but not the testcase itself). Fix tdf#113198 again, this time in Shape::createAndInsert(), which is meant to be closer to what the binary PPT import does. With this, all cases from tdf#104722, tdf#113198, tdf#129685 and tdf#137023 are meant to be handled correctly at the same time. (cherry picked from commit dfa1856cdb4c69985ef1e809d33055427b6fbd76) Change-Id: Id785252c26fc407cd74c9cfb55624091798d7773 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104006 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-09-30oox smartart: snake algo: make sure child shape height stays within parentMiklos Vajna1-6/+28
1) When applying double outside spacing, introduced with commit 0a29c928afa74123bca05dc089c751603d368467 (oox smartart, picture strip: fix lack of spacing around the picture list, 2019-02-26), make sure that is only applied in the direction of a signle row: i.e. the bugdoc case is left/right outer spacing, but no top/bottom spacing. 2) If a child shape has an aspect ratio request, make sure that it only decreases what would be allocated by default, so the children never leave the parent's rectangle. 3) Fix a mis-match between the first and second row, the unexpected small left padding in the second row was because code assumed that all child shapes have the same width; which is not true, when widths come from constraints. With this in place, we finally do a good rendering of the bugdoc, and child shapes are always within the bounds of the background. (cherry picked from commit 71303c5c23bdb385e9f12c0dbe5d2a0818b836ec) Change-Id: Ia2606dcd945402f7dfe17c6e2f261bfd98667022 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103697 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-30oox smartart: snake algo: apply constraints on child shape widthsMiklos Vajna1-10/+47
This requires tracking what is the total of the width request of child shapes, then scaling them according to what is the total available width. Additionally, the height of child shapes should be adjusted based on their aspect ratio requests. A related trap is when an (invisible) spacing shape is at the end of the row, that would result in smaller spacing between the rows, so track the max height of shapes inside a single row. With this, finally the 6 child shapes are arranged on 2 rows, not 3 ones. (cherry picked from commit 5d899bf3ee59a226f855c8c56389344862efaa95) Change-Id: I4eb2f06676df11c1432e0934ca3a0ec8891c5843 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103696 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-30oox smartart: snake algo: start parsing relative width constraintsMiklos Vajna1-13/+90
This is needed, but not enough to have the correct width for each shape and spacing item on the path of the snake. Currently we give the same width for all children, while the shapes typically have a larger width than the spacings. (cherry picked from commit ab291c94fb5338a1cf0ab8fe7cbf57dd5c5f81cb) Change-Id: I4e2638ea5b566c21cb1cf503a8cf2e5d35256e3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103695 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-30oox smartart: snake algo: consider child's aspect ratio request for cols/rowsMiklos Vajna1-2/+9
If the child's aspect ratio request will shrink the width, then take that into account when calculating how many rows / cols we need. This reduces the number of columns for the bugdoc from 4 to 3, which is needed, but not enough to render it correctly. (cherry picked from commit acc9aead3cc5162379d34a455aa15f7b13907cf1) Change-Id: I1d02df4834b8a2ce97d5e006db0e3135d3d42917 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103694 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-29tdf#136267 OOXML Chart Import: create main category axis labels onceBalazs Varga5-8/+7
because InternalDataProvider can not handle different category names on the primary and secondary category axis. Revert e0b0502516a10181bbd1737b93b38b2bba4c98e8 commit, except the relevant unit test. Regression from commit: e0b0502516a10181bbd1737b93b38b2bba4c98e8 (tdf#128016 Chart OOXML Import: fix duplicated category labels) Also fix tdf#129994 (FILEOPEN - hang at import time), which is a a regression from commit fa0a981af41a2606541eec1cb20a379a739691e0 (tdf#114166 DOCX chart import: fix missing complex categories) Change-Id: I5d049e760eb1a647ea774be264349a2f16f15f5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102463 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/+/103617 Tested-by: Jenkins
2020-09-29tdf#124013 XLSX shape export: fix missing solidFillRegényi Balázs1-27/+1
of the inside of the shape (resulting for example, invisible shapes). See also commit 83c30743eaf44d8eded4a73e3ac2585b5bdbaffc (tdf#77236 DOCX shape export: fix missing solidFill). Co-authored-by: Szabolcs Toth Change-Id: I4efde86f82e22e1aa49b89dc13557ef5f238ba83 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102871 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/+/103616 Tested-by: Jenkins
2020-09-29tdf#77236 DOCX shape export: fix missing solidFillRegényi Balázs1-8/+0
(resulting for example, invisible shapes). Co-authored-by: Szabolcs Tóth Change-Id: I328514022f4a594c374d5a97db39d1cf3a954e02 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102195 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/+/103615 Tested-by: Jenkins
2020-09-29tdf#136650 DOCX pie chart import: fix percentageBalazs Varga1-7/+13
Follow-up of commit e0da00d655ecca5986eea3812a8a670c6adbc40f (tdf#132174 Chart DOCX import: fix label number format). Change-Id: Ie0b2fe6305d7696de6dddc1f17d078fc2e749e4e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102753 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/+/103611 Tested-by: Jenkins
2020-09-25tdf#136830 Fix: positions of group shapes of PPTXnd1011-1/+13
For certain PPTXs, Impress fails to import the document with correct group shape positions. More specifically, chExt (Child Extents) calculation should take the values from group shape when 0 is given. Change-Id: I1f8e89dcfe61ab2071ad00850ff99aecb7218067 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102895 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit b3f2fd983f0728893505d7ae12e3def924ab520f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103333
2020-09-21tdf#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/+/103088 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21tdf#136620 tdf#136708 filter,oox,sw: fix export of 2 different wrapsMichael Stahl1-4/+18
This reverts commit 2cb90a5c87fe46737c8d840967d8836284f92ffd. Revert the change to EscherPropertyContainer, which was completely bogus, based on pre-existing bogus code in VMLExport::Commit(). The problem is that ESCHER_Wrap values are for wrapping text *inside* a text box, which is "mso-wrap-style" in VML, whereas VML's w10:wrap element defines how text wraps *around* a shape, doesn't exist as an ESCHER property and is specific to Word formats. Instead, export the w10:wrap element in VMLExport::EndShape(). This has 2 callers, WriteActiveXControl() and writeVMLDrawing(). Furthermore the value "none" wasn't written for WrapTextMode_THROUGH, which caused the wrap element to be omitted in that case. Change-Id: Id4a01fcb2ea73fa9bef4ee8769b5e0680e059f15 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103009 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit fdc8590032b292dcb8152b328401e591fea642a4) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103090 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-16tdf#131537 DOCX export: fix OLE "Display as icon"Daniel Arato (NISZ)1-7/+3
for example to avoid converting OLE icons of an ODF document to an icon-size embedded spreadsheet. When creating a new OLE object in Writer the user has an option called "Display as icon" which causes the actual contents of the OLE to be hidden when rendered in the document. This setting, referred to internally as the DrawAspect of the object, was imported fine, but when exported to a .docx it always had the value "Content" (corresponding to "Display as icon" being unchecked). Now OLE objects with "Display as icon" checked are saved with DrawAspect="Icon". A grab bag entry was previously used to let the DrawAspect setting flow through Writer from OOXML import to export. Now this workaround is no longer needed and is removed by the present commit. Change-Id: I46ea4fc95a26bcd1f85e19a506c0965f73d4257a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101711 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 07dcb0dab759d4ab535d99c0e6d326959906b87e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102652 Reviewed-by: Dániel Arató <arato.daniel@nisz.hu> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
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/+/102712 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@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 Change-Id: I6c591eadc7166c7c42752650afdb7ee1e416cff6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102711 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2020-09-15tdf#135665 DOCX: import tight wrap setting of VML shapesDaniel Arato (NISZ)2-0/+2
The wrap setting that OOXML calls "tight" and LibreOffice calls "contour" (== true) was not supported by the import code, only the export. Change-Id: I48739ffaad48e28df05fd87a9b51a14238dc47e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101932 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 4b7ee7bd61f78be60211cc72ba36da987191266e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102124 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-09-15tdf#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> (cherry picked from commit 74be8bb787a44464957e5d3105c8de6d36e81b4a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101871 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-09-01tdf#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> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101750
2020-09-01tdf#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> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101749
2020-09-01tdf#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> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101748
2020-09-01tdf#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> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101747
2020-09-01tdf#121189 PPTX export: fix missing chartDaniel Arato (NISZ)1-0/+1
Based on Regina Henschel's technical analysis and code pointer. Change-Id: Ifdea48c09d23dce495fa6bc90a9e1648dbb5ccb3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101283 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 0c5ac9d1cb39eac838a612092a8934a6ca12326f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101674 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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/+/101164 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) Change-Id: I4ab43b4c6d40d9f43caad22b85f5b885fa8b4ef1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100971 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2020-08-10oox: 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> (cherry picked from commit 8d83c29905ca6c4067ae0330d3544ddb983cafbc) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100343 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-08-10oox: 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> (cherry picked from commit 2af2b9be05a4733c691db7201e76b4058516c47b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100354 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-08-10tdf#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) Change-Id: I11d593c01a6a4b16149ce74c1408c2a39895e941 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100283 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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: sd/qa/unit/export-tests-ooxml1.cxx Change-Id: I4243656821629f90125d0408a38165a8a29e6e24 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100282 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-07oox: 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> (cherry picked from commit 090c61eb93db4302d4565d5f11f7673190835fdb) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100259 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
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/+/100107 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@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/+/100105 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@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/+/100104 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@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/+/100103 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@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) Change-Id: I352443277e88be0eb711659489587127727a258f Conflicts: sd/qa/unit/import-tests-smartart.cxx Change-Id: I352443277e88be0eb711659489587127727a258f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100102 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2020-08-05oox 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/+/100101 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2020-08-05tdf#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> (cherry picked from commit e0018be102edd6e376e0622e0a9384176d2f119c) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100052 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-08-05Avoid 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/+/100106 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-23 02:13:44 +0000