summaryrefslogtreecommitdiff
path: root/svx/CppunitTest_svx_unit.mk
AgeCommit message (Collapse)AuthorFilesLines
2021-03-17tdf#141021 Correct sign in Origin in Extrusion NorthRegina Henschel1-0/+1
This is about customs shapes in 3D mode using direction floater. Shapes, which were created with older versions, keep their values until the direction is newly assigned. So the change will not automatically change existing documents. Change-Id: Ib1ce511de0f524bf59279fb4e976f66ed65bc080 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112474 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-02-26tdf#132368 svx: empty the interop grab-bag on ending text editMiklos Vajna1-0/+1
Regression from commit aafaf1f55fa413ad49d4556cf7c0a713dd206ae4 (PPTX export: save SmartArt as diagram instead of group of shapes, 2019-03-13), the idea of interop grab-bag was to carry additional information around as long as the object is not changed. However, actual clearing of the grab-bag was never implemented, do this when editing shape text. An alternative would be to do this in SdrObject::SetChanged(), but Writer sets the layer of SdrObjects during layout (when the import filter is already finished and undo is enabled), so that would mean loss of the smartart metadata for DOCX. Change-Id: I9ab205b4ef84169f4b5a16b86fe9a152e3370a6c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111560 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-05-11tdf#129916 svx: fix origin of scaled shadowMiklos Vajna1-0/+1
We assumed that the top left corner is the origin for scaling, but that is not necessarily the case. The intention is that the shadow direction can be determined from its x and y offset, and the origin is the opposite corner of the shape. Change-Id: I6759302767d20739b6e2be79d379740dd06f70f5 (cherry picked from commit a1dde1a85a8d1c54521a0ac6310571ffcdd4bb5a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93974 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-01-17tdf#98584 Correct import draw:transform values skewY and matrixRegina Henschel1-0/+1
Covers tdf#98583 and tdf#98565 too. TRBaseGeomety (API) uses for skewX the same angle orientation as written to file. But that results in mathematically wrong matrices. Change sign where needed. Vertical shearing is converted and written to file by LO as sequence rotation * shear horizontal * scale. Same should happen on reading. Because LO does not write skewY itself, I have used the angle orientation, that was used in OOo1.1.5 and that is used in Scribus 1.5.4. Import generates a transformation matrix from the draw:transform attribute. That is a mathematically correct matrix. It is applied to the shape via TRSetBaseGeometry. But that uses a wrong sign in the shear angle. Therefore conversion of mathematical matrix to TRBaseGeometry matrix is needed. The draw:transform attribute can generate a scaling, which needs to be applied on top of the scaling made from svg:width and svg:height. Such happens on import of skewY() and might happen with matrix(). SdrPathObject puts scaling form svg:width and svg:height directly into the coordinates of its points. It had ignored any additional scaling. I have add a part to detect and apply it. Change-Id: I7636b9feec432cf403e7c6ef8dbd6a769793d144 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86244 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2019-11-20svx: add rendering for semi-transparent shape textMiklos Vajna1-1/+6
The color's alpha is normally lost when we roundtrip SvxColorItem's tools Color via TextSimplePortionPrimitive2D's basegfx::BColor. One way would be to add an extra transparency member to the primitive, like BackgroundColorPrimitive2D does that. However, a much easier way is to go via UnifiedTransparencePrimitive2D, that way we handle transparency in drawinglayer::impBufferDevice::paint(), rather than platform-specific code like CairoTextRender::DrawTextLayout() in the Linux case. Change-Id: Ie7aebe77ad9ac776dd27fc50538a5045200c8010 Reviewed-on: https://gerrit.libreoffice.org/83307 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-03-04tdf#121845 rework custom shape path command U and TRegina Henschel1-0/+1
The patch covers several errors, see comments in the bug report. Change-Id: I6cdaf3e8951dab21b314ef61e12ffa3b3ee481dc Reviewed-on: https://gerrit.libreoffice.org/68029 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2018-12-13tdf#121890 ODF custom shapes use left and top from viewBoxRegina Henschel1-0/+1
MS custom shapes use always zero for identifier left and top in the formulas of the shape geometry. But custom shapes in ODF use the left and top value from the svg:viewBox attribute, see table 11 in section 19.171 draw:formula; part 1 of the spec. Change-Id: Ief4b9d9b8797e165a494d049f32c5a46880044c2 Reviewed-on: https://gerrit.libreoffice.org/64704 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2018-05-19tdf#117614 svx: make drawing.GraphicExportFilter work with sw imagesMiklos Vajna1-0/+3
A Writer image has an underlying SdrObject, but GetSdrObjectFromXShape() won't work for it, also we can't an sw SdrObject into an XShape because SvxDrawPage::CreateShape() has no idea how to handle sw's SdrInventor::Swg inventor. Fix the problem by just getting the Graphic of the Writer image and improve GraphicExportFilter to be able to work with just a Graphic as well. Change-Id: I3c9b3005366fcc87815597a27df3cb8a99a8876c Reviewed-on: https://gerrit.libreoffice.org/54527 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-02-27Fix exporting bitmap table + testTomaž Vajngerl1-0/+11
Change-Id: I0577de02000c6aeb45bf1e950b9212beadacb05b Reviewed-on: https://gerrit.libreoffice.org/50334 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2017-03-08make SfxGetpApp just get and move GetOrCreate to the peripheryCaolán McNamara1-0/+1
Change-Id: If3b22635e46dbccf0fad101f51bb653cbbcd3a32 Reviewed-on: https://gerrit.libreoffice.org/34957 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2016-11-22trivial makefile cleanupsMichael Stahl1-4/+0
Change-Id: Ida5bdfa06ecd7907305f4f171ca5ab64260d0259
2016-06-29svx: add XOutBitmap testcaseMiklos Vajna1-0/+11
This fails with commit 7d76bb251e0c88ff17282a33b801a5d17a434af5 (vcl: add graphic export-as-pdf filter, 2016-06-24) reverted. Change-Id: Idea5c282d610d949958d757677ee642d97ca1c8e Reviewed-on: https://gerrit.libreoffice.org/26747 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-06-09tdf#94698 cleanup Makefiles. Get rid of udkapi and offapiGleb Mishchenko1-4/+1
This patch changes occurences in makefiles from $(eval $(call gb_CppunitTest_use_api,comphelper_test_config, \ udkapi \ offapi \ )) to $(eval $(call gb_CppunitTest_use_sdk_api,comphelper_test_config)) (corrected instead of abandon, jani) Change-Id: Ic96ec65d82d7452e288f05a8b6d576ef543b068e Reviewed-on: https://gerrit.libreoffice.org/23426 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: jan iversen <jani@documentfoundation.org> Tested-by: jan iversen <jani@documentfoundation.org>
2014-09-19fdo#84061 Fix setting text style sheet listeners in SdrTextObjTobias Lippert1-0/+32
The code in SdrTextObj::ImpSetTextStyleSheetListeners is obviously not working correctly. The families of the stylesheets are appended to the name of the family for further usage. An encoded string looks like "STYLE_NAME|3 " The family is then extracted by copying the first (length-6) bytes, e.g., "STYLE_NAME" in this example. Then another copy starting a position 1 is created, e.g., "TYLE_NAME". This string is cast to an Int32. Since this is not possible, 0 is returned, and the originally stored family is lost. This patch corrects this behavior, and adds a unit test. Change-Id: I60c0add6e4b670acbbc264cc77672452f282f737 Reviewed-on: https://gerrit.libreoffice.org/10818 Reviewed-by: Matúš Kukan <matus.kukan@collabora.com> Tested-by: Matúš Kukan <matus.kukan@collabora.com>