Since BitmapEx was unified into a single premultiplied 32-bit BGRA
Bitmap, converting such a bitmap runs a per-pixel loop that builds a
BitmapColor and dispatches through the `GetPixelFromData` /
`SetPixelOnData`, (un)premultiplying one channel at a time.
Add a fast scanline path for the common case, a premultiplied 32-bit
truecolor bitmap (ABGR/ARGB/BGRA/RGBA). It resolves each channel's
byte offset once and then moves the scanline bytes directly, using the
premultiply / unpremultiply lookup tables.
Signed-off-by: Karthik <karthik.godha@collabora.com>
Change-Id: Ie8ee47055bdffca9e06d48955fdc0b61b34e08ac
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6752
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 54c68922eaa2d2c4e20e10091ad4911e8d32aed2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208641
Tested-by: Jenkins
there is one firebird engine per process and it reads its configuration once
from the directory we set up, so a .fdb the user picked somewhere else could
not be attached. firebird resolves a name in databases.conf before it treats
it as a path, so give the file a name there and pass firebird that name,
dropped again when the connection is disposed.
since:
commit 520d8173cef39a4da85b3ba21bdaaa3150384c25
Date: Sun Jul 12 12:10:41 2026 +0000
firebird: keep each embedded database's files in one directory
Change-Id: I4872a4e2165c4701bfb20be5dcd8c119b1723125
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/7990
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
(cherry picked from commit 6ab71a109bd8a8335208c9faa37a3cfa94523148)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208773
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
This change restores the system gallery theme ID to bullets.thm, which
restores language and localization-independent lookup in the gallery UI.
This field was unintentionally removed by a prior update to the file
contents. Updating these .thm files is unnecessarily fragile. There does
not appear to be any way to set an ID other than by using a hex editor,
and the ID field is only retained if updates are incremental. In order
to make this somewhat easier, this change also adds an --id <id>
parameter to gengal. This parameter can be used to manually set the
correct ID when a new .thm file is generated (however, it will not
change the ID for an existing .thm file that is being updated).
Regression from commit 480ef73dee
Author: Heiko Tietze <heiko.tietze@documentfoundation.org>
Date: Mon Oct 27 12:37:09 2025 +0100
Revert^2 "tdf#139076 update Bullet icons with sexy .svg icons"
Change-Id: Idccdffb987606a1863c745c96bc0f8ba5cb6565f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208701
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
When editing an SQL query in SQL view it is important to keep the
formating. To secure this this fix implements a warning dialogue that
fires in the case a query is last saved in SQL view and the user tries
to open it in Design view and when the user switches from SQL view to
Design view since editing in Design view may canonicalize and rewrite
the query thus destroying its formatting.
This is related to tdf#42713 that impements something similar but for
queries with comments. Note that after this fix the mechanism
implemented for tdf#42713 is only kept for backward compatibility and
could be removed in the future.
Change-Id: I47f46d8953dc4b1e7326413d6f97ca35eeaa3a22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208786
Reviewed-by: Vissarion Fisikopoulos <vfisikop@libreoffice.org>
Tested-by: Jenkins
- headers and footers implemented and formatted
- GroupOn for all values, i.e. Day, Week, Hour, etc.
- treat a group with no expression as a single implicit group
- skip empty group expressions when building the ORDER BY clause
- fix nested-group detection: an outer group's change now
always forces every inner group to break too, even when the
inner group's own value happens to coincide across the boundary
- add nestedGroupBoundary CppunitTest + nested_group_boundary.odb
Co-authored-by: Adam Seskunas <adamseskunas@gmail.com>
Change-Id: I52ae7e07f4fd9082348a4ae2987f779676132d01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208315
Tested-by: Jenkins
Reviewed-by: Vissarion Fisikopoulos <vfisikop@libreoffice.org>
- Environment variable is called
SAL_ENABLE_PENTAHO_FREE_REPORTBUILDER
- Change save path in ReportEngineJFree so that if
the env variable is false Pentaho is called, if
true the C++ ReportBuilder is called
Co-authored-by: Adam Seskunas <adamseskunas@gmail.com>
Change-Id: I154f40d15b2532aee48a2609f045bb3bea3b4fa8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207092
Tested-by: Jenkins
Reviewed-by: Vissarion Fisikopoulos <vfisikop@libreoffice.org>
- ReportDefinition add flag for save path along
with getter/setter
- ReportEngineJFree use flag to determine which filter
to use depending on whether a report is being saved
or executed
Co-authored-by: Adam Seskunas <adamseskunas@gmail.com>
Change-Id: Ie6d797e5ec11bba5ca4ab56db6bf1f2fcf063f9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207091
Reviewed-by: Vissarion Fisikopoulos <vfisikop@libreoffice.org>
Tested-by: Jenkins
-Subclass xmlExport in xmlExport2
-Pentaho needs to be bypassed in ReportEngineJFree
for functionality
-Set to use xmlExport2 filter
-add xmlExport2 to Library_rpt.mk
Co-authored-by: Adam Seskunas <adamseskunas@gmail.com>
Change-Id: Ia687217ee843f3ac0708d60ea83c55d9d35c30f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207090
Tested-by: Jenkins
Reviewed-by: Vissarion Fisikopoulos <vfisikop@libreoffice.org>
The problem is that when finding/applying an attribute,
an empty paragraph is counted twice.
In my previous patch, I only did the move
if the paragraph contained some content.
But the same problem exists for empty paragraphs.
The unit test was quite annoying,
until I discovered it was searching for the exact opposite
of what it was intending to look for.
make CppunitTest_sw_uiwriter7 CPPUNIT_TEST_NAME=testTdf131431
It still double-counts for the very last paragraph,
since it tries to move forward but can't.
WARNING:
This patch breaks the counting for finding attribs (without replace).
The reason for this is that SwFindParaAttr doesn't bMoveFirst
when bReplaceAttr is set.
So, it worked for 'Find-All', but not for 'Replace-All'.
However, Find and Find-All suffer from skipping the first empty para,
so that bMoveFirst is a bad thing really.
While developing the follow-up patches,
I discovered that after the end of a paragraph,
a text search checks in anchored editeng objects.
So we can't move when doing a text search!
I wonder what other disasters are lurking in wait for me...
Change-Id: I10a786bd18c7b9957a70ea68324660e3c84b9b03
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208681
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Justin Luth <jluth@mail.com>
This no more has any callers after
Change-Id: Idd749171019914d444c04a29c18f5fc3f8d55e34
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jul 29 18:11:56 2026 +0200
sd console: Drop always null PresenterViewFactory::mpResourceCache
More cleanup will follow in separate commits.
Change-Id: I2a547a8795ff646ca0be095cccebb9a20ae94614
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208808
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This unique_ptr is never set to anything non-null, so drop
it and related logic that would only be relevant if it
were ever been non-null.
This is similar to previous commit
Change-Id: Ic6784e716d54bbddfd9e184086218cfab8261954
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jul 29 18:07:34 2026 +0200
sd: Drop always null PresenterPaneFactory::mpResourceCache + logic
, but in a different class.
Change-Id: Idd749171019914d444c04a29c18f5fc3f8d55e34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208806
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This unique_ptr is never set to anything, so is always null.
Drop the member and all logic that would only be relevant
if it were ever non-null.
Change-Id: Ic6784e716d54bbddfd9e184086218cfab8261954
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208805
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reuse the logic moved to the base class in previous commit
Change-Id: Id50ad3b81c484323325ccb6457a1ce1d7489e8a9
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jul 29 11:15:22 2026 +0200
sd: Move PresenterPane::getCanvas impl to base class
to deduplicate code a bit.
Change-Id: I25a4b362d1d6128e74392ec9bbeca570b61e2430
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208779
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The implementation doesn't do anything specific to
the PresenterPane subclass. Move the logic to the
PresenterPaneBase base class instead, which will
also allow reusing the logic in
the other subclass, PresenterSpritePane in an upcoming
commit to deduplicate its own override.
Change-Id: Id50ad3b81c484323325ccb6457a1ce1d7489e8a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208778
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Both, PresenterPane and PresenterSpritePane implement the same
logic in their overrides for the abstract AbstractPane::getWindow
method.
Deduplicate by moving the implementation to their
shared PresenterPaneBase base class.
Change-Id: Id633fe3122c8fd2b2e6106d26b5da7d3ff566d73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208777
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Instead of returning an XWindow, the UNO abstraction
over a window, return the vcl::Window directly, to
be able to use the more concrete implementation classes
in the future.
Initially, just get the XWindow in all callers again for the
existing code to continue working as is,
but this could be adjusted in the future to further reduce the
use of UNO abstraction in the presenter console code.
Change-Id: I08a20fd3fc087b6b095c690aa271235426d4a676
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208776
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
While fixing unwanted escaping in code blocks, it was noticed that
in Markdown export, code spans were being emitted for preformatted text
paragraphs even though they appeared within a single code block.
Change-Id: Ifc538e14f5ad14a2c326b726a3036c623701a823
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207399
Reviewed-by: Hossein <hossein@libreoffice.org>
Tested-by: Jenkins
Tested-by: Hossein <hossein@libreoffice.org>
Merge the logic to retrieve the AquaSalInstance into the
OSX_RUNINMAIN_* macros instead of having another macro
that retrieves the AquaSalInstance and passes it to the
former macros.
Change-Id: I0dd5e5c1de814dd04e86ffc9f7fa66aa5b486086
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208168
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Port to use the existing equivalent OSX_SALDATA_RUNINMAIN{,_*}
macros instead, to consolidate/reduce the number of macros
for the same purpose.
Change-Id: Ia18b6431811da3dfa085b6135076310d355bce95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208167
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
ImplSVData already has a pointer to the SalInstance,
independent of the vcl plugin.
Don't store an additional one in the macOS specific
SalData, but reuse the existing one.
Introduce a GetAquaSalInstance() helper function
that returns the instance cast to AquaSalInstance
(similar to other helper functions used in other
vcl plugins).
Change-Id: I851711153fe287a882b8188e89ae54a1b810466b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208163
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Index retrieved corresponded to blue value, that's why:
-the right circle of the first line
-the two circles from left of the second line
-the second circle of the last line
were modified.
Change-Id: I57a5334ca11f5b987d4125c88810991f83d44d42
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208817
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
* Update helpcontent2 from branch 'master'
to eedd1ff1d4780b7741a9514f1d808226b1d57981
- tdf#172793 Help page fos Math matrix input dialog
+ Note : This page may be reviewed when the feature is ready.
Change-Id: Ib07079ce1ee3de9b75c32a9a408bc664d5e244ac
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/208795
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Since
commit 64510d3c8e
Date: Mon Feb 2 13:08:15 2026 +0100
rust_uno : Cargo.lock must be in the git repository
, Cargo.lock is under version control and no longer
generated during the build.
Therefore, also no longer delete it on
make rust_uno.clean
(Mentioned also as a problem by Christian Lohmaier
in the Gerrit change for the above commit, see [1].)
[1] https://gerrit.libreoffice.org/c/core/+/198541/comments/3ca5a9a2_4be61700
Change-Id: I6583e1ba246b8f73f12f0ee72d1b37eb6ba874f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208781
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
reproduce with a dbgutil build loading forum-mso-en-4208.docx
sw/source/core/crsr/bookmark.cxx:294
sw::mark::Fieldmark::IsCoveringPosition(this=0x0)
writerfilter field import calls InsertFieldmark, which splits the
paragraph. SwTextNode::CutImpl moves the text, which already carries
the CH_TXT_ATR_FIELDSTART/FIELDSEP/FIELDEND dummy characters, to the
destination node before the fieldmarks themselves are repositioned.
relocating a content-control nesting hint then runs sw::CalcBreaks
over the destination node. getFieldmarkAt finds no mark at the
FIELDSTART character and the assert at the FIELDSEP character
dereferences the null pushed for it.
keep pushing the possibly-null mark so start, separator and end stay
paired on the stack, and let the two asserts accept a null top entry.
The loop at the end over the still-open fields already handles a null
mark.
a similar guard existed since:
commit b3325ef8cd
Date: Sat Nov 6 16:40:17 2021 +0000
ofz40766 Null-dereference
until:
commit a7116b890c
Date: Tue Nov 16 14:28:15 2021 +0100
ofz#40766 svtools, sw: HTMLParser: really stop inserting control chars
removed it when the source of stray control characters was fixed
instead. Here the field characters are legitimate and only the mark
repositioning lags behind.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I9c7a33f5fac614645e420152c490765b53a7004c
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6714
Tested-by: Michael Stahl <michael.stahl@collabora.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
(cherry picked from commit 274d1402efe96b367be1cf0fdfe7edd3641c9df2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208770
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
A matrix formula cell holds the "top-left" result of its matrix in the
reference-counted xUpperLeft of ScMatrixFormulaCellToken.
CloneUpperLeftIfNecessary cloned that only for svDouble; other types
were kept by shared reference.
But threaded group calculation switches every token in the group's shared pCode
to RefCntPolicy::None while worker threads interpret it, on the basis that
interpreting only reads pCode, since:
commit 791a2489ee
Date: Sun Mar 24 21:31:38 2024 +0000
Related: tdf#160056 elide ref counting for initial tokens
A matrix formula whose result is a string constant from its own pCode
broke that: the pCode token was taken as the upper left during the None
window, so its IncRef was a no-op.
At teardown the matrix released it and freed a token the pCode array
still pointed at.
Where the uncounted reference is taken:
#1 boost::intrusive_ptr<formula::FormulaToken const>::operator=
boost/smart_ptr/intrusive_ptr.hpp:121
#2 ScMatrixFormulaCellToken::Assign sc/source/core/tool/token.cxx
#3 ScFormulaResult::SetToken sc/source/core/tool/formularesult.cxx:206
#4 ScFormulaResult::Assign sc/source/core/tool/formularesult.cxx:171
#5 ScFormulaCell::InterpretTail sc/source/core/data/formulacell.cxx:2476
#6 ScColumn::CalculateInThread sc/source/core/data/column2.cxx:3266
#7 ScTable::CalculateInColumnInThread sc/source/core/data/table1.cxx:2715
#8 ScDocument::CalculateInColumnInThread sc/source/core/data/documen8.cxx:420
#9 ...Executor::doWork() sc/source/core/data/formulacell.cxx:5437
#10 comphelper::ThreadTask::exec
Clone the upper left when it is svDouble (as before) or not reference counted
(RefCntPolicy::None). The clone is a counted token the cell owns, so no
reference into pCode is taken during the threaded window. The non-threaded
path is unchanged.
Also assert in HandleStuffAfterParallelCalculation that a matrix result's
upper left does not alias the cell's own pCode.
Found with an ASan+UBSan build reloading crashtest document
forum-mso-en4-676909.
The original motivating tdf#160056 benchmark document never visits this
clone branch, so that case remains unchanged.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: Ibd9e93aa9e59fabb99941a92a16aef247f7ae160
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5638
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
(cherry picked from commit 2a70b7a75ce8768e077ea42175e59465d3adba31)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208769
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A blank at the end of a line hangs outside the line by design, and the
justification of the line can leave it in the space that an object
reserved for its wrap: the text is stretched right up to the object, and
the blank starts where the reserved space begins. Its underline was then
drawn beside the object, which is no better than drawing it on the
margin.
The room such a blank was formatted against is measured before the line
is adjusted, so the check that keeps it inside the line cannot see this
coming, and the clamp that runs after the adjustment does not reach it:
the blank keeps no width of its own here, neither its own nor an extra
blank width, so there is nothing to compare a remaining room with.
Take the position instead, which is what the question really is: while
painting, the blank's own place in the line and the offset where the
object's reserved space starts are both known, so drop the decorations
of a blank that begins at or after that offset. A blank before an object
that still has room in front of it keeps them, as does one that Word
writes with its "underline trailing space" option on.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I1d23a77b7b6767e82eb64ad76335f06f57ebe193
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7881
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit f42c56ae45f98e5081825ac0329226a175b9ed12)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208757
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A hyperlink at the end of a line looked like its underline reached past
the word. The blank after it is not part of the link and carries no
underline of its own, so nothing should have been drawn under it.
The blanks that a line break leaves over go into a hole portion, and the
painter only picks up character attributes for the text, field and tab
groups, which a hole portion belongs to none of. It was therefore painted
with whatever font the portion in front of it had left behind, in this
case the underlined one of the link, and the blank showed decorations
that the document never gave it. Seek the attributes for a hole portion
as well, so it is drawn with the font of the blanks it holds.
The hole was always painted with the wrong font, but it used to make no
difference: 90a83191a4 (Resolves: #i68503#
a SwHolePortion must not be decorated, 2013-01-03) took the decorations
off the hole's font again before drawing it. Since
b36f181bb7 (tdf#168777: Trailing space must
show all decorations, also for ODF, 2025-10-11) the blank keeps them, and
the wrong font became visible.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Ie7cd9a5780dc449e12a2b4585c8f0b0c80e94235
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7877
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 84746ca8ab0725d55980a027e4c2744de47a8f94)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208756
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A blank at the end of a line ends up in a hole portion, and it can be
made in two places: SwTextPortion::Format_ splits off the blanks that no
longer fit the line, while SwTextPortion::FormatEOL peels off a blank
that did fit, which is what happens when text wraps around an object and
the line continues after it. Only the first one was taught to show the
blank's decorations, so the blank before such an object stayed bare while
Word underlines it. The test document, saved by Word with its
"underline trailing space" option on, shows both in one line: the blank
before the rectangle was not underlined, the ones at the end of the line
were.
The blank cannot end up decorated outside the space available to it. The
one Format_ makes is only decorated as far as it fits, and the one
FormatEOL makes was part of a portion that already fitted on the line, so
its room is there by construction. Checked against a rectangle moved past
the end of a line in steps of a fraction of a blank: decorations switch
off exactly when the remaining room drops below the blank's width.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I8f3ba57bbb8f00b30b9798cba1ac64270b87c197
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7866
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit b3d35b9d0f907b7b2446c8ae26a53c382919e43b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208755
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Caolán McNamara