summaryrefslogtreecommitdiff
path: root/oox/qa
AgeCommit message (Collapse)Author
2022-03-25tdf#147978 export subpaths individually in custGeomRegina Henschel
...and implement export of all missing commands, use existing viewBox if suitable, use one EnhancedCustomShape2d move WriteCustomGeometryPoint to protected, make GetCustomGeometryPointValue local The fix solves tdf#100390 too. Without the fix the entire enhanced-path was exported as one element <a:path>. The command F was applied to the whole drawing but should affect only the subpath. The implementation is changed so that each subpath gets its own element <a:path> and command F acts only on its subpath. Support for export of handles and equations is still a long way off. Thus there is no reason to tread shapes with and without handles different. Shapes with handles had used method WritePolyPolygon, but that is not able to handle subpaths. So have desided to use method WriteCustomGeometry for all cases. To get shapes exported regardless of path commands I have added the export for the missing commands. I have removed the no longer used method WritePolyPolygon. The special treatment of shapes "moon" and "mso-spt89" (right up arrow) in export is no longer needed. Related code parts are removed. The unit test testFlipAndRotateCustomShape is adapted. In case the method WriteCustomGeometry fails, the enhanced-path is invalid. In that case an minimal custGeom is written in case of docx. Shapes whose drawing does not touch all edges of the snap rectangle were exported with wrong position and size of the drawing inside the snap rectangle. That is fixed by using an existing ViewBox for the OOXML path size. The old way of creating a path size from point coordinates is only used if the shape has no suitable ViewBox. The point values in unit test SdOOXMLExportTest2::testTdf111798 are adapted to path size 21600 x 21600 and traverse direction of the points is corrected. The resulting shape outline is still the same as before. The expected xml is updated for file tdf92001.odp in SdImportTest::testDocumentLayout. The resulting shape outline is the same, because the shape touches the edges of the snap rectangle. The case, that the shape outline does not touch a edge of the snap rectangle is tested in SdOOXMLExportTest3::testEnhancedPathViewBox. Still missing is the case, that ViewBox has other left,top than 0,0. In that case all coordinates would have to be shifted because the path size in OOXML has only width and height but not left,top. That will not be included in this patch. Change-Id: Ib1736d6a08371f4d98411d2769275f0580cd0030 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131837 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-03-24sd theme: add PPTX export for shape fill colorMiklos Vajna
Do this only in case there are no effects on the color, as that is not yet handled. Note that the theme color was already stored in the grab-bag, so this is primarily interesting in case the theme color was changed or the source format was ODP. Change-Id: Ia4995be68d5f243875632eec4aaf8afbb8f4d5cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131984 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-03-23correct misleading commentSarper Akdemir
Corrects copy/paste residue with the correct content Change-Id: Ie10a4db728de154ebbdaf6c7902b28c71c815456 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131957 Tested-by: Jenkins Reviewed-by: Sarper Akdemir <sarper.akdemir@collabora.com>
2022-02-22Removed executable bits on data filesAndrea Gelmini
Change-Id: Ifcdae0106380de978c608f46e82155c6c9eed20b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130292 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-02-20tdf#146690: pptx export: fix endParaRPr size value for empty paragraphsSarper Akdemir
Fixes paragraphs made from a single new line, not getting the correct sz(text size) value in EndParagraphRunProperties on pptx export Change-Id: I31ebb5735ad392e081aa2f43b0b60a845e4de9c2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128265 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2022-02-15Removed executable bits on pptx fileAndrea Gelmini
Change-Id: Ib14e5357830b587921b633fb57fa74b1314aa1e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129975 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-02-15tdf#132557: PPTX import: Workaround for slide footer shape presetsSarper Akdemir
It appears that placeholder shapes with service names: - com.sun.star.presentation.TitleTextShape - com.sun.star.presentation.DateTimeShape - com.sun.star.presentation.FooterShape - com.sun.star.presentation.SlideNumberShape ... Are unable to have custom shapes in Impress. (i.e. can't be ellipse, triangle etc.). These presets get specified in OOXML with <a:prstGeom prst="ellipse"/> inside spPr (shape properties). Therefore with similar results to the PPT import, a workaround is applied where slide footers which have non default shapes are imported with com.sun.star.drawing.CustomShapes service. The layout/master footers are left as is since if they were to be imported as CustomShapes they would appear on each slide even if the slide had those footers enabled or not. Change-Id: Ic8a8ab3f6dfb7367ecd2c619ce888bf77abef460 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129889 Tested-by: Jenkins Reviewed-by: Jan Holesovsky <kendy@collabora.com>
2022-01-06Removed executable permission on pptx fileAndrea Gelmini
Change-Id: I6a571f12f2e194a6d72a457622505cca72bd8eb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128021 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-01-05tdf#146534 pptx import: make Z rotation work with rotation transformSarper Akdemir
Expands previous idea from a9c5c0d814a266096483572b84c72875ef8efd77 (tdf#133037 OOXML shape import: camera rotation along Z) and uses it also for shapes that have a true bUseRotationTransform flag Also fixes same Z rotation exporting twice from InteropGrabBag to both spPr and textBody causing text overrotating on roundtrip. Change-Id: If0f192af029ca86b932a63613f961be1f5003c5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127880 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-12-16VML import: handle <v:imagedata gain="..." blacklevel="...">Miklos Vajna
Map it to (the UNO API of) GraphicDrawMode::Watermark, similar to what the binary import does in SvxMSDffManager::ImportGraphic() and how the drawingML import does it in oox::drawingml::GraphicProperties::pushToPropMap(). On export, the drawingML export is used, and that already maps GraphicDrawMode::Watermark to <a:lum bright="70000" contrast="-70000">. Change-Id: I33986a03bf3d3863da5c5b1f0a2e0da0fa595c9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126908 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-06PPTX export: handle theme color of shape text with effectsMiklos Vajna
Handle luminance modulation and offset (lighter and darker colors in PowerPoint); not handling tinting/shading for now, as that seems to be not used in DrawingML (only in WordprocessingML), and this code is for shape text only at the moment. Change-Id: I5e97f890d3072c7ef282ed4fb971362b3ddaaa4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126400 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-02PPTX export: handle theme colors from the doc model for shape textMiklos Vajna
As a start, do this only in case there are no effects used. If there is no theme color or there are effects, fall back to the old code. Also move parseExportStream() from SdModelTestBaseXML up to MacrosTest, so oox/ test code can use it as well. Change-Id: Ia76581dcef110341f6c3e60f22c34818ed0dcabc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126215 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-11-24PPTX import: implement native handling of a color's luminance offsetMiklos Vajna
This was already handled in oox/ at import-time: this adds it to the doc model, including UNO API and PPTX import. This is a dependency PPTX export and UI, and also the last transform which is easy to generate from the PowerPoint UI and we didn't import to the doc model. Change-Id: Ica4e738d8dc8e0409160ceab941a82f2475ddc68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125749 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-11-23PPTX import: implement native handling of a color's luminance modulationMiklos Vajna
This was already handled in oox/ at import-time: this adds it to the doc model, including UNO API and PPTX import. This is a dependency PPTX export and UI. Change-Id: I5d875b53d715beb10c13ef616d06cf958d43f70f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125684 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-11-22PPTX: implement native handling of <a:clrScheme> childrenMiklos Vajna
This was already handled by converting them to raw colors at import time. This commit imports the color scheme contents (the 12 colors) into the doc model. This is a dependency to export them back to PPTX and to be able to update these colors on the UI by picking a different theme. Change-Id: I177de4f15d5f0e628669998d1cda7db24220b2eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125651 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-11-19PPTX import: handle <a:clrScheme name="...">Miklos Vajna
We had doc model for this, but the UNO API and the PPTX import was missing. Change-Id: I199e9cc235a783d91700ce74f17d442f41d3c3f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125532 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-11-15PPTX import: fix handling of theme overrides in the chart importMiklos Vajna
A problem since commit 08818d8a45e034ad825c7fafbb76766f106f1d1d (bnc#882383: Do not ignore themeOverride for charts in .pptx, 2014-07-04), an override for one chart should not affect later drawingML objects. Change-Id: I22b70c8c82e8e8520179c628f566d7f6663c887f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125218 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
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
generated by cgit (git 2.34.1) at 2025-01-19 16:58:00 +0000