| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The situation is the following: we have a text frame, with at least two
anchored objects: one is wrapped not-wrap-through, the other is. In case
the non-wrap-though one shifts the text content of the text frame right or
down, then layout may or may not want to re-consider what is the top
left corner of the text frame for anchoring purposes.
Regarding the x position, sw layout repositioned the anchor point
depending on the AddFrameOffsets compat mode: it's enabled for documents
imported from Word, disabled otherwise. Regarding the y position, no
repositioning was done, however the bugdoc shows that Word does the same
repositioning on the vertical axis as well.
Add a new AddVerticalFrameOffsets compat mode that enables vertical
repositioning as well, and enable that mode for documents imported from
DOCX.
Also (squashed in, as the second commit partly undoes what the first one
did):
tdf#99004 SwAnchoredObjectPosition: handle textboxes when determining surround
Writer TextBoxes are always wrapped "through", so that they can appear
inside their shapes. However, the surround of the shape may influence
its position. So when surround is asked for anchor position purposes,
take the surround of the TextBox's "parent" shape instead of the one of
the TextBox directly.
With this, the textbox in the bugdoc is properly positioned inside its
parent shape as expected. (The problem only happens when at least two
shapes are anchored to the same paragraph.)
(cherry picked from commits 911261a3a581b9f2f4262f1d5403d9be3bbecf63,
f5e0236566b913aebb1376d97c7d37a23c69bd84,
50223ea6e212b60b7d33839c2753c5601fb50f95 and
cd1b2f923e0b0be89a5d1c8cbc647133aac09ed5)
Conflicts:
sw/qa/extras/uiwriter/uiwriter.cxx
sw/source/core/inc/anchoredobjectposition.hxx
sw/source/core/objectpositioning/anchoredobjectposition.cxx
sw/source/core/text/txtfrm.cxx
sw/source/uibase/uno/SwXDocumentSettings.cxx
Change-Id: Idc5cad7d86662008a92ff3bf5fbb3806aa2c7b07
Reviewed-on: https://gerrit.libreoffice.org/23739
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
renames the most annoying abbreviations in Writer (and partially
in the shared code too).
Change-Id: I9a62759138126c1537cc5c985ba05cf54d6132d9
|
|
Resurrect the special hack "lcl_SubtractFlys" that effectively paints
"lower" flys on top of "higher" flys, defying the z-ordering, if the
lower fly is *anchored* in or at the higher fly.
It turns out that this is not obvious to emulate in any other way that it
is currently implemented:
One idea would be to split up painting of the fly background from the
foreground, by creating 2 different view objects per fly as children
of the SdrPage when decomposing it in svx; but the problem is, they will
be ordered in z-order of the flys, and the point would be to paint the
backgrounds first and in a different order, call it "anchoring order".
What that order should be is hard to tell, there is a conflict between
the defined z-order and the flys that are part of one "anchoring
hierarchy" and should have their backgrounds re-ordered, because
entirely unrelated flys that could belong to different "anchoring
hierarchies" but overlap the first ones may result in a cyclic ordering.
Painting one "anchoring hierarchy" recursively would not get
z-order of flys from different anchoring hierarchies right.
Another difficulty is that heaven-layer backgrounds would need to be
painted before hell-layer ones.
Another aspect of the lcl_SubtractFlys is that it entirely ignores
drawing shapes; only Writer's own flys are handled.
Since none of the above makes much sense, we clearly want to
deprecate the lcl_SubtractFlys rendering.
Introduce a new compatibility flag "SubtractFlysAnchoredAtFlys" so that
the legacy rendering is only active for legacy documents, while new ones
remain free from its taint.
(regression from 6e61ecd09679a66060f932835622821d39e92f01)
Change-Id: I710fe79710b89c8f865ebb7162e14713aac6cc4a
|
|
Change-Id: Ia4f135c64e6b6b5bd7a522e4a1e9ca63738ff3ef
|
|
Change-Id: I66ac08c52d472d96979da84f5be462dca3105e0b
|
|
This is enabled by default, to get the new formatting where the first
line of a paragraph is shrunk if a proportional line spacing < 100% is
applied; existing OOo documents get the previous (before LO 3.3)
formatting. Since the formatting in LO releases is broken anyway, it
does not matter much which way documents written by old LO get
formatted.
Change-Id: I0952f568a933c137bd03070759989cac3517d8b9
|
|
Into the new class DocumentLayoutManager.
Change-Id: I02d0cfcc63633d0bdab380508b2ef563187fd269
|
|
Into the new class DocumentStateManager.
Change-Id: I91c9097b091ff6118d58fd15fff2a4cefe0171fd
|
|
Change-Id: I9f6c8ceafd09b4a5d4e951e01e1a06b2b5265181
|
|
To the new class DocumentDrawModelManager.
All moved methods and members have the same in thew new class.
Change-Id: I89ad0e0c4a42885d5810e834983ea8e8e6c0a2d2
|
|
Compatability -> Compatibility
Change-Id: Ia80e6db589a74d2aa8d1276195bc30ddb8d251fd
|
|
Moved mn32DummyCompatabilityOptions1 from SwDoc to DocumentSettingManager
and moved a comment from SwDoc to it.
Change-Id: I4abd5cd9596d23dc3ac12460ee9b38345d0bf0a7
|
|
Change-Id: I3ed0f926e79f3878c5702c2becae97d99d00e201
|
|
Change-Id: I12cb17c5b357d966e7a11bdeb69d930bcdc8ab22
|
|
Change-Id: I324a0ffde2ddcca105451c19e7aadcfad15211d8
|
|
Change-Id: I4a7ec73d3bdf9888e50d071b593798b74780b80c
|
