Age | Commit message (Collapse) | Author |
|
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>
|
|
Change-Id: Ib686c6872388b02c8939d3b65f6bd25cda348bc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114754
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie2f5bff44d8a113c3605fbe4311af5cbcfe009fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113658
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
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>
|
|
Change-Id: I9fc633a9a7c977d869297237cdd8547ca0cd9d47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113037
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: Ic79d81387867f028eb8dc9553fb87f5961d6c771
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112364
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
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>
|
|
Change-Id: I4188e0bcc4089db3060179b7b1c085218fce92f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111649
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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
|
|
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
|
|
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
|
|
Change-Id: I2d89085a22d7424c6f8f7662307433ce50fc61d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110666
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: I4884bfb67a061b865e8cf38b2fea6de0cb1bc3d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109057
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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
|
|
Change-Id: I78f837a1340be0ca5c49097f543a481b7b43a632
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108367
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
Change-Id: Id18a25e3d3310342887757fe417769f4213b8a3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107981
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3e8cbdb70f70002f1fe2b873e899f25a72463358
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107704
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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>
|
|
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
|
|
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
|
|
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
|
|
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>
|
|
...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>
|
|
Change-Id: I482a00c9f65fd08be03f101c0e18f044c9323137
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105716
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
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>
|
|
Change-Id: Ia28e96cf1f6ec476f202e99877fa80e93d691278
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105314
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
(*) 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>
|
|
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>
|
|
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>
|
|
Change-Id: I4a73a720845436d25fc1a02eb615dad47f17f96d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103269
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
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>
|
|
Change-Id: I3955a66b7ec4f463264dbb5db6209bbb667bf2b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101557
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: I5424388dfc37988b2f4e5f8f34dcb1a577d9bfb6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95806
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
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>
|
|
Change-Id: Ia7b4f69361b6cc29f6e5c0093b13cf0b48e25ba3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95576
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I47099bd08e73ef726be60b740c4b72220cb7fc6b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95362
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|