summaryrefslogtreecommitdiff
path: root/oox/qa
AgeCommit message (Collapse)Author
2021-10-18tdf#125582 use TextVerticalAlign_BOTTOM for textCircleRegina Henschel
PowerPoint aligns the bottom of the text to the path for prstTxWarp 'textCircle'. That preset type is mapped to 'fontwork-circle-curve' on import with additional attribute ScaleX=true. Currently the property TextVerticalAlign is only evaluated in case ScaleX=true. Therefore I have written the condition similar as the already existing with 'fontwork-arch-up-curve'. If it will be necessary later, all those conditions can be changed to use rPresetType instead of rClass. The rendering is slightly different compared to PowerPoint, because descenders and paragraphs line-spacing are handled differently. The rendering has still the problem, that in PowerPoint the letters are placed without gap, but in LO they have additional distances from each other. The needed ODF attribute draw:text-path-mode is not yet implemented in LO. Its value 'normal' would be needed here. Change-Id: I1f03d4845312885eff9ee8dbe1d51ddd437ed8e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123726 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-10-05drop 'using namespace std' in o* r* x*Julien Nabet
Change-Id: I15d56d133cf464a3cb6483be785b1259c7f35b43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123120 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-09-21tdf#142602 DOCX: export adjustment points of custom shape arrowsDaniel Arato (NISZ)
When exporting custom shape arrows LO used to fall back to writing out their plain vertex coordinates, losing the customizability of the shape after loading from file. This commit changes the export of some of the most commonly used arrow custom shapes to proper adjustment value export. Follow-up to commit 63cd67e5e18f01aca303131e148c80398a181a41 "tdf#92525 tdf#142398: fix export of simple custom shapes". Change-Id: If248556764bdb7e00cfde4ebe5b32bb380b1fa19 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121901 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-08-27tdf#112450 correct points and size for polyline in VML importRegina Henschel
The points in file source might have units. Decode was missing. maWidth and maHeight are used in ShapeBase::convertAndInsert(), and moCoordSize is used in PolyLineShape::implConvertAndInsert(). So ShapeContext needs to provide both in case of importing a polyline. That was missing. Word writes the size into the coordsize attribute of the v:polyline element. But from VML specification it need not exist, but bounding rectangle of points has to be used. That is added too. Unclosed polyline cannot be filled in LO and ODF, a fill is only possible for a closed polygon. LO defines a sequence of points as being closed, if first point == last point. The import is adapted to that behavior. Word allows an unclosed polyline to have filling. That cannot be represented with a simple PolyPolygonShape but would need a CustomShape. Because the user cannot yet edit points in a CustomShape but can do that in a PolyPolygonShape, the v:polyline element is not converted to a CustomShape on import and not to DML on export. LO would first need an UI for editing points of a CustomShape. Change-Id: I23d08fda2005f8b36488e1d9ba32e565d8a0f803 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121042 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-08-14tdf#142605 use frame size in oox export of BezierCurveRegina Henschel
The export had used the bound rectangle of PolyPolygonBezier. But that contains control points. Use API position and size instead. I have not incorporated the changes into existing WritePolyPolygon, but have made an own version for SdrPathObj, because I find it easier to read and maintain, than having a lot of case distinctions depending on the shape type. Change-Id: I2e646c4f5fa37174c4979855212ca72f2dfa447e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120407 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-08-06tdf#132696 PPTX import: fix missing SmartArt when it's part of a group shapeMiklos Vajna
Regression from commit e9986153e44d7ec6ca9c5f1373971de74dcbacda (PPTX import: import SmartArt drawing into single GroupShape, 2019-03-14), the problem was that oox::ppt::PPTShape::addShape() and oox::drawingml::Shape::addShape() were not in sync. PPTShape unconditionally maps SmartArt to shapes, while the shared Shape class defaults to converting it to a non-editable metafile. The above commit changed the handling of in-groupshape SmartArts to go via Shape::addShape() instead of PPTShape::addShape(), which exposed the underlying problem that the convert-to-metafile mechanism is currently only working in the DOCX case. Fix the problem by again ignoring the convert-to-metafile flag for the PPTX import case. This also exposed a previously hidden problem: make -C oox -sr CppunitTest_oox_drawingml CPPUNIT_TEST_NAME="testGroupShapeSmartArt testTdf131082" started to make testTdf131082 fail. The tweak in Shape::createAndInsert() fixes the testcase failure, but likely there is a deeper problem there, unrelated to the regression. Change-Id: I4e1e9645eaa266d0d7560767c3c59ba9549ccdb4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120122 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-07-13tdf#141786 correct position of child elements in groupRegina Henschel
...in export to docx. Rotated child elements need a correction to the position values, because LO uses left/top of snap rectangle as position, but Word uses left/top of unrotated shape. For the group itself it is done in DocxSdrExport::startDMLAnchorInline. But child elements' position is exported in DrawingML::WriteShapeTransformation. And there this correction was missing. Position is relative to anchor in Writer and relative to group in Word. The adaption is contained in WriteShapeTransformation. But PolyPolygon and Connector have no explicit rotation and therefore they do not use DrawingML::WriteShapeTransformation but call directly DrawingML::WriteTransformation. So they missed this adaption. I have added the adapation directly to these shapes. Unittest testDmlTextshapeB in sw-ooxmlexport6: I have adapted the values. The position of the connectors relative to the group is better now. You see this, if you compare it with a screenshot of the original file in Word. The handles of the connectors are still wrong and the whole group is still shifted. The patch does not fix the wrong position of rotated legacy ovals, because that error exists independent of groups. Change-Id: Iaf843dcf04bac596427dd35ccfa6cd20e3a4cdc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118748 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-06-15Remove some unused includesMiklos Vajna
See tdf#42949 for motivation. Change-Id: I559eb3b41a5a0fdb37db6c45d73211ca223384fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117193 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-06-04test: introduce XmlTestTools::registerOOXMLNamespaces() to reduce copy&pasteMiklos Vajna
sc/ could potentially benefit from this as well, that's not yet done here. Change-Id: I03d0b4afa21a02c74d34aab6e03ab53991df29dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116679 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-05-26tdf137314 Add margin to CppunitTest assertionsJan-Marek Glogowski
The test had multiple failures on Windows with: oox/qa/unit/vml.cxx(79) : error : Assertion Test name: tdf137314_vml_rotation_unit_fd::TestBody equality assertion failed - Expected: 1490 - Actual : 1491 So add a 1px margin to all value checks. Change-Id: I70298db253299a57cc37eed482c0816d902fbeab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116192 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-05-25tdf#137314 apply conversion from vml angle unit 'fd'Regina Henschel
Fixes wrong rotation in tdf#109129 and tdf#142432 too, but they have further, unrelated errors. Change-Id: I7bd56876bb42b261fe425f80cf9beb639c3ac276 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116078 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-05-20fix leak in CppunitTest_oox_cryptoNoel Grandin
Change-Id: I41d4fe581842cb7822ae899dc6ee6a43e485d211 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115856 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-11tdf#141463 avoid skew in shape group in ooxml import ..Regina Henschel
and implement special resize handling for rotation angles larger 45deg. This solves tdf#93952 and tdf#141953 too. Change-Id: I798f6d2cea29c4a5285f530e9cf7bb10e7f6c41d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115296 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-04-20tdf#122962 DOCX drawingML export: fix polygon shape in group shapeMiklos Vajna
Regression from commit cfb5b20cdc230320ff9f864d1cfd81aaea221da0 (DocxAttributeOutput::OutputFlyFrame_Impl: enable DML export by default, 2013-12-18), there were two problems here. First, <a:chOff> and <a:chExt> was not written for docx group shapes. This can be done for toplevel shapes just by writing what would be the shape position and size (but for docx, we don't write the size). Second, (poly)polygon shapes used the bounding rectangle of their points as size, which doesn't necessarily match the shape size. Given that the group shape is meant to simply contain its children in LibreOffice (and not have an own size), switch to using the UNO API for polygon shapes as well, that way the two sizes will always match. Change-Id: I4406ddefe5f6105aa2fc74d805359add452936bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114305 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-03-12Drop some unused includesMiklos Vajna
Change-Id: Ic79d81387867f028eb8dc9553fb87f5961d6c771 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112364 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-02-25tdf#139734 Remove redundant asserts after MacrosTest::loadFromDesktopMoaz
MacrosTest::loadFromDesktop itself asserts on its return value. Thus, the additional checks in unit tests are redundant, and only create noise unrelated to the tested functionality. Change-Id: If616001b296afdde38f5a23ececee3d44b4a395d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111290 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-01-10fix coverity parse errorsCaolán McNamara
Change-Id: I4884bfb67a061b865e8cf38b2fea6de0cb1bc3d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109057 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-26New loplugin:stringliteralvarStephan Bergmann
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for details. (Turned some affected variables in included files into inline variables, to avoid GCC warnings about unused variables.) Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-17tdf#129961 oox: add PPTX export for table shadow as direct formatMiklos Vajna
Custom shapes export shadow as part of WriteShapeEffects(), so use the same for table shapes as well. This needs fixing the effect export up a bit, because table shapes have no interop grab-bag, glow or soft edge properties, but the rest of the code can be shared. Change-Id: Icf0b90c5b44e3d9c4115c9f3b0d56ba0852ab640 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107836 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-12-11Drop some unnecessary OUStringToOString conversionsStephan Bergmann
Change-Id: I7535065d37a5d56ace0fec90c4f146ff4ce2d753 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107586 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-10tdf#129961 oox: add PPTX import for table shadow as direct formatMiklos Vajna
PPTX export and ODP filter is still missing. Change-Id: I451b334ada80d9d228b7d7f36b5f26473b575ef6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107529 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-12-10tdf#41466 DOCX import: fix VML v:shape/v:textboxRegényi Balázs
VML v:shape/v:textbox element was imported only as a text frame, losing (otherwise recognized) preset shape geometry, i.e. replacing a callout bubble (wedgeRectCallout) and other special shapes with a plain rectangle. Thanks to Attila Bakos for the initial help. Change-Id: I03a608822ed54a20ed07406a08c3539e72958f5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105299 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-11-19tdf#123936 Formatting files in module oox with clang-formatPhilipp Hofer
Change-Id: Ie061189450e0f9004ca503bb28164885812f2acc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105694 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-11-10tdf#42949 Fix new IWYU warnings in directories [h-r]*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I886b6f446293d3b1cfbf4ae05e8dbd7fabab9f20 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105510 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-05clean up some temp files after running testsAndras Timar
Change-Id: Ia28e96cf1f6ec476f202e99877fa80e93d691278 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105314 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-11-03tdf#128877 DOCX import: fix lost position of image cropped to shapeMiklos Vajna
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). Change-Id: I74a60136d0ca8383e58948711b47858823f42437 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105263 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-10-09tdf#133037 OOXML shape import: camera rotation along ZDaniel Arato (NISZ)
Instead of implementing proper OOXML 3D rotation (which would be an entirely new feature if I understand correctly), I merely interpret attribute "rev" of the rotation element a:camera/a:rot as a directive to rotate the entire shape the usual 2D way. That is already implemented and works well. This isn't the same thing Word does, but it might be good enough for now. This is kind of a mock solution, but it will be very easy to revert if it turns out to cause problems. Note: the export worked well previously, too (moreover, reloading the first LO export fixed the import). Change-Id: I2a99c119880bbed1c5b6430c4638cfbd10b7ac06 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103627 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-10-06tdf#137023 PPTX import: fix unexpected center alignment of shape text, 2nd tryMiklos Vajna
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. Change-Id: Id785252c26fc407cd74c9cfb55624091798d7773 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103996 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-27Fix typo in codeAndrea Gelmini
Tested before split here: https://gerrit.libreoffice.org/c/core/+/103464 Change-Id: Iadc9dd49762ec63bd8b3edba322bcbf5d0f862a3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103487 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-18tdf#129685 PPTX import: fix unexpected centering of shape textMiklos Vajna
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. Change-Id: I81a7b3e8c76bfbce5c5569d16d5238958ac20f75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103012 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-18tdf#132555 PPTX VML import: handle stroke properties of image shapesMiklos Vajna
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-06tdf#134183 PPTX: improve import of transparency in multi-step gradientsMiklos Vajna
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-07-15tdf#131175 oox chart import: fix char color of <dLbl>, inherited from <dLbls>Miklos Vajna
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
2020-06-10PPTX import: handle adjust values from both the shape and its placeholderMiklos Vajna
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. Change-Id: I09f669bf59c33b552b906733d323eba7af5548e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95993 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-06-04Upcoming loplugin:elidestringvar: ooxStephan Bergmann
Change-Id: I74da8354fe58c2800a7aaa4145356f61b388dc58 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95507 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-25[MS-OFFCRYPTO] convert oox implementation into UNO serviceVasily Melenchuk
To permit pluggable crypto services, abstract existing implementation behind an XPackageEncryption API. Previous code already had two halfway-polymorphic classes (agile and standard 2007 engine), so we're not adding much additional layers. As MS crypto always uses OLE storage to wrap content into one single file, current implementation passes all substorage names down into XPackageEncryption APi, so different downstream implementations (e.g. for MS RMS, or Azure AIP) are possible. Because OleStorage classes are internal to LibO core, access is provided via XInput/XOutput stream API function. Change-Id: Icc32a4e0ce215090c3b739f1dcaa0654b36b7f08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84436 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-04-01Remove unused includeMiklos Vajna
Change-Id: Ifa3b50b6b31b4a8e8babf7695339848f6730bf11 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91458 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-20tdf#131082 fix missing fill property of grouped shapesnd101
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>
2020-03-17tdf#131118 VML import: fix size of non-autosize shapes containing textMiklos Vajna
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. Change-Id: I9410fc695c3edfa5089d845864bf237e71c533c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90592 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-12Revert "loplugin:constfields in oox"Noel Grandin
This reverts commit a84e3df74eecc8778e3d5be5dd80ad4ddb511edf. Now that we know that making fields has negative side effects like disabling assignment operator generation. Change-Id: I7b45b7ead281cf3a9202ca6aabc55ee5033e5331 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90332 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-03tdf#84399 VML import: map <v:shape o:spt="202"> to TextShapeMiklos Vajna
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. Change-Id: I33a4b3cd03b0df5d93cffa19e7ea834113df2bdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89852 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-02-20Remove some unused includesMiklos Vajna
Change-Id: I28b007cff3a99bc40901ecdeaecacf42b4521574 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89058 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-02-07test: move component context from subclasses to BootstrapFixtureMiklos Vajna
To avoid duplication. Change-Id: I0ee7c26d5d55bd868ead04c77e7f4ef2582f90e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88138 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-02-06CppunitTest_oox_shape: remove unused includesMiklos Vajna
Change-Id: I00f7b042779aa981a5a6390c02f6f4ede59f3c89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88061 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-01-14tdf#129516 DOCX import: fix incorrect z-order with textboxesMiklos Vajna
Commit 3272c1eb5563f3bda2caa24f32b1018372622109 (related tdf#100074: prepare group shapes text input via writerfilter, 2018-10-01) tweaked the oox code, so that later it'll be able to call back to writerfilter to parse group shape text. That makes sense, but it also removed the reset of the group shape context, which means that two subsequent group shapes are now imported as a single group shape with a merged child list. Reset the group shape context again when writerfilter asks for the XShape from oox. If this causes a problem for the above scenario later, then it could be considered to handle this in ShapeContextHandler::endFastElement(). Change-Id: I14f7f0bab2c66c8430313d5b2daffe3160a58c27 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86712 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-01-08Remove some unused includesMiklos Vajna
Change-Id: Icc451b72fd0b4181a082f2ee2b85b82765bd0c31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86385 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-12-20CppunitTest_oox_drawingml: remove unneeded includesMiklos Vajna
Change-Id: I33c524a3991fc3de226ebee3cc98ced18fb74886 Reviewed-on: https://gerrit.libreoffice.org/85547 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-12-19sal_Char->char in oox..registryNoel Grandin
Change-Id: Icc7f2a32696c30317c1ee77ef39d682d5f5a80b9 Reviewed-on: https://gerrit.libreoffice.org/85512 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-03tdf#128429 VML import: let mso-layout-flow-alt:bottom-to-top imply verticalMiklos Vajna
Normally layout flow is set to vertical to denote TBRL, and then optionally there is a layout flow alt to denote BTLR, but the bugdoc shows that the first may be missing. So map to BTLR even in case only the alt layout flow is found in the file. Change-Id: I06fce738fca9aedc0de90ccebda3a24e99425326 Reviewed-on: https://gerrit.libreoffice.org/84275 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
generated by cgit (git 2.34.1) at 2025-01-29 17:26:24 +0000