RearrangeFootnotes may cause SetRstHeight to set the rest height to 0 for
footnote lines no more fitting the footnote area; but 0 was used as a
special value in IsInside, meaning "no rest height was set", which then
incorrectly measured the upper instead - still as tall as the lines the
frame had before the truncation. Then the frame was considered as having
enough space, marked valid, and the lines cut away from it got no follow to
move to, so they never appeared anywhere.
Give the rest height its own "not given" state instead of spelling that as
a number, and honour a height of zero for what it says. A magic negative
would not do: SwContentFrame::WouldFit_ passes a negative height when the
frames before it overfill the new upper, and that has to keep meaning that
no line fits. The footnote computation in the constructor still falls back
to the upper when it ends up at or below zero, so only the SetRstHeight
path changes behaviour.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: If692577f3ee692ad5c0dbe87f9a11a2670f8cf16
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8906
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 77634c741bb538853a757c2a41e4c9b919f22815)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209271
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
When the cursor position is requesting a spelling correction,
and it is over top of numbering (which translates to ContentIndex 0),
then don't return a spelling alternative
for the first word in the paragraph.
Change-Id: Ie57eaaea443db9ccf0a7c76c6c8c2ccf1cfb4080
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209296
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
The end condition `E.back() > (nRound - 32)` is using the wrong value of
`nRound` and so the loop can end too early.
This has caused a few CI builds to fail after pushing the padding fix,
as the input to `computeHashR6` includes a random IV it happened rarely.
Fix it by counting the iterations of the loop that have been done.
Signed-off-by: Michael Stahl <michael.stahl@collabora.com>
Change-Id: I8bbdc85439789db3753942b1292ba48d39b76541
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8625
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 082e5a49669e2d9058c2b3675c829a495b2044f3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209277
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The arguments for a macro when invoked by the dispatch provider get
converted from a set of PropertyValues to a sequence of Anys containing
just the values. Since the commit below, the TransformItems step was
changed to store the PropertyValues in an unordered_map which makes the
order of the values unpredictable. If the dispatch provider is used to
execute a macro then the order of the arguments becomes important
because the macro has no other way to determine which argument
represents which property. In order to maintain the previous behaviour,
the dispatch method now reorders the arguments so that they have the
same order as before. The previous order was determined by the order the
properties were handled in TransformItems.
commit e8d73d5307
Author: Mike Kaganski <mike.kaganski@collabora.com>
Date: Wed Dec 3 10:45:35 2025 +0500
Let TransformItems return comphelper::SequenceAsHashMap
Simplifies its usage in all places where the result needs to be
modified.
Change-Id: I37f8d99827e0f1cb2b6e4f4f7735e26fb87f6703
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195162
Change-Id: Iacf64650842eb62c0a2bd266784aa9c7accf45bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209231
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
The sequence for LAMBDA in the RPN code is now:
[0] ocLambda, svJump
[1] ocPush, svStringName (parameter name)
[2] ocSep, svSep
(Repeat [1] and [2] for each parameter)
[3] (body code)
[4] ocClose, svSep
[5] (code after LAMBDA expression)
Jumps in the ocLambda point to [0], each [2], and [4], which means
there are two more jumps than parameters.
For example:
=LAMBDA(x;y;x+y)(3;4)
generates the following RPN code:
index opcode type (data)
[0] ocLambda svJump ({4,0,2,4,8})
[1] ocPush svStringName ("x")
[2] ocSep svSep
[3] ocPush svStringName ("y")
[4] ocSep svSep
[5] ocPush svStringName ("x")
[6] ocPush svStringName ("y")
[7] ocAdd svByte
[8] ocClose svSep
[9] ocPush svDouble (3.0)
[10] ocPush svDouble (4.0)
[11] ocCall svByte (3)
The first parameter is in [1], the second is in [3], the body is
in [5]-[7], and [9] is where the code resumes after the LAMBDA.
Change-Id: I4dc871893f47ebbd4dad9cc02ac3efe0ca6ca883
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207973
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
To see the problem, open that bug's document,
https://bugs.documentfoundation.org/attachment.cgi?id=206628 - its
footer holds a picture that wraps top and bottom, anchored to the footer
paragraph and lifted by 81pt, which is less than its own height of
88.5pt. Writer applied that offset as given, so the picture covered the
footer text and sat 7.3pt lower on the page than Word puts it.
What Word does, measured over hand-authored probes:
- an object that wraps top and bottom cannot share a line with its
anchor paragraph, and a footer paragraph has nowhere to be pushed -
the footer holds it at the page's footer distance;
- so the object goes up instead, until its bottom reaches the top of
that paragraph, and it does so for any offset of zero or less, no
matter what the offset says;
- an offset above zero puts the object below the paragraph and is left
alone, and square or through wrapping is not touched at all.
In the body the two already agree, because there the anchor paragraph
can move and both push it below the object.
So pull such an object up until it clears its anchor paragraph, for
MSO-formatted documents only; ODF documents without compatibility flags
keep their pre-existing layout. This reuses the compat flags as commit
409835939a3f1fbaeb1fdf705e60ce508a2be09e (tdf#162211 tdf#137590
layoutInCell: identify bMSOLayout better, 2026-04-14) did, identifying
MSO layout by TAB_OVER_MARGIN and TAB_OVER_SPACING; no new compat flag.
Headers are left alone: there Word clips the object at the page edge
instead, which is a separate question, as is whether a footer object may
hang off the bottom of the page at all (tdf#143933).
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Ifabfe5ee28ba48f3bce615ff490eef52e2ab26f0
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8829
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 7926e7a5852178e17d682cf1c54e5b74d34e1abf)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209267
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
To see the problem, open that bug's document,
https://bugs.documentfoundation.org/attachment.cgi?id=206628 - its
body starts with a floating table spanning three pages (w:tblpPr,
w:tblOverlap val="never"), and its footer holds a picture with
<wp:wrapTopAndBottom/> and a negative positionV offset, so the picture
reaches up into the body. Writer put every page's part of the table at
the top of the body and painted its last rows over the picture, and it
left the table lower on the page than Word leaves it.
What Word does, measured from its print output over hand-authored probes
with exact row heights:
- how much of the table goes on a page comes from the full body height,
with nothing in the way taken into account;
- the part is then shifted up as a whole until its bottom clears the
object below it, which may take it into the top margin area;
- the page edge is the limit - where clearing the object would take the
part off the page, it stays put and keeps the overlap.
The low placement and the overlap are therefore one behaviour: the shift
is what avoids the object. CalcOverlap already avoids overlaps for split
flys, but a header/footer object is anchored outside the body and so was
dismissed as a fly from another upper, and the one conflict it knows how
to resolve is by moving down - which here would push the fly off the
page.
So consider such an object too, and resolve a conflict with one that
starts below the fly by shifting the fly up until its bottom clears it,
as far as the page frame allows. Where the page cannot hold the shifted
fly, keep the overlap, and in no case give up a row to fit.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I00eed5401b5981b0f3eb9b40e7be920bf71b15b3
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8826
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit b356ac63ed2824e20906b26f337d7852994c1a6b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209266
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A row that may not break across pages, and is taller than what a page has
left below the repeated heading, had nowhere to go: it stayed under the
heading, reached past the bottom of the page, and everything below that was
not shown. The setup never worked - StarOffice 5.2 drops the same text.
Two strategies fix it and both are viable: split the row anyway, or leave
the heading off the page the row needs and repeat it again afterwards. This
implements the second, because Word does that. Either would serve our own
documents, but differing from Word turns every such DOCX into an
interoperability report, and adopting Word's layout later would then need a
compatibility flag to keep the ODF documents written in the meantime laying
out as their authors designed them.
A heading is not repeated where the following row could not fit under it, in
neither of the two places that create the repeats: splitting the table, and
rebuilding its frames after a row is added. Otherwise the row is only pushed
on again, and the repeat is left holding a page of its own.
Because the change creates layouts with a lone heading row and no non-heading
row on a page, GetFirstNonHeadlineRow() now returns nullptr where it
previously could not. The two places that dereferenced it unchecked,
MakeSelUnions and SwContentFrame::Cut, are guarded; the first of them crashed
on inserting a row into such a table.
A row taller than the page itself is still split regardless of the setting,
as since commit b271cc4685 (tdf#123116 sw
layout: allow rows larger than page to split anyway, 2020-03-04).
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I5d7a6c555c0b978a9d48d5266574f90e3c41ae3d
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8834
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit db3f6d7fe6b368b5e8989f389f68f73dc3c163b4)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209269
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
with a document loaded from file:///tmp/doc.html a data attribute
resolves as wanted:
<object data="movie.mp4"/> -> file:///tmp/movie.mp4
but with only a src attribute the empty data string resolved against
the base url and replaced the src url already in aURLObj with the
document's own url:
<object src="movie.mp4"/> -> file:///tmp/doc.html
now that case keeps its src url:
<object src="movie.mp4"/> -> file:///tmp/movie.mp4
since:
commit c40afac8a3
Date: Mon Mar 5 17:29:51 2018 +0100
sw XHTML import: map <object> to OLE objects
Change-Id: Ie18ce1ef35a55e618c126db050b0864b342b59df
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8383
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 161009e7f14768d6c37620f722c00fb1f1bc3bee)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209249
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A customer reported recurring crashes (no reproducer available) while a Writer
document was being saved by AutoRecovery. The minidump shows a read of address
0 on the GUI thread with this stack:
InsertCnt_ sw/source/core/layout/frmtool.cxx
MakeFrames sw/source/core/layout/frmtool.cxx
UnHideRedlines sw/source/core/layout/wsfrm.cxx
UnHide sw/source/core/layout/wsfrm.cxx
SwRootFrame::SetHideRedlines sw/source/core/layout/wsfrm.cxx
sw::DocumentRedlineManager::SetRedlineFlags sw/source/core/doc/DocumentRedlineManager.cxx
SwXMLWriter::WriteMedium sw/source/filter/xml/wrtxml.cxx
SwWriter::Write sw/source/filter/basflt/shellio.cxx
SwDocShell::SaveAs sw/source/uibase/app/docsh.cxx
SfxBaseModel::storeToRecoveryFile
Serializing to ODF temporarily shows the tracked changes, which rebuilds the
layout (SetHideRedlines -> UnHideRedlines -> MakeFrames -> InsertCnt_). While
closing a section, InsertCnt_ does
pLay = pLay->FindSctFrame();
and then dereferences pLay unconditionally (pLay->IsHiddenNow(), and in the other
branch pLay->ContainsContent()). FindSctFrame() returns nullptr when pLay is not
inside a section frame, which happens for a section whose content was not laid out
- seen here with tracked changes inside a table - so the dereference crashes.
Guard the result: when there is no section frame there is nothing to close, and
pLay must be left untouched because the following nodes reuse it.
The unguarded pLay->IsHiddenNow() was added in
0c6ec63c81 ("sw: fix hiding of flys in hidden
sections, part 3", 2024-09-06). This is the same kind of fix as
4d48d43a68 ("null deref of pActualSection seen",
2025-08-11), which guarded pActualSection in this same function.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I52d1fb1933498d7d6cb246dab4618807e106afcb
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7321
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
(cherry picked from commit 340b7273e3401da077402b3dcf158ca12e2d7055)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209255
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The color name is stored in the language the format was parsed in, while
GetMappedFormatstring matched it against the keyword table the scanner holds
at export time. Those differ in a document holding formats of several
languages, and the color was then left out of the exported format - German
being the only language with localized color names. Identify the color by its
value instead, against the standard color table the color keywords are
aligned with; that table is static, so the value does not depend on which
formatter parsed the format.
This surfaced as testLocalePrefix in CppunitTest_sc_subsequent_export_test4
failing in a CODA-W build with
- Expected: #,##0.00\ [$€-407];[RED]\-#,##0.00\ [$€]
- Actual : #,##0.00\ [$€-407];\-#,##0.00\ [$€]
where the German format's name is not normalized because
GetFormatStringForExcel skips that step with the Kit active, see commit
0a5026b367 ("lok: save correct number format in
multi-lang session", 2024-04-26).
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I9874185a3204c8e6aac19532b4b446895807feeb
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8063
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 967df3c828dbaba1d5e1451fcf43b2d57d404c67)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209260
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
ScPrintFunc::InitParam decides per sheet whether that sheet contributes
pages. It checked IsVisible on a sheet with no print range, but a sheet
that has one was printed whatever its visibility, so a hidden sheet with
a print area landed in the PDF. Test visibility first, ahead of the
print-range branches. That also drops the duplicated check the other two
branches carried.
The "whole sheets as single pages" option does not go through
ScPrintFunc. It gave one page to every sheet in the document and drew
page N from sheet N, so hidden sheets came out too. Count only the
visible sheets and draw page N from the Nth visible one.
Signed-off-by: Karthik <karthik.godha@collabora.com>
Change-Id: Iee46c1dc1312789bac5aa82d47a17b76b12e651a
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8660
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 7b538dabeb8a19519a55e47ad86a98c39fa24b30)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209252
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The conversion reads results without interpreting, so a formula that nothing
has read since its last change was stored as 0. That happens off the visible
range without the Kit too; with the Kit, testTdf120190 in
CppunitTest_sc_pdf_export failed in a CODA-W build, the converted cell
rendering as 0 instead of the two lines of =5&CHAR(10)&6.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I70f46ef4ca0f36368c88e930db3829081ac12603
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8179
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
(cherry picked from commit 219cd2d0f3ff58388468ce4253dd5835f2fd1081)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209256
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The paragraph sidebar panel is shared, but only Writer and Impress described
the command, so in Calc shape text its indent button arrived with no label and
nothing could give it an accessible name.
Currently calc1/a11y_sidebar_spec.js (Shape Text Context) tests this
incorrectly; the proper testing will happen with a follow-up change.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I546bf93ef1ff58120ba1603764e4644b38d962e3
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8385
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
(cherry picked from commit a588e482f99a4b0816ca3d9b8f963007da9ffe6c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209257
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
It appears that the ownerIdx attribute of <cx:series> is used to indicate
that series share data. At least that seems to be the case with pareto
charts, which have both a clustered column and a pareto line series. Going
on that assumption, implement parsing/export of ownerIdx, and don't write
a dataId tag when ownerIdx is present. That fixes round-tripping of
pareto charts, at least based on what I've seen.
Signed-off-by: Kurt Nordback <kurt.nordback@collabora.com>
Change-Id: Ie948d2e5992b778462e34e1ef90681631c867332
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5900
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 8c37a25ffb7711f69de978045b4e3dc8d52759da)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209240
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
* Update helpcontent2 from branch 'master'
to 6724b6384ee492e29ddc82ad6439474fdd8c036d
- tdf#173165 Explain autodetection of ISO 8601 date format
+ update on how to get it
Change-Id: Id83c4611fce1333c7e315db4392e7ecf7b8f8cab
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/209199
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
For instance, when they were created using Split(), since they may have
been reassigned to a different type.
Change-Id: Ib562dad0156fac267982a224395559713831042c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209107
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Tested-by: Jenkins
GetDropSize is expensive because it goes down into the layout.
There was no need to call this twice.
Found while fixing up some of the documentation.
Change-Id: Iaa44cc9e9cf62b8b1aa7a325c926b01cd8c9ad59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209226
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
We had only one shared setting for the three script groups, which means
the same variation settings are applied to the three groups, which makes
no sense as they often use entirely different fonts.
Change-Id: I6f2a8b4d1c9e0357a6b2d8f4e1c7093b5a2d6e84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209222
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
It is inherited per CSS Fonts, so the children of a group must inherit
it when set on the group.
Change-Id: I3a7f1c58b249e0d647c3b8a15f9e2043b7d6c891
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209212
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Tested-by: Jenkins
rData.sChanged.getLength() - rData.nLen can be negative
when initial data is longer than the changed data
so nSum can be negative too.
So change type of nSum so a negative value isn't transformed in a big positive value.
Also in this case, no need to check if there's some space left.
Change-Id: I9a90a7917509f332463832728e0ab705af136f0b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209186
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
Mike Kaganski