Age | Commit message (Collapse) | Author |
|
Cleanup of class SfxItemSetFixed as described in the bug ticket.
Change-Id: I0704ab45624217a8d00a942e0e8d6d6276934306
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180255
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
This change adds loext:margin-left and loext:margin-right, which
implement margins that support font-relative units.
See tdf#36709 for additional details.
Change-Id: I31b0dd2b6f98cb5b02fd4dca3608db6fdee4054c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177473
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
|
|
Select an inline table (make sure the whole table is selected), insert a
frame, then the frame width is already calculated from the table width,
but an unexpected second frame border / spacing is also added. Given
that the table already has its own border, adding a second border by
default makes no sense.
It's possible to disable default borders in SetFrameSizeFromTable(), but
in case the borders are unchanged, the dialog's output item set will
still contain no border info, so we will still get the default borders.
Fix the problem by making this explicit: if the dialog's input item set
had border info and the output item set had none, then still copy over
the border info from the input to the output in
SwTextShell::ExecInsert().
This automatically fixes the unwanted border spacing as well, so the
default frame properties are on par with the ones created by Word import
filters.
Change-Id: I4c9f165dad7a8bb70cfcfadaea4466a8d174b46e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159399
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The frame insert UI could move a table into a new fly, and then the
frame properties allowed marking this fly as a split fly, but not in one
step.
This happened because the "split fly" checkbox is only visible when we
have a fly that has exactly 1 table, but the "new frame" dialog has no
fly as it still has to be created.
Fix the problem by showing the "split fly" checkbox if we don't have a
fly, but a single table is selected, because we know
SwDoc::MakeFlyAndMove() will create a fly that has exactly one table in
it.
Extract the common code to a new
SwFlyFrameAttrMgr::SingleTableSelected() to avoid copy&paste.
Change-Id: I24129e3fb4cb6231fb10b0adda53c205dfd90d62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159201
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Inline table width defaults to the body frame width, so a hardcoded 2cm
default for the fly width is a bit poor.
Leave the normal fly insert case unchanged, but if an entire table is
selected, then change the default to the table width.
Check for the table selection like SwFEShell::NewFlyFrame() does it, and
determine if the entire table is selected like SwDoc::MakeFlyAndMove()
does it.
With this, a default table with a default frame keeps its width on frame
insert.
Change-Id: Iaf954395a4799222074acd83b5eae52ca75ae0ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159104
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Which flushes out some dodgy behaviour.
Particularly in SwUndoFormatAttr, which was storing a sal_Int32 content offset in a sal_uInt16 page field.
In this case, rather just store the value on SwUndoFormatAttr itself, the same way it does for other things.
Change-Id: I5890353f5d51d82037bf7e0e77a16cf3b0dff565
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149764
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
part of the process of making SwFormatAnchor not use an SwPosition
(because SwFormatAnchor does weird does with the internals of an
SwPosition)
Change-Id: I1694ae83070082f10699aa7b3bd2a043c518d0c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143227
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9a3b33595e34a264baeede33672a0c090ae85157
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138134
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic82df8d321ba2eb94957236264c71c5eb9a940a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130905
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I69e188d7599b7fc439f613cec0a0967ccb748b7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123313
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... in WhichRangesContainer and SfxItemSet ctors. Now it's not needed
to explicitly use 'value' in WhichRangesContainer's ctor, or create an
instance for use in SfxItemSet ctor (svl::Items is already defined as
a template value of corresponding type).
Instead of
WhichRangesContainer Foo(svl::Items<1, 2>::value);
SfxItemSet Bar(rItemPool, svl::Items<1, 2>{});
now use:
WhichRangesContainer Foo(svl::Items<1, 2>);
SfxItemSet Bar(rItemPool, svl::Items<1, 2>);
Change-Id: I4681d952b6442732025e5a26768098878907a238
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119157
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I8662b2e03b0dbe3a7206d8b59ae3556e3b2e75a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119007
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The anchor type is determined during insertion, it's stored as direct
formatting after that.
We used to have a user-profile default for the anchor type. This commit
allows customizing the Graphics or OLE styles: if they specify a custom
anchor type, then that is user instead of the user profile setting.
This allows creating templates where the default depends on the used
template and not on the user profile.
The UI for this was added in commit
5951da5175b9d7e5b3b47bd0d90989d2ef528c79 (sw image anchor type: add
style UI for this, 2021-06-10).
Change-Id: Id05342a5f38dc6267cdbe68b248dc50b87854ce2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117040
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
See tdf#42949 for motivation
Change-Id: Ifc253bf800bb1468b5774663a93f4fb30bec81d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113657
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
(*) Fix SwRotationGrf::GetPresentation to return a more accurate string
(*) Add utility functions
sal_Int32 toDegree100(Degree10)
double toRadians(Degree10)
(*) Fix SwVirtFlyDrawObj::GetRotateAngle to return the angle in the units
that svx expects (deg100)
which was introduced in
commit c2e30949e0fb7c6a73742450f646e0d8d59d5e4f
Date: Wed Apr 10 15:13:53 2019 +0200
lok: writer: svg export transformed images
and consequently we can remove the kludge from that commit in
SdrMarkView::SetMarkHandlesForLOKit
Change-Id: I1a8c5f3a417f887f85b92ae5464578e9ee251619
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108406
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Option introduced at Tools > Options > Writer > Formatting Aids
Change-Id: I8d890f84107647821c39669114b991c301727788
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106970
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Change-Id: I44be72b3a9b14823ec37a3c799cffb4fb4d6e1de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104527
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iff2bd302c3a6cc23be462e5a59aee0d12e7e7c09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99794
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Regression from commit a2f85c062aafb3fd9dfb1c6c6e87e1e73e7545a3
(tdf#130362 sw: fix anchoring of inline math objects, 2020-02-04), the
problem was that the SwFlyFrameAttrMgr ctor wanted to set the anchor
type to at-char, and then later
DocumentContentOperationsManager::InsertEmbObject() wanted to undo that
for math objects, but this did not play nicely with objects imported
from DOCX.
So don't set and clear the anchor type, rather set it conditionally in
the first place. This allows setting the anchor type in writerfilter/
before insertion, and then all of 1) docx import (depends) 2) insert of
Math objects (as-char) 3) insert of images (at-char) are working.
Change-Id: I94d82c12f30d069426db1bab70c456cadf1c91ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99559
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: I07178531d1c1edbfcd1ec1feed0dbe96ed2627a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85793
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I7e1e641ff180035c7dcefdcfdd185eadbae32142
Reviewed-on: https://gerrit.libreoffice.org/84850
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This changes the default set in commit
4f40bf6a79de6d60da0a5090cdfeda6242e889f0 (sw: insert image: set anchor
to as-char by default, 2019-07-04), to have a better compromise, taking
both Word defaults compatibility and usability into account.
The problem is that users are used to just inserting an image and being
able to drag it to its final location, which is broken with as-char
anchoring.
So default to at-char anchoring, this is still something that is fully
interoperable to Word (unlike the old to-para anchoring), but allows the
easier image move again.
Change-Id: Ibc61ae167fc9e5cc31b04c83e854556309e27fd4
Reviewed-on: https://gerrit.libreoffice.org/83089
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I3d1dd03022eb37609ee0dd62c4ee9cec93ac0717
Reviewed-on: https://gerrit.libreoffice.org/76813
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
See the mailing list thread at
https://www.mail-archive.com/search?l=mid&q=999e55c8-5d15-1014-e6f9-9f3d19d003af@collabora.com
(minutes of ESC call ..., 2019-05-09) for motivation, this is meant to
improve Word compatibility, by not defaulting to the at-paragraph anchor
type, which is unavailable in Word.
See tdf#45778 and tdf#87720 for related bugs.
Change-Id: I2699ce04dce02e8436dc3af3b2cc8778f8dc476c
Reviewed-on: https://gerrit.libreoffice.org/75091
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: I861d3f0fa15ee3b7e0e830c4fac2e5794ea4071b
Reviewed-on: https://gerrit.libreoffice.org/72213
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
This reverts commit 8bc951daf79decbd8a599a409c6d33c5456710e0.
As discussed at
<https://lists.freedesktop.org/archives/libreoffice/2018-April/079955.html>
"long->sal_Int32 in tools/gen.hxx", that commit caused lots of problems with
signed integer overflow, and the original plan was to redo it to consistently
use sal_Int64 instead of sal_Int32. <https://gerrit.libreoffice.org/#/c/52471/>
"sal_Int32->sal_Int64 in tools/gen.hxx" tried that. However, it failed
miserably on Windows, causing odd failures like not writing out Pictures/*.svm
streams out into .odp during CppunitTest_sd_export_ooxml2. So the next best
approach is to just revert the original commit, at least for now.
Includes revert of follow-up 8c50aff2175e85c54957d98ce32af40a3a87e168 "Fix
Library_vclplug_qt5".
Change-Id: Ia8bf34272d1ed38aac00e5d07a9d13fb03f439ae
Reviewed-on: https://gerrit.libreoffice.org/52532
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
which triggered a lot of changes in sw/
Change-Id: Ia2aa22ea3f76463a85ea077a411246fcfed00bf6
Reviewed-on: https://gerrit.libreoffice.org/48806
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If07efe4c15cfc28df38a9327856d39313ca78d50
Reviewed-on: https://gerrit.libreoffice.org/50078
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0c71a6fd2e094cebdb720e6c0661cd8a7bb8482c
Reviewed-on: https://gerrit.libreoffice.org/46812
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie56daf560185274754afbc7a09c432b5c2793791
Reviewed-on: https://gerrit.libreoffice.org/45068
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The FlyFrames containing a graphic now support an
interactive rotation mode. Added a rotation icon to the
Toolbar close to right/left 90degree rotation. When
activated, works as similar to draw object mode as
possible. Shear and move of the rotation center is
deactivated since not supported. It uses as much of the
existing interaction stuff as possible.
Change-Id: Ia1a4e5c064d8576b114c3fcf3a96ccb42c9372bb
|
|
This version allows rotation (in 10th degrees) and perserves
it over save/load cycles. Rotation of multiples of 90 degree
behave close to original except not changing the contained
Graphic and being adaptable to all kinds of graphic. The
rotated Graphic is displayed centered and under preserved
AspectRatio in the available frame space (so no rotation,
180 degree is identical, 90/-90 is identical with 1:1 ratio
of the graphic)
Change-Id: I54b3385f709ee0d34a55324aca919dcd2ce0c009
|
|
To allow free rotation of Graphic FlyFrames in Writer,
several adaptions are necessary. This change takes care
of all needed changes to internally support a freely
definable rotation angle for that case. Save/Load round
trip is working, the graphic does no longer get modified
and added in 90-degree-changed state to the object, the
original will be preserved. Support for needed slot in
core/ui is implemented. Rotation can be applied from
Menus/Toolbars in the known 90/180 degree steps. Added
a slot/Button/command to reset rotation in these cases.
Added support in Sidebar to rotate using the rotation
wheel and/or numeric field. These fields and support added
to Image TabPage, too, fully functional.
Missing now is a solution for displaying the rotated
Graphic. For now, it just gets rotated, but this will not
be the final state of this change.
Change-Id: I6f3b85ebb5be2b4ad3311c536d54f27a37a494e7
RotGrfFlyFrame: Linux build adaptions
Change-Id: I365287ecd6525b1972e8436d61332f7121d88649
|
|
Change-Id: Ib6888045cecb4bd7b3498534605d790324f1b40a
Reviewed-on: https://gerrit.libreoffice.org/43265
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Translates leftovers found using a custom regex.
Additionally translated:
- One randomly found comment in /reportdesign
- Test strings in /stoc/test (let's see if it works)
Change-Id: I5f893c194c4b56b5365700928a3b8b63936d03e2
Reviewed-on: https://gerrit.libreoffice.org/41583
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
This is a follow-up to 45a7f5b62d0b1b21763c1c94255ef2309ea4280b "Keep WID ranges
sorted, and join adjacent ones". While SfxItemSet::MergeRange relies on the
m_pWhichRanges being sorted (and, under DBG_UTIL, asserts if they are not), the
various SfxItemSet constructors curiously only check (via assert or DBG_ASSERT)
that each individual range has an upper bound not smaller than its lower bound.
Arguably, all SfxItemSet instances should fulfill the stronger guarantees
required and checked by MergeRange.
And in many cases the ranges are statically known, so that the checking can
happen at compile time. Therefore, replace the two SfxItemSet ctors taking
explicit ranges with two other ctors that actually do proper checking. The
(templated) overload taking an svl::Items struct should be used in all cases
where the range values are statically known at compile time, while the overload
taking a std::initializer_list<Pair> is for the remaining cases (that can only
do runtime checking via assert). Most of those latter cases are simple cases
with a single range covering a single item, but a few are more complex.
(At least some of the uses of the existing SfxItemSet overload taking a
const sal_uInt16* pWhichPairTable
can probably also be strengthened, but that is left for another day.)
This commit is the first in a series of two. Apart from the manual changes to
compilerplugins/clang/store/sfxitemsetrewrite.cxx, include/svl/itemset.hxx, and
svl/source/items/itemset.cxx, it only consists of automatic rewriting of the
relevant SfxItemSet ctor calls (plus a few required manual fixes, see next).
But it does not yet check that the individual ranges are properly sorted (see
the TODO in svl::detail::validGap). That check will be enabled, and the ensuing
manual fixes will be made in a follow-up commit, to reduce the likelyhood of
accidents.
There were three cases of necessary manual intervention:
* sw/source/core/unocore/unostyle.cxx uses eAtr of enum type RES_FRMATR in
braced-init-list syntax now, so needs explicit narrowing conversion to
sal_uInt16.
* In sw/source/uibase/uiview/formatclipboard.cxx, the trailiing comma in the
definition of macro FORMAT_PAINTBRUSH_FRAME_IDS needed to be removed manually.
* In svx/source/svdraw/svdoashp.cxx, svx/source/svdraw/svdotext.cxx,
sw/source/uibase/app/docstyle.cxx, sw/source/uibase/shells/frmsh.cxx,
sw/source/uibase/shells/grfsh.cxx, and sw/source/uibase/shells/textsh1.cxx,
some comments had to be put back (see "TODO: the replaced range can contain
relevant comments" in compilerplugins/clang/store/sfxitemsetrewrite.cxx).
A few uses of the variadic form erroneously used nullptr instead of 0 for
termination. But this should have been harmless even if promoted std::nullptr_t
is larger than promoted sal_uInt16, assuming that the part of the nullptr value
that was interpreted as sal_uInt16/promoted int was all-zero bits. Similarly,
some uses made the harmless error of using 0L instead of 0.
Change-Id: I2afea97282803cb311b9321a99bb627520ef5e35
Reviewed-on: https://gerrit.libreoffice.org/38861
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and
coverity#1403735 Mixing enum types
coverity#1403737 Mixing enum types
Change-Id: I278b7d5116d4157e6aa4483d8eef42325e4bc03b
|
|
Change-Id: I029ad67dfcbc40f3953adf485957efcbd97f23d0
Reviewed-on: https://gerrit.libreoffice.org/35328
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id8a2940ae7348bf75ca967f31adf8489dc678d00
Reviewed-on: https://gerrit.libreoffice.org/35161
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7125b6f8593cac2c33916341f5649f57044ad045
Reviewed-on: https://gerrit.libreoffice.org/31761
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Iec10c5411814008f873868382faf245f38eeae1f
Reviewed-on: https://gerrit.libreoffice.org/31097
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|