| Age | Commit message (Collapse) | Author |
|---|
|
The final problem with the bugdoc is that half row of the second
floating table was still on page 1, while it should be fully on page 2.
The reason for this was that first we thought we can't move forward,
since GetIndPrev() returns nullptr for a table that's inside a fly
frame. Then we thought it's a good idea to split, even if the split
would move the entire first row to the next page.
Fix the problem by:
- In SwTabFrame::MakeAll(), handle split flys after calling
GetIndPrev(), an indirect prev of the anchor has the same meaning in
this context.
- In SwTabFrame::Split(), fail for split flys in case only half of the first
row's first line would fit, which gives an opporunity to call
MoveFwd().
- In SwTabFrame::MakeAll(), call MoveFwd() in a way that it's not a
problem that the GetIndPrev() call in MoveFwd() gives us a nullptr.
- At this point we don't split the table, we move it forward, but an
empty master remains on page 1. Fix that by improving
SwFlowFrame::MoveSubTree() to mark empty flys for deletion, similar to
how it does the same for sections.
- Finally avoid a layout warning in SwTabFrame::MakeAll(), it's OK to
try to split in case our split fly has a follow, we can move there on
split failure.
Also bring the test document closed to the original bugdoc, so we can
assert the content on both pages.
(cherry picked from commit 45574624ff05673d44f11cdbbbb49e1af599133e)
Change-Id: I2d3f88342d91b3e256bc41416a9afb274a9309d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155091
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
getViewRenderState would get its output from the current view, make it
so that it's possible to specify a specific view
Change-Id: I279b215f8311b079c220c79b8b41c76bc0210154
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154943
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This reverts commit c5ed52b1cd6f22787c94bec035ceecf9e1da3271.
The reverted commit would insert a pagebreak on section breaks if the
margin before and after the section break was different. While this
means a table after the section break will get the correct margin, it
would also create a page which is very breaking - it shouldn't be the
case in documents that have multiple continuous section breaks in a
single page that a new page is created for each of those breaks if the
margins are different - there are documents where this happens and in
those documents a single page gets converted to multiple messy pages.
Thus the table margins being correct after a section break with a margin
change should be fixed in a different way.
Change-Id: Ia5d5b98ddbd021803a6a9f80762b97db5808509f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154565
Tested-by: Jenkins
Tested-by: Paris Oplopoios <parisoplop@gmail.com>
Reviewed-by: Paris Oplopoios <parisoplop@gmail.com>
(cherry picked from commit df00cd5cf77eb2322f53b80296862940ba815d9a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154624
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
so this is a duplicate call, drop it
Change-Id: I4d332217594f7e1ceb4692ea31a6718ecd44d1ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152304
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 94639b415729beb2a27bcb47da2cbd5205006861)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154850
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
notifyViewRenderState should be executed as soon as a view is created in
order to give a view id to the client
Change-Id: I31b7e61599f546bd5ec134775e6235633a6526f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154681
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Paris Oplopoios <parisoplop@gmail.com>
|
|
The bugdoc has to pages, the floating table from the top of page 2 is
partially moved to page 1 and overlaps with the footer text.
Part of the reason this happens is that in case the vertical position is
relative to the page frame, then Word allows using the footer area for
floating tables (see tdf#155118), but turns out that in case the
position is relative to other places (e.g. paragraph), then this is not
necessary.
Fix the problem by making the "is legacy" condition in
GetFlyAnchorBottom() more strict, which keeps tdf#155118 fixed, but
improves this bugdoc.
Leave the layout unchanged for cases where the floating table is not in
the body text (e.g. footnotes). Now the overlap is fixed, but still a
bug remains where the first row on this split table is not moved page 2.
(cherry picked from commit 9a5d1c250cbaac855b3e63d8c5fa0882ba7d14a2)
Change-Id: I96d6eb527d7f33dd65de8a66f815219c02625d93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154638
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The bugdoc is created from DOC (so tables are shifted to the left,
slightly) and has 2 floating tables on 2 pages. Writer puts them to a
single page, so they overlap, which is not wanted.
The trouble is that there is some space (but not much) on the right of
the floating table on page 1, and Writer wraps the empty anchor of the
floating table on the right of the floating table, while Word puts it
below the table, so no overlap happens.
Fix the problem by extending the work from commit
8f8b31abd02876c3601e343b8b3274754f8a61b6 (compatibility setting for MS
Word wrapping text in less space (bnc#822908), 2013-08-06), and work
with that limit in SwTextFormatter::CalcFlyWidth(). This way Writer
keeps its behavior that PARALLEL wrap text mode requires no minimal text
width for existing documents, but correctly ~300 twips minimal text
width (Word formats).
The bugdoc still has a footer vs floating table overlap, but at least no
2 floating tables overlap now.
(cherry picked from commit a4af5432753408c4eea8a8d56c2f48202160c5fe)
Change-Id: Ib307ede08ead272fe16dca261db615fd8e9c547d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154576
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The document has 2 pages with 2 floating tables, but instead Writer had
a single page with 2 overlapping floating tables.
What happened is that most of the horizontal space on page 1 was used by
the floating table, but out of the 10466 twips body width, 11 remained
(after accounting for the floating table and its margin. Considering
that the empty paragraph needs no space, the paragraph marker was
shifted up, next to the floating table, leading to losing page 2 and
overlapping floating tables.
Fix the problem by checking if the remaining space has some minimal
size: if it has no space to host any actual content, then shift the
paragraph marker down (in compat mode), similar to what Word >= 2013
does.
Note this only fixes the "DOCX, Word >= 2013" version, the original
bug DOC file still needs more work.
(cherry picked from commit 8bd30999098567b3bdb84a6ca65c071952192932)
Change-Id: I00864d9b3ae662cdf19fa63e004da1ee1cc7be7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154572
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The bugdoc has a single floating table, spanning over 6 pages. Loading
results in a layout loop, SwFrame::GetNextFlyLeaf() never finishes as
the last follow fly has no anchor, which should never happen.
The root of the problem seems to be already on page 3. The 6 fly frames
are meant to have 6 matching anchor frames, where the offset of these
text frames is all 0, i.e. the anchor frame's text goes to the last
follow, since commit 73bada774ef37efd5a4498ccc083b1358314557d (sw
floattable, crashtesting: fix PDF export of fdo72790-1.docx, part 3,
2023-04-26).
Fix the problem by improving SwTextFrame::FormatAdjust(), so it never
sets the offset of a follow anchor frame to non-zero when the current
frame has a non-last split fly. All the negative fly frame heights and
the final layout loop was a result of this.
Note that there are still calls to ManipOfst() on the follow frame after
this, but all such calls are from SwTextFrame::RemoveFootnote(), and
that always just sets a non-zero offset + restores it, so that is not a
problem for us.
(cherry picked from commit d59704b6b8c7e5395c0606fa01f37392afc4b2cd)
Change-Id: If62a1e2690cffed2de0be047ffb741d524532dea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154377
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Objects may have offset moving them outside of the current page, where
their anchor is. This doesn't mean that they would move to another page,
just that they will be clipped.
Without this taken into account, objects which rectangle would be on
another page, would trigger infinite loop because of their position
invalidation in SwLayAction::FormatContent's cleanup code, where they
will move to their correct page; and then their off-page rectangle
would move them to another page again.
Change-Id: I2b818403163041a49a3bc1640b1af9a1705fd671
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154444
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 8fc1162d3e7f894adf225fa65ec09bbb83bb17fb)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154451
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The bugdoc has a floating table, followed by an inline table. The inline
table should be on the second page, but instead it's on the first page,
overlapping with the floating table.
It seems this works already for DOCX since commit
50223ea6e212b60b7d33839c2753c5601fb50f95 (tdf#98987 sw: add
AddVerticalFrameOffsets compat mode, 2016-03-31).
Fix the problem by enabling the same compat flag for DOC, since the
intention was to have this on for Word formats in general.
The original bnc#816603 bugdoc still needs more work, though.
(cherry picked from commit 1f2d523aeeafd241c71a468c970054120fb23b3d)
Conflicts:
sw/qa/filter/ww8/ww8.cxx
Change-Id: If9b4e1d3feeeaa24d6e84fea9a10ecdfd995c18f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154346
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Enabling this feature on a list level makes all numbered sublevels, that
constitute the number of this level, to use Arabic numerals. This doesn't
change the labels of other levels: e.g., if level 1 uses A,B,C; level 2
uses i,ii,iii; level 3 uses a,b,c, and is "Legal"; and level 4 uses 1,2,3;
then a list may look like
A. Something
A.i. Some subitem
A.ii. Another subitem
1.2.1. This is a "Legal" sub-subitem
A.ii.a.1. And its child
This improves interoperability with Word.
This change introduces document model, ODF and OOXML import and export.
In ODF, a new boolean attribute of 'text:outline-level-style' element,
'loext:is-legal', is introduced; its default value is "false".
Change-Id: I5ae9f970864854c7e84c4b2f7ce46634b3ef104e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154288
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154332
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The bugdoc has 2 floating tables next to each other, which overlap in
Writer, but not in Word.
This looks quite similar to the DOCX case, which was solved in commit
01ad8ec4bb5425446e95dbada81de435646824b4 (sw floattable: fix lost tables
around a floating table from DOCX, 2023-06-05).
Fix the problem by improving SwWW8ImplReader::StartApo() so it inserts a
fake paragraph when a floating table is immediately followed by a
floating table. A similar case, floating table followed immediately by
an inline table was already handled like this in
WW8TabDesc::CreateSwTable().
Creating a reproducer document from scratch is quite tricky, as Word
will also insert a fake paragraph on the first save of the DOC test file
(so the doc model will be floattable-para-floattable-para) and manual
edit of binary DOC files is also not easy. So the compromise is that the
testcase file has 2 floating tables anchored to the same paragraph, but
they don't overlap visually, while they do overlap in the original,
internal bugdoc. With this, finally the bnc#816603 DOC bugdoc renders
without overlaps, which was the case before my multi-page floating table
changes.
(cherry picked from commit 663db89378aa1f0425e795ef5d471f134e658dc4)
Conflicts:
sw/qa/filter/ww8/ww8.cxx
Change-Id: Ib1b4c7c80833db5a7bde38092c8c3ed6fd1d2462
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154300
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The bottom margin of floating table anchor paragraph in the footnotes
was non-zero, which meant that the document had 2 pages in Writer, but
only 1 in Word.
What happened here is that commit
d1ac8df139a2a65db45d1970ccc0b80e17d827f6 (tdf#146346 DOCX import: fix
table margins in footnotes, 2022-05-03) fixed this, but only for the
case when the floating table conversion was delayed and not in the
instant conversion case. Then later commit
c50bf5a5daaae3d40f89ea0784a75a8a571c208d (sw floattable: remove no
longer needed DOCX import heuristics, 2023-04-12) made all floating
table conversions instant, so the problem was re-introduced.
Fix the problem by now fixing the problem in
DomainMapperTableHandler::endTable(), restoring code that was removed
from SectionPropertyMap::CloseSectionGroup().
There was a disabled testcase for this, so just enable that.
(cherry picked from commit 9ac864159b241d2093e86f664ab6f4b76c69196d)
Change-Id: Ifb7c8fe2bdc70625d3e334cea0893b8e563664ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154238
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Implementing multi-page floating tables resulted a partial
regression here: not last table of the footnote, but empty
paragraph under it resulted an empty split footnote on the
second page, without noticing the problem.
Problem with the previous unit test of tdf#146346 was
reported by Mike Kaganski: "using getPages, does *not*
fail when there are two pages - because getPages is
(problematically) implemented as jumping to the end of
the document (body!), and texting which page is this; and
for the original problem, only a part of footnotes moved
to the second page, while all the body text was on the page 1."
Add unit test to catch the original problem (all tables of the
footnote must be on the first page), which fix likely wasn't
tested correctly using only getPages(), also add a (disabled) test
for the new regression, too.
Follow-up to commit d1ac8df139a2a65db45d1970ccc0b80e17d827f6
"tdf#146346 DOCX import: fix table margins in footnotes".
(cherry picked from commit 7520349b61a74e93a1d5d992f41b60631c3c5937)
[ Miklos: also now CppunitTest_sw_core_layout would fail, so pick a
number of test document updates from commit
fc1b9ab2913bc8c2d8414b6d8de3ceed3910c5d8 (tdf#133560: re-anchor objects,
to use paragraph's dispose for bEndOfDocument, 2023-06-23) from master,
too. ]
Change-Id: I6006db3fe2b5e6f7029a8a2d5d9cf99a17ec2ad2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154237
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
FindPageFrame might return nullptr
Introduced with c684301352bcca709bc8d1c99e0f08e7096e9716
"(related: tdf#149595) sw: also re-sort SwSortedObjs on SwPageFrame"
See https://crashreport.libreoffice.org/stats/signature/SwTextNode::Update(SwContentIndex%20const%20&,long,SwContentIndexReg::UpdateMode)
Change-Id: I2e8df1428400f6752eafaaa6102a1fc3de3f0daa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153977
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit a62af0444515ab28bc0ffdc8ff7f320ca962bbc0)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154112
|
|
See https://gerrit.libreoffice.org/c/core/+/153947/8#message-45a748bf68235bf143bec07cda2d704abb2b140f
> This started to cause e.g. CppunitTest_sw_rtfexport3 to fail with
> /sw/inc/node.hxx:493:53: runtime error: downcast of address 0x606000617540 which does not point to an object of type 'const SwAttrSet'
> 0x606000617540: note: object is of type 'SfxItemSet'
> 00 00 00 00 30 15 0f a9 a6 7f 00 00 50 6a 4a 01 40 60 00 00 c8 98 0f 00 30 61 00 00 80 30 6c 00
> ^~~~~~~~~~~~~~~~~~~~~~~
> vptr for 'SfxItemSet'
> #0 0x7fa671d1b765 in SwContentNode::GetpSwAttrSet() const /sw/inc/node.hxx:493:53
> #1 0x7fa671d7159e in SwContentNode::GetSwAttrSet() const /sw/inc/node.hxx:729:25
> #2 0x7fa673be6c4a in SwDoc::TextToTable(std::__debug::vector<std::__debug::vector<SwNodeRange, std::allocator<SwNodeRange> >, std::allocator<std::__debug::vector<SwNodeRange, std::allocator<SwNodeRange> > > > const&) /sw/source/core/docnode/ndtbl.cxx:1236:51
> #3 0x7fa6775f46a5 in SwXText::convertToTable(com::sun::star::uno::Sequence<com::sun::star::uno::Sequence<com::sun::star::uno::Sequence<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> > > > const&, com::sun::star::uno::Sequence<com::sun::star::uno::Sequence<com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> > > const&, com::sun::star::uno::Sequence<com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> > const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /sw/source/core/unocore/unotext.cxx:2279:51
> #4 0x7fa6775fba56 in non-virtual thunk to SwXText::convertToTable(com::sun::star::uno::Sequence<com::sun::star::uno::Sequence<com::sun::star::uno::Sequence<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> > > > const&, com::sun::star::uno::Sequence<com::sun::star::uno::Sequence<com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> > > const&, com::sun::star::uno::Sequence<com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> > const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /sw/source/core/unocore/unotext.cxx
> #5 0x7fa61c596a81 in writerfilter::dmapper::DomainMapperTableHandler::endTable(unsigned int, bool) /writerfilter/source/dmapper/DomainMapperTableHandler.cxx:1481:35
> #6 0x7fa61cf2fdee in writerfilter::dmapper::TableManager::resolveCurrentTable() /writerfilter/source/dmapper/TableManager.cxx:409:33
> #7 0x7fa61cf30bb1 in writerfilter::dmapper::TableManager::endLevel() /writerfilter/source/dmapper/TableManager.cxx:427:9
> #8 0x7fa61c642f37 in writerfilter::dmapper::DomainMapperTableManager::endLevel() /writerfilter/source/dmapper/DomainMapperTableManager.cxx:496:19
> #9 0x7fa61cf2cae1 in writerfilter::dmapper::TableManager::endParagraphGroup() /writerfilter/source/dmapper/TableManager.cxx:338:9
> (<https://ci.libreoffice.org//job/lo_ubsan/2836/>)
Regression after commit b036e563e699595fa7625888f11ab0c76f1abd66
(tdf#141969: use paragraph autostyle to mimic Word's table style,
2023-07-04).
Change-Id: Idc905cdea35bd0c5f3cfbd562d63894f44e64446
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154106
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit ab8a1e31019056709fbdbbd93a305c7e02af5a5b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154120
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
1. During import, XParagraphAppend::finishParagraph(Insert) are called,
which are implemented using SwXText::Impl::finishOrAppendParagraph,
and the latter calls
m_pDoc->getIDocumentContentOperations().AppendTextNode( *aPam.GetPoint() );
// remove attributes from the previous paragraph
m_pDoc->ResetAttrs(aPam);
so that there is always another (empty) paragraph after the finalized
one;
2. During import, lcl_AddRange is called to create anchored text content;
the start and end of it may reference the very end of the document
(using xTextAppend->getEnd()) - i.e., that last (maybe empty, maybe
extra) paragraph.
3. In many places, and in particular, in DomainMapper_Impl destructor,
DomainMapper_Impl::RemoveLastParagraph is called; and the latter uses
one of the two techniques to remove that last paragraph:
3.1. It either obtains the paragraph's lang::XComponent interface, and
calls its dispose (SwXParagraph::dispose), which eventually calls
DocumentContentOperationsManager::DelFullPara;
3.2. Or it uses cursor to select 1 ch back, and replace the resulting
selection with nothing.
3.1 has an advantage of keeping the formatting of the remaining (second-
to-last) paragraph, but DocumentContentOperationsManager::DelFullPara,
among other things, removes all anchored objects, thus this mode is not
used for the end-of-document case (e.g., see commit message of commit
e521930ea1c855c236efb67793e540d07c201d35 "fdo#58327: writerfilter:
RemoveLastParagraph is tricky:", 2013-01-10);
3.2 keeps the anchored objects, but needs workarounds to keep bookmarks,
and destroys the remaining paragraph character formatting.
Let me try to use #3.1 also in the end-of-document case, by introducing
code to move anchored objects to previous paragraph before calling
XComponent::dispose. Indeed, it may happen that more processing could be
needed, if more properties would happen to be bound to the very last
extra paragraph.
This change adds a call to DocumentRedlineManager::CompressRedlines in
DocumentContentOperationsManager::DelFullPara, because previously, this
was called during #3.2 inside setString. testTdf150086 failed without
this change.
testTdf131386 and testTdf152872 were changed to the now-correct import of
last paragraph properties (previously both of them relied on the hidden
property not present there, while it is there in Word).
In DomainMapper_Impl::RemoveLastParagraph, the check of the content of
selection made by moving backward one character was generalized to be run
before both cases, because RTF sometimes has only one paragraph after a
table (see e.g. testTdf148515), which now could be removed in the absence
of the check.
testTdf104390 was changed to not check the number of runs, because now
the paragraph keeps the trailing "paragraph mark formatting" empty run,
which previously was dropped using setString path.
Also, the fix for tdf#148273 is re-implemented here, by dropping
RES_PARATR_LIST_AUTOFMT in lcl_RstAttr. Likely keeping it was an
unintended side effect of placing RES_PARATR_LIST_AUTOFMT inside
RES_PARATR_LIST_BEGIN/END. After the change, explicit drop of it will be
not needed at arbitrary boundary, which is section break; this property
should only be applied where it's defined. This change can't be done
separately, because of interrelated unit test failures left and right.
In XMLParaContext::endFastElement, setting ListAutoFormat property must
be set only after setting style now, because otherwise it will be reset
in lcl_RstAttr when the style is set.
Some test documents were modified, to drop font from the last paragraph
properties, because their respective tests started to crash (see commit
172270a8f04388a8f8062f672f9c3f3144a01a1f "abort writer layout tests if a
font isn't found", 2022-05-01). Before this change, these paragraphs had
lost their formatting, so those fonts weren't used in layout.
Change-Id: I7e41c20e68e24c78fae1d2005c3fd75fb146ba2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153481
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit fc1b9ab2913bc8c2d8414b6d8de3ceed3910c5d8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153520
Tested-by: Jenkins
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154104
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
See https://crashreport.libreoffice.org/stats/signature/SfxObjectShell::GetBaseModel()
Change-Id: Idcfc8219b5765bca9c45819bde5f276ce68c45de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153971
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
(cherry picked from commit a0669a1a4963b2611fb372c8394ea4530d2c9e96)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154003
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Word's table styles may define paragraph and character properties. They are
handled in DomainMapperTableHandler::ApplyParagraphPropertiesFromTableStyle.
When setting such a character property using setPropertyValue, it may apply
to the text runs inside the paragraph, overriding values from character
style and direct formatting, which must be kept.
To fix that, this change creates a *paragraph* autostyle first, containing
the properties; and then applies only this autostyle to the paragraph; the
autostyle can't apply to runs, so the properties apply at paragraph level.
Sadly, it is impossible to create a useful autostyle in writerfilter using
UNO, because of the same problem that caused tdf#155945. UNO properties
may define only parts of complex SfxPoolItem; setting them without having
already applied values of such SfxPoolItem's would create wrong values for
properties that weren't set by the UNO properties, but happen to share the
same SfxPoolItem. To workaround that in writerfilter, a map of UNO names
to sets of UNO names defining the complex property would be required, and
then maintained.
Instead, introduce a hidded 'ParaAutoStyleDef' property of SwXTextCursor,
taking the same PropertyValue sequence as in XAutoStyleFamily::insertStyle.
Implement it similarly to SwUnoCursorHelper::SetPropertyValues: first,
build a WhichRangesContainer for specific WIDs needed for the properties;
then obtain the actual values for these WIDs from the paragraph; and then
set properties from the PropertyValue sequence.
To create the autostyle properly, the code from SwXAutoStyleFamily::insertStyle
is reused.
There are more "proper" ways to fix this in part or as a whole, e.g.:
* Split all complex SfxPoolItem's to simple ones, as done for one of them
in commit db115bec9254417ef7a3faf687478fe5424ab378 (tdf#78510 sw,cui:
split SvxLRSpaceItem for SwTextNode, SwTextFormatColl, 2023-02-24);
* Rewrite writerfilter in sw;
* Implement the missing proper table styles with paragraph and character
properties, having the same precedence.
But I don't feel crazy enough for any of these :D
Change-Id: I07142cb23e8ec51f0e8ac8609f367ba247d94438
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153947
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154010
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Comments in margin were not exported to PDF when there was no comment
on the first page.
Change-Id: I102834d6e39b0cf471e4b28f7f6b112ad52c54a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153870
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
(cherry picked from commit c8a553388683f12e92d3c30c9d7a29a47ee12c2c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153900
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
The bugdoc has 3 pages, and there are at-page flys anchored to the 3rd
page, and these are not displayed - simply missing from the layout.
In LO 6.1, this worked because the layout-cache was read from the file,
and 3 pages were created in SwRootFrame::Init() calling InsertCnt_().
But now this creates only 2 pages, and later SwLayAction creates the 2nd
page between the existing ones on some MoveFwd(), but despite page nr 2
becoming page nr 3 nothing attaches the at-page flys to the now-page-3.
If a document is loaded containing at-page flys, then all pages that
have flys anchored to them should be created in SwRootFrame::Init()
already.
(regression from commit 7e8b4756d95057f069467b34e7849f9354856578)
Change-Id: I4792c483a7620efd81211e6ad0d9220152367d68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153720
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit ff8ec4cfe5df1e15c3e9f6adc843dfe31358e097)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153699
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
... accidentally broken by commit 4ed26badfd6fd9190cb6e54078b41eb38cb37dca.
Change-Id: I407e1eab47277dd8fa00c123b32596557fd5f2a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154037
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
The bugdoc has a floating table, anchored in a paragraph that is hidden
via character formatting. The bugdoc also has a normal table. This leads
to 1 table in Writer, but 2 tables in Word.
We already have code that tries to make sure floating tables have a
suitable anchor, see the code in WW8TabDesc::CreateSwTable(), but that
checks for the case when the next node after a floating table would be
table (and not text), instead of the hidden character property.
Fix the problem by not creating the hidden char attribute in the first
place in SwWW8ImplReader::SetToggleAttr() in case the pool item would be
inserted at the paragraph start and we just inserted a floating table,
which makes the 2nd table visible in Writer as well.
This is for DOC, interesting when Word converts this document to DOCX,
then the hidden attribute is removed, so there this is not really needed.
(cherry picked from commit 79ddca4def81198e3eee42eca8aca42fef964c80)
Change-Id: I3a7411e6fcc318740bcbd4b0cde9f34134f384a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154090
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
- This dialog was not properly tunneled so did not show on collabora
online
- Running asynchronously as a jsdialog both fixes this issue and is a
general improvement (in that jsdialog conversion improves
accessability, looks more consistent with the rest of COOL, etc.)
Note- This commit was previously given the Change-Id
Ie9a70da70bbb30de039ded82f738285b1b734421 however I have replaced
it due to accidentally creating it against the wrong base branch.
To see the old change go to
https://gerrit.libreoffice.org/c/core/+/147295
Change-Id: I2715eb1d8e3e301e1519e2ef6b69c823e571d08c
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151188
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
The bugdoc has 3 floating tables on page 1, and the anchor of the last
floating table goes to page 2. All anchors are empty (no text), apart
from serving as an anchor for the floating tables. The last floating
table goes to page 2 in Writer, but not in Word.
The problem is quite similar to what commit
2d0a4ef1d83b8de6cb133970c2c35ae706fb058e (sw floattable: fix negative
vertical offset handling on page boundary, 2023-06-20) fixed already,
but here the anchor of the floating table is empty, and there it had
some text, which is a different codepath.
Fix the problem by first requesting a frame split in
SwTextFrame::FormatAdjust() even for empty paragraphs with flys (so the
fly part can go to page 1 and the empty paragraph can go to page 2) and
second disabling the SwTextFrame::FormatEmpty() optimization that would
assume no split is needed, while a split is required for a correct
layout here.
With this, the DOCX version of the original bnc#816603 document finally
renders without overlaps (4 pages, 11 floating tables).
(cherry picked from commit 16b5b21d36da87be9b50235acbbb8008ed23b8bb)
Conflicts:
sw/source/core/inc/txtfrm.hxx
Change-Id: Ie64ce92bf19b3dee8059fa14294d7599b41cc53f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154018
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
It would be that sometimes .uno:ChangeTheme would not load the new
scheme because it was using EditableConfig::GetCurrentSchemeName which
uses a static name - normally great except for when you need different
views to have different color schemes in tiled rendering
Change-Id: I5b149bd1a4776337f76753c6de98d5386a899d34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153939
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Paris Oplopoios <parisoplop@gmail.com>
|
|
Save/load content types' expanded status to view, and make sure it
is synchronized with client.
Treeviews now receive/send collapse event/status from/to client.
I've rewritten the way how headings are opened by default
(because synch of collapsed status broke that, as sub-headings
were not expanded at core side).
Change-Id: I80f5b4d99fe5224391a92c4609f94ddbcf37b8ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153771
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
There is a ToX that is updated; it has about 4 pages worth of entries.
When the old entries are deleted, 2 of the pages become empty, and since
commit b9ef71476fd70bc13f50ebe80390e0730d1b7afb these pages are deleted.
While layouting the new entries, these are moved onto the page following
the ToX, which starts with a page break and contains lots of footnotes.
Now the footnotes reduce the space on the page available for the ToX
entries, and thus after CalcLayout() there are 5 ToX pages instead of 4.
Then the page numbers are inserted into the entries, and another layout
action deletes one of the ToX pages; now all the page numbers are too
large by 1.
Some ideas to fix this:
1) ignore a footnote when formatting a frame that is before the
footnote anchor frame; similar to commit
c79bf7865bff4e88cc201357370d8faeef8e6ad9
2) invalidate the last content on the page when moving forward the
footnote container, similar to commit
eb85de8e6b61fb3fcb6c03ae0145f7fe5478bccf; this doesn't look easy to
do because as it turns out the footnote container is moved in
SwLayoutFrame::Cut() 5 function calls inside MoveFwd() while the frame
on which MoveFwd() is called is still on the page, so would probably
somehow need to be detected in MoveFwd() itself?
3) don't move frames forward onto a page that was created by a page
break - instead create a new frame.
Let's try 3) for now, only in SwFrame::GetNextSctLeaf().
(regression from commit b9ef71476fd70bc13f50ebe80390e0730d1b7afb)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151711
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit 325fe7ab507fd8f2ca17a3db32181edf30169525)
tdf#155324 sw: add unit test
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151876
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit 247738a9afeeb2f0644fa0307b7023fe115fae83)
Change-Id: I641f586799a5ddb4e2a6ff8e9de784e422ecc214
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151889
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Change-Id: If1b902d34157be8c9eab2d5ec140f5e85dfc49e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153731
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
(cherry picked from commit 19fbd6862302065cdf490085d1a8fea49f73d6ca)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153753
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Send the doc background color to the kit on theme change
Change-Id: Ibbcd8d20c8cfce4918544716ffbdf374a1f06e5d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153712
Tested-by: Paris Oplopoios <parisoplop@gmail.com>
Reviewed-by: Paris Oplopoios <parisoplop@gmail.com>
|
|
As Justin Luth noted, "TabOverflow is basically always true", and
using it basically equal to making the test always true. On the
other hand, TabOverSpacing is accurate for the task.
Change-Id: I608b200dac0169cbafc935a03452aac9ba0527a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153722
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
(cherry picked from commit e24a3a3c339d7a175ebfeef31a280becda9d5950)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153703
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Before commit 29bd00f7628e7a54e69cabcc7e2a1792c24aa55c, TabOverMargin
compat option was set for DOCX with any compat mode. After that commit,
the unset option disallowed output of content after a tab stop outside
of the paragraph indents, even within page margins.
SwTabPortion::PreFormat consults TabOverflow when checking if position
is outside the frame; so let's consult it also when painting.
Change-Id: I05ada0da6cd765c70b7bad1287ccc8c11d9b60ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153672
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit dbfa56424f3d41bb58b7c9137f25f4ccb76dc92d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153691
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Change-Id: I2fba70968c97cd9704212cd799b333d2d158a042
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153115
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit 5ab4fb27f4232fe0f36cfc079acb065d1712a355)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153131
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
This can be reproduced with a table containing in the last cell a
paragraph followed by a table, then ExtendedSelectAll in the cell and
delete.
On Redo of the SwUndoDelete:
warn:legacy.osl:326138:326138:sw/source/core/frmedt/tblsel.cxx:1775: MakeSelUnions with pStart or pEnd not in CellFrame
In function:
const_reference std::vector<SwTableBox *>::operator[](size_type) const
[_Tp = SwTableBox *, _Allocator = std::allocator<SwTableBox *>]
Error: attempt to subscript container with out-of-bounds index 0, but
container only holds 0 elements.
The problem is that DelTable() calls PaMCorrAbs() with a target that is
outside of the outer table, so the SwEditShell::DeleteSel() rPam has one
end in the last table cell and other end outside the table.
Change-Id: Ia2764a4c99ba12102957153e005284a44be04fd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153114
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit 4ef548a672658ab164e45e45ebd1b9f0b9282019)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153130
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Second try. This time making sure start > end even for RTL text.
This also now works for horizontal, vertical and rotated Arabic text, in
Writer and Edit Engine.
Change-Id: I6fe1e9dbb9c071287054200a58d4ddddee073311
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152820
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
While the selection with table at the end works for Copy, unfortunately
it doesn't work for Delete, because SwUndoDelete can't handle it,
and an empty SwTableNode+SwEndNode pair remains.
This needs some extra code, extract a SwDoc::DelTable() out of
SwDoc::DeleteRowCol() and call it from SwEditShell::DeleteSel() to
create separate SwUndoDelete objects per table, which appears to work.
(regression from commit d81379db730a163c5ff75d4f3a3cddbd7b5eddda)
Change-Id: I1534b100d31bc279bce298d3c2bd235cffc1f9d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152628
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit 16e40e8d6e6d606cd239331ad7d4c409b3add8e6)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152652
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Surprisingly, SwContentFrame::Cut() is called in a situation where the
frame is not connected to any SwPageFrame yet - it is in a follow fly of
a fly chain that is anchored in a footer, and SwFlyFrame::ChainFrames()
removes it.
(regression from commit b9ef71476fd70bc13f50ebe80390e0730d1b7afb)
Change-Id: Iad84b7b422126e050493dc3b181d47c4dca2fae2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152510
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit d3b64de9581bd5e36ced007ff2e9139bd0343a35)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152533
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
With the minimised bugdoc, on Undo, some 12 or so pages are created, and
the end of the deleted table is shown in the document view.
So first the last pages are layouted, and then once those are done
layout proceeds from page 1.
The problem is that on page 9, a table remains in the 2nd column of the
section, and there is nothing in the 1st column and on pages 5-8.
This is because ::CalcContent() is the last thing that formats the table
on page 9, and it explicitly disables MoveBwd() for follow tables via
m_bLockBackMove.
That appears to be intentional but because it's already been there since
initial CVS import it's unclear why; it might be based on the assumption
that a previous column would have moved over rows from the follow table
already.
Try to encourage the table to try to MoveBwd() at a later time, when
it's being formatted from the SwLayAction::FormatContent_() loop, which
appears to help.
(somehow regression from commit 723728cd358693b8f4bc9d913541aa4479f2bd48)
Change-Id: I421525269948aa58888f5302e6db234c89230f00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152485
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit 5a739d98d0efa5be2130b7d758d494012abc87b3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152446
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Commit 776f7e7463de3e97f3056712ee567f49a314829d changed cclass_Unicode
to reject group separators in numbers by default, but users are
complaining that the neat "5.000" numbers in their existing documents
are now considered invalid.
* in SwCalc, use GROUP_SEPARATOR_IN_NUMBER
* in cclass_Unicode::parseText(), reject a group separator if it is not
followed by at least 3 digits
With this, a number from tdf#42518 "0.19" is still considered invalid,
while "5.000" is now valid again.
Change-Id: If86f2ed4c27be16f866d7f4cee00789344e9ee2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153047
Tested-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit 29f5742bc8ff36741baac5b71082b3daee70ac18)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153146
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: Ibc501dc595eba93adde7b635a5de1122b22c9651
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153190
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
we need to weld also RB_INSERT_NEW_PAGES so
when we check it - JSDialog executor will make
it active and RB_USE_EXISTING_PAGES inactive
Change-Id: I0abc5b6610e301abb1d24ecea680f63358dc5584
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153189
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
When doing undo we save EditShell reference in the context object.
Later it is used to get cursor we want to move to the place
where modification was done (in sw/source/core/undo/unins.cxx:281).
In LOK case when 2 different sessions were used and undo was done
by user A - then user's B cursor was moved. This fixes that issue.
We use current shell instead of getting it indirectly through
SwDoc::GetEditShell()
Change-Id: I7a10ea98587f48818e8d0aaa9ad739d4eed514f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153461
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
SwUnoCursorHelper::SetPropertyValues obtains the node's item set using
SwUnoCursorHelper::GetCursorAttr, adds new items for the property values,
and calls SwUnoCursorHelper::SetCursorAttr to set the updated item set
to the node. This puts all the item set data as direct formatting of the
node (autostyle).
For complex SfxPoolItem, containing several properties, it could result
in some properties having incorrect values e.g. in this sequence:
1. SwUnoCursorHelper::SetPropertyValues is called with a property sequence
including "ParaStyleName" and "ParaTopMargin", represented by a complex
SfxPoolItem (SvxULSpaceItem's nPropUpper). The current node uses another
style, which has a non-default bottom margin; new style has 0 as bottom
margin.
2. It builds a set for the union of all WhichIds corresponding to all the
passed properties, which includes WIDs for paragraph style and for the
respective SvxULSpaceItem.
3. It calls SwUnoCursorHelper::GetCursorAttr to fill the set with current
values for these WhichIds, getting also values defined in still applied
style, including an SvxULSpaceItem with both upper and lower spacing
(the bottom margin value of old paragraph is stored there).
4. It sets new value of paragraph style in this item set, and then calls
SwUnoCursorHelper::SetCursorAttr with the item set.
Now the set contains a new value for paragraph style, *and* an old value
of the paragraphs margins. This margins value is set as the paragraph's
direct formatting (autostyle).
5. SwUnoCursorHelper::GetCursorAttr is called, updating the item set with
new values of paragraph style and margins; the direct-formatted value
for the latter is returned, still containing the values previously
inherited from old style.
6. New value of top margin is set, modifying only nPropUpper member of
SvxULSpaceItem, and keeping nPropLower (value for bottom margin) as it
was, i.e. keeps the value incorrectly saved from old style.
This happens e.g. on DOCX import. Commit db115bec9254417ef7a3faf687478fe5424ab378
(tdf#78510 sw,cui: split SvxLRSpaceItem for SwTextNode, SwTextFormatColl,
2023-02-24) has incidentally fixed handling of left and right paragraph
indents, making their items independent; but top/bottom margins still need
to be fixed.
This change splits the properties that cause side effects (styles) from the
rest; so that properties with side effects are processed first, with item
sets containing only one WID for the currently processed property. This
both allows to avoid the problem, and simplifies the code.
Change-Id: Idd451fa1e53806cdb6b9064dec31e9171d14d5d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153384
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153408
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Removed hardcoded text width/heights and margins in pagenumberdlg to
create the preview image and also added a different text preview for
IncludePageTotal mode
Change-Id: Ib4f4f9ba702f87babf13c1435dc3845add1f43cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153030
Tested-by: Jenkins
Reviewed-by: Paris Oplopoios <parisoplop@gmail.com>
(cherry picked from commit 63627c174778f7d435a540c43ec0498c76e739ab)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153288
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
The bugdoc has 3 floating tables, the last one was on page 1 in Word,
but it was on page 2 in Writer.
It seems what happens is that the vertical offset of the last table is
negative, so it is moved above the paragraph before the last floating
table, but once the anchor frame (last paragraph) is moved to a new page
(because it doesn't fit), then its fly frame is also moved to page 2,
which leads to overlapping text in the original bugdoc. Interesting this
works already with 0 vertical offset, and in that case we split the last
paragraph, fill the page 1 part with a fly portion and fill the page 2
part with the anchor text.
Fix the problem by:
- triggering a split of the frame in SwTextFrameBreak::IsBreakNow(): if
the anchor frame doesn't fit (has to be moved to a next page), then
split it, so only the anchor text is moved, the fly is not (so its
position matches Word)
- preventing the manipulation of the frame offset in
SwTextFrame::AdjustFollow_(), so no content is moved from the follow
to the parent, because that would mean later we move the joined frame to
the next page
- finally minimizing the frame height at the end of
SwTextFrame::Format(), so the master still fits the current page
An alternative approach would be to extend
SwAnchoredObject::FindAnchorCharFrame(), which already has code to
handle the case when the text frame master and the anchored object is
not on the same page, but that operates on existing anchor frames, and
here the original problem is that the entire anchor frame is moved to
page 2, so we don't have anything left on page 1. Note that this is all
specific to floating tables, I could not reproduce the same behavior
with an anchored shape in Word.
(cherry picked from commit 2d0a4ef1d83b8de6cb133970c2c35ae706fb058e)
Conflicts:
sw/qa/core/text/text.cxx
sw/source/core/inc/txtfrm.hxx
Change-Id: I007b57b369f5c1e98ccad77111958dfd9335f079
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153374
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Turning spell checking on or off for a single view would turn it on/off
for every view which is correct behavior normally but not in tiled mode
because different views might want different view options
Change-Id: Ib422f692e97618cfba6a7cb8b2a4f2b3f20a0ca2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153370
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Paris Oplopoios <parisoplop@gmail.com>
|
|
The bugdoc has 2 paragraphs and a floating table between them. The
floating table has a large enough negative vertical offset so it "pushes
down" the paragraph that is before the table in the doc model. Our
layout didn't push the first paragraph down, the second paragraph
overlapped with the table and the whole layout process was just stopped
by the layout loop control.
What happened is that we realized that we have to push down the first
paragraph, so an SwFlyPortion was created for it. Then we made an
UnlockPosition() in SwTextFrame::MakePos(), so it could be calculated
again. This lead to an oscillation, and the calculated vertical position
of the floating table's fly changed between 964 (good) and 2990 (bad)
twips.
Fix the problem by limiting when SwTextFrame::MakePos() calls
UnlockPosition(). The general strategy is that flys are only positioned
once during a layout pass. The exception from this is when the fly moved
to a new page and it's not yet positioned. So if we unlock when the fly
only has the page frame top left position, then we keep the original
use-case working, but fix the layout loop.
Regression from commit 12a9009a1c19ee26c65fb44fc90f3432c88ab6a5 (sw
floattable: fix bad position of follow fly if anchor is positioned late,
2023-03-23), where I didn't realize how dangerous UnlockPosition() is.
(cherry picked from commit 01eff4a68b05dd4eeee94bc4b3b018059efa60d4)
Change-Id: I0aa0a52db712a464105e8040497fd429e0604309
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153315
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
This adds support to import and export background and fill theme
color properties.
Change-Id: I0f40615fe2d06cdcb4f2f9752602fe2ec699c7b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152835
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 9e121f3a6b95dab7525aa1583f810b2b504ce1b3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153255
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
... at start of section.
(regression from commit 2e8aad6d45c53d554ccaf26de998ede708cfc289)
Change-Id: I1e0e720758b607b69645b29c46f4092264289f9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153053
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(cherry picked from commit 142aa77265361492e74707b08c5bcd366e7205ad)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153072
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
