What seems to be a long-standing calamity was apparently exposed
by my 7.5 commit 0031f34d0b.
Without this fix, nIdx was never changing,
so the while loop ran infinitely - ever since initial creation.
Since synchronized SwTextNode::GetMinMaxSize (mentioned in the comment)
doesn't loop, it doesn't seem to need any changes.
Change-Id: I503839d93f212d354dd66e8a5dfdf3f4730f068f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211691
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
crash on import of bugtrackers/html/novell574949-2.html,
novell574949-3.html and novell688091-3.html, a debug build asserts:
soffice.bin: include/o3tl/typed_flags_set.hxx:168: constexpr typename o3tl::typed_flags<T>::Wrap operator&(E, E) [with E = SwFrameType; typename o3tl::typed_flags<T>::Wrap = o3tl::is_typed_flags<SwFrameType, 64511>::Wrap]: Assertion `o3tl::detail::isNonNegative( o3tl::to_underlying(lhs))' failed.
and valgrind of novell688091-3.html reports:
Invalid read of size 4
at SwFrame::GetType() const (frame.hxx:533)
by SwFrame::IsContentFrame() const (frame.hxx:1283)
by SwContentFrame::ImplGetNextContentFrame(bool) const (findfrm.cxx:523)
by SwContentFrame::GetPrevContentFrame() const (cntfrm.hxx:138)
by SwFrame::FindPrevCnt_() (findfrm.cxx:1250)
by SwFrame::FindPrevCnt() const (findfrm.cxx:267)
by SwTextFrame::IsHiddenNowImpl() const (txtfrm.cxx:1635)
by SwTextFrame::Prepare(PrepareHint, void const*, bool) (txtfrm.cxx:3047)
by SwFlyInContentFrame::NotifyBackground(SwPageFrame*, SwRect const&, PrepareHint) (flyincnt.cxx:230)
by SwFlyInContentFrame::DestroyImpl() (flyincnt.cxx:51)
by SwLayoutFrame::DestroyImpl() (ssfrm.cxx:509)
by SwSectionFrame::DestroyImpl() (sectfrm.cxx:192)
by SwLayoutFrame::DestroyImpl() (ssfrm.cxx:572)
by SwCellFrame::DestroyImpl() (tabfrm.cxx:6021)
by SwLayoutFrame::DestroyImpl() (ssfrm.cxx:572)
by SwRowFrame::DestroyImpl() (tabfrm.cxx:4853)
by SwTabFrame::DestroyImpl() (tabfrm.cxx:154)
by SwTableNode::DelFrames(SwRootFrame const*) (ndtbl.cxx:2530)
by (anonymous namespace)::TableSaveStruct::MakeTable(unsigned short, SwPosition&, SwDoc*) (htmltab.cxx:4754)
by SwHTMLParser::BuildTable(SvxAdjust, bool, bool, bool) (htmltab.cxx:5167)
Address 0x2d286d30 is 272 bytes inside a block of size 472 free'd
at operator delete(void*, unsigned long) (vg_replace_malloc.c:1146)
by SwSectionFrame::~SwSectionFrame() (sectfrm.cxx:197)
by SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:392)
by SwLayoutFrame::DestroyImpl() (ssfrm.cxx:572)
by SwCellFrame::DestroyImpl() (tabfrm.cxx:6021)
by SwLayoutFrame::DestroyImpl() (ssfrm.cxx:572)
by SwRowFrame::DestroyImpl() (tabfrm.cxx:4853)
by SwTabFrame::DestroyImpl() (tabfrm.cxx:154)
by SwTableNode::DelFrames(SwRootFrame const*) (ndtbl.cxx:2530)
by (anonymous namespace)::TableSaveStruct::MakeTable(unsigned short, SwPosition&, SwDoc*) (htmltab.cxx:4754)
by SwHTMLParser::BuildTable(SvxAdjust, bool, bool, bool) (htmltab.cxx:5167)
SetControlSize creates a hidden temporary view to measure a form
control, so a layout exists while the document is still being parsed,
which is an unusual thing to attempt, so it seems easiest to just avoid
that entirely.
The temporary view is originally, since:
commit ff09ed094d
Date: Mon Jul 7 11:06:22 2008 +0000
INTEGRATION: CWS ab53 (1.26.112); FILE MERGED 2008/06/20 06:47:28 tkr 1.26.112.1: #i47763# synchronous html import
But svx already had a way to get a control for a plain window with no
view with:
commit e1137040e3
Date: Tue Nov 14 12:48:07 2006 +0000
INTEGRATION: CWS aw024 (1.18.138); FILE MERGED ... 2006/03/21 13:20:59 fs 1.18.138.7: #i62854# +GetTemporaryControlForWindow ...
The recent problem only shows up in crashtesting since hidden text
support was added to html filter in:
commit eb9ca728e179aab3f51be4d96b02a03e502a1f87
Date: Fri Sep 18 08:36:02 2026 +0200
Related: cool#16219 engine sw HTML import: handle hidden text
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12991
so drop the temporary view and realize the control with
GetTemporaryControlForWindow in a hidden window of the parser's own
when there is no view. valgrind is clean on all of these documents,
and the 104 controls in them and in the sw HTML test documents keep
the same sizes.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I47c26c7efba47f747cd1ec29b21350172b1df0c2
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13960
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit c7e0ef4a46fb127962a69b2124de46bc46486685)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211685
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
ISO 32000-2 Table 369 makes the order normative: a Ruby shall contain
one RB followed by an RT, or by RP, RT and RP. A ruby's two sub-lines
paint in visual order, though, and each opened its structure element as
it painted, so an exported ruby held its RT before its RB. PAC 2026
reports that as two errors per ruby; veraPDF does not report it.
An element is ordered among its siblings where its type is set, not
where it is painted, so both kids are created and typed before either
sub-line paints, and each sub-line then enters the kid already created
for it.
Which sub-line carries the annotation follows OnTop, while bRubyTop only
reflects where a squared grid puts the annotation and is true everywhere
else. Keying the role off bRubyTop tagged the base of a ruby positioned
below outside a squared grid, or to the right, as the RT and its
annotation as the RB, so both the role and the element follow OnTop now.
A squared grid with the ruby text below was already right, bRubyTop and
OnTop agreeing there.
The kids are created only where BeginInlineStructureElements would enter
them: a ruby in the repeated headline row of a follow table would
otherwise leave an empty RB and RT on the table, once per following
page.
testLinkWithRuby asserted only that both kids are present, the order
being wrong when it was written; it compares them in order now.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I8e38a3544008f79939d7d0795c4808a1a72caad7
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13402
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 65c62bc31aff793465f31ab6172c118921fe9d51)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211690
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Copying a cell over another one with change recording on could crash, or
destroy the tracked change it had just recorded when the target cell had a
number format.
The root cause was that formulas and formatted numbers overwrite
existing cells and destroy some tracked changes..
The cursor could point to a character that is not exist anymore.
So, first i made some cursor position fix in some key points
to avoid some crashes.
Then disabled tracked changes when a cell with formula is changed.
Every time it was recalculated, it generated a new tracked change.
Normally if we want it to be tracked, we should track the formula inside,
not the visible value .. but we don't have that type of tracked change.
ChgTextToNum() could also generate lost tracked changes:
If we copied a formatted number cell content to an other similar cell,
(for example a currency like $1,000.00 to $10.00)
by replacing the text ... then at first it generated a cell content like
$1,000.00($10.00)
where ($10.00) is a delete change..
Then the ChgTextToNum() reformatted the cell.. and overwritten it with
the $1,000.00 ... so we lost the delete change.
now i changed it so it can keep tracked deletion changes as well
(it was able to store some insert changes)
and then it checked if the format is fine for the real text ..
If it is, then it will leave it.. so tracked changes survive.
If the format is not good, then i keep the old way of working to
replace cell with the new value... and make it 1 insert tracked change
I do this to avoid complex problems.. because at format changes
a lot of things can change.. position of the characters ..
and it could be a confusion where the old delete change should start from.
It would need more planning to figure out a way to handle it.
Side note: in some cases if we modify the value of the formatted number cell
to something that does not fit the format, it can lose the formation
and change to pure text. (so all track changes will work on it)
like if you change this: $1,123,234.00 -> $1,123234.00
(This is not my change. i just mentioned this behavior.)
Signed-off-by: Attila Szűcs <attila.szucs@collabora.com>
Change-Id: I152ec4720ec8e133800186c7e5787fe0f6954fc8
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13456
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
(cherry picked from commit 699b9cb056cb283fc2699763e1a2340e12680c3f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211684
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A shape that goes over a shape with a text box was put one place too high
and ended up over the shapes that should have covered it.
Regression from commit da7414e63578c17adb7f5f3345fa2143f0bc769c (sw: fix
setting mbIsTextBox on shapes' text boxes).
GraphicZOrderHelper::findZOrder() works out where a shape goes by reading
the z-order of the shape it is to sit on and adding to it.
200cd2b99b (tdf#138995 DOCX import: fix handling of textbox zorders)
made it add one more place when that shape has a text box, since a shape and
its text box are two objects and going over the pair means passing both.
The z-order it reads back, though, is the one SwXShape reports, and that
is SwTextBoxHelper::getOrdNum(), which leaves the text frames out.
Until de070c8e59 nothing set the flag it asks for: SetTextBox(true) was
called on the shape's SdrObject, which is not a SwFlyDrawObj, so
IsTextBox() stayed false, the text frames were counted like any other
object, and the extra place was right. Now that the flag reaches the text
frame, a shape and its text box take a single place in that numbering, so
the extra place is one too many.
200cd2b99b noted that it was needed until there is a setter
version of SwTextBoxHelper::getOrdNum(); that setter still does not
exist, but the numbers the filter reads back no longer count the text
frames, so there is nothing left for the extra place to skip.
Signed-off-by: Attila Szűcs <attila.szucs@collabora.com>
Change-Id: Id8d6746c3832e5e512cb0a970d07440f1afb67bc
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13659
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
(cherry picked from commit eb4fe084855f60a41de4493aa289160ba074e14c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211667
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
When image is wrapped through in document body.
Separate part of SwFEShell::ShouldObjectBeSelected()
to SwFEShell::IsTextOverBgObjectAt(), and use it to detect
text overlapping background image.
Handle case when DocumentSettingId::PAINT_HELL_OVER_HEADER_FOOTER
is set. (see eg. SwFlyFrame::InitDrawObj())
Not part of this change: updating mouse pointer over objects/text.
Related to b860aea9d6,
which introduced special handling of
PAINT_HELL_OVER_HEADER_FOOTER for DOCX compatibility.
Change-Id: I571942a43c3c1d5a5be5906fcce08640739e6493
Signed-off-by: Aron Budea <aron.budea@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/11523
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 3bae82eb865b2568506417349d2f3a62bfd775e8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211680
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The test replicates the instructions in the bug report. Jenkins is
building with optimisations for MacOS so the test should be able to
catch the original problem if it were to regress.
Change-Id: Ia8fd381be15ef3986fdb1f515be45097abf614ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211377
Tested-by: Jenkins
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Object streams and a cross-reference stream shrink a tagged PDF, but
I1e27dc3a8f43aa8b6c75ae930615c8d4b4645627 ("tdf#157028 vcl: write the
structure tree into object streams") left an encrypted export out of
both, so a password kept the whole structure tree uncompressed. The
spreadsheet reported in tdf#166233, attachment 171182, exported tagged
at 2368642 bytes, and at 13465120 with a password. The protected export
is 2389620 bytes now, and what it has over the plain tagged one is what
encryption itself costs.
This writer encrypts a string as it builds the object. ISO 32000-2 7.5.7
forbids encrypting a string in an object stream separately: the stream
that carries it is encrypted instead. So the strings of a stream-bound
object go in plain now, and the object stream is encrypted as a whole,
with the cipher set up for the stream's own object number rather than
for the objects inside. The stream's /Length counts what the cipher
adds. Only the structure elements and the ID tree put strings in a
stream, so only those two builders ask getStringEncryptor for one, and
it returns nothing while the file uses object streams.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Ia6a063244baf456d7c7368a6bba7a8cbb96e31b0
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13370
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 59193295323917bd065ea3a235f7653ad7f9b04b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211655
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
if wrapping the case insto a block, Xcode 16 is happy.
Solves building on macOS 14 that is stuck with Xcode 16 (at least
when not trying to sideload anything newer)
Without the block it fails with "error: expected expression" on the
variable declaration lines.
Change-Id: I0888fc5d2d6088f6071a72cde0c26532779cedad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211633
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
* Update helpcontent2 from branch 'master'
to 5c387d491750bbc4e5c3ddef61eb94002959a0c2
- tdf#173756 Link to converting text to numbers
+ Refactor
Change-Id: Ib797d40bf8573c5612d6317e608a4737894da711
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/211539
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
I messed up in
commit e174028ce0335d702ecdad5eac823845a16e2f6d
Author: Noel Grandin <noelgrandin@collabora.com>
Date: Mon Sep 21 18:13:44 2026 +0200
Rename paragraph related types in EditTextObject.
This is not the primary paragraph data structure for
EditEngine.
Add some commentary to reduce the chance of anyone
else making this mistake.
Rename typedef
EditEngineParagraphs -> EditTextObjectParagraphs
Rename class
EditEngineParagraph -> EditTextObjectParagraph
Change-Id: I810571cb61b944dd9d056145fe4cef14ba3e43bb
Signed-off-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13273
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit e8dde7d988a1768b68380ab95ba8fabb5feefc2e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211653
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
With Tagged PDF on, a paragraph in a language other than the document's
gets /Lang on its structure element. What is anchored in the paragraph
is tagged inside that same element and inherits the attribute, so a
frame's text and its description would be declared the paragraph's
language.
0d2d9e656d87647f904f1a463ed9b879c2bfb10c (tdf#163272 sw: give a
paragraph its own /Lang, 2026-09-21) avoided that by putting no /Lang on
such a paragraph, on a check of one node of a text frame that can cover
several. Its text still carried the language, on a Span, while what was
anchored in it specified none and inherited the document's. In a German
document that declared a shape's English text German. See
https://gerrit.collaboraoffice.com/c/online/+/13117/comment/89a7866d_907a2957/
The paragraph specifies its own language now, and a frame anchored in it
no longer inherits it. A Figure, a Formula and a frame's Division
specify the document's where the paragraph's differs, which is what the
frame's own paragraphs are measured against. A drawing shape's text is
tagged by drawinglayer, which takes the locale of the drawn portions and
specifies it where they agree; such a shape is nested in its anchor
paragraph in Writer and in no such paragraph elsewhere, so there is
nothing to compare against.
A drawing shape's own element specifies the document's language too. svx
anchors it under the anchor paragraph, drawinglayer opens it there, and
it carries the shape's title and description. Without the attribute, a
described shape in a paragraph that specifies one would have its
description declared the paragraph's language, and its text likewise
where the portions disagree.
testParagraphLanguage compared a structure type against a language and
quoted no text, so nothing identified the words affected. It lists every
element holding text or a description now, against the language it
specifies, an entry reading "P de-DE: Ein deutscher Absatz mit einem
Bild."; one specifying none is listed without a language, so correct
inheritance is asserted too. PDFiumPageObject gained getMarkedContentID
to join a page object's text to its element.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I1eecf0b56f09fc6d144894910a9037d89884dd3b
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13239
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 898a2e1b3a6fc07d7b43315b2f4781b32f1a20d3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211609
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Because losing compound boundary information in the new versions of the
Dutch Hunspell dictionary, add German test documents and unit tests for
compound-based "smart" hyphenation, testing also the Hunspell-based
morphological analysis, which was improved for the languages with
fogemorphemes in commit e668dc84eb.
Also remove the unnecessary dependency of the compound-based "smart"
hyphenation, i.e. Hunspell-based morphological analysis of the test
words from the Dutch and Hungarian *non-compound-based* unit tests.
This enables the plain "smart" hyphenation tests for all versions of
the Dutch and Hungarian Hunspell dictionaries.
The German unit test improves the hyphenation in the following three
lines:
* Unter|drückung: Un-terdrückung -> Unter-drückung
* Gleich|berechtigung: Gleichberech-tigung -> Gleichberechti-gung
* Sklaven|handel: Sklavenhan-del -> Sklaven-handel
(where the word "Sklave" has got an "n" fogemorpheme).
These 3 lines are 10% of the hyphenated lines, while the German
dictionary still lacks of compound boundary data for all the dictionary
words, only compound splitting heuristics of Hunspell is used here, yet.
Note: The Dutch tests became outdated temporarily because
of the recent version of the Dutch dictionary, where the test
compound words moved into the .dic file, but without compound
boundary information.
Unit testing uses system-installed German spelling and hyphenation
dictionaries. E.g. installation of the missing dictionaries:
sudo apt-get install hunspell-de-de-frami
sudo apt-get install hyphen-de
Follow-up to commit commit f9f694f5d9
"tdf#173389 sw: add compound-based “smart” hyphenation for readability"
and commit e668dc84eb "tdf#173389 cui
offapi sw xmloff: add custom compound-based hyphenation".
Change-Id: I1c1fb28d6c0299a284951adc96b77d3205db5f4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211642
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Using 0xf10d0c ("Dark Red 1") for Spelling brings a contrast of 4.8
and 4.37:1 against white and dark respectively. 0x3465a4 ("Dark Blue 1")
for Grammar results in 5.92 / 3.54.
Change-Id: I8347c2dd68e25aea33f7f2476f6b6d2db370ee7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211616
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Sonoma (macOS 14) builds with Xcode 15.2 can't find locale_t when
building fontconfig. Later OS versions and Xcode builds don't seem
to have that problem.
In file included from fcarch.c:24:
./fcint.h:682:9: error: unknown type name 'locale_t'
typedef locale_t FcLocale;
^
Fontconfig added "#include <xlocale.h>" recently in c24472116 to
fix the issue, but also switched to the Meson build system which
is the only mechanism by which HAVE_XLOCALE_H gets defined. Given
that LibreOffice uses fontconfig's old configure-based system and
it's a bunch of work to switch to meson here, we're not going to
bump fontconfig just for this. For now just assume all Apple
platforms have xlocale.h, which they do.
Change-Id: Ida9ef328dbd79e0c54b3d37355c344d7ca8d1b4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211630
Tested-by: Jenkins
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
* Update helpcontent2 from branch 'master'
to 5ca01b66114919efccfccb77f006e8744b6d79fe
- More fixes in Alignment and number formats
Change-Id: I5549b8167e169eecd6de1112f1d2fa6db4e7091f
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/211629
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Tested-by: Jenkins
Add an intermediate OAccessible subclass to avoid this
linker error otherwise seen in my local --with-visual-studio=2022
build on Windows:
icomphelper.lib(comphelper.dll) : error LNK2005: "public: virtual class com::sun::star::uno::Any __cdecl cppu::ImplInheritanceHelper<class comphelper::OAccessible,class com::sun::star::accessibility::XAccessibleSelection>::queryInterface(class com::sun::star::uno::Type const &)" (?queryInterface@?$ImplInheritanceHelper@VOAccessible@comphelper@@VXAccessibleSelection@accessibility@star@sun@com@@@cppu@@UEAA?AVAny@uno@star@sun@com@@AEBVType@4567@@Z) already defined in GraphCtlAccessibleContext.o
icomphelper.lib(comphelper.dll) : error LNK2005: "public: virtual void __cdecl cppu::ImplInheritanceHelper<class comphelper::OAccessible,class com::sun::star::accessibility::XAccessibleSelection>::acquire(void)" (?acquire@?$ImplInheritanceHelper@VOAccessible@comphelper@@VXAccessibleSelection@accessibility@star@sun@com@@@cppu@@UEAAXXZ) already defined in GraphCtlAccessibleContext.o
icomphelper.lib(comphelper.dll) : error LNK2005: "public: virtual void __cdecl cppu::ImplInheritanceHelper<class comphelper::OAccessible,class com::sun::star::accessibility::XAccessibleSelection>::release(void)" (?release@?$ImplInheritanceHelper@VOAccessible@comphelper@@VXAccessibleSelection@accessibility@star@sun@com@@@cppu@@UEAAXXZ) already defined in GraphCtlAccessibleContext.o
icomphelper.lib(comphelper.dll) : error LNK2005: "public: virtual class com::sun::star::uno::Sequence<class com::sun::star::uno::Type> __cdecl cppu::ImplInheritanceHelper<class comphelper::OAccessible,class com::sun::star::accessibility::XAccessibleSelection>::getTypes(void)" (?getTypes@?$ImplInheritanceHelper@VOAccessible@comphelper@@VXAccessibleSelection@accessibility@star@sun@com@@@cppu@@UEAA?AV?$Sequence@VType@uno@star@sun@com@@@uno@star@sun@com@@XZ) already defined in GraphCtlAccessibleContext.o
Creating library C:/Users/mwegh/development/git/libreoffice/workdir/LinkTarget/Library/isvx.lib and object C:/Users/mwegh/development/git/libreoffice/workdir/LinkTarget/Library/isvx.exp
C:\Users\mwegh\development\git\libreoffice\instdir\program\svxlo.dll : fatal error LNK1169: one or more multiply defined symbols found
This is somewhat similar to
commit f5667d1e3b
Date: Thu Jun 26 18:25:31 2025 +0500
Fix error LNK2005 in MSVC after recent sd changes
Change-Id: I8f01ea095d0a196c61521f92ea9ec76217941aeb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211618
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
That UNO service was dropped in
commit bcd90334e8
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Sep 2 10:31:59 2026 +0200
[API CHANGE] a11y: Drop com.sun.star.accessibility.AccessibleContext
, so don't claim to implement it.
Change-Id: I8c569f1db4c05228ba18a2d8e20b96b8712764f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211617
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
There is a bug where, an impress comment does not close when clicking outside of it.
More precisely, the comment does close, but is immediately opened again.
(Qt/gen)specific bug, not reproducible with GTK
The issue is caused by the handling of NotifyEventType::MOUSEBUTTONDOWN: it triggers
FloatingWindow::EndPopupMode(). However, when NotifyEventType::MOUSEBUTTONUP
is received, the call chain eventually reaches FuSelection::MouseButtonUp(),
which accesses an SdrObject from the SdrMarkList (GetMarkedObjectList()).
At that point, the list still contains the popup that is supposed to
be opened, so the comment gets opened again.
Change-Id: Ieb5691812009059d2100976932c34876cca5bc4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211275
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
focus out reason fix for qt/kf
The bug causing the comment’s context
menu to disappear is caused by a focusOutEvent() being received by the
widget when the context menu is opened. This triggers closePopup(),
which immediately closes the menu.
The fix adds the condition if (e->reason() !=
Qt::FocusReason::PopupFocusReason) so that the popup is not closed when
the focus loss is caused by opening popup.
if (m_rFrame.isPopup() ... ) condition in QtWidget::mousePressEvent
removed, because it can never be reached.
Change-Id: I70a0e9a3051f305f242c3ec7ca08f356d4520ab6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211273
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Earlier commit
commit 6296615b8d
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Sep 29 14:20:18 2026 +0200
tdf#173695 svx: Ensure minimum height for ColorWindow
had ensured a minimum height of 200 pixels for the ColorIconView
in ColorWindow.
As discussed in tdf#173695, increase the minimum height
to 250 pixels which should be sufficient to show all rows of the
"Standard" color palette even if different styles/themes
(when using an actual toolkit like GTK or QT) may result
in slightly different spacing.
Quoting explanation from tdf#173695 comment 5 of why at least 10 rows
should be shown:
> The "Standard" palette does not merely contain 12 hues arranged in 12
> columns; it also uses 9 rows to provide 9 different shades for each hue.
> (The topmost row contains 12 achromatic colours with different
> brightness values, making 10 rows in total.)
>
> If this were a user-created palette, this might not matter. However,
> since the palettes provided as official presets have a
> two-dimensional structure, I think that preserving that structure
> requires at least the 12 columns × 10 rows that were available
> previously.
Change-Id: Iafee178ceab6ccbbf6d880fa45cd90e3fd81be9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211601
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Turning Tagged PDF on added 2.4 MB to the reporter's document, 2.0 MB of that
its structure tree: 12562 elements, each its own top-level object,
uncompressed, and each costing a further 20 bytes in the cross-reference
table.
The elements go into /Type/ObjStm streams of 200 now, with the parent and ID
trees. The cross-reference has to become a /Type/XRef stream with them,
because a table cannot address an object inside another object. PDF 1.5
introduced both, so a PDF/A-1b file keeps the plain form. So does an encrypted
file, since a string in an object stream shall not be separately encrypted,
and this writer encrypts strings as it builds the object. So does a hybrid
file, because sdext reads the embedded original document out of a trailer.
The reporter's document exported 3157118 bytes tagged before the change and
1086230 after, against 769448 untagged either way. An 8300-row Writer table
exported 4017140 bytes tagged before and 500967 after, against 73183 untagged.
testTdf159066 and testTdf173162 grep the exported bytes for something the
structure tree carries, /Alt< and the /Namespaces array. They inflate the
object streams first now. testListLabelPDFExport counted its List element in
the token stream, and asks GetObjects() for it.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I1e27dc3a8f43aa8b6c75ae930615c8d4b4645627
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13209
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit ad4bb8ae080aba98080dfaabd688dfdb48cf7ade)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211556
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
When a paragraph had a tracked format change before the selection,
formatting another author's tracked format change and rejecting the new
change kept the other author's formatting.
Since commit ee3171adb2 (tdf#143918 sw:
fix reject of multiple changes, 2021-08-19), lcl_SetRedline looked for
an existing redline over the range, and continued while
"pRStt <= rRg.Start()", which compared the addresses of the two
positions, not the positions themselves.
Compare the positions, and go on while the redline does not start after
the end of the range, because since commit
b5d0868ef42135beb0329ecb9302ce48b08fa2a8 (cool#15941 sw interdependent
redlines: fix creating a fmt on top of ins-then-fmt, 2026-06-17) a
redline inside the range counts as well.
For some reason, the added unit test fails without the fix only on
Windows; on Linux on my system, it passes without the fix.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I396567d8507e800fefcdc643a63ee6ad91b8b8ee
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13802
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 2da0c4fa2e5284b25f0dca85243a1f8ef5e9506b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211602
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
An equation's size lives in the w:sz of its math runs. The import ignored it,
so every equation came in at the 12pt default of the formula editor, and a file
holding equations at three sizes showed all three the same. An equation whose
runs name no size takes the size of the text around it, which the styles and
the document defaults hold.
The export wrote no size at all. It now puts the size on every math run, and in
the control properties of each object, which is where the fraction bar, the
radical sign and the brackets take theirs from. The size travels in the w
namespace, so it goes out for a DOCX only, the way the color of a formula
already does.
Every formula now carries a size of its own on the way out, including one
written in ODF. Such a formula used to leave the size open and took whatever
the text around it had in the reading application. It now keeps the size it is
drawn at here, so both applications show it the same.
Setting the base size means giving each of the fonts that same size. The font
size dialog, the BaseFontHeight property of the model and this import each did
that on their own, so they now share SmFormat::SetBaseSizeAndFonts. The
property used to put the sizes in a copy that a later merge step reads only for
a font the same call has named, so a lone BaseFontHeight left the fonts alone.
Signed-off-by: Gülşah Köse <gulsah.kose@collabora.com>
Change-Id: I18b6c5814a57d8ccb8be5b7bdd357ce76cea024d
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13297
Reviewed-by: Balázs Varga <balazs.varga@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 582e3fdb6496d9f511dfefc1f716b4ead6cc3797)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211600
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Previously, when setting HELP_DEBUG=1, the tooltips lacked the label
(description) for the commands in extended tip mode.
The problem was that, if the extended help content was empty, then the
ToolBox::RequestHelp() function added appropriate description. But, with
the help debug mode on, the tooltip was no longer empty. It containted
seperator "-------------" and the UNO command.
This patch adds the description when the extra help content is empty and
solves the issue. The result contains mnemonic characters like ~ which
can be suitable for debugging. These characters are removed with the
call to MnemonicGenerator::EraseAllMnemonicChars in ToolBox::RequestHelp
in a normal LibreOffice session without setting HELP_DEBUG.
Keyboard shortcuts are displayed in normal mode, but not in the extended
tips mode. This issue can be later fixed by adding the keyboard shortcut
to the tooltips when HELP_DEBUG=1 is set.
Change-Id: Iead828ece855fa3e712919ef62353dbca9db1d52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211577
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Justin Luth