| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Change-Id: I56463130ab617b0e11e237718cb8456913373818
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165696
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
|
|
For an empty line at the end of an empty paragraph, Writer already uses
any existing text attribute in the paragraph, see for example
testEmptyTrailingSpans.
For an empty line at the end of a non-empty paragraph, Writer text
formatting uses only paragraph attributes, ignoring any text attributes,
whereas the UI will display the attributes from the text attributes
(such as font height) if you move the cursor there.
Word uses text attributes also in this case, so adapt the inconsistent
Writer behaviour: text formatting now uses text attributes too.
Apparently this can be achieved by calling SeekAndChgBefore() instead of
SeekAndChg().
Add another compat flag "ApplyTextAttrToEmptyLineAtEndOfParagraph" to
preserve the formatting of existing ODF documents.
Adapt test document fdo74110.docx, it has a line break with "Angsana
New" font.
Change-Id: I0863d3077e419404194b47110e4ad2bdda3d11c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165887
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
The last (5th) paragraph in the index was on page 2, even if page 1
still had space for it.
This is a regression from commit
397d72e582c725d162c7e0b819dc6c0bb62e42b0 (Related: tdf#158986 sw
floattable: fix unexpected page break with sections, 2024-02-23), in
case SwLayAction::FormatLayout() doesn't calc its lower content frames
then this bugdoc is good, but the old bugdoc moves its floating table to
the next page, which would be bad.
Fix the problem by making the condition for this "calc lower in
FormatLayout()" action more strict: only do this for content frames
which are in sections, followed by sections.
Note that probably a cleaner way would be to completely stop calculating
content frames in SwLayAction::FormatLayout() and only do that in
FormatContent(), but then it's not clear how to re-fix tdf#158986, and
at least this resolves the regression.
Change-Id: Id671b3b68d8af8ad1cca3399a9aa028de58df3a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165878
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ifde41deb66c8dcb72842e18e539609ff351be832
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164972
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
Open the document, press tab to switch to a field, start typing, nothing
shows up.
Looking at the doc model dump, it turns out we inserted characters
between the field start and the field separator dummy characters,
instead of the field separator and the field end ones, which is quite
bad.
Turns out that in the meantime commit
c80606bb23fd42e41710d70a96b7ffaf948384a6 (tdf#109272: make sure that
Delete / Backspace move cursor correctly, 2024-01-18) fixed this, kind
of by accident: the comment says the motivation there was change
tracking.
Add a testcase to to make sure this now continues to work.
Change-Id: I1a300d8064f7c2a30aafeefc6cb5612bfcd9a06a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165368
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The function unnecessarily uses an intermediate XUnoTunnel variable to
handle SwXTextRange, but the implementation of XUnoTunnel was removed.
(regression from commit 635448a996714a81cb15b41ac4bb0c73cabfb74f)
Change-Id: I90dd7acbd259e8ca562a534ad0bc9a5b85356553
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165162
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
This reverts commit 332faa63407305852f5044e4bbc41302ccfe46cd.
This change adds a CppUnit test that changes the position
of an image in an example document which causes a crash
if the bug exists.
This also adds a delete guard for a SwFrame used to
prevent a use-after-free condition.
Change-Id: I5cfec75681a5877c007df33c23d9a5e61e4292c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162940
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Conversion of hex/dec colour notation
(example entry Color( 255, 255, 255), Color(0xFFFFFF) - COL_WHITE)
For the other available colour definitions.
Change-Id: I9eed0cd64adcbc8d25e1c22143a000906a457586
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163729
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ib3edefc365d3c605c3024e160572fa4030100ef1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164724
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The events may be processed after the shell has been destroyed. This is
happening reliably after commit e2bfc34d146806a8f96be0cd2323d716f12cba4e
(Reimplement OleComponentNative_Impl to use IGlobalInterfaceTable,
2024-03-11) when controlling LibreOffice from external Java scripts; but
obviously, it could happen before as well.
Now SotObject inherits from cppu::OWeakObject, instead of SvRefBase.
Change-Id: I73a3531499a3068c801c98f40de39bdf8ad90b2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164458
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Regression from commit 6d8da2b2deb4be2182ca1852cec7eb38a4c654eb
(tdf#96943 sw Hide Whitespace: don't create pages for widow / orphan
..., 2016-01-07), the reduced bugdoc has 3 paragraphs, 1.5 paragraphs
are on page 1, 1.5 paragraphs are on page 2. Hiding whitespace moves the
entire paragraph 2 to page 1, which is unexpected.
Checking the original use-case, the
CheckPageHeightValidForHideWhitespace() call in
SwTextFrameBreak::IsInside() can be removed, and still the original
"type character at the end of the document results in a new, unwanted
page" problem is not back. Likely at some point in the meantime we gave
up on these reduced page heights for the last page, so the original
tweak for widow/orphan lines is not needed anymore.
Fix the problem reverting the original, no longer needed fix, but
keeping its testTdf96943 test in the CppunitTest_sw_uiwriter4 suite.
Such reducing of last page doesn't happen with Word 2021, so probably
this change in behavior is wanted.
Change-Id: I5d46d0cd84d0071ffb9ef3f8e4ca7335e61bb226
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164408
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Regression from commit ce2fc5eb29b4e252993b549dee002fa8948c8386
(tdf#158341 sw floattable: fix layout loop when fly is below the body
frame, 2023-11-29), open the bugdoc, add an empty paragraph at the
start, Writer layout crashes. The immediate problem is that
SwTabFrame::MakeAll() assumes that in case HasFollowFlowLine() is true,
then GetFollow()->GetFirstNonHeadlineRow() is always non-nullptr,
similar to the situation in commit
223d2fac61e061478721a7a4a89b1362f5037d8f (sw floattable: fix crash by
trying harder to split tables, 2023-11-22).
The deeper problem is that the bugdoc has a repeated table header row,
the fly frame temporarily gets shifted down, so nominally the header
doesn't fit anymore, and this leads to a modification of the doc model,
which creates inconsistency: the model now says we have no header rows
but the layout still contains table row frames where the header bit is
true. This is problematic in theory, but in practice caused no problem
so far.
Fix the problem by disabling this mechanism for floating tables: trying
to have a table header that doesn't fit the table is asking for trouble
anyway, and this way at least we have a layout that is consistent with
the model, which also avoids the crash, now that nobody violates the
"HasFollowFlowLine -> follow's FirstNonHeadlineRow != nullptr"
invariant.
Also extend the layout dump, so it's easier to see when the master's
flag and the follow's row list gets out of sync.
Change-Id: I52b51f6d86ab4e0bab560f892e9cceb183aecd5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164136
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Regression from commit c303981cfd95ce1c3881366023d5495ae2edce97
(tdf#156724 sw: layout: fix tables not splitting due to footnotes
differently, 2023-08-24), the floating table in the DOCX version of the
bugdoc went from page 1 to page 2.
It seems what happens is that the first page has 2 section frames, and
we used to directly recalc the last lower of the first section frame,
which triggered a recalc of the second section frame, so the table moved
from page 2 to page 1 once the top of the second section frame was
reduced (so the table could fit on page 1). But this direct recalc was
removed because it caused problems for split tables and footnotes in
tdf#156724.
Fix the problem by conditionally restoring the OptCalc() call in
SwLayAction::FormatLayout(): only do it for the last lower of section
frames, which is enough for the DOCX version of tdf#158986, but it keeps
the old tdf#156724 use-case working (the layout of that bugdoc doesn't
modify with this change).
The RTF version of the bugdoc (which was the originally reported
problem) still needs more work, but that's hopefully not a layout
problem but an RTF import one.
Change-Id: I1134ec3a27aec8ee871b535d81dedf9d27bd6bd5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163805
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This patch imports bitmaps/tiled textures (primarily),
but also somewhat for gradients
(because of a gradient2 -> gradient mismatch somewhere)
and somewhat for patterns
(because patterns are not well imported in general).
Note that the imported fill likely will NOT match MSO,
because their background CHANGES BASED ON THE ZOOM LEVEL.
For example, my primary testing file (A6 landscape)
has a logo which is only 25% visible in Word 2003 at 100%,
but shows 90% of the logo at 200%, and many tiles of logos
when exported as PDF.
The same is true for gradients etc.
Changing background on zoom is an absolutely bizarre implementation,
and naturally LO could only accidentally look identical
(and should never try to do so).
make CppunitTest_sw_ooxmlexport21 \
CPPUNIT_TEST_NAME=testTdf126533_noPageBitmap
make CppunitTest_sw_ooxmlexport21 \
CPPUNIT_TEST_NAME=testTdf126533_pageGradient
This is slightly ugly, but I don't know how to make a COPY
of the XPropertySet UNO junk. All I have is references,
and dispose deletes everything, even the references.
I took some inspiration from RTF
which just disposes the shape after grabbing the background color.
Thus, just change the page style known to exist and be used,
and then simply remove the fill if it isn't needed in the end.
Any new page styles can just copy the default page style fill.
Change-Id: Id3ea002c685642ff4c289982d0108247a6e9bb8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162958
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Regression from 868140fcc1311259b9d5f666637b33d226511a53 (tdf#60558 sw
floattable: allow wrap of table on the right of a floattable,
2023-12-05), the bugdoc layout looped on load.
Somehow the big while() loop in SwTabFrame::MakeAll() never finishes: it
always tries again but can't reach a state where all of frame area
position, frame area size and frame print area is valid.
Fix the problem by going back to the old behavior (floating table is
wrapped by text frames, not by table frames) for the nested table case:
that keeps the old tdf#60558 use-case working and fixes the new
tdf#159285 use-case.
At some point it would be useful to support the combination of nested
floating tables and the "floating table wrapped by table" combination,
but that will be a new layout feature.
Change-Id: Ia3fdbd08de87e13ddef086ae1339e79a8833674d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163630
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ia2a3100f07b45dba214a7f534d6adb54b2ceaa89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163000
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
The bugdoc had no header in Word, but had one in Writer, since commit
17e51f427b3f0cec74ac8e0a1b3f51189006ae6f (DOCX import: first page header
should always set default headers as well, 2014-11-21).
The code has changed a log in the meantime, today we import first page
headers and left/right page headers as a single page style, but still
code was missing to detect the case when <w:headerReference
w:type="first"> was not followed by <w:titlePg>, which is an indicator
that the first page header/footer should be used.
Fix the problem by new flags to SectionPropertyMap to track if we ever
seen a first/left/right header. This allows making an informed decision
in SectionPropertyMap::setHeaderFooterProperties(): if the header is on,
but we effectively don't have none of a first, left or right header,
then it's time to turn it off, similar to what the DOC import does.
Note that this only changes behavior for headers, but if there is a
practical need, then the same could be also done for footers as well.
Instead of adding a new test, notice that testTdf112694 in
CppunitTest_sw_core_header_footer explicitly tests this case: a first
header which is not a title page. So change that testcase to assert the
behavior now matches Word and drop the FIXME.
Change-Id: Ib604e786d7a5a197d4b562533326206697de882a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162992
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This reverts commit 16d46e25e03cd506576ac3dcb6be56270b47b4a6.
Reason for revert: macOs jenkins fails in CppunitTest_sw_core_objectpositioning now
Change-Id: I45ed894c9773e0dc23d0f9fdd9066eb5ca7110f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162901
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
This change adds a CppUnit test that changes the position
of an image in an example document which causes a crash
if the bug exists.
Change-Id: I0f507ccf63c2c7f49f6ed71cd8df174b2b3136f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162857
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Regression from commit 9bad5be0ffdcdee92d40162b598ed2ab2815e5d5 (sw
content controls, checkbox: add PDF export, 2022-09-13), we used to
export checkbox content controls as plain text, but once checkbox
content controls are exported as forms, the state of the checkboxes are
lost.
Writer content control checkboxes support custom values for the checked
and unchecked states, but the PDF export does not. On one hand,
PDFWriterImpl::createDefaultCheckBoxAppearance() assumes that the
checked state should be a checkmark, not the Writer default 'BALLOT BOX
WITH X' (U+2612). On the other hand, the PDF spec section 12.7.4.2.3
"Check Boxes" says that the checked state should be "Yes", which
explains why our checked state is not recognized by PDF readers.
Fix the problem by making the export of checked/unchecked states
conditional in SwContentControlPortion::DescribePDFControl(): the
checked state then shows up as expected.
Leave the unchecked case unchanged, the current markup there doesn't
cause problems.
Change-Id: I9063d8607c8cccfa080921af38b3cbfe40905115
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162765
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
How to reproduce it from scratch:
1. Open writer
2. Form - Content Controls - Rich Text/Plain Text
3. Split the control intro different lines
4. Export to PDF
-> The content control is displayed in one line
Change-Id: Ia8666c8a6520e94ae06693ea8767c1d79aa5d3a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162446
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
|
|
Regression from commit 868140fcc1311259b9d5f666637b33d226511a53
(tdf#60558 sw floattable: allow wrap of table on the right of a
floattable, 2023-12-05), the document had an inline table, followed by a
floating table, and we moved the inline table to the right even if the
left hand side of the floating table already had enough space.
What happens here is that nominally the inline table's original position
overlaps, but because the table width is small enough, such an overlap
doesn't actually happen. In this case, it's not needed to shift the
inline table to the right.
Fix the problem by making the check that decides whether it's necessary
to increment the left margin of the table more strict: it's not enough
to have enough space on the right of the fly, it's also needed to *not*
have enough space on the left side.
This keeps the original "floating table wrapped by inline table on the
right" use-case working, but restores the ~no left margin for the inline
table for the new bugdoc.
Change-Id: Ifb30d90ca6dba7cc4a402d8a4445251120b575ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162447
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
In commit 19062c98da5b2e9edc7a99068fa06a83c7578826, it was important to
check if objects have frame format before using GetFrameFormat.
Thic change makes it simpler amd more obvious. Also, it allows to avoid
two calls to GetUserCall, by obtaining the pointer once and checking it.
Change-Id: I980fcba9e369e107f3d062e8cab0a34e02384290
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162044
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
or Endnote"
This reverts commit 75680dd751062b7ca34ff91e03de3add3fc973c6.
I won't be able to debug layout problems indicated by Miklos.
Change-Id: Ie610949a229468ba00d04b3542e14bdb68d7e1dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161752
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
There's still layout refresh pb.
Change-Id: I613cbf77a32452fdc42501e2eaf8450b7dedf327
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161085
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
The problem was that the bugdoc had an empty paragraph with superscript
(as char format) enabled and that was simply lost in the layout. Adding
text to the paragraph or removing the superscript formatting worked
around the problem.
What happened is that SwSubFont::GetHeight() has a somewhat surprising
explicit check for escapement, and there the CalcEscHeight() call might
be invoked on an SwSubFont whose m_nOrgHeight is 0, while the intent is
to just return the original height in case of automatic subscript or
superscript.
Fix the problem by checking the result of GetDefaultAscentAndHeight() in
SwLineLayout::CalcLine(), and in case it would simply turn the line into
an invisible one for an empty line with sub/subscript then go back to
the already correctly calculated line height.
This needed adjusting a test in CppunitTest_sw_ooxmlexport12 because the
bugdoc there had such a paragraph, effectively testing if we lose
content during layout, which is not wanted.
Change-Id: I1e836531851ea5c9a983ae69da5be8a042cc6e39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161588
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The old name was misleading (it doesn't take an URL, but a filename);
also, now it's easier to grep for it - doesn't get mixed with
vcl::graphic::loadFromURL.
Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Update hex colors 0x000000, 0xFFFFFF, and 0xFF0000 with COL_BLACK, COL_WHITE,
and COL_LIGHTRED, respectively. See comment #30 for more details.
Change-Id: I82ff851d8c19f9ef4aeeb01bff313160da615222
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160452
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
See
<https://gerrit.libreoffice.org/c/core/+/160756/2#message-9a43d741ca1307aa796eda092bd3857614c63a6f>.
Change-Id: I6db7128240b344a8169214a70fdcaff3cab57286
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160759
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The document has a floating table of 2 pages, with some anchor text on
page 2. Split of the anchor text resulted in 2 paragraphs: the first
still hosts the floating table and now lacks a fly portion (overlap of
text and floating table) and the second still wraps around the floating
table but has the correct position.
What happens is that we format the first text frame, then its flys
(which moves the follow fly from page 1 to page 2) and then we format
the second text frame. This means that the first text frame should have
a fly portion to wrap around the floating table, but it does not have,
because SwTextFrame::Format() is called for the first text frame, then
SwPageFrame::MoveFly() is called, then SwTextFrame::Format() for the
second text frame, i.e. no reformat of the first text frame after moving
the fly.
Fix the problem somewhat similar to what commit
cf2c070de2bafeec3b476c6bff7bb4ac87ba46db (sw layout: invalidate margins
of body content when moving a fly from page, 2022-12-09) did, but here
what's outdated is the portions of the text frame, and only for the
anchor text frame.
This fixes the problem in practice, but note that in theory this could
affect non-split flys and also other, non-anchor text frames as well.
Limit the update of the portion list to the anchor of the split fly, but
we may want to do the same for all lowers of the body frame if there is
a practical need for it.
Change-Id: I3067e78d30e16ed3d2f02a80cff4cd84d9bdcf3b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160748
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The document has a floating table with some anchor text. If we hit enter
at the end of the anchor text, the anchor text remains in the old text
node and a new text node is inserted after it, still wrapping around the
floating table. If you do the same at the start of the anchor text, then
a new paragraph is inserted before the floating table, which is
unexpected.
The OOXML concept we try to model here is that a floating table is a
table-in-fly that's followed by a paragraph that hosts the anchor text,
so the anchor position of the floating table should never change. This
behavior was even locked down in the testSplitFlyMoveMaster testcase,
but there the motivation was to make sure the fly chain is consistent.
Fix the problem by removing the special-casing in
SwTextNode::SplitContentNode() for the "at para start" case that was
added just to please the testcase. Instead update the test assert the
bad 1 -> 4 -> 2 chain is not there, so it still covers the old fix but
allows the new behavior.
With this, the Word and Writer UI behaves the same when inserting a new
para right after a floating table. The layout position problem of the
empty text node (should be wrapped, is not) still needs fixing.
Change-Id: Ib9a1f07eeb144ea929183cdc72a22bc23042fee1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160669
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Iadafff97ba19d5c24be768238bddb4d684edde1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160509
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
If you go to the anchor text of the floating table and you press enter
in the second half of the anchor text, you get a layout loop.
The reason for this: an invariant around split text frames were
violated, later resulting in a layout loop. The rule is that in case you
have a split frame, then there can't be a frame for a new text node
between the two split frames. So no new text frame for an other node
after the master anchor of the fly; no new text frame for an other node
before the follow anchor of the fly.
Fix the problem by improving SwTextNode::SplitContentNode() to check if
this is an anchor for a split fly: if so, always insert the new text
frame after the follow anchor of the fly, which doesn't break the above
invariant.
The layout loop is fixed, but the text in the follow anchor of the fly
still has a bad position, that still needs fixing. Also currently
testSplitFlyMoveMaster enforces that split at the para start inserts a
paragraph before the floating table, so leave that case unchanged for
now.
Change-Id: I77962a354e297d2e9957edcce9bf140f2c72fc6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160608
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I5f000f53f4dfec62a6d5a332361c380dc142d2bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160342
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
The bugdoc shows that Word wraps inline tables around floating tables if
they have enough space, but Writer didn't do this.
Table frames may wrap fly frames by adding some top, left or right
margin to the table at a layout level, this is calculated in
SwTabFrame::CalcFlyOffsets(). There we currently decide the give a top
margin to such tables, which fixes the overlap problem, but the bugdoc
is now of 2 pages instead of 1 page, since we don't wrap.
Fix the problem by improving the "shift down" case by checking if
shifting to the right would also work (has enough space). If so, do that
in case the fly frame is a split fly.
Note that this could be done for all flys as well, but that would have
to be conditional on some Word compat flag and that's not needed to fix
the bugdoc, so leave that for later.
Change-Id: Idb45413257758fd0334b17ef348ba28010a52316
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160331
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Iae999cd64ca73f178e4e1148af71b47fe03c8e2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160206
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Clicking on the right of the floating table on the page 1 resulted
in a cursor position on page 2 instead of a position inside the floating
table on page 1.
What happens is that the anchor text frame on page 1 is wide enough to
contain the mouse click position, but then "before the first character
of the paragraph" is on page 2, so a page 1 click results in a page 2
cursor position, which is unexpected.
Fix the problem by first ignoring which dummy anchor frames (all
non-last ones) in SwLayoutFrame, so
SwLayoutFrame::GetModelPositionForViewPoint() in
SwPageFrame::GetModelPositionForViewPoint() fails for the perfect match
case, and then later looking for split flys explicitly, so the corrected
case finds the split fly on the page.
I imagine this is not only useful for mouse clicks, but it's also good
for everything else that uses GetModelPositionForViewPoint(), e.g.
keyboard page-down.
Change-Id: I761b211c1b5468d9d8996c59a32ac9be5b83a777
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160194
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Previously the ooxml import added a new page style when the first
header or footer was detected. Since then we gained support to add
first page header/footer in an existing page style so we don't need
to import it like that anymore.
This changes the import code so that the old complication to add
"First Page" page style is removed and it always just uses the
"Standard" page style for all 3 cases: first, left and right headers
and footers.
This also adjusts the existing tests to align with this change.
Change-Id: Ibf69597e6990499ac520ea9e323a5f73f429800b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157860
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
When the PageDesc is copied from one document to another, we
don't make sure the stashed FrameFormat(s) are also properly
copied to the new document (which can happen at copy/paste). This
can cause a crash if the stashed FrameFormats are accessed or
destructed after the original document is destroyed.
This fixes the issue so that when we detect the PageDesc belong
to different documents, the stashed FrameFormats are copied just
like the non-stashed FrameFormats (used for headers and footers).
Change-Id: I948068dba4d39bb47c3725dfa8491c53c5833c7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160065
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I1ca85b9f1424df5432c76d08280b9dba3e01d2dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160090
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Regression from commit 28675af84ae8e2342bd78be3696dc09de6ce5cc5
"tdf#41652: Variable width NBSP".
Change-Id: I066ecadac8961b182f8580147b197f13dd0daae4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160054
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Regression from commit 25b8fdd3b939a221ba00ca37fbf89adaf893aab7 (sw
floattable: maintain the invariant that fly height is at least MINFLY,
2023-09-28), the document started to layout-loop on load.
What happens is we have a fly frame where the bottom of the body frame
is above both the top and bottom of the fly. We used to make sure these
flys don't "flip" (with a negative height) and ensure that their height
is still MINFLY. But that causes a new problem, because the layout will
try to make sure they fit, but they can't have enough space.
Fix the problem by improving the correction of the fly height, so in
case even the top is below the deadline, then we set the height to 0 and
explicitly mark the frame as clipped. That keeps the unwanted warnings
about violated invariants fixed and fixes the layout loop.
The test just ensures that all pages but the last one has a single
multi-page floating table, chained over several pages.
Change-Id: Ibac0a465839a59abe5ae49809c0d76c955aa39b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160061
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
In addition add some more basic header/footer tests.
This makes refactoring of header and footer OOXML import
much easier.
Change-Id: I5b3b3714656ba2f7b1dda8d8f067c3bfe68857a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159946
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
The anchor text of a floating table is normally wrapped around the table
only on the last page of the table. This property requests to wrap on
all pages instead for this frame.
Commit 7d7ca347fafa7a06094b00e8fb0d0452c4c81366 (sw floattable, wrap on
all pages: add layout, 2023-10-13) already arranged the layout code to
go via the per-frame SwFlyAtContentFrame::IsWrapOnAllPages(), so only
that needs updating.
Instead of always deciding this at a per-doc level, first check if the
frame itself requests the on-all-pages behavior. Otherwise keep deciding
this on a per-doc level. This is meant to please what the OASIS/ODT
proposal wants and also keeps the Word-style per-doc setting.
The ODT filter still needs doing.
Change-Id: Ibf10b5f016d70e6fe948d5273cc1fb1d98495586
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159981
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This exposes the internal property SwFormatWrapTextAtFlyStart on the UNO
API.
We need this, because otherwise the ODT filter can't read/write it.
Change-Id: I67d3c28e3531b19183f8361a6df87b7a4ca84294
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159888
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Currently the wrap-on-all pages mode is off by default and a
document-level setting can enable it for all split flys.
Allowing this at a per-frame level (and not only per-doc level) is
suggested in <https://issues.oasis-open.org/browse/OFFICE-4150>. Given
that this floating table proposal is coming from us, it makes sense to
also support this additional attribute from the proposal, even if it's
not supported by Word.
Fix this by adding a new SwFormatWrapTextAtFlyStart property on fly
frames: this is meant to be enabled when wrap-on-all-pages is wanted for
this fly, but it's disabled at a per-doc level.
Unlike SwFormatFlySplit, this is meant to be easy at a layout level,
since SwFlyAtContentFrame::IsWrapOnAllPages() is already a per-frame
function, it is just backed with a per-doc setting.
Change-Id: I8f562102c2bc366a36c08895b681c4a2ab256bd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159847
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Regression from commit 60e2fdf1d7e8346e5a3835369c47e582c737ce20 (sw
floattable: maintain the invariant that fly height is at least MINFLY,
2023-09-28), the bugdoc crashed on load in SwTabFrame::MakeAll(),
because the tab frame's HasFollowFlowLine() was true, but
GetFollow()->GetFirstNonHeadlineRow() was nullptr and the invarint is
that these are always in sync.
Digging deeper, what happens is that the master table has a split row at
the end, so the follow table has a "follow flow line". We remove that
when we try to split the master table (split either moves rows to the
follow or creates a new follow), so the follow table only has a
"headline row" remaining. Then Split() is called with bTryToSplit set to
true, this fails (because only a single line would fit the master, but
orphan/widow control rejects that) and then we join the follow table
(because it only has headline rows), so a split with bTryToSplit set to
false (don't split the row itself) never happens. This at the end leads
to a strange table frame with only headline rows and gets deleted, which
is odd to happen during the initial layout.
Fix the problem by remembering if we just removed the follow flow line,
and in case we tried to split the rows itself and table split failed,
then don't join the follow table, so a next split can be invoked with
bTryToSplit set to false, which leads to the correct layout. This means
not only the crash is fixed, but also no layout loop happens and result
matches Word.
Limit this to tables in split flys, at least for this bugdoc the inline
table case would not have this problem as widow/orphan control is
disabled inside inline tables.
Change-Id: I172e38be11baf6f73df722a4c6c035a6a283d727
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159802
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Fixes a crash introduced by commit 5082d50.
Change-Id: Id33c49165c4d345d652a546db14df98ee0ff754a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159736
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Pressing the unfloat context menu item for a frame resulted in 2 undo
actions and trying to undo both even crashed.
One problem was that no SwNode was left in the TextFrame and then it was
deleted; but undo created a TextFrame with an empty SwNode in it.
Fix this by inserting an empty text node at the end of the TextFrame and
only then moving content from it.
The other trouble was that in case the new text node has no matching
frame during MoveNodeRange(), then the fly frame will be deleted twice:
once during MoveNodeRange() (because it has become empty) and once more
during DelLayoutFormat(). This can be avoided by moving AppendTextNode()
to its own layout action. Finally also group the (now) 3 undo actions
together, because it was a single action on the UI.
Change-Id: I95ce0abbab79a293ecb209579c105f96d284a1c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159730
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I210f61f6d90776b086b7058fb1a831d235699fb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159670
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
