Add a few bulleted lines to a text frame in an Impress document, copy
them, paste in Writer: the paragraphs are imported with no bullet marks.
ImpEditEngine::WriteRTF() emits a bare \level<n> for the paragraph's
outline level, which editeng's own RTF importer reads back as a
bulleted item, but sw's RTF import ignores. The PowerPoint RTF clipboard
markup for the same thing is the RTF 1.0 old-style numbering pair: a
{\pntext <bullet>\tab} fallback and a {\*\pn\pnlvlblt{\pntxtb <bullet>}}
destination that contains the bullet character.
Fix the problem by emitting that pair alongside \level<n>, from the
paragraph loop in WriteRTF(), when the paragraph's EE_PARA_NUMBULLET
at that outline level is of type SVX_NUM_CHAR_SPECIAL.
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I18a022ac28d50a8b7557ee2282cd3fd8e7c37299
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/14439
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit b7002f07f475ce4eb5cf7309dfe8e59ba21ecd7a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211942
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Patches:
- external/pdfium/extractpatterns-fill.patch.1 is now upstream
- external/pdfium/extractpatterns-stroke.patch.1 as well
- external/pdfium/fix-windows-build.patch.1 as well
- external/pdfium/system-icu.patch.1 as well
- external/pdfium/system-dragonbox.diff is a new dependency, patch the
code to use our bundled dragonbox
- update external/pdfium/system-abseil.diff to apply again
Adapted tests:
- CppunitTest_vcl_pdfexport goes back to its previous expected values
after pdfium.git commit 17cf94b52e01507108da6460ebca6b48995a698e
(Revert "Fix mixed-direction line extraction", 2026-09-17)
- CppunitTest_vcl_pdfexport2 as well
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I09bf5fc9f54b697eed2e144c3f57c3b72f3bbc37
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13508
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 0272de3a9b98d0c3ef4479e0dc12abe8cc040447)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211551
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Have a document with hidden text (an OOXML w:vanish, say), open it in
Writer, save it as HTML and open the HTML again. Writer's HTML export
writes the hidden flag as a span with the CSS declaration
"display: none", but the round-trip loses that hidden state and the
run comes back visible.
sw's CSS parser has no rule for the CSS "display" property, so "display:
none" is ignored on import.
Fix the problem by adding ParseCSS1_display() that puts a
SvxCharHiddenItem into the CSS item set when it sees "display: none".
With this, hidden text round-trips through Writer's HTML: an OOXML
w:vanish run comes back as hidden after HTML export/import too.
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I6add0f9859b6edffbe783a0d0a5b8f39361d3ffe
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12991
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit eb9ca728e179aab3f51be4d96b02a03e502a1f87)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211507
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
- fix build against our bundled ICU
- update external/pdfium/extractpatterns.patch to work after the
upstream commit fc790866bf26d977b2ea3a0c3938bb52895309ea (Consolidate
CFX_RenderDevice and remove CPDF_WindowsRenderDevice, 2026-06-29), which
folded CFX_DefaultRenderDevice into CFX_RenderDevice.
- update CppunitTest_vcl_pdfexport2: mostly likely needed after the
upstream commit 2f7a54a926a1b8e51aff9ac2aca5cccb29920aae (Partially
fix RTL character and line reading order in CPDF_TextPage, 2026-07-24)
- CppunitTest_vcl_pdfexport: same
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I25612e6696a24588b9bf045e666047e6c2955d7c
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8557
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit a7149002917e82ef07250d2e964537118294993a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210417
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Open the bugdoc, navigate to the end of the last bulleted paragraph,
paste the 2 bullets from markdown, the 2nd bullet of the pasted content
has the text, but not the bullet.
What happens is that the markdown parser inserts a last empty paragraph
to the model, that needs merging to avoid the empty paragraph and there
we JoinPrev() keeps the formatting of the empty paragraph, not the
format of the previous one, that still has content.
Fix the problem by instead joining the last-but-one paragraph with the
next one via JoinNext(), which keeps the bullet and loses the empty
paragraph properties at the end of the pasted comment, including the
unwanted RES_PARATR_LIST_ISCOUNTED that caused the lack of bullet.
Found while testing commit ccd06e3822f4a828be7467bf7e338b717d6facda
(cool#16002 sw markdown paste: avoid unwanted empty paragraph at the
end, 2026-07-14).
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I94346e591942cd69fb2482a24c5b9b4a6ce62be4
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7557
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 2d61ca1da95db96384b9a5185990fbe0ed243281)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208525
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Open the bugdoc, navigate to the end of the first bulleted paragraph,
paste the 2 bullets from markdown, there is an empty bullet between the
end of the pasted content and the start of the content after the paste
position.
What happens is that paste finishes with an empty text node at the end
of the document, which is handy in general, in case there is content
after the bullets for the normal import case.
Fix the problem by checking for this "empty paragraph before the insert
position" situation in MarkdownReader::Read(), and by joining the
problematic empty text node with the previous node in the paste case.
This is the opposite of the problem in commit
f6f13d042b1e176ba1cb13cea37d5e5c2add9a9f (cool#16002 sw markdown import:
avoid unwanted list join at start, 2026-07-13), where two paragraphs
were joined together and that wasn't wanted.
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I711f1eb520854081e579f77dc98606592672720a
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6786
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit ccd06e3822f4a828be7467bf7e338b717d6facda)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208343
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Open the bugdoc, navigate to the end of a bulleted paragraph, paste the
2 bullets from markdown, the last para text before the paste position
and the first para text from the pasted content are in the same
paragraph, even if they are expected to be two separate bullet points.
What happens is that paste inserts an empty paragraph at the paste
position, then pastes the content, finally it cleans up the previously
added two paragraph breaks. This works when you just paste a couple of
words and you're in the middle of a paragraph, but makes no sense when
you try to paste bullet points into an existing list.
Fix the problem by tracking if the paste position is at paragraph end
and if both the paste position and the start of pasted content are
list paragraphs. If so, keep the paragraph break the start of the pasted
content.
This paragraph splits/joins before/after paste were introduced in commit
e1a599aa5082a528b36ba2d4711111c4cd39eb7a (cool#15535 sw markdown import:
handle pasting into an existing paragraph, 2026-04-17).
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I6c356f2311d7c4df02611d94c9c0c11fbbf858e7
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6580
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit f6f13d042b1e176ba1cb13cea37d5e5c2add9a9f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208342
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
...redlines when hiding changes
The bugdoc had a format redline, but redlines were hidden, so it looked
like normal text. Then the user selected a word, pressed delete and
seemingly nothing happened, which is unexpected.
What happened is that pressing delete for a selected format redline
creates a delete-then-format redline and our layout code only looked at
the "format" on top, not hiding the text when redlines (deletions) were
asked to be hidden.
Fix the problem by moving GetRedlineTypeIgnoringAdditonalFormat() into
SwRangeRedline and then using it in HideIterator::Next(), to hide not
only deletions but also delete-then-formats when hiding redlines.
This is a problem similar to what commit
1a34019623 (tdf#166319 sw interdependent
redlines: handle ODF export of delete under format, 2025-05-20) fixed,
but there the problem was updating the model to match the layout when
hiding redlines at a model level; and here the problem was to have the
layout from the model in a correct way.
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I753d0b9fc8af9d6330f8d0fa719babd7b25ee8f6
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4808
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 2c5c0e0fca4c510fc436ce9c8850983d953408f7)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207753
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Upstream now has a theoretical build config where the rendering is
handled via skia and not agg; use -DPDF_USE_AGG to keep things
unchanged.
Also it now depends on harfbuzz, use our harfbuzz instead of the bundled
one.
This reverts the:
- vcl/qa/cppunit/VectorGraphicSearchTest.cxx
- vcl/qa/cppunit/PDFiumLibraryTest.cxx
- sw/qa/extras/uiwriter/uiwriter11.cxx
- sc/qa/extras/scpdfexport.cxx
- sd/qa/unit/export-tests.cxx
parts of commit 4731284939ce286316738d1fced7f16e9b91028b (pdfium: update
to 7691, 2026-02-19), since they are not necessary, probably after
pdfium.git commit 4a298961558e1e54fde965d133d61f90df2431bc (Revert
"Reland "Remove character width check from cpdf_textpage.cpp"",
2026-03-10).
Change-Id: I9c62dc5251aa91a1178c32ca9e5f440269b6071f
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/1131
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1173
Reviewed-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit 06d0ffcd63f1cb3133a7920e116bd5a88f6cc714)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207006
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Paste from dark mode Jitsi chat to Writer, the result is not readlable
white characters on white background.
What seems to happen is that the <span> has CSS, first 'color:', that is
imported, then '-webkit-text-stroke-width:', that stops parsing, so the
'background-color:' that comes after it is ignored.
Fix the problem by improving CSS1Parser::ParseStyleOption(): if m_nToken
is not the expected CSS1_IDENT (but something else, here it's a
CSS1_MINUS), then just keep parsing till we reach a CSS1_SEMICOLON and
continue parsing the next token after that.
In general, this should help with parsing any previously lost CSS
properties that were after a vendor-specific CSS property.
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I2e801cc1f6e587c26b87d64e2817798aeacff9c9
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4093
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 1de889d09cabb7c875a56b0790ff09290390f149)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206295
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Have a text document, select a word, dispatch the postmessage API's
'Action_InsertLink' message with a '{"url": "http://www.example.com",
"text": "mytext"}' value, the selected word is replaced by 'mytext'.
As described in commit 1e91e03bb69ce162323f7b42dd4b25536963e396 (wopi:
Action_InsertLink: accept optional "text" label from the host,
2026-04-22), the idea is that the "text" key is only used as a hint,
when the cursor has no selection.
Implement this first in Writer: if there is a selection, then set the
hyperlink on that selection, else try to use the "text" key, finally go
with the URL. Do this via an opt-in flag, so the hyperlink dialog
behavior is unchanged.
An alternative approach would be to try to have the current text
selection in the browser all the time as
<https://gerrit.collaboraoffice.com/c/online/+/1447> would do it, but
that would require storing the currently selected text in the browser
again, and not doing that was an improvement in commit
75251f9496f44f8678e43c1525719e5e4cc3b6ee (cool#8648 clipboard: try to
use navigator.clipboard.write(), 2024-04-04). It would also not preserve
the formatting of the text selection.
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: Ib7473ec2b301c913af767c2f9e655b08d07a70bd
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3609
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 277ebe4cdc9ce386e9baedc687f67498b8c60cba)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206210
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
...copying slides between documents
Open both presentations bugdocs, right click on the preview of slide 1
in the source document, copy, right click on the preview of the last
slide in the target document, paste, nothing happens in product builds.
In debug builds, we hit an assert due to a non-async dialog:
coolforkit-ns: /home/vmiklos/git/collaboraonline/online/engine/vcl/source/window/dialog.cxx:947: bool Dialog::ImplStartExecute(bool): Assertion `!"A dialog without a notifier: make me async / properly set up"' failed.
Converting the appearing dialog to async is not trivial, because
sd::slidesorter::controller::Clipboard::PasteSlidesFromSystemClipboard()
first calls InsertFileAsPage() (part of that triggers the dialog) and
then later it also calls InsertBookmarkAsObject(), so a number of
callers would need an async conversion. Instead do what other
presentation software (e.g. PowerPoint does): when pasting slides in,
just scale the objects unconditionally.
The test uses the same trick as commit
3db35199e711da81032c40cf525eb9fb3e792851 (Fix Impress textbox background
changing on cross-document paste in engine and online., 2026-05-11) to
trigger a slide sorter paste.
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: Ia410f57efbaf0a514ae2fc3fb2a645be76bb799d
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3077
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 350d2c9da46659781095361e0ded395102b9619f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205700
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Open the bugdoc, BBB has a bold format redline from Alice. Select this,
apply italics, then reject the format redline, bold remains in the
document.
What happens is similar to commit
bd7f20bdf7d1e66ab13c46074c0482ccab6d6867 (cool#15451 sw interdependent
redlines: fix creating a format on top of format-on-delete, 2026-04-24),
but here we don't have a hierarchical change. DOCX also can't support
format-on-format, instead it merges the two format redlines into a
single one and goes with the metadata (author name, etc) of the new one.
Fix the problem the same way in Writer: keep the "use the new one, drop
the old one" behavior in
DocumentRedlineManager::PreAppendFormatRedline(), but copy the format
data over to the new redline, so a later reject will reject both the old
and the new format redline. Note that this function runs before the
format redline is filled based on the current format operation, so just
setting the extra data to the old redline's format data works.
An additional problem is that the old redline intentionally had no
format data (means: reset all direct format to default), but we had
unwanted fallback code at lcl_SetRedline(). As a result it filled an
empty format redline with the current model state. This makes sense for
a new format redline (bold, then start tracking, italics, revert: should
result in just bold), but not for format-on-format, because in that case
reject wants to get rid of bold, too. So check for the format-on-format
case here & don't fill the new redline from the model to have the
correct result.
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I558ed41ce0e84851092db4e51b301dc2ed15c0d8
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2438
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 0449be1640408a3fad529ed5dec82ae7bd7af240)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205161
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
...on top of format-on-delete
Enable track changes, delete a sentence, select the deleted text, format
the selection as bold, then reduce the selection to just one word inside
the sentence, format as italics: the delete redline is lost for that
word.
This is similar to commit bd7f20bdf7d1e66ab13c46074c0482ccab6d6867
(cool#15451 sw interdependent redlines: fix creating a format on top of
format-on-delete, 2026-04-24), which works because comparing the
to-be-inserted format redline with the existing format-on-delete redline
results in SwComparePosition::Equal.
Here we hit the SwComparePosition::Inside case, so fix that in a similar
way. It already has code to drop the to-be-inserted redline when the
existing redline is an "own" one: do the same if the existing redline is
a hierarchical one, too.
The other way around (bold on just one word, italic on the entire
sentence) was working already.
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I40b1a06daa8fa158da25825e46abd087adeb767d
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1698
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 0e50a49b4c41c7767d51a829c71d3c064f4d5b93)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205160
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
... format-on-delete
Enable track changes, delete a sentence, select the deleted text, format
the selection as bold, then format as italics: the delete redline is
lost.
What happens is that we first have a format-on-delete redline. But then
we try to insert a new format redline for italic, Writer doesn't know
how to combine this new format redline with the existing
format-on-delete redline, so it deletes the old redline by default.
Fix the problem by not creating the new redline in this case. This works
because the format redline needs to deal with the old format and the new
format. If you apply a new formatting, the old format doesn't change and
the new format goes to the model. This means that not creating the new
redline preserves the old delete redline and accept/reject works
correctly, too.
Regression from commit eef0dfed81
(tdf#166319 sw interdependent redlines: add UI to create format inside
insert, 2025-06-12), previously simply no format redline was created, so
the delete redline wasn't lost.
(cherry picked from commit bd7f20bdf7d1e66ab13c46074c0482ccab6d6867)
Change-Id: Ia81b748fd5095bc9141117197edac9d21d95f834
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/1697
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit bb3e131ce43d5dbba2d0edebf2ce248182798c80)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204605
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Open the bugdoc, position the cursor before "A", paste the markdown
snippet: the content is OK, the bullet size is OK, but the paragraph
style & margins of the new content is different to the existing content.
Given that markdown has no way to specify a paragraph style for normal
(non-heading) text and also no way to specify paragraph margins, it's
reasonable to expect these are just copied from the paste insertion
point for consistency.
Fix this by:
1) Putting the end of Reader::StartPaste() back to SwRTFReader::Read(),
so the RTF paste behavior is unchanged, but we don't reset the
paragraph style in Reader::StartPaste() for markdown
2) Extending SwMarkdownParser::CallParser() to not reset the paragraph
style in the paste case before calling md_parse()
3) Extending SwMarkdownParser::EndNumberedBulletListItem() to not touch
paragraph margins when pasting.
The behavior for normal (non-paste) markdown import is unchanged.
Change-Id: I57e9f329f48bcd9a6e1388bb635c7a2a9489aecf
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/1238
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 21c6c0139ceb307525fb0cc05c7a547b8e07d16f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204397
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Have your cursor before "A" in the bugdoc (bulleted paragraph with a
named list style), paste a bullet from markdown, the pasted bullet has
no named list style while the original insert position has, which is
inconsistent.
The problem is that the markdown import assumes the target document is
an empty one, so just creating anonymous bullets or numbered lists will
result in a consistent model.
Fix the problem by looking up the numbering rule at the cursor position
before insert: if we find it and its number format type (ordered,
unordered) is the same as what we want to create, then work with the
existing rule.
The paragraph style is still inconsistent, though (standard vs body
text).
Change-Id: I6c0f1d09c27b9baab58a98ac0995121f4623db20
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/1158
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 57594d280767403f5de59820013f6e4c41f60d28)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204019
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Have your cursor at the start of an existing paragraph with text ("A"),
paste two markdown paragraphs there ("1", "2"), the result is "1A" and
"2", instead of "1", "2" and "A".
The same works better on RTF paste and note how SwRTFReader::Read() has
a double-split at its start + joins at the end to have an empty
paragraph to paste into.
Fix the problem by extracting this paste start/end logic from the RTF
import to Reader::StartPaste() / Reader::EndPaste(), and then using
these in MarkdownReader::Read().
Also remove a misleading comment in CppunitTest_sw_filter_md, there is
no CppunitTest_sw_mdimport.
Change-Id: Id589654edee41494e8ee2f06437748e571f03f3b
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/1102
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit e1a599aa5082a528b36ba2d4711111c4cd39eb7a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204018
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Crashreport backtrace:
#0 0x00007d8e166943f0 in lcl_GetConfigPropertyMap()::aConfigPropertyMap_Impl () from /opt/collaboraoffice/program/../program/libsclo.so
#1 0x00007d8e1876047a in cppu::WeakImplHelper<com::sun::star::ui::dialogs::XExecutableDialog, com::sun::star::lang::XServiceInfo, com::sun::star::lang::XInitialization>::release (
this=0x5a9aec60) at /home/collabora/jenkins/workspace/build_core_co-25.04_for_online_snapshot/include/cppuhelper/implbase.hxx:115
#2 svt::OGenericUnoDialog::release (this=0x5a9aec60) at /home/collabora/jenkins/workspace/build_core_co-25.04_for_online_snapshot/include/svtools/genericunodialog.hxx:80
#3 cppu::ImplInheritanceHelper<svt::OGenericUnoDialog, com::sun::star::ui::dialogs::XAsynchronousExecutableDialog>::release (this=0x5a9aec60)
at /home/collabora/jenkins/workspace/build_core_co-25.04_for_online_snapshot/include/cppuhelper/implbase.hxx:171
#4 cppu::ImplInheritanceHelper<svt::OGenericUnoAsyncDialog<SfxTabDialogController>, com::sun::star::beans::XPropertyAccess, com::sun::star::document::XExporter>::release (this=0x5a9aec60)
at /home/collabora/jenkins/workspace/build_core_co-25.04_for_online_snapshot/include/cppuhelper/implbase.hxx:171
#5 rtl::Reference<PDFDialog>::~Reference (this=<synthetic pointer>, __in_chrg=<optimized out>)
at /home/collabora/jenkins/workspace/build_core_co-25.04_for_online_snapshot/include/rtl/ref.hxx:126
#6 operator() (nResponse=<optimized out>, __closure=<optimized out>) at /home/collabora/jenkins/workspace/build_core_co-25.04_for_online_snapshot/filter/source/pdf/pdfdialog.cxx:88
Calling into sc/ sounds like a broken vtable, possibly just reading
already freed memory.
The potential problem is that by the time the lambda in
PDFDialog::runAsync() would try to keep 'this' alive, it's gone already.
Try to fix that by moving the keep alive variable to the caller, so the
lambda increases the refcount.
Change-Id: Ida39f6fda976ddc044bb92e839de125fdae4fc2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203059
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204057
Tested-by: Jenkins
In-git source files typically have no spaces in filenames, and
underscore is good enough here as well.
sc/UITest_autofilter2.mk references the entire directory, so no need to
update it.
Change-Id: I3d4299f363c7b2ddb70fbc0ca76250b88369b3aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203066
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Regression from online.git commit
3cf8a2f1f161270fb0a85863bea1d5277e92eed3 (cool#10630 doc electronic
sign: fix outgoing mouse messages on 2nd page, 2025-01-27), click
somewhere on the 2nd page of a PDF file in LOK mode, the view jumps to
page 1, while nothing should happen.
This "worked" previously because the JS client had a bug and we sent an
out-of-page coordinate for the mouse click, so nothing happened, while
now it started text edit on the only graphic object on the page. One big
image for each page is the expected model for pdfium-based import
result, but adding text to images in a read-only view is not wanted.
Fix the problem by improving sd::FuDraw::DoubleClick() to check for
LokReadOnlyView next to the existing ReadOnly, which should improve
things in general for multiple LOK views where some of them are
read-only and others are read-write.
Change-Id: Id862c0e143366f7f6fec07576ef5bad8729a0a72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202506
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
online.git's 'make -C cypress_test check-desktop
spec=writer/a11y_dialog_spec.js' points out these can be 0 in practice,
just increase these from non-zero to avoid the assertion failure and
keep commit 281596e732 (cid#1606823
silence Overflowed constant, 2024-09-16) fixed.
Change-Id: I7a4ab6e3aa632345bb49f882d678c5d8af7a5e66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202247
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Create a new Writer document, enable track changes, type "a", "1", "a"
with IME (pinyin) input, crash.
What seems to happen is that we have a transient redlie that's not yet
inserted into the redline table but already has its index assigned while
IME composition is in progress.
Fix this by simply handling this as if there would be no redline: once
the composition is done, we'll re-render anyway and that index will be
inside the bounds of the redline array anyway.
Regression from commit a24dd7b1d7
(cool#13574 sw redline render mode: avoid coloring, set lightness,
2026-01-15).
Change-Id: I08c667d4da40d20cd3a54ffbcb53f5acd2912722
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202248
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Regression from commit 5dc4ab7e3a071133b08db1c234eac6e6c253516e
(tdf#157119 sw floattable: fix moving master of split fly to next page,
2023-09-22), Writer layout went into a loop on opening the bugdoc.
There are multiple problems here at a Writer layout level, if the actual
feature of having 3 nested floating tables would have to work across
pages: first there is some oscillation around borders (+- 10 twips for
the calculated fly position, which looks like the border width of the
table), and then later a lot of new fly frames are created, even if
SwFrame::GetNextFlyLeaf() has code to reuse existing follows. These need
addressing if the actual feature of multi-nesting floating tables are
wanted.
However, the primary problem is that that the document doesn't open and
in practice the inner table needs no wrapping, it's nominally a floating
table probably by accident. So fix this at a DOCX tokenizer level: if a
floating table has multiple parents, then the inner table itself should
be inline, till Writer layout lacks the feature to work with this model.
A further alternative would be to fix this in
sw/source/writerfilter/dmapper/, but our import processes inner tables
first, so by the time we need to decide if the inner table should be
floating or not, dmapper doesn't have the info if the parent tables will
be floating or not, so that is not the right place to implement the DOCX
import change.
Change-Id: I32ac8d1c7c9b372bed32b56eb22f41c2d0f8925d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202149
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
If --with-python=internal is used, then building its curses module
expects an ncurses header with wide char support, otherwise the build
fails with:
/usr/bin/ccache clang -fsanitize=address -fsanitize=undefined -fsanitize=float-divide-by-zero -fsanitize=local-bounds -fsanitize-blacklist=sanitize-ubsan-excludelist -fno-sanitize=function -Iworkdir/UnpackedTarball/bzip2 -Iworkdir/UnpackedTarball/expat/lib -Iworkdir/UnpackedTarball/sqlite3 -Iworkdir/UnpackedTarball/lzma/src/liblzma/api -fno-strict-overflow -Wsign-compare -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -Og -Wall -Iworkdir/UnpackedTarball/zlib -O0 -Wp,-U_FORTIFY_SOURCE -fstrict-aliasing -fstrict-overflow -std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal -I. -I./Include -fPIC -fPIC -c ./Modules/_cursesmodule.c -o Modules/_cursesmodule.o
./Modules/_cursesmodule.c:764:9: error: call to undeclared function 'setcchar'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
764 | setcchar(&wcval, wstr, attr, PAIR_NUMBER(attr), NULL);
| ^
Turns out that /usr/include/ncurses.h and
/usr/include/ncursesw/ncurses.h are not the same here and only the later
provides the wide char support.
Fix this by explicitly adding /usr/include/ncursesw to the include path
on Linux, which should help when that dir exists and it's meant to be
ignored otherwise.
Change-Id: Ic967163d4dbab5df6a0c95146f0d92b564c9901c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201935
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Open a large document, the first page (inside the visible area) shows up
fast, then the idle layout starts calculating later pages. Now scroll
down to page 2, and tiles for that second page only arrive after the
full layout finished.
What happens is that idle layout unfortunately creates high priority
tasks as a side effect of completing its work, so the COOL any input
callback will not interrupt (assuming core has high priority tasks),
even when it should, so idle layout runs to completion and only then we
start rendering tiles.
An option would be to fix the priority of these tasks, but there are a
lot of them: 'vcl SystemDependentDataBuffer', 'svx::SdrPaintView
aComeBackIdle', 'svx::svdraw::SdrPageWindow mpObjectContact',
'sw::SwView m_aTimer', then I stopped looking further. At this point it
looks better to have a higher level mechanism. So introduce a flag in
comphelper/, and using that ignore reporting high priority tasks from
core to COOL till idle layout is in progress.
Note that recursive layouts are not supported, so no need to query the
current value before the first
comphelper::LibreOfficeKit::setIdleLayouting() call. With this, my 839
pages long document shows content on e.g. pages 2 & 3 just fine, even if
the full layout is not yet complete.
Change-Id: I3b7d422dd4a6c95e6fcedbdecb8a98bca6130002
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201102
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
It's better to assert each JSON value separately, so if the
non-significant whitespace changes in JsonWriter, this works still.
Change-Id: I8b84e2319a2d7fd4f06dab2d63150c3ecc6f759d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200831
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Open a document with a tracked change in a LOK client, hover your mouse
over the tracked change, LOK_CALLBACK_TOOLTIP gets triggered, but no
info is sent about the redline itself.
Something similar already happens for content controls, there
LOK_CALLBACK_CONTENT_CONTROL has a 'rectangles' key to describe the
range (rectangles) of the content control.
Fix the problem in a similar way: let SwEditWin::RequestHelp() check if
the content under the cursor is a redline and if so, emit the redline
range's rectangles as a new property of the tooltip.
This time do it as a JSON array, e.g.
{ "type": "generaltooltip", "text": "Deleted: ...", "rectangle": "...", "anchorRectangles": [ "1418, 1966, 2390, 264", "2159, 1701, 9231, 264"]}
to do less string parsing on the LOK client side. And finally expose the
redline type in a similar way, so the LOK client can color the highlight
accordingly.
Change-Id: I6b72d5ff38d2a2b4fab0bda3564dd5b2770779d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199849
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
gdb on the crashreport core dump:
#0 OutputDevice::GetOutputSizePixel (this=0x0) at include/vcl/outdev.hxx:324
#1 vcl::Window::GetOutputSizePixel (this=this@entry=0x5479f1e0) at vcl/source/window/window3.cxx:90
#2 0x0000733bcba58cca in vcl::RoadmapWizard::ImplPosCtrls (this=0x5479f1e0)
at vcl/source/control/wizardmachine.cxx:135
#3 0x0000733bcba5c25d in vcl::RoadmapWizard::ImplHandleWizardLayoutTimerHdl (this=0x5479f1e0)
at vcl/source/control/wizardmachine.cxx:129
#4 vcl::RoadmapWizard::LinkStubImplHandleWizardLayoutTimerHdl (instance=0x5479f1e0, data=<optimized out>)
at vcl/source/control/wizardmachine.cxx:127
#5 0x0000733bc8df817d in Scheduler::CallbackTaskScheduling () at vcl/source/app/scheduler.cxx:585
and
(gdb) up
#1 vcl::Window::GetOutputSizePixel (this=this@entry=0x5479f1e0) at vcl/source/window/window3.cxx:90
90 Size Window::GetOutputSizePixel() const { return GetOutDev()->GetOutputSizePixel(); }
(gdb) print mpWindowImpl
$2 = std::unique_ptr<WindowImpl> = {get() = 0x0}
I.e. this is similar to commit e66599cc396a79e4fc0f59ee256148bc00ca6e15
(vcl: fix crash in Window::ImplInvalidate(), 2025-11-18), you can't
assume mpWindowImpl is a non-nullptr here.
Change-Id: I09c93f568c96cf52369f4eef1798c84f230b880e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199556
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit 8f763a7644fc03eec6d723cb45945015c3f9832c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199561
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Drop the last hunk of build.patch.1,
<https://pdfium-review.googlesource.com/c/pdfium/+/139690> now does the
stream upstream.
Adapt CppunitTest_vcl_pdfium_library_test & CppunitTest_sc_pdf_export:
trailing whitespace is not part of the search match anymore, probably
due to <https://pdfium-review.googlesource.com/c/pdfium/+/142110>.
Adapt CppunitTest_vcl_graphic_test, the search match index is slightly
different now, presumably again due to the whitespace changes.
Adapt CppunitTest_sd_export_tests, the order of shapes on the page
changed.
Adapt CppunitTest_sw_uiwriter11, again trailing whitespace is now
stripped away by pdfium.
Change-Id: Iebc85465320aab2c187b577de304aff7425431b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199595
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Document compare works best when you open the new document, then perform
document compare taking the old document as a parameter. This way
insertions and deletions are correct (instead of being the other way
around.)
This is not intuitive, so help a LOK client provide hints to the user by
exposing the last modified date and the last modifying user when
comparing.
Unfortunately this info is just available when comparing, so we can't
send it again on document load, since the "this document" model doesn't
have both the old and new metadata, we only compare content.
Change-Id: I24c1968ea359536efbe26d7a673374ad42c2ff83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199464
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
gdb backtrace on the crashreport core dump:
#0 0x000076a39e91a0fb in Dialog::PixelInvalidate (this=0x38b519c0, pRectangle=0x7ffc82c86cf0)
at vcl/source/window/dialog.cxx:403
#1 0x000076a39e8db071 in vcl::Window::PixelInvalidate (this=0x388b1b50, pRectangle=<optimized out>)
at include/rtl/ref.hxx:203
#2 0x000076a39e9adcb3 in vcl::Window::queue_resize (this=0x388b1b50, eReason=<optimized out>)
at vcl/source/window/window2.cxx:1453
#3 0x000076a39e9ac0e0 in vcl::(anonymous namespace)::queue_ungrouped_resize (pOrigWindow=pOrigWindow@entry=0x38b50a30)
at vcl/source/window/window2.cxx:1389
Seeing that Dialog::dispose() can reset mpDialogImpl, check for the case
when mpDialogImpl is nullptr in Dialog::PixelInvalidate().
Change-Id: I752f792291abac9af657e58b3257b55cca011ca3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199272
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
gdb on the crashreport core dump:
#0 SwNodeIndex::GetNodes (this=0x0) at sw/inc/ndindex.hxx:117
#1 SwNodeIndex::SwNodeIndex (nDiff=..., rIdx=..., this=0x7ffc29a667f0) at sw/inc/ndindex.hxx:67
#2 SwNodeIndex::SwNodeIndex (nDiff=1, rIdx=..., this=0x7ffc29a667f0) at sw/inc/ndindex.hxx:65
#3 lcl_GetSwUndoId (pFrameFormat=0x53c5c4e0) at sw/source/core/undo/undobj1.cxx:409
#4 SwUndoDelLayFormat::SwUndoDelLayFormat (this=this@entry=0x5477eb40, pFormat=pFormat@entry=0x53c5c4e0)
at sw/source/core/undo/undobj1.cxx:426
I.e. it's possible that in lcl_GetSwUndoId(), rContent.GetContentIdx()
returns a nullptr, so we can't unconditinally dereference that. Return
early with a SwUndoId::DELLAYFMT in that case, matching what would
happen if we would get a content index, which is not a graphic or OLE
node.
Change-Id: I0e6506ffc1506afe616d637571b181d2d6751e1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199123
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
gdb on the crashreport core dump:
#0 0x000071590be5da30 in o3tl::cow_wrapper<OutlinerParaObjData, o3tl::UnsafeRefCountingPolicy>::operator-> (this=<optimized out>)
at include/o3tl/cow_wrapper.hxx:331
#1 OutlinerParaObject::Count (this=0x0) at editeng/source/outliner/outlobj.cxx:168
#2 0x00007158fd9ccb0a in sd::(anonymous namespace)::AnalyzeRenderingRedirector::createRedirectedPrimitive2DSequence (this=0x7ffc29a67820, rOriginal=..., rDisplayInfo=...)
at sd/source/ui/tools/SlideshowLayerRenderer.cxx:550
#3 0x000071590d4469ee in sdr::contact::ViewObjectContact::getPrimitive2DSequence (this=this@entry=0x560c9e40, rDisplayInfo=...)
at svx/source/sdr/contact/viewobjectcontact.cxx:477
#4 0x000071590d447109 in sdr::contact::ViewObjectContact::getPrimitive2DSequenceHierarchy (this=0x560c9e40, rDisplayInfo=..., rVisitor=...)
at svx/source/sdr/contact/viewobjectcontact.cxx:551
I.e. it's possible that in
AnalyzeRenderingRedirector::createRedirectedPrimitive2DSequence(),
pTextObject is non-nullptr but pTextObject->GetOutlinerParaObject() is
nullptr, check for this.
Change-Id: I1013809f134115fbeb56a9962d71380aaee17b22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199059
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Open the bugdoc, switch to non-standard redline render mode (e.g.
dispatch .uno:RedlineRenderMode), the tab portion in the second line
should not be crossed out, but it is.
What happens is similar to number portions, but here the tab portion
doesn't have its own font, it conditionally inherits the font of the
previous number portion.
Fix this by improving SwTabPortion::Paint() to use the new
GetRedlineRenderModeFont() of the number portion when we're in
non-standard redline render mode.
Also simplify some existing checks for getting the redline render mode,
now that I found that SwTextSizeInfo::GetOpt() gives you a
SwViewOption&.
Change-Id: I1bd5aca7705de6641630439f6ff83a73a7fba8b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198970
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Open the bugdoc, switch to non-standard redline render mode (e.g.
dispatch .uno:RedlineRenderMode), the "2." number portion is still
underlined, while this mode doesn't underline insertions otherwise.
The reason this happens is because number portions don't decide redline
coloring/markup at render time, like SwTextPainter::DrawTextLine()
does, instead the font to be used is decided earlier at layout time in
SwTextFormatter::NewNumberPortion().
Fix the problem by creating two fonts in
SwTextFormatter::NewNumberPortion(), one without the redline markup and
one with it. And then later in SwNumberPortion::Paint() use the font
that matches the current rendline render mode. This works, because
changing the redline render mode means SwNumberPortion::Paint() will be
invoked, but the layout's portions won't be re-created for performance
reasons.
Note that similar to table redlines, this just disables the unwanted
standard redline render decoration. That is probably fine, since the
surrounding "real" text is still colored gray/red/green. But we possibly
this can be improved in the future to apply similar coloring even for
the number portion.
Change-Id: I16b4123d20bf0c14c76bb23e574eb21a719d15df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198822
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The bugdoc has some table row-level insert and delete redlines.
Switching to omit insert/delete redline render mode is expected to just
color existing text as gray/red/green, and we get an unexpected table
background here.
The table background was added in commit
f348440e17 (tdf#146120 sw: show tracked
table changes with different color, 2021-12-08), and is wanted with
standard redline render mode, where you already underline/strikethrough
modified text.
Fix the problem by rendering table background similar to "hide changes"
when we're in a non-standard redline render mode.
In the future, we may want to draw some red/green border around these
table row or cell frames, similar to what we do for images. But for now,
just make sure the unwanted background is not painted.
Change-Id: I42f8ec3acacb697fb59ad9ee4d5d9a62efade76a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198695
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
vcl's scheduler assumes that tasks don't throw exceptions. Currently we
log something like:
> warn:vcl.schedule:3886322:2983641:vcl/source/app/scheduler.cxx:590: Uncaught com.sun.star.container.NoSuchElementException message: "Default Page Style"
Which would be more usable if we know either the source location of that
throw and the backtrace or at least the task name.
The later seems to be available, so log it; hopefully next time this
happens we'll know how to fix the actual problem.
Change-Id: I56515c482a63916e69cddc8c0ae116298158f649
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198674
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
gdb on the crashreport's core file:
#0 0x00007afad505b307 in sc::SheetView::unsync (this=0x0) at sc/inc/SheetView.hxx:44
#1 sc::SheetViewManager::unsyncAllSheetViews (this=0x11fa76c0) at sc/source/core/data/SheetViewManager.cxx:120
#2 0x00007afad552a415 in sc::SheetViewOperationsTester::check (this=this@entry=0x7ffcad3703c0, eOperation=<optimized out>, eOperation@entry=sc::Operation::DeleteRows)
at sc/source/ui/docshell/SheetViewOperationsTester.cxx:157
#3 0x00007afad54c2235 in ScDocFunc::CheckSheetViewProtection (eOperation=sc::Operation::DeleteRows)
at sc/source/ui/docshell/docfunc.cxx:126
#4 ScDocFunc::DeleteCells (this=0x124ca680, rRange=..., pTabMark=pTabMark@entry=0x164cec90, eCmd=<optimized out>, eCmd@entry=DelCellCmd::Rows, bApi=bApi@entry=false)
at sc/source/ui/docshell/docfunc.cxx:2469
#5 0x00007afad5971e06 in ScViewFunc::DeleteCells (this=this@entry=0x164cec60, eCmd=eCmd@entry=DelCellCmd::Rows) at /opt/rh/devtoolset-12/root/usr/include/c++/12/bits/unique_ptr.h:445
#6 0x00007afad57f13c6 in ScCellShell::ExecuteEdit (this=0x183359d0, rReq=...)
at sc/source/ui/view/cellsh1.cxx:348
Seeing that SheetViewManager::getPreviousSheetView() checks if the
pointers in the maViews container are nullptr, do the same here.
Change-Id: I0e430edacccae83e2d2d5e7228c437dbd1de5d60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198645
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Open the bugdoc, switch to a non-standard redline render mode (omit
inserts or omit deletes), it's expected to see red-gray or gray-green
pairs of text (for delete and insert), but instead double underline was
shown for some inserts.
This comes from the insert part of moves, which is wanted for the
stanard redline render mode, where an author-specific color is used,
then green (on top of that) means a move.
Fix the problem by avoiding the move-specific rendering for the
non-standard redline render mode case, similar to what the
officecfg::Office::Writer::Comparison::DisplayMovedTextInGreen setting
does.
This required extending the metafile dumper a bit, since underlines were
not exposed in the XML dump.
Change-Id: I717eb0925c1959f787701ef9778ddb704b28031a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198583
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
gdb backtrace on the crashreport's core dump:
#8 SwView::GetWrtShell (this=<optimized out>) at sw/inc/view.hxx:433
#9 SwFrameControlsManager::SetContentControlAliasButton (this=this@entry=0x53674d00, pContentControl=0x536d7210, aTopLeftPixel=...)
at sw/source/uibase/docvw/FrameControlsManager.cxx:192
...
#19 0x000071084f165009 in SwWrtShell::GotoFieldmark (this=this@entry=0x552f4880, pMark=0x536d7e00)
at sw/source/uibase/wrtsh/wrtsh3.cxx:227
#20 0x000071084f15d56b in SwWrtShell::SwWrtShell (this=this@entry=0x552f4880, rDoc=..., _pWin=<optimized out>, rShell=..., pViewOpt=pViewOpt@entry=0x7ffcab7ca2f0)
at sw/source/uibase/wrtsh/wrtsh1.cxx:2118
#21 0x000071084e4a542c in SwView::SwView (this=this@entry=0x552f5180, _rFrame=..., pOldSh=pOldSh@entry=0x0)
at include/rtl/ref.hxx:203
...
#29 0x000071085b272a05 in framework::LoadEnv::loadComponentFromURL (xLoader=..., xContext=..., sURL=..., sTarget=..., nSearchFlags=nSearchFlags@entry=0, lArgs=...)
at framework/source/loadenv/loadenv.cxx:167
I.e. the document on load may have form protection on, in which case it
jumps to the first fillable form, and if that happens to be inside a
content control that has an alias/title defined, we hit this, probably.
The problem is that the SwView ctor is not finished at this stage, so
the view has no writer shell:
(gdb) frame
#9 SwFrameControlsManager::SetContentControlAliasButton (this=this@entry=0x53674d00, pContentControl=0x536d7210, aTopLeftPixel=...)
at sw/source/uibase/docvw/FrameControlsManager.cxx:192
192 const SwViewOption* pViewOpt = m_pEditWin->GetView().GetWrtShell().GetViewOptions();
(gdb) print m_pEditWin.m_rInnerRef.m_pBody.m_rView.m_pWrtShell
$5 = std::unique_ptr<SwWrtShell> = {get() = 0x0}
Fix the problem by not assuming that the view has a writer shell set,
which is usually true, except when the view creation is in progress.
Change-Id: Ic7254e1ccbb9fdcafd94c04b829fae21a2322123
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198530
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Load an Impress document, add a textbox, use the bullet library toolbar
button to have a popup with previews, select the "white bullet" option,
"black cricle" gets used.
This went wrong in commit fe9fab9702
(Related: tdf#89365 sd UI, from numbering to bullet: fix defaults,
2025-12-18), where the old use-case was to just toggle from no numbering
to bullet, without specifying any item from the bullet library, where
the expectation was to connect this paragraph to the outermost outline
style.
Fix the new use-case by not setting bullet properties if a specific item
is selected from the bullet library. This way the new use-case again
takes bullet properties from the bullet library and the old use-case
keeps setting the defaults to have a correct bullet size.
Change-Id: I77931a48e604f177deff4976336783bcff8a7e8a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198398
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
clang 15 warns:
In file included from /home/vmiklos/git/libreoffice/co-25.04-clang/sc/source/ui/unoobj/datauno.cxx:46:
In file included from /home/vmiklos/git/libreoffice/co-25.04-clang/sc/inc/rangeutl.hxx:24:
/home/vmiklos/git/libreoffice/co-25.04-clang/sc/inc/dbdata.hxx:140:18: error: definition of implicit copy assignment operator for 'ScTableStyleParam' is deprecated because it has a user-declared copy constructor [-Werror,-Wdeprecated-copy]
SC_DLLPUBLIC ScTableStyleParam(const ScTableStyleParam& rParam) = default;
^
/home/vmiklos/git/libreoffice/co-25.04-clang/sc/source/ui/unoobj/datauno.cxx:1986:20: note: in implicit copy assignment operator for 'ScTableStyleParam' first required here
aParam = *pOldParam;
^
1 error generated.
cherry-pick from: 2febcb044daf9f75b67c952182835dd6a0525fd3
Change-Id: If0e2c196d2ba8e421fb292aca3eb3486842c4801
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194146
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 6206e9f96551795e998a0687b784d92955ee1806)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196870
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198348
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga@collabora.com>
gdb backtrace on the core file from the crashreport:
#0 0x00007078323c6c4e in std::__shared_ptr<SfxItemSet, (__gnu_cxx::_Lock_policy)2>::operator bool (this=<optimized out>)
at /opt/rh/devtoolset-12/root/usr/include/c++/12/bits/shared_ptr_base.h:1670
#1 SfxMedium::GetItemSet (this=0x0) at sfx2/source/doc/docfile.cxx:3840
#2 0x0000707832428792 in SfxObjectShell::PostActivateEvent_Impl (this=0x3e357de0, pFrame=pFrame@entry=0x427b7460)
at sfx2/source/doc/objmisc.cxx:933
#3 0x0000707832214661 in SfxApplication::SetViewFrame_Impl (this=0x3c0a39d0, pFrame=pFrame@entry=0x427b7460)
at sfx2/source/appl/app.cxx:273
#4 0x000070783254804f in SfxViewFrame::SetViewFrame (pFrame=0x427b7460) at sfx2/source/view/viewfrm.cxx:3735
and:
#2 0x0000707832428792 in SfxObjectShell::PostActivateEvent_Impl (this=0x3e357de0, pFrame=pFrame@entry=0x427b7460)
at sfx2/source/doc/objmisc.cxx:933
933 const SfxBoolItem* pHiddenItem = pMedium->GetItemSet().GetItem(SID_HIDDEN, false);
(gdb) print pMedium
$1 = (SfxMedium *) 0x0
Assume that no medium means the same as medium having no hiddem item.
Change-Id: I6295cfd90d2a3d529fa5e915983578e6768a2244
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198357
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Load the bugdoc, see that the comment is marked as deleted (is anchored
inside a delete redline), save, reload, the comment is no longer
deleted.
This is because we write redline start/end around DOCX "runs", and the
comment reference dummy character is one such dummy run. So unless
explicit redline markup is written, comments (their comment reference)
is not inside a redline.
Fix this by checking if we'll write comment references (part of comment
end) in DocxAttributeOutput::EndRun(). If we're inside a delete, write
the delete redline markup around the comment reference, too.
Doing the same for inserts would make sense, but then first we would
need to tweak Writer's UI to insert new comments outside redlines,
otherwise UITest_writer_tests7's
tdf90401.tdf90401.test_tdf142902_remove_personal_info_in_DOCX would
break.
Change-Id: I8d6db05c8a9fd1d5e1e619843967e3f21fb43e59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198353
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Anchored images conditionally got a red/green frame in since commit
afdf4e287fb91c7baf2767eb95b0565472b8343d (cool#13988 sw redline render
mode: add colored border for anchored images, 2026-01-27), but the same
didn't work for inline images.
Seems what happens is that SwFlyFrame::GetRedlineRenderModeFrame() sets
the border line with to 1 (in twips, so some minimal value), but then
this is turned into a SdrFrameBorderPrimitive2D, which gets decomposed
into a PolygonStrokePrimitive2D. At this point the cairo pixel processor
handles it at CairoPixelProcessor2D::processPolygonStrokePrimitive2D(),
which assumes that hairline is when the width is 0. The trouble is that
in case Writer sets the width to 0, then we don't even start processing
such stroke primitives.
Solve the problem by going with a larger border width: just query from
output device what would be a logic value for a 1px border, so it does
show up reliably.
This is similar to how SwViewOption::s_nPixelTwips gets configured
already. Note that the testcase just asserts these polygons are painted,
but it can't verify how CairoPixelProcessor2D simply didn't paint the
old bad width.
Change-Id: I83f7aec4d09fc628dd314e1325bfd47af07308ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198339
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
So far the non-standard redline render mode for images focused on
graying out images when they are meant to be "omitted".
In the meantime, text got red/green colors since commit
9bc163b5637572684ac6cc5985d276c4bc01679f (cool#13574 sw redline render
mode: somewhat color ins/del as green/red, 2026-01-20), for the case
when the inserted/deleted text is not omitted.
Do the same for images: if an anchored image is not omitted, then
provide a red/green border for deleted/inserted images.
This is for anchored images, inline images need more work. Two
alternatives would have been to draw this border at the end of
SwFlyFrame::PaintSwFrame() (like the standard redline mode does its
cross for deletes, but doesn't work due to clipping problems) or as part
of SwLayoutFrame::PaintSubsidiaryLines() (like the gray "boundary"
indicator does, also has clipping problems). Doing it in
SwFrame::PaintSwFrameShadowAndBorder() is free from these clipping
problems.
Change-Id: I7489e5be5c7081a8e6dc243cb30d8fd2dc4f1917
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198254
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The bugdoc has commented text range inside a deletion. The import result
doesn't mark the comment as deleted.
Comments with a single anchor point work fine, since commit
419b70b5d4 (tdf#105485 DOCX: import
deleted comments as deleted, 2019-08-26).
Fix the problem by invoking CheckRedline() in
DomainMapper_Impl::PopAnnotation() in the range case as well, that
correctly creates the delete redline for the comment anchor.
This is shared code for any redlines, so fixes inserts, too.
Change-Id: I620e1419cee79ab729ea7be248f1ad079a9fc536
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198125
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
gdb backtrace on the core file:
#8 chart::OfPieChartDialogController::fillExtraControls (this=0x23c15020, xChartModel=..., xTemplateProps=...)
at chart2/source/controller/dialogs/ChartTypeDialogController.cxx:841
#9 0x0000719b38a2076f in chart::ChartTypeTabPage::selectMainType (this=0x23948420)
at chart2/source/controller/dialogs/tp_ChartType.cxx:272
#10 0x0000719b3b656103 in Link<weld::TreeView&, void>::Call (data=..., this=0x1fd52058)
at include/tools/link.hxx:111
and:
(gdb) print aValuesSeries
$1 = std::vector of length 0, capacity 0
But leave the assert in place, so we have a chance to find the deeper
problem in a debug build.
Change-Id: Ic590c777a0a6fbe5fd188b6600c1de908c9a0910
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197926
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Load the bugdoc, dispatch .uno:RedlineRenderMode, anchored images in
deletions are grey, but this doesn't work with inline images.
There is some infrastructure for this added in commit
d845b91bcc (tdf#78864 sw track changes:
cross out deleted images, 2021-04-30), but that crosses out images
instead of shading.
Fix this by checking for the usual SwRedlineRenderMode flags in
sw::FlyContentPortion::Paint() to avoid the unwanted cross. Also extend
SwLineLayout::CalcLine() to set the inserted/deleted flags on the fly
frame for redlines, so SwGrfNode::GetGraphicAttr() can do its shading as
usual.
And add a GetMetaFileImages() in the test suite to reduce some
duplication.
Change-Id: I97f2311ad7e9a6ffc70d76c1811faa2c13e509fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197799
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
So far the non-standard redline render mode focused on hiding inserts
and deletes: typically hiding inserts on the left hand side, and hiding
deletes on the right hand side, a bit similar to the side-by-side source
code diff. What's missing is to do a color transform for the opposite
cases, i.e. deletes on the left and inserts on the right.
The intent is to color deletes with a red-like color on the left and
inserts with a green-like color on the right.
We still need to do this in SwFntObj::DrawText(), because automatic
colors are not expanded before that point. To keep this readable in both
light and dark mode, do the color transform in HSL space and set the
"hue" of the color to red/green, and constrain saturation/lightness a
bit to ensure readability.
The images are not yet touched for this, they are still simply
grayscale when hiding and unchanged otherwise.
Change-Id: I21e0721d66a5b0d4e85476a0631f360610c92d8a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197712
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
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>
User A managed to format a piece of text as red, formatted with
underline and then user B is now confused why rejecting this tracked
change doesn't work.
This is working as intended for the normal redline render mode, but we
can try something different for the 'omit insert/delete' redline render
mode: when showing the old version, we can render deletes unchanged and
when showing the new version, we can render inserts unchanged. The rest
of the redlines can be semi-hidden.
That semi-hidden is a bit tricky to provide. Now that we don't add
layout-level colors in SwModule::GetInsertAuthorAttr(), we go with
automatic color, which gets resolved quite late. So first figure out if
we need to "omit" (semi-hide) the current redline portion in
SwTextPainter::DrawTextLine(), and then pass around a flag, so that once
SwFntObj::DrawText() is past ApplyAutoColor(), we can set lightness to a
medium value.
This is needed, because a typical auto color resolves to either white or
black, and changing saturation has no effect for those colors. And this
way we still get readable text in both light and dark mode.
Change-Id: I0ff57cd996fda80fadc315ad0c6c85e5af1ff3e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197350
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Try to dispatch .uno:CompareDocuments with
URL=https://example.com/old.docx, notice that the document gets
downloaded multiple times. This is a problem if the URL is set up in a
way that the content can be downloaded only once.
It seems the problem is in SwView::InsertDoc(), where we access the
stream data at least twice: once during file detection and once during
actual file import.
Fix the problem by reading the remote stream data only once, somewhat
similar to what GraphicFilter::LoadGraphic() does for non-file URLs.
In practice this fixes doc compare when the URL is generated by the
Nextcloud file picker, where doc compare didn't work, but image
insertion did work. No testcase, that would require setting up some HTTP
server which does more than serving static files.
Change-Id: I2cae56db9d6c10f411770f23f1d0b66b24e63440
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197166
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Try to insert a https:// image URL into Writer when the URL's host is
meant to be not verified, 'curl -k' works with the URL but insertion in
Writer still fails.
Turns out this is an expired self-signed certificate (in a local test
env). Mechanism for not verifying SSL certs in the curl session was
added in commit 2a5c998d4c (allow an
exemption to be made for a specific host, 2024-08-23), but that results
in an image insertion failure.
Fix the problem by adapting the ucb/ code to do what
<https://github.com/curl/curl/blob/470e26ff6eb55e8d18d6fa44104834e9d1f71274/src/config2setopts.c#L375>
does for 'curl -k', also clear the CURLOPT_SSL_VERIFYPEER option.
With this, inserting https:// images from my local test server works
again in Writer.
Change-Id: I0c52f6c0c0dfd6ebf0b4081a8088b623935a96f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197093
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
gdb on the crashreport core dump:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 SwViewShell::GetLayout (this=0x0) at /opt/rh/devtoolset-12/root/usr/include/c++/12/bits/shared_ptr_base.h:1665
and
#0 SwViewShell::GetLayout (this=0x0) at /opt/rh/devtoolset-12/root/usr/include/c++/12/bits/shared_ptr_base.h:1665
#1 0x000078c9268a799d in SwViewShell::GetDocSize (this=<optimized out>) at sw/source/core/view/viewsh.cxx:2320
#2 0x000078c926ca55e8 in non-virtual thunk to SwXTextDocument::getDocumentSize() () at sw/inc/unotxdoc.hxx:444
#3 0x000078c933bc4e16 in doc_getDocumentSize (pThis=0x8e8cc20, pWidth=0x7ffdd9b4c5e0, pHeight=0x7ffdd9b4c5e8)
at desktop/source/lib/init.cxx:4626
Fix it similar to what SwXTextDocument::setPart() does: don't assume
that we still have a view shell by the time getDocumentSize() is called,
a document teardown may be in progress where we still have a model, but
no views anymore.
Change-Id: Id2f5ac4bf08601a9664909f5a78322bf41998a86
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197062
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Open the bugdoc which has a <format>BBBCCCDDD</format> redline. Select
CCC, press delete: now CCC is only covered by a delete redline instead
of a format-on-delete redline.
The trouble is in sw::DocumentRedlineManager::PreAppendDeleteRedline(),
where rCtx.pRedl (format redline) initially covers BBBCCCDDD, but then
it gets reduced to cover only BBB. We also create a pNew redline to
cover only DDD. This gives Writer a way to set rCtx.pNewRedl's range to
CCC without an overlap. The downside is that now reject-all doesn't
modify the format of CCC anymore, so some unexpected boldness remains in
the document.
Fix this similar to how
sw::DocumentRedlineManager::PreAppendForeignRedline()'s rCtx.eCmpPos ==
SwComparePosition::Inside case works: except there PushData() is used to
push the redline data "over" (before creating pNew), and here we use
PushData() to push the redline data "under".
This way UI creates a model where format is always on top of delete (and
not the other way around), which is useful, since DOCX only has markup
for that order and ODT explicitly says this order should be used in
files.
Change-Id: Ida640ad7bb99ed89faef306dac2b840ae3be53f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196918
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
gdb backtrace on the core file from the crash report:
#5 0x0000000000afc0ee in std::__glibcxx_assert_fail(char const*, int, char const*, char const*) ()
#6 0x0000727cd30229b1 in std::deque<std::pair<sw::mark::Fieldmark const*, bool>, std::allocator<std::pair<sw::mark::Fieldmark const*, bool> > >::pop_back (this=0x7ffc1ea0f8e0)
at /opt/rh/devtoolset-12/root/usr/include/c++/12/bits/stl_deque.h:1597
#7 std::deque<std::pair<sw::mark::Fieldmark const*, bool>, std::allocator<std::pair<sw::mark::Fieldmark const*, bool> > >::pop_back (this=0x7ffc1ea0f8e0)
at /opt/rh/devtoolset-12/root/usr/include/c++/12/bits/stl_deque.h:1597
#8 ModelToViewHelper::ModelToViewHelper (this=this@entry=0x7ffc1ea0fb40, rNode=..., pLayout=0x631dce00,
eMode=eMode@entry=(ExpandMode::ExpandFields | ExpandMode::ExpandFootnote | ExpandMode::ReplaceMode | ExpandMode::HideFieldmarkCommands))
at sw/source/core/txtnode/modeltoviewhelper.cxx:207
#9 0x0000727cd311cea2 in SwXFlatParagraphIterator::getNextPara (this=0x64417ab0)
at sw/source/core/unocore/unoflatpara.cxx:485
...
#12 0x0000727cd2c23b4f in SwDoc::StartGrammarChecking (this=<optimized out>, bSkipStart=bSkipStart@entry=false)
at sw/source/core/doc/docnew.cxx:184
and:
(gdb) frame 8
#8 ModelToViewHelper::ModelToViewHelper (this=this@entry=0x7ffc1ea0fb40, rNode=..., pLayout=0x631dce00,
eMode=eMode@entry=(ExpandMode::ExpandFields | ExpandMode::ExpandFootnote | ExpandMode::ReplaceMode | ExpandMode::HideFieldmarkCommands))
at sw/source/core/txtnode/modeltoviewhelper.cxx:207
207 startedFields.pop_back();
(gdb) print startedFields
$2 = std::deque with 0 elements
We have no reproducer for this, but seems the grammar checker is somehow
invoked on an inconsistent model where the start and end field mark
dummy characters are not balanced. Leave the assert in place, so
possibly a later debug build can find a reproducer; but also check for
this to avoid a crash in product builds.
Change-Id: Ic9696e32bf344b336800bfa475f506e3cc103ef6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196615
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
And the same for use_more_fonts
MORE_FONTS is part of the default build type and Linux distro people
typically disable it, but it's not obvious where to document that.
This means that 'gb_CppunitTest_set_non_application_font_use' is
routinely inside a 'ifneq ($(filter MORE_FONTS,$(BUILD_TYPE)),)'
condition, since without 'more fonts', it's hard to avoid font
fallbacks.
Change-Id: I54673c16e067c922fb566961f3e59c3dd7ef1faf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196591
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
This is similar to commit 4154d281fb (sw
lok: hide UI to set Word-incompatible anchor types, 2019-07-05), but
here the context menu was already filtered, so just need to hide two
radio buttons in the Writer-specific tab page of the shape position &
size dialog.
Change-Id: I575872a65deb2e6c6bc08515752911991e6505f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196552
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
gdb backtrace on the crashreport core dump:
#0 SwNodeIndex::GetIndex (this=0x0) at sw/inc/ndindex.hxx:109
#1 (anonymous namespace)::ApplyFlyFrameFormat (rFrameFormat=..., rWrt=..., rChange=...)
at sw/source/filter/md/wrtmd.cxx:151
#2 0x000072427b5880dd in (anonymous namespace)::ApplyItem (rWrt=..., rChange=..., rItem=..., increment=<optimized out>)
at sw/source/filter/md/wrtmd.cxx:280
#3 0x000072427b58888b in (anonymous namespace)::CalculateFormattingChange (currentFormatting=..., pos=0, positions=..., rWrt=...)
at sw/source/filter/md/wrtmd.cxx:323
#4 (anonymous namespace)::OutFormattingChange (rWrt=..., positions=..., pos=pos@entry=0, current=...)
at sw/source/filter/md/wrtmd.cxx:385
#5 0x000072427b58ad66 in (anonymous namespace)::OutMarkdown_SwTextNode (rWrt=..., rNode=..., bFirst=<optimized out>)
at sw/source/filter/md/wrtmd.cxx:821
#6 0x000072427b58b8e7 in SwMDWriter::Out_SwDoc (this=this@entry=0x4229cea0, pPam=<optimized out>)
at sw/source/filter/md/wrtmd.cxx:1063
If there is no start node in the SwFormatContent, then we have no way to
access the Graphic to export, so just return early.
Change-Id: I3c2e4b256aa63c415bb224246f0ce2fc4f3e5059
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196102
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
The DOCX bugdoc has a format redline (mark as bold) + a delete redline,
and these two overlap. Open the document in Writer, reject the delete
redline, the boldness remains in the document, which is unexpected.
The problem is an in case a format redline is created and that would be
on top of an insert or delete from the same author, then we currently
merge this into the insert/delete redline. The reason for this seems to
be that search&replace inserts text to the document and then copies
direct format from the insert position to the inserted text range, and
this format should not show up on the UI, since the UI action was just
to replace text. Another variant of this is autocorrect "make first
character of the paragraph uppercase" in action, which is internally
again a replace.
Fix the problem by disabling combine of redlines in
sw::DocumentRedlineManager::PreAppendFormatRedline(), in case we would
do a combine and this is a format on delete. This way the format is
rejected by the UI reject action and the unwanted format on insert still
doesn't show up. The behavior was like this already in case the authors
of the format and the delete redlines were different.
Note that this tweak is not even important for the insert-then-format
case: accept doesn't modify the body text and reject would remove text
from the body text, so we get rid of the unwanted format anyway.
Change-Id: Ib08b0c62c012f14801deae47a4b85d77e32fc1a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196095
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Load the document, press Ctrl-1 to set a heading 1 paragraph style, an
unexpected leading tab shows up before the paragraph text.
This went wrong with commit a7d9837a8a
(tdf#148360: sw: do not ignore list label followed by, 2022-08-02),
previously "followed by" was ignored by the layout if the numbering
portion before the separator was empty. This is needed to correctly lay
out DOCX files.
Fix the problem by changing the default Outline numbering rule in
Writer: the numbering type is set to "none", so also set the "label
followed by" property to "nothing". Note that this doesn't affect DOCX
files which already have heading styles configured, nor documents where
the DocumentSettingId::NO_NUMBERING_SHOW_FOLLOWBY compatibility option
is off.
There was one handy side-effect of having "followed by" as "tab": once
the UI was used to change the numbering type from "none" to e.g. Arabic,
the user didn't have to explicitly ask for the tab separator, which is
usually wanted. Continue supporting this scenario by checking for the
"number type none + followed by nothing" scenario: if the number type
changes to something else, then also change "followed by" to the old
"tab" default.
Change-Id: I60905623e6c4b6ded56a1a089ae0fb3af3b2bd3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195706
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
The old comment happened to focus on the SwClient part of it; also say
where it appears in the model & where to find it on the UI.
Change-Id: I4d91e4d77b1f9ded6cbe7d0f5b4a9232d697b73a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195909
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Open the bugdoc, start text edit on the only slide, in the only shape.
Use the toolbar button to change from no numbering to bullet, some very
small bullet with no spacing between the bullet and the text shows up.
This happens since commit f60ee00edcc5b0fdee5227bb695448119cddb013
(tdf#89365 sd UI: fix transitioning from a numbered list to a bulleted
list, 2025-11-04), previously the numbering to bullet transitioning was
broken and you had to click on the "turn on bullets" button twice. A
side effect of the old two-step transitioning was that no formatting
from the old numbering was kept, so better defaults were used (but the
numbering level was lost).
Keep the old use-case fixed and fix the new use-case by looking at how
this works on master pages: there TextObjectBar::ExecuteImpl()'s
FN_NUM_BULLET_ON block calls
SdStyleSheetPool::setDefaultOutlineNumberFormatBulletAndIndent() before
setting the number format for a specific level of the numbering rule. Do
the same for non-master pages in
FuBulletAndPosition::SetCurrentBulletsNumbering(): if we transition to a
bullet, then use the same defaults in the non-master-page case, too.
Note that turning bullets on or off as direct formatting is not ideal: a
better style is to assign bullets (or no bullets) to different outline
levels in the master page, and then just change the list level of
paragraphs in the outliner shape, which avoids this sort of problem in
the first place.
Change-Id: I4227988593baeaa91cc21525fb895c3acaf3afd7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195839
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
gdb in the core dump gives:
#0 0x000073b5e9fd6bb9 in SwFieldType::Which (this=<optimized out>) at sw/inc/fldbas.hxx:276
#1 SwField::GetTypeId (this=0x0) at sw/source/core/fields/fldbas.cxx:267
#2 0x000073b5e911faa4 in SwFieldEditDlg::AddressHdl (this=0x4a057e70) at sw/source/ui/fldui/fldedt.cxx:296
#3 0x000073b5f85de37c in std::function<void ()>::operator()() const (this=0x7fffed028930) at /opt/rh/devtoolset-12/root/usr/include/c++/12/bits/std_function.h:587
#4 Control::ImplCallEventListenersAndHandler(VclEventId, std::function<void ()> const&) (this=<optimized out>, nEvent=nEvent@entry=VclEventId::ButtonClick, callHandler=...)
at vcl/source/control/ctrl.cxx:311
#5 0x000073b5f85c16c8 in Button::Click (this=<optimized out>) at vcl/source/control/button.cxx:130
and
#2 0x000073b5e911faa4 in SwFieldEditDlg::AddressHdl (this=0x4a057e70) at sw/source/ui/fldui/fldedt.cxx:296
296 if (pCurField->GetTypeId() == SwFieldTypesEnum::DocumentInfo)
(gdb) print pCurField
$2 = (SwField *) 0x0
return early in case we don't have a valid pointer for the current field
anymore.
Change-Id: Ibc614cc825a0b14cd4f79060d35f6635eb0cdd55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195784
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
The bugdoc has two redlines: a format and a delete redline. Pressing
"reject all" in the manage changes dialog doesn't reject the format
redline.
Seems this happens because of code added in commit
9c4eef7d80 (tdf#52391 reject/clear
formatting of format-only changes, 2019-01-29), which argued that
rejection of format redlines isn't really implemented, so better if a
"mass reject all" doesn't reject them, unless only format redlines are
found in the document. But in the meantime I worked on improving
support for rejecting format redlines, most recently commit
47cb60bc534104852a219426e3beb4c714b6cf07 (tdf#167761 sw format redline,
char props: implement ODF import, 2025-08-18) added ODF import/export of
these old direct character properties, so it now makes less sense to
filter out format redlines while rejecting all of them. Also, the
matching toolbar button didn't ignore such format redlines.
Fix the problem by simplifying SwRedlineAcceptDlg::CallAcceptReject():
unless the redline data for the iterator says this item is disabled,
always add it to the list of redlines, similar to what the "reject the
selected redline(s)" case did already.
Note that the original 2019 commit was less confusing, as it did change
the label of the reject all button, but that was removed in commit
2e1a38ceb6 (tdf#146893 Rework Manage
Changes dialog, 2022-01-24).
Change-Id: I69e7247d068cea2a25cd46ad2d5b41fccfa54919
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195772
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Patch out the single unconditional usage of `raw_ptr`, which belongs to
the partition allocator, that we disable using
`-DMEMORY_TOOL_REPLACES_ALLOCATOR`.
Change-Id: Iac9239c741af2de59b2f88d7748e41e540019254
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195700
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
I'm looking at a weird numbering which has a tab portion but no actual
numbering, and this is part of the puzzle.
Change-Id: I840b535846bf20fa962423ddee7245ad81705c3e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195696
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Miklos Vajna