| Age | Commit message (Collapse) | Author |
|---|
|
an effort to remove C6011 Dereferencing NULL pointer 'pDepend'
Change-Id: If9e7b7be25ece3df60ada09e5c83d03aebe9c535
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166865
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Regression from commit c804c5354855188b5a37219cfe11dc079dc235f4 (sw
content control: fix lost properties on copy&paste, 2023-03-10), select
a plain text content control, copy it to the clipboard, quit: assertion
fails during shutdown because the doc's "placeholder text" char style is
still referenced by a client.
What happens here is that the SwContentControl copy ctor copies the
plain text flag, and that flag is only read in SwTextNode::InsertHint(),
so that causes the problem. Note how that code is inconsistent: we avoid
the creation of dummy characters in the copy case, but we still try to
adjust the start/end of the content control attribute in the copy case,
which makes not much sense.
Fix the problem by not adjusting the content control attribute
boundaries in the copy case, since the original intention was to do
thees corrections only at a UI level, during interactive edit.
It's not clear why this inconsistency had an influence on the clients of
the char style, though.
Change-Id: I86b0516464f24fc453dcd97588dafb8afd010a9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166882
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
In case this flag is active (intended for DOCX files), then don't
automatically mirror the position of drawing objects, just because they
are anchored in an RTL text node.
Change-Id: Ie743d94ecb511d7de89e8e1e8303896370ce58c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166883
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I9d212348edfa1897ad139fbb9f633fbd5a09566d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166808
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
where it was obsoleted by commits 2484de6728bd11bb7949003d112f1ece2223c7a1
(Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and
fb3c04bd1930eedacd406874e1a285d62bbf27d9 (Drop non-const Sequence::operator[]
in internal code 2021-11-05).
Change-Id: I4ccc647bb794515c8c11f8dfd9a26563f4aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166819
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I994b276ad39b09547cb1dbd3710daf519c5f5c66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166864
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
The DOCX bugdoc has a circle shape anchored inside an RTL paragraph:
this shows up on the right hand side in Word, but on the left hand side
in Writer.
What happens is that Writer implicitly mirrors draw objects anchored in
RTL paragraphs, while Word doesn't do this.
Start fixing the problem by adding a new layout compatibility flag that
can be used by the DOCX import in the future, to leave the behavior
unchanged for new & existing ODT documents.
An alternative would be to do something similar to the DOC import's
SwWW8ImplReader::MiserableRTLGraphicsHack(), but 1) we don't have the
page margins by the time we import the shape and 2) as its name says, it
doesn't feel like a clean solution, it's better to handle this
difference at a layout level.
Change-Id: I2ec067d86c7fbdbe57e4cd9547015fe25a9a56b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166820
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Introduced by 495b5db74f0db59395ff68bacc8d8ca67595b66e
"sw: check GetUserCall"
https://ci.libreoffice.org/job/lo_ubsan/3154/consoleFull#-1571115798d893063f-7f3d-4b7e-b56f-4e0f225817cd
Change-Id: Ifc80312890f2e6b82dcc9419b5b7e8bfcd5340a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166824
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I84a4c82176681eb55e90240a2db7001123605c1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166807
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...presumably since 6a11bf9f7bd209a082254c861d5a04c7f5729d68 "use more concrete
UNO classes in writerfilter (SwXBookmark)", failing sw_writerfilter_misc with
> DynamicLibraryManagerException: "Failed to load dynamic library: workdir/LinkTarget/CppunitTest/libtest_sw_writerfilter_misc.so
> instdir/program/libsw_writerfilterlo.so: undefined symbol: _ZTI11SwXBookmark"
Change-Id: I9f839ca0f6986723cd2c4add5eaef3ac8ab8d841
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166821
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
It was not possible to select and edit the content of the bottom
cell, if an image cropped by the fixed row height "covered" it,
i.e. the image was in the previous row, anchored as character.
Note: table cells with fixed row height are usable to crop images
easily, with a single drag & drop, according to the requirement of
the text layout, while the cell above or bottom of the cell with
image is for the caption of the image. This is very useful to
adjust a book layout with sections with multiple columns and
illustrations.
Change-Id: I8683b4066db6ce43549ec3aa69b0e639a59e3681
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166794
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I12b41369ee65f46e08494acda0435f767e28f290
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166804
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic00730c49c0feb7ab7e649c7d6e5d3ff1cb79b27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166801
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I39e2c1d7d3c49017795d1365895ef8bd8d1e0e87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166800
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I407d165ccdfcb23e2b922701dc9753c72c439cc4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166788
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I44eb8d4561798980ff7008d843bf076fc29582c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166769
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It might return nullptr
See https://crashreport.libreoffice.org/stats/signature/SwFEShell::ShouldObjectBeSelected(Point%20const%20&)
Change-Id: Ia0ed355a7eb9084b9f57163ffbfe6b549c8bdb3f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166642
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I17703c2fe388f485462bd82982664f0b4a14d537
Signed-off-by: Mohit Marathe <mohitmarathe@proton.me>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166040
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Use a Sequence of XAccessible rather than its base
interface XInterface for AccessibleRelation's TargetSet.
As the targets are accessible objects as well,
anything other than XAccessible doesn't make much sense.
Using XAccessible right away makes that clearer and avoids
the need to query the XAccessible interface.
(The winaccessibility bridge was already using
`static_cast`, relying on the fact that the objects
are XAccessibles.)
The a11y UNO API is not published, so an API change
should be unproblematic.
Change-Id: I7f08e98d1ec303d5343d9a7954187cdd71495ebc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166586
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
Commits 8f48f91009caa86d896f247059874242ed18bf39 (ODT export: omit
unreferenced <text:list xml:id="...">, 2022-03-10) and
82bbf63582bdf28e7918e58ebf6657a9144bc9f3 (tdf#155823: Improve the
check if the list id is not required, 2023-06-14) tried to improve
deterministic ODF output, by omitting the list identifiers in case
when those identifiers were unreferenced. The latter of these used
document model node numbers to check if other lists appeared after
the last occurrence of the list that is continuing in the current
node. But it turned out, that this isn't robust. Consider this ODF:
<text:list xml:id="list1" text:style-name="L1">
<text:list-item>
<text:p>a</text:p>
</text:list-item>
</text:list>
<text:p>b<text:note text:id="ftn1" text:note-class="endnote"><text:note-citation>i</text:note-citation><text:note-body>
<text:list text:style-name="L2">
<text:list-item>
<text:p>x</text:p>
</text:list-item>
</text:list></text:note-body></text:note></text:p>
<text:list text:continue-list="list1" text:style-name="L1">
<text:list-item>
<text:p>c</text:p>
</text:list-item>
</text:list>
The paragraphs a, b, and c are all in the main document body, and
have sequential document model node numbers (say, 15, 16, 17). If
these numbers are checked, there is no node between node 15 ("a")
and node 17 ("c") with a different list (both 15 and 17 belong to
a list with style "L1" and identifier "list1", and node 16 doesn't
belong to any lists). That suggests that the list identifier isn't
needed in this case. Bug when the actual output of node 16 is done,
it includes a node from an endnote ("x"), which is located in a
different place in the document model, and has a node number like
7 (so not between 15 and 17). The paragraph "x" belongs to another
list with style "L2", and is output to ODF between paragraphs "a"
and "c". Here, we must refer from paragraph "c" to the list of the
paragraph "a" using the list id, but this is not obvious when only
considering node numbers, and requires the prior knowledge of the
actual order of appearance of lists in the ODF.
Unless we build a DOM, this is only possible, if we do a two-pass
output, and collect the nodes order in the first pass. The output
already does that in a "collect autostyles" pass. The problem here
is that the "collect autostyles" pass used an optimized function,
XMLTextParagraphExport::collectTextAutoStylesOptimized, introduced
in commit 8195d7061ed52ebb98f46d35fe5929762c71e4b3 (INTEGRATION:
CWS swautomatic01 (1.126.4); FILE MERGED, 2006-12-01) for #i65476#
and which used style::XAutoStylesSupplier for optimization to get
the autostyles.
This drops XMLTextParagraphExport::collectTextAutoStylesOptimized,
and reverts to use of collectTextAutoStyles, which handles nodes
in the same order as when writing to ODF. There, we build a vector
of the node numbers sequence, used later to sort DocumentListNodes.
This uncovered an omission from the work on paragraph mark (commit
1a88efa8e02a6d765dab13c7110443bb9e6acecf tdf#155238: Reimplement
how ListAutoFormat is stored to ODF, 2023-05-11). Turns out, that
the code in SwTextFormatter::NewNumberPortion introduced in commit
cb0e1b52d68aa6d5b505f91cb4ce577f7f3b2a8f (sw, numbering portion
format: consider full-para char formats as well, 2022-10-20) was
left behind when re-implementing paragraph marks to use dedicated
property; empty trailing spans still affected how the lists were
rendered, and that allowed to overlook import defects, where the
paragraph mark properties weren't properly set.
In ODF import (XMLParaContext::endFastElement), for compatibility,
this treats empty trailing spans as defining paragraph mark (when
the paragraph mark wasn't set explicitly). This way, the trailing
spans get converted to the paragraph mark.
In WW8 import, last cell paragraphs didn't call the code handling
the paragraph marks. This is also fixed now.
The changes result in slightly different numbering of autostyles
in the ODF. It seems, that the new numbering more closely follows
the order of appearance of the autostyles in the output; and some
cases of autostyles that were written, but unreferenced, are now
eliminated. The unit tests were updated accordingly.
I hope that the performance impact on the export time would not be
too large.
It is unclear why outline numbering exports a list element at all.
Fixing that to not emit the list element is a separate task / TODO.
Change-Id: I5c99f8d48be77c4454ffac6ffa9f5babfe0d4909
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166572
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Have an empty Writer document, set preferences so images created via
drag&drop are anchored as-char, drop 2 images from a file manager,
crash.
The root of the problem is that the first image gets dropped fine, but
the second one would be anchored to the currently selected graphic node,
since commit 651527b4efe9700c8c8dff58ce5aa86ad5681f16 (sw: fix
double-click opening frame dialog, not graphic dialog on images,
2022-04-26).
The new SwTextCursor::GetModelPositionForViewPoint() returning a graphic
node for a point inside the image looks correct, so fix the problem by
extending SwFEShell::Insert() to take the anchor position as the anchor
for the new image, in case a graphic node is selected.
The original use-case would use SwEditWin::ExecuteDrop(), but keep the
test simple and invoke the underlying SwFEShell::Insert() instead, that
also triggers the problem.
Change-Id: Ibba57aa28d0616ded16b4abb314f04974f1b8f9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166499
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
wayland
I think the lines of code removed by this patch were meant to allow
recency to remember the cursor position before being moved to a start/
end/previous/next word or sentence position by an UNO dispatch command. These are already taken care of in the slot execute function void
SwTextShell::ExecMoveLingu.
Change-Id: I8bf231ea4cbb03125f54332a41c5544f9094b768
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166350
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
|
|
Field Shading / .uno:Marks toggles now only fields, footnotes, tox etc.
and Tab, SoftHyphen, Blank, as well as ControlChar depends now on
Formatting Marks / .uno:ControlCodes. Field Shading also does not
toggle HardBlank and SoftHyphen, and what control character is shown
respect the options under Formatting Aids
Change-Id: I63c826e7fdc09ec95f17aee9735d4f5de9a1b897
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166033
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Change-Id: Ibb4d4d1cca59ece6bcd28e887f84d657dedee756
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166314
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia1379762ba957097a1a2134c5d206f254e22683b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166313
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Idf7d3abd464b7be87d109d14adf94357a5d49dd5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166312
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia3e1b50954354973ffef701821f661cf782687db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166311
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I was concerned that I might override highlights
set in numbering.xml but in that case
pFormat && pFormat->hasItem(RES_CHRATR_HIGHLIGHT)
so pCleanSet no longer hasItem.
(see num3n.docx and TestDoc_highlight2.docx)
Note: must use Word 2010+ to see numbering.xml highlights!!
This is strictly a visual thing. Unit testing has traditionally
used magic tile rendering x,y positions to check the color,
which seems completely untrustworthy.
Change-Id: I026252f127107e4782d08f72bfd5e2a412142111
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166303
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
Unfortunately the actual computed margins are not stored in text
formatting data structures so are only available directly from
SwTextMargin.
Change-Id: Ia7ce5e148194a55b5d9874ed112aaa977ed16c7b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166258
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
There is a special handling of CrossRefBookmark, which has no end position
in the document model, but must span the whole paragraph, and end position
is generated explicitly.
Since commit 1d7ce421480d9170316533de03feb8d04eb5c767 (tdf#159438: when
there's no frame, close previous bookmark first, 2024-01-30), end marks
of an index are sorted before start marks of the same index, with the
expectation that start / end marks represent non-empty span. Dun in case
of empty paragraphs with a CrossRefBookmark, both start and end mark were
emitted into the same index, and the new sorting resulted in the wrong
order of the elements.
Fix this by checking if the start index is less than node end, and don't
handle CrossRefBookmark specially, if the check is negative. This writes
a single text:bookmark, instead of a text:bookmark-start, followed by a
text:bookmark-end.
Change-Id: I533c4f7814edddc3cf24b1213490f251d60b2273
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166266
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I7447e649dc3ef4e51242f69c7486a3e84e103d2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166159
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I4fb7b4b113e60dc3cc4aabd49e4dd23dbeeb74f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166112
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I63eeb8662ee28f1a0e990160b1ff9992d9d9337f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166111
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
And use it when assigning to tools::Long
Change-Id: I0814d7bac9cdd48191ba69c64e3b12a4973b3417
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166071
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I3a58469c52055121e8726cee2d3e42ecd23cdf96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165826
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Not sure why but somehow still crashes in the code added in commit
ab7893544dc6be6dc192dffefd57cd5ddd421c35
https://crashreport.libreoffice.org/stats/crash_details/912e7417-5e04-4279-bbaf-380234f4cd33
Change-Id: I23b7ecdd83009cfe6584866ed72102d8f2179f86
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166010
Tested-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Support XSL attribute "column" and CSS 4 attribute "spread",
stored in loext:hyphenation-keep-type, to give better control
over hyphenation-keep. E.g. spread: both parts of a hyphenated
word shall lie within a single spread, i.e. when the next page
is not visible at the same time (e.g. the next page is not a
right page of a book).
– css::style::ParaHyphenationKeep is a boolean property now,
importing hyphenation-keep = "page" as true.
– type of ParaHyphenationKeep, including the new non-ODF types
is stored in the new ParagraphProperties::ParaHyphenationKeepType.
– default value of ParaHyphenationKeepType is COLUMN for
interoperability.
– Add checkboxes to Text Flow -> Hyphenation Across in
paragraph dialog:
* Column (previously: Hyphenate across column and page)
* Page
* Spread
– enabling/disabling them follows XSL/CSS 4/loext, i.e.
possible combinations:
* No Hyphenation across
(hyphenation-keep = "page" and loext:hyphenation-keep-type = "column")
* Hyphenation across [x] Column
(hyphenation-keep = "page" and loext:hyphenation-keep-type = "page")
* Hyphenation across [x] Column [x] Page
(hyphenation-keep = "page" and loext:hyphenation-keep-type = "spread")
* Hyphenation across [x] Column [x] Page [x] Spread
(hyphenation-keep = "auto")
– Add ODF import/export
– Update DOCX import
– Add ODF unit tests
Note: recent implementation depends on widow settings: disabling widow
handling allows hyphenation across columns and pages not only in table
cells.
Note: RTF import-only, but not used bPageEnd has been renamed to bKeep.
Depending on the RTF test results, likely it will need to disable
the layout change, e.g. GetKeepType()=ParagraphHyphenationKeepType::AUTO,
if PageEnd uses obsolete hyphenation rule, i.e. shifting only the
hyphenated word to the next page, not the full line.
More information:
– COLUMN (standard XSL value, defined in
https://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#hyphenation-keep)
– SPREAD and ALWAYS (CSS 4 values of hyphenate-limit-last,
equivalent of hyphenation-keep, defined in
https://www.w3.org/TR/css-text-4/#hyphenate-line-limits).
Follow-up to commit 9574a62add8e4901405e12117e75c86c2d2c2f21
"tdf#132599 cui offapi sw xmloff: implement hyphenate-keep" and
commit c8ee0e8f581b8a6e41b1a6b8aa4d40b442c1d463
"tdf160518 DOCX: import hyphenation-keep to fix layout".
Change-Id: I3ac6d9e86d0ed1646f105de8607c0e8ebc534eaa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165954
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
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>
|
|
...ever since the code got introduced in
9dc6e2c9062725ef1f9d7e321cae5f4dbe8ca749 "sw: fix expansion of SetGetExpField in
headers with split table rows"
Change-Id: I44e8d375a47286b625ce9a7808484a32dc1f0aa6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165879
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@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
|
|
A single large object in a paragraph must be moved down, when the page
has other content before this. On the other hand, there must not be
moving down, when an unsuccessful attempt to move was already done (so
the master frame is empty), or even the first time, when the frame is
at the page body start.
Change-Id: Ib8e2fe7b77c622d9cfac22722ca6b55dba7ad8ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165869
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ie88dbf29bd03b890a75fb4a1059083bbd939f56e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165837
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I4bfe875d0484bf77472301f9dea3fc4c6dacdbf4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165852
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The bugdoc has a very large header containing hidden text changes height
when toggling Formatting Marks. When toggling on, it crashes, because
UnHide() iterates the text frames in all headers, but after the first
one empty pages at the end of the document are removed, so UAF.
Remove the pages without content earlier; SwLayAction::InternalAction()
already does it after the "normal" page loop, but the 2nd page loop
following that may also move content off pages, so do it again.
Change-Id: Iaae6a16842b3494f25cba8fc036d15049b71961f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165801
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Which means we get boxes (cells) grouped by lines (rows), instead of a
flat list of all cells in a table.
Change-Id: Ibb14c6fb26b2f4b502b18544d9a08d964c45a97e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165806
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I19f466a272c821185bea4b45efd34392e525c0d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165785
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This makes the behavior of the endnotes in the end of sections consistent
with the behavior of dedicated endnote pages, where heading fields ignore
headings in endnote content.
Change-Id: Iad0218b75a678808b1266024fe4c81f040a631c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165789
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Fix the problem similar to what commit
1d9221ebc86f2696a65c12287ea19eea44d680cf (tdf#124601 sw: fix misplaced
images in table cells, 2022-11-30) did: use a font that we ship to avoid
font fallback.
Change-Id: I59be457e018c96f7edda80fb5d3787593d75b010
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165784
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0ae90e10fad2d6e41d855ead69b8cdcf8d53f525
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165719
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
