summaryrefslogtreecommitdiff
path: root/svx/qa
AgeCommit message (Collapse)Author
2021-05-04tdf#139500 svx: fix crash on changing table properties during active text editMiklos Vajna
Regression from commit fdeb04f7c59cf8032fe17072ed779e70505cc6ab (tdf#129961 svx: finish UI for table shadow as direct format, 2020-12-15), the problem was that the BegUndo() / EndUndo() pair can be only used if we know that the text edit of a cell of a table shape is not started or ended in-between. The bugreport scenario was an active text edit, where setting attributes on the shape ends the text edit: #9 0x7f6dbb417121 in SdrEditView::EndTextEditAllViews() const /svx/source/svdraw/svdedtv.cxx:1079:20 #10 0x7f6dbb466798 in SdrEditView::SetAttrToMarked(SfxItemSet const&, bool) /svx/source/svdraw/svdedtv1.cxx:1095:9 #11 0x7f6dbc34b0af in sdr::table::SvxTableController::SetAttrToSelectedShape(SfxItemSet const&) /svx/source/table/tablecontroller.cxx:2738:12 Which also means that the underlying edit engine is deleted. But then undo/redo would still reference that edit engine: ==31830==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c0001fc300 at pc 0x7f6dd73a9cb9 bp 0x7fff788db4b0 sp 0x7fff788db4a8 READ of size 8 at 0x60c0001fc300 thread T0 #0 0x7f6dd73a9cb8 in EditUndo::GetComment() const /editeng/source/editeng/editundo.cxx:147:34 Fix the problem by not grouping in case there is an active text edit, that's not something I considered when I added the original grouping. Change-Id: I4f3583e21a27f8380c35b3f4563ce496819bcb81 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115049 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-04-28use string_view in INetURLObject::encodeNoel Grandin
Change-Id: Ib686c6872388b02c8939d3b65f6bd25cda348bc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114754 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-06tdf#141268: svx_unit: Add unittestXisco Fauli
Change-Id: Ie2f5bff44d8a113c3605fbe4311af5cbcfe009fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113658 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-04-03Revert "tdf#141127 Use ODF default values for draw:extrusion-skew"Regina Henschel
This reverts commit 2bf8c1e0e211601a70b6b28fdb92f636c7969513. Reason for revert: tdf#141268 LibreOffice uses -135deg skew angle as internal default. If a user does not touch the direction, the value is not written to file, although that would be necessary because it is not ODF default. With the patch applied the missing value will be interpreted as 45deg on opening. So the first step is, to write -135deg to file. And then after some time, when wrong files are unlikely, the patch can be applied. A suggestion for writing -135deg is from Julien Nabet in https://gerrit.libreoffice.org/c/core/+/113257. From code it looks good to me, but I have not tested it yet. I would only add some comments to explain the situation. Change-Id: I71673ad2e5376c2a78fa74900e95117b8543e268 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113538 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-03-29tdf#60684 Add unit testAditya Pratap Singh
Change-Id: I9fc633a9a7c977d869297237cdd8547ca0cd9d47 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113037 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-03-25const OUString -> const OUStringLiteralMike Kaganski
Mostly automated rewrite Change-Id: Ie020a083f898bc126b8fb039d4ecb2e687172da1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112965 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-03-22tdf#141127 Use ODF default values for draw:extrusion-skewRegina Henschel
The default value for extrusion skew angle is 45 in ODF and -135 in binary MS Office. LO had used -135 in case the draw:extrusion-skew attribute was missing on import. This could be fixed in GetSkew() in EnhancedCustomShape3d.cxx#92. But that would break import of ppt files. So I have decided not to search, were the binary import would need to be tweaked, but I set the default values directly in file open in case the attribute is missing. Change-Id: Ieeffa64099fdbdbe0ba9d4dab7ed2f19d397a6e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112819 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-03-17tdf#141021 Correct sign in Origin in Extrusion NorthRegina Henschel
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-03-13add PixelFormat enum that replaces bit count in Bitmap/BitmapExTomaž Vajngerl
Bit count for the image is a numeric value (sal_uInt16) but only a handful of values make sense - namely 1,4,8,24 and 32. This replaces the numeric value with an enum, which only accepts those values and checks the correct values are used at compile time. Change-Id: I0fc137c62bce3b0d021f05019a1648da628521bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112408 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.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-03-11svx: rework to avoid pdfium ifdefsMiklos Vajna
Return early in case pdfium is not available, to avoid the ifdef forest. Change-Id: If0e12f9dd937b308b6c3b121801269b2ce68ae60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112284 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-02-27Fix typosAndrea Gelmini
Change-Id: I4188e0bcc4089db3060179b7b1c085218fce92f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111649 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-02-26tdf#132368 svx: empty the interop grab-bag on ending text editMiklos Vajna
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
2021-02-22svx: fix unexpected large bezier shapes when created via the UNO APIMiklos Vajna
Regression from commit bc886f523872d4f9845c188c7d525d72a1a60946 (tdf#98584 Correct import draw:transform values skewY and matrix, 2020-01-02), then problem is was that now we handle the transform matrix for path objects the way ODF likes it, but this breaks UNO API clients with existing code. In an attempt to make everyone happy, revert the default to ignore scaling from the transform matrix, but add a way so that xmloff/ can opt in to handle it. This way the ODF import result doesn't regression and UNO API compatibility is not broken, either. Change-Id: I8d525e56954bf68c42d3629eca87fe9b513de507 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111340 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-02-12svx: fix import of multiple paragraphs into title shapesMiklos Vajna
Title shapes try hard to have a single paragraph only, the Impress UI inserts linebreaks instead of paragraphs breaks in sd::FuText::KeyInput(), ever since commit f47a9d9db3d06927380bb79b04bb6d4721a92d2b (initial import, 2000-09-18). This matches the PowerPoint behavior. This is most visible when the paragraph has a bullet associated with it. Interestingly you can still put multiple paragraphs into title shapes using paste special -> plain text. In that case, it was inconsistent that we exported these multiple paragraphs to ODP, but merged them to a single paragraph on import since commit 0a783c1a041e2b74b7bf238d11ee2c303f6708f4 (#100190# don't allow more then one paragraph on title text objects, 2002-06-25). This results in loosing your bullets on save + open, both in the ODP and PPTX cases, since removeActionLock() on the XShape triggers this tweak. Also, PowerPoint does not do this merging on import. So fix the problem by removing the import-time tweak but leave the UI unchanged. Change-Id: I6796f83c40e83f65cfb0f6c7e66069c3e08c1e2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110826 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-02-10loplugin:refcounting also check OWeakObject subclassesNoel
Change-Id: I2d89085a22d7424c6f8f7662307433ce50fc61d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110666 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-03use more unique_ptr in EnhancedCustomShape2dNoel
and fix some leaks in the unit tests Change-Id: I8d324a24de11b14b4820e3cdd7f078d5877489e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110288 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
2021-01-06tdf#134288 svx: fix rendering of text on a zero-width shapeMiklos Vajna
We have conflicting requirements here: on one hand, the shape is zero width, so the text area is also zero. On the other hand, we put some text on the shape, which should be visible. The result was that the left/right text margin (2x250 mm100) was counted as part of the text area, so we put a few (but not 1) characters / line for zero width. Fix this to be PowerPoint-compatible: as the width decreases, we break the text up to more and more lines, but if the width is 0, then we don't break it up at all. An alternative would be to do this later in SdrTextObj::impDecomposeBlockTextPrimitive(), but there we no longer know the width is really 0, because the text margins and some small increase (+1 to be an inclusive range, +1 to have a non-zero scale) is already added to the original width. Change-Id: Ieaa3e726bc5d37983b6221452e14f01db315f790 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108835 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-01-02introduce Degree100 strong_int typeNoel
Change-Id: I78f837a1340be0ca5c49097f543a481b7b43a632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108367 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-19don't mention VclBuilder in the dialog tests docsCaolán McNamara
Change-Id: Id18a25e3d3310342887757fe417769f4213b8a3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107981 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-17tdf#138976 change "Cancel" button to "Close" in Template Manager dialogSeth Chaiklin
Change-Id: I3e8cbdb70f70002f1fe2b873e899f25a72463358 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107704 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-16tdf#138945 update fObjectRotation for NbcResizeRegina Henschel
SdrObjCustomShape::NbcResize uses the inherited SdrTextObj::NbcResize. But a SdrTextObj does not know fObjectRotation. Explicit update to new rotation angle after resize is needed. The error became visible, if you changed width or height of a rotated or sheared custom shape in the Position&Size dialog. Then the shape handles were not on the shape outline. Change-Id: Idbe47a3b1ef2b34e9645d62830cb330f2e49bd3e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107792 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2020-12-15tdf#129961 svx: finish UI for table shadow as direct formatMiklos Vajna
Normally properties on an SdrObject is set using SetAttributes(), but that would take the selection controller into account, so we would call SvxTableController::SetAttributes(), which sets the item set on the selected cells instead. So use SetAttrToMarked() instead, which works on the shape's item set, even in the table case. Don't replace all existing items because we only have shadow properties here and also a disabled shadow is still a (set) SdrOnOffItem (with value=false), so no old SdrOnOffItem will be forgotten in the shape's item set. Also add an outer undo grouping, so once the user presses OK in the table properties dialog, we only create a single user-visible undo action, not two. Change-Id: I77b55ba1f07b8d0eeac5070e0ec07d39573d1f9a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107781 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-12-02tdf#129961 svx: add rendering for table shadow as direct formatMiklos Vajna
There was already shadow support in ViewContactOfTableObj::createViewIndependentPrimitive2DSequence(), but the UNO API and UI could only set the shadow properties on a shape style, so shadow-as-direct-format is new. One difference between the PowerPoint shadow and our shadow is that we draw shadow for table text as well, while PowerPoint only does it for the borders / cell fill style. This means we're either backwards-compatible or compatible with PowerPoint. Solve this problem by leaving the style case unchanged, but render direct formatting like PowerPoint. Change-Id: I2bc64fea8062f9d8162b95d1eaccb49c3466b5c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107073 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-12-01tdf#129961 svx: add UNO API for table shadow as direct formatMiklos Vajna
Adding it via a style was working already. Change-Id: I122c359716a404159d3521d63d44ef8bfe35c214 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106987 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-11-25tdf#42949 Fix new IWYU warnings in directory svxGabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: If578c5119b85f991825e91df37c42e28f16e9de5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100555 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-16Instead of labs, use overloaded absStephan Bergmann
...more likely to pick an appropriate version for the involved integer types, esp. after the recent long -> tools::Long changes Change-Id: Ia91259ca35aaf74b0e907de6831fc926f30057f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105949 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-16tdf#123936 Formatting files in module svx with clang-formatPhilipp Hofer
Change-Id: I482a00c9f65fd08be03f101c0e18f044c9323137 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105716 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-11-13Fix (some of) fallouts from tools::Long change to 64 bit on _WIN64Mike Kaganski
Change-Id: I297d43c594c5d8c3378e8b7f29ad798e89e4ebaf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105776 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@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-10-26switching long to a 64-bit type on 64-bit windowsNoel
(*) create a rewriting plugin to do most of the work, heavily based on the fakebool plugin (*) but there are still a number of "long"s in the codebase that will need to be done by hand (*) the plugin needs lots of handholding, due to needing to add #include and update macros Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-20CppunitTest_svx_unit: directly use asserts hereXisco Fauli
if it failed, it wouldn't be clear why Change-Id: Ib96674a2d243bea946abff429a267c3ce4fc64f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104559 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-10-16tdf#128212 Change the text z camera rotation order.Gülşah Köse
Old order: 1) Apply all rotation values (normal and camera z) 2) Do the adjustment (top, middle, bottom) New Order: 1) Apply rotation values except camera z 2) Do the adjustment (top, middle, bottom) 3) Apply camera z rotation. We rotate the text at the center of the already positioned rectangle of the text, which depends on e.g. the length of the laid out text. This matches the PowerPoint behavior. Change-Id: I8741cf443834bf01cc07c04318fd6205ed6a0dd6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103965 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2020-09-23tdf#136176 Correct update fObjectRotation in NbcShearRegina Henschel
Change-Id: I4a73a720845436d25fc1a02eb615dad47f17f96d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103269 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2020-09-22OUStringLiteral/OStringLiteral coverity PARSE_ERROR workaroundCaolán McNamara
do more like commit 121771e37f7e2de41cd5643475861062bf25627b Date: Mon Sep 21 09:17:54 2020 +0200 Make some OUStringLiteral vars constexpr cause coverity can live with that Change-Id: I9efd7f848289c4865997a44c6780373068422227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-06svx refactoring: Remove GalleryStorageLocations from GalleryThemeEntryAditya
Change-Id: I3955a66b7ec4f463264dbb5db6209bbb667bf2b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101557 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-04svx refactoring: Remove GalleryThemeEntry::GetThmURL() and othersAditya
Remove GalleryThemeEntry::GetThmURL(), GetSdvURL(), GetSdgURL(), GetStrURL because they don't belong here because they deal with URL. Change-Id: I5a36742c49793726505ebbf394d9410194c39e6c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101547 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann
This is a prerequisite for making conversion from OUStringLiteral to OUString more efficient at least for C++20 (by replacing its internals with a constexpr- generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount, conditionally for C++20 for now). For a configure-wise bare-bones build on Linux, size reported by `du -bs instdir` grew by 118792 bytes from 1155636636 to 1155755428. In most places just a u"..." string literal prefix had to be added. In some places char const a[] = "..."; variables have been changed to char16_t, and a few places required even further changes to code (which prompted the addition of include/o3tl/string_view.hxx helper function o3tl::equalsIgnoreAsciiCase and the additional OUString::createFromAscii overload). For all uses of macros expanding to string literals, the relevant uses have been rewritten as u"" MACRO instead of changing the macro definitions. It should be possible to change at least some of those macro definitions (and drop the u"" from their call sites) in follow-up commits. Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-13loplugin:stringstatic also look for local staticsNoel Grandin
Add some API to O*StringLiteral, to make it easier to use in some places that were using O*String Change-Id: I1fb93bd47ac2065c9220d509aad3f4320326d99e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100270 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-03fix build with (system-)cppunit 1.14.0Rene Engelhard
by #include <unotest/bootstrapfixturebase.hxx> so that CPPUNIT_TEST_FIXTURE is defined Change-Id: Iacbfb2f513df6e7eb7ca04f7900cd4e6b3fd69c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99963 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-07-13move Primitive2dXmlDump from drawinglayer::tools to drawinglayer NSTomaž Vajngerl
drawinglayer::tools causes conflicts with ::tools namespace, so better to move Primitive2dXmlDump out from this namespace as for inspecting purposes it ccan be injected into existing code which could break make it conflict and break compilation. Change-Id: I5f9e594b2b8b1dd24067fa5f5ca3cfc4eefb85cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98627 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-06-14tdf#103474 handle edge cases in ARCANGLETORegina Henschel
The arc-polygon generation in tools does not consider edge cases with zero height or width. That leads to wrong rendering in some ooxml shapes, when the handle is dragged to its extrem position, e.g. in left/right braces/bracket and can. I have switched from tools to basegfx in case ARCANGLETO and added handling for edge cases. Switching to basegfx has the additional advantage, that Bezier curves are used and not polylines. You see the difference, if you convert the shape to curve. ARCANGLETO is not used from our shapes or from import from binary MS Office, but only from OOXML or user-defined custom shapes. tdf#122323 MS Office restricts the swing angle to [-360°,360] in rendering. Such restriction is not in OOXML and not in ODF. Nevertheless, I have added a clamp for ooxml-foo shapes for better interoperability. Change-Id: Ib3233ce14dab950cc521cb8cbac6809a1d3e34a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96068 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2020-06-14Fix typosAndrea Gelmini
Change-Id: I9fbb2e38632d8baa48fb9325824fd2bf7a064d10 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95840 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-06-08svx: fix loplugin:elidestringvar warningMiklos Vajna
Change-Id: I5424388dfc37988b2f4e5f8f34dcb1a577d9bfb6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95806 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-06-08tdf#103474 handle quarter angles before using atan2Regina Henschel
sin(basegfx::deg2rad(fEAngleDeg)) does not result in 0 for fEAngleDeg=180 because of rounding errors and therefore atan2 later in the code gives wrong angle. Because the corresponding circle angle is the same as the ellipse angle for 0°, 90°, 180° and 270°, these angles are now handled before using atan2. Change-Id: Iae2a4d188b837ff787f2af4d79f874ba21c9aa2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95772 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2020-06-05Upcoming loplugin:elidestringvar: svxStephan Bergmann
Change-Id: Ia7b4f69361b6cc29f6e5c0093b13cf0b48e25ba3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95576 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-02Removed executable permission on graphic filesAndrea Gelmini
Change-Id: I47099bd08e73ef726be60b740c4b72220cb7fc6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95362 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>