It's annoyingly difficult to remove the links from the broadcaster,
drop that approach and do it a more direct and less reentrant way.
Get ~SwFormat and SwContentNode::ImplDestroy to report the death to the
tracker instead.
A flag on SwDoc keeps the common no-links case in those destructors to a
single test.
During ~SwDoc the hosts stay silent: the links administration manager
can already be unreachable through the half-destroyed document, and
~FillBitmapLinkTracker releases whatever is left without touching the
dead hosts.
SwContentNode::ImplDestroy skips disconnected nodes, the stack-built
working copies like SwTextNode::Update's SwContentNodeTmp that have no
nodes-array and no SwDoc. A node deleted for real still reaches its
SwDoc, since SwNodes::RemoveNode deletes nodes while they are still in
the array.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: Ibbf15e4e17a7a08aa029c9d5df8f40b7a4a13e04
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4282
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 38ac5c0e6c7baf4de27498e5428d6279c753c97e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208603
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
When a document had several frames each containing a match, using Find
Previous only ever selected the match in the last frame; earlier frames
were skipped ("Find Next" and "Find All" were fine).
Backward text search walks the node array through SwNodes::GoPrevSection.
Since 691cfd22c6 ("tdf#159565: make sure to
handle leading hidden section correctly", 2024-02-14) that function stops
at the start of the current global section (here, a fly's start node), so
once the search stepped into a frame it could not move back into an
earlier one and got stuck in the last frame reached. GoPrevious got an
opt-in canCrossBoundary flag back then, but GoPrevSection did not.
Give GoPrevSection the same canCrossBoundary flag (default false, so plain
backward moves keep respecting section boundaries), and let the search
iterator in GetNode() opt in: it walks a range that is already bounded by
the PaM's mark, so crossing fly / header / footer / footnote boundaries
within that range is both wanted and safe. This also restores backward
Find across multiple headers, footers and footnotes. Forward search uses
GoNextSection, which was never limited - which is why Find Next and Find
All kept working.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I0c0971013d2fab19dac1de1e252586d7ea554c2b
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7060
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 051e00083683db002942b94d0323c5d8fd13e6d4)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208242
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
since we only use one break-iterator these days,
expose a additional C++ interface to that, as well as the existing UNO interface,
and add a method which allows us to avoid allocating an OUString when calling endOfScript().
Shaves off 20% of the temporary allocations.
Change-Id: I7092affc1820555353e8bf6498e11c9eff42cfad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198276
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Once a non-standard redline render mode is set, either the inserts or
the deletes are "omitted" (painted in a semi-transparent way), but
nothing happens with images.
The standard redline render mode already had a way to cross out deleted
images, which gives us a starting point.
So use that info to render deleted flys in grayscale, and do the same
for inserted images, depending on if "omit of inserts" or "omit of
deletes" was requested.
The test simply asserts if the pixel at the center is gray-ish, which
detects the unwanted colors. The alternative would be to go via
BitmapEx::ModifyBitmapEx() and basegfx::BColorModifier_gray, but then
the bitmap checksum didn't match for me, even if the result was visually
the ~same. (I.e. the idea could have been to see if a 2nd "gray" filter
has any effect: if no changes, then the input was grayscale.)
Change-Id: I3484b3b122d42006b44617b6df5bc9a5631b9266
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197674
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Add a new UNKNOWN constant instead of using USHRT_MAX.
Not sure about the naming of the ZERO constant. Maybe
it should be DEFAULT.
Change-Id: Ia1d0c0e0036c3dbd52cb4cdd935d0c736dcea5fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197455
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Found after running bin/find-unneeded-includes --headersfwd include/vcl/[d-g]*
This shaves off about 150M input
Change-Id: I2b15257451d4b392dca3e5d07f4a443ee653b04c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196395
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
utl::MediaDescriptor was just a SequenceAsHashMap with a few added
methods. It made it more difficult to assign a SequenceAsHashMap to
MediaDescriptor, without real upsides. In many places, the class was
used not as media descriptor, but just as helper to create sequences.
This change puts the string constants and the former methods into a
namespace utl::MediaDescriptor.
It would be also good to drop comphelper::NamedValueCollection, which
is basically a twin of comphelper::SequenceAsHashMap (TODO).
Change-Id: Ia9b69c5a2ad153ecc654944c419c1880252ed86e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195163
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
A table is allowed to specify a page break.
If a table-in-table is the first thing in cell A1,
then (only) that table-in-table is checked for the page breaks,
so transfer page breaks when inserting a table-in-table.
make CppunitTest_sw_htmlimport CPPUNIT_TEST_NAME=testTdf155011
Change-Id: Iae6d54aa2c7c33e07cdd235ff347a9d0fde3dc65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191050
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
The problem is that the Table Split feature on a floating table results
in 2 tables inside 1 frame, which then cannot be exported to DOCX as a
floating table.
Split the fly frame in this case, and add an anchor node because every
floating table needs its own anchor node.
Change-Id: I7444a75a953fcea60ffc92c2fa7eaca1b044f54b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190009
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 6f55b9a74f8fdd8609e1aa72388a5f8b97dfcea0)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190075
Tested-by: Jenkins
It may attempt to open the passed document, and then it would create
an SfxMedium, that will define how to interact e.g. on errors. When
caller has an interaction handler, it should pass it.
Change-Id: Icd0881ecf31b1e1a4731e1776413c1f62803c256
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190173
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Open the bugdoc, the DOCX file has an insert with a format on top of the
middle, but the format is lost in Writer.
The first problem is that we tried to create an insert on top of format
(while in DOCX the format is always inside the insert/delete), fix that
by changing the order of redline creation in
DomainMapper_Impl::CheckRedline(). The original motivation is no longer
relevant after commit b3567d7e1f
(tdf#165322 sw: apply formatting for multiple redlines in SwRedlineItr,
2025-02-25) Writer core to handle the rendering of format on top of
insert/delete.
The other problem is that in case we try to append a format redline on
top of insert ("AB" is an insert and the format would affect "B"), then
we simply deleted the (candidate) format redline -- change this to
handle this similar to delete on top of insert.
CppunitTest_sw_ooxmlexport8's testN830205 would now create an unsorted
redline table on file open, so make sure SwDoc::TextToTable() resorts
the table after splitting the redlines.
Change-Id: Iada13204892ffccfe09bc2c28bf0c563db6e1ab9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184752
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
by wrapping up OUStrings inside some type-safe wrappers
to make it obvious in the code what kind of name we
are dealing with.
The new classes are in sw/inc/names.hxx
Note that I spun the names for table formats out into
their own name class TableStyleName, becuase they
are weird. Most of the time they are UINames, but
not always.
Change-Id: Iaf320639fd1aae8ba0f99866ff206906544c42be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178839
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Go to the end of the 3rd paragraph of the bugdoc, press Enter, list
level of both the old and new paragraphs change from 5 to 4,
unexpectedly.
It seems what happens is that the paragraph in question has a style
which has its outline level set to 4. So once the node is split, the
newly inserted node will host the old text (so need to set the style on
it to the old style, which sets list level to the outline level from the
style as a side effect) and the old node will host what looks like a new
bullet point on the UI, so there we need to set the paragraph style to
the follow style. This second set-style also drops the list level direct
formatting and takes the outline level from the style.
Fix the problem by keeping the old scenario (paragraph style with a
different follow style) unchanged, since a different list level on an
actual paragraph style change can be expected -- but avoid setting a
list level when this is a simple node split with just the same style on
both nodes. That's not seen as an explicit "set style" by the user, so
changing the list level there is confusing.
In fact the list level is fine after copying the text node's item set
from the old node to the new node, just make sure that
SwTextNode::ChgTextCollUpdateNum() doesn't set a new list level in the
"effectively no style change" case. Make sure to not set a new list
level at both places (SwTextNode::MakeNewTextNode() does this for the
previous node, SwTextNode::ChgFormatColl() does this for the next node).
Change-Id: Ifdf9048f01fef7bb8e99098ebeb5d1ec339fdaa6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182869
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This is a follow-up to commit 2bcfb7231b
"tdf#152872 sw: conditionally hide paragraph breaks".
Word determines the paragraph properties differently depending on
whether paragraphs are merged by hidden text (where the first paragraph
containing non-hidden text wins) or delete redlines (where the last
paragraph wins).
This fixes the hidden text situation while leaving the delete redline
situation as it is.
The problem is that CheckParaRedlineMerge() only considers hidden text
on the paragraph end marker (RES_PARATR_LIST_AUTOFMT) but not elsewhere
in the paragraph, so there are extents for the hidden text.
The actual hiding of that is done via ScriptInfo::m_HiddenChg, which
cannot be removed and replaced by merging because it is required for
Writer's notion of hidden paragraphs in SwTextFrame::IsHiddenNowImpl().
* FindParaPropsNodeIgnoreHidden() skips over nodes that contain only
hidden text in case hidden text isn't shown
* factor out ScriptInfo::InitScriptInfoHidden() because it is now needed
to find the pParaPropsNode, but the rest of InitScriptInfo() requires
the pParaPropsNode...
* testTdf152872 requires changes as it was relying on ControlCharacters
alone toggling the merging
list of commits that tweaked setting pParaPropsNode:
58353884dc (related: tdf#130685) sw: adapt definition of sw_redlinehide index 0
b86ff2c6a8 tdf#118699 sw_redlinehide: need some more changes to use the last node
fa5eb82b39 tdf#118699 change tracking: don't number empty lines
beec159458 tdf#125319 sw_redlinehide: handle empty paragraphs more like Word
c20308f1b9 sw_redlinehide_4b: surprising discoveries
Change-Id: If0e49a4d105dbf7d71e753967f36f2ec56f21f1d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181918
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
The problem is that the table node only gets a SwFrameFormat assigned at
the end of the operation after all the nodes have been split etc., and
moving a field into a newly split node calls
sw::FindNeighbourFrameForNode() which needs to handle table node without
SwFrameFormat now when going backwards (not when going forwards because
the table node is always before the nodes in the table).
(regression from commit 9dc6e2c906)
Change-Id: Ia0c1f7d7b14f525aa8de4a2b6492c39b59f31052
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180914
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
Add file name only to the objects anchored at page, not
to all of them.
Follow-up to commit 2f135fa82c
"tdf#121119 master docs at-page anchor: fix missing images",
commit fb4197ed81
"tdf#121119 master docs at-page anchor: fix duplicated images"
and commit 47d596688f
"tdf#121119 master docs at-page anchor: fix runtime duplicated images".
Change-Id: If851818731e87225d53370978a92c02cfb5d7189
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180678
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Skip saving images anchored at page in the master document,
if they are imported from subdocuments to avoid their duplication
during the round-trip/update of the linked subdocuments.
Follow-up to commit 2f135fa82c
"tdf#121119 master docs at-page anchor: fix missing images".
Change-Id: I731026bee01576fe66c9d677b53c7f85a53230fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180627
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Images and other objects anchored at pages weren't imported
from the subdocuments, resulting broken master document.
Subdocuments are imported as sections of the master document,
but their objects anchored at page need a document-level copy,
not a section one. To calculate the new document-level page
number of the copied object, store and sum the page count
meta data of the previous subdocuments, added to the subdocument-
level page number of the object.
Note: the recent solution doesn't calculate with the own text
content of the master document yet. As a workaround, to get
the original page number exactly, store everything in subdocuments
before the objects anchored at page.
The problem is inherited from OpenOffice.org, see ooo#19131.
Change-Id: I0be80bb27442565764142d2b23b0f56a3421c035
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180626
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Caolán McNamara