see on loading forums/xlsx/forum-mso-en4-748529.xlsx and doing a
hard recalculation, which aborts with:
soffice.bin: sc/inc/formulacell.hxx:514: void ScFormulaCell::MaybeInterpret():
Assertion `!rDocument.IsThreadedGroupCalcInProgress()' failed.
#4 ScFormulaCell::MaybeInterpret at sc/inc/formulacell.hxx:514
#5 ScFormulaCell::IsEmpty at sc/source/core/data/formulacell.cxx:3153
#6 FillMatrixHandler::operator() at sc/source/core/data/column2.cxx:2636
#7 sc::ParseBlock at sc/inc/mtvfunctions.hxx:66
#8 ScColumn::FillMatrix at sc/source/core/data/column2.cxx:2708
#9 ScTable::FillMatrix at sc/source/core/data/table1.cxx:2700
#10 ScDocument::FillMatrix at sc/source/core/data/documen8.cxx:400
#11 ScInterpreter::CreateMatrixFromDoubleRef at sc/source/core/tool/interpr5.cxx:386
#12 ScInterpreter::ScSpilledRange at sc/source/core/tool/interpr1.cxx:1703
#13 ScInterpreter::DispatchOpCode at sc/source/core/tool/interpr4.cxx:3868
#14 ScInterpreter::Interpret at sc/source/core/tool/interpr4.cxx:4414
#15 ScFormulaCell::InterpretTail at sc/source/core/data/formulacell.cxx:2209
#16 ScColumn::CalculateInThread at sc/source/core/data/column2.cxx:3270
#17 ScTable::CalculateInColumnInThread at sc/source/core/data/table1.cxx:2740
#18 ScDocument::CalculateInColumnInThread at sc/source/core/data/documen8.cxx:421
#19 Executor::doWork at sc/source/core/data/formulacell.cxx:5463
ScSpilledRange calculates cells itself. It calls MaybeInterpret on the
master cell of the dynamic array, and CreateMatrixFromDoubleRef then
covers the whole spill range, so FillMatrix asks every cell in that
range whether it is empty and IsEmpty calculates it. A worker thread
inside a threaded group calculation must not calculate a cell.
The dependency evaluator can't cover it either, only the operand's own
cell is named by a reference token and how far the spill reaches is
known only once that cell has been calculated
an issue since:
commit 9b97b0fc91bce4b8726ea210347e8ea84270e148
Date: Mon Jul 6 13:09:39 2026 +0000
sc: add the # postfix operator for spilled-range references
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: Id58e88d1bd927576e4723dd23bc119673feed108
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/11285
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 89af05e8a5e8ce4ae337e2f0048f670940573930)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210542
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
As Eike indicated in https://bugs.documentfoundation.org/show_bug.cgi?id=146404#c4
COLOR format codes are preserved in ods/fods format.
The pb was the missing map back.
Indeed, we had the mapping for [COLOR<something>] => Color value (eg: "ffaa16")
but not the reverse mapping Color value => [COLOR<something>]
Eike had provided the right code pointer in xmlnumfi.cxx.
First, I thought using PaletteManager but this one is in svx and svx shouldn't be used in xmloff
(dependency pb).
Then I used ChatGpt (GPT-5.6 Luna) and it pointed the right process.
It just consisted to use a similar callback system (DECL_LINK, IMPL_LINK, LINK) of GetUserDefinedColor.
In addition, by testing all this, I noticed that maList in XColorList::GetIndexOfColor was empty.
So I added the Load call in case mbListDirty is true.
Change-Id: I0ef6b5901f2e4c757e88994412dbf79a13100ffd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210518
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
This fixes a 24.2 regression from Khalid's commit 4b743de97f.
The problem I'm trying to fix is that setting optimal column width
is not necessarily providing enough width to avoid seeing '###'.
The reason is that GetOptimalColumnWidth calls GetTextWidth
with MapMode disabled, so no subpixel calculations were done.
However LayoutString does have MapMode enabled,
so it calculates a different length than what optimal column got.
Surely that must always be wrong. But Khalid's similarly more-correct
commit triggered a lot of 'regressions'. However, this should be
moving in the right direction as tdf#168002 suggests
that mbSubpixelPosition should always be true in the future.
Since it is needed for width, it seems reasonable that it should
also be done for height...
Change-Id: I30590ebba8b3027c5214ee075a1a258d3a61b8c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210438
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
* Recognize LAMBDA during dynamic array analysis; LAMBDA
never produces an array, but it can be part of a formula
that generates one.
* Fix handling of LET; subexpressions before the last should
not affect the result, unless we are willing to to a more
thorough analysis.
* Update test to check for the new behavior.
* Account for svExternalDoubleRef.
Change-Id: Ia9a4761079de986906ac70252066d8d9b4655f59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210461
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A table's totals row exported even when the table had no header, or
when its only content was a plain number wrongly declared as a text
label. Excel rejected both cases and repaired the file on open.
Only export a totals row when the table has a header and a column
actually shows a real label or total. Otherwise leave the row as
plain data, matching what Excel itself does when it repairs such a
file.
Signed-off-by: Samuel Mehrbrodt <samuel.mehrbrodt@collabora.com>
Change-Id: I6dc84680780805d8cfe666d681a62a9a907605d2
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10367
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit cfb01061aec26a218dcd1e4b5cccad395d2a5489)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210453
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The compiler decides whether a blank is the intersection operator by
looking at the tokens on either side. Both parenthesis tokens have the
separator type, which those checks read as "not a reference", so
=SUM((A1:B1,A2:B2) A1:A2) didn't parse even though it should intersect
the list with the range. The parentheses are now accepted by their
opcode, and so is a reference list built from a converted separator on
either side.
The blank also keeps the parenthesis after it a group. An operand
followed by a parenthesis normally opens an argument list for a
callable, but with the intersection blank in between there is no call,
so ocCall is not injected. A name in front still calls either way.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I8e4b5fb7136419b4e937c8abb521711a8d418af8
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10162
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit b12a7af0e1aab942aa5014b799a96271d03c472f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210305
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A symbol like F25:IF lexes as a single range reference because IF is
also a valid column name, and then it doesn't name a valid range. The
whole symbol was kept as an unknown name, so =SUM(F25:IF(TRUE,F26))
gave #NAME? instead of summing up to the cell the call returns.
When such a symbol is followed by an opening parenthesis the lexer now
backs up to the range operator and reads it again (a symbol that isn't
a reference at all is already handled elsewhere). The reference then
stands on its own and the call after the operator is read separately.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I709de89206008894b1a07b482ac1ca5457ab059d
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10161
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit cc8e9277c510bb8f95d11a37e326a68bd8bca513)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210304
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A reference list is built from the separator between two parts of a
parenthesised expression, and which parts join was decided from the
opcodes at the top of their compiled code. That was wrong both ways:
INDEX returns a reference but wasn't counted, so (INDEX(A1:A3,1),B1)
fell apart, while (F25, F26%) didn't parse at all even though it
should give #VALUE!.
The left part now has to end in a reference or an opcode that returns
one, INDEX among them. The right part joins if it starts with one, or
with a nested list, IF, CHOOSE, a lookup, the @ operator or an error
constant. What it then makes of that reference is the calculation's
business.
A part starting with anything else leaves the separator a separator
and the formula doesn't parse, which is what the producing
application refuses at its formula bar too.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: If65d2f0f9cc599729564cfc5369c0479b07c93e8
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10160
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 50ddf65b640a9cb88aea56be4367a3e44152c230)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210303
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A reference list holds several ranges, so there is no single value an
operator could work on. GetDouble and GetString had no case for it and
fell through to their parameter error, so =(A1,B1)% and =(A1,B1)&"x"
came out as Err:504 instead of #VALUE!. They report #VALUE! now. A
function that takes the list itself, like SUM, still reads it whole.
The union operator gave the generic Err:502 when one of its parts was
a value instead of a reference, as in =(A1~5). That reports #VALUE!
now too.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I8da8a30a691f2b939d04af7f1abd58e586cd5b7f
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10159
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 2cd6e380f8aec3b691dc15ade6798191b8d64d89)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210302
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A # spilled range travels as a matrix that carries the range it was
read from, so a plain cell can reduce it to the value of the row it
lines up with. Every operator dropped that range on the way through
GetMatrix and PushMatrix, so =A1#% on a master spilling 1, 2 and 3
came out as 0.01 instead of the row-aligned 0.02.
The range is now noted when a matrix operand that carries one is
popped, and put back on a result of the same shape - those are the
only way in and out. The note only lasts for one token, and two
operands with different ranges cancel it. Functions don't get it,
because something like SORT is free to move the values around.
The values of such a result are the operator's own, not the cells'.
So ScMatrixRangeToken now answers the two questions separately: the
range says where the values sit, and a second flag says whether the
values are still the ones the cells hold.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ie4851dcc208f20220f07cd75a691aee88cfdc5ac
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10158
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit a393976584be143df7cb40623f31322e46889756)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210301
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The # operator refers to the master cell before it. ScSpilledRange
took its operand with PopSingleRef, which turns anything that isn't a
single reference into a parameter error, so a # after a range or a
reference list came out as Err:504 instead of #REF!. Anything covering
more than one cell has no master, so it now reports #REF! too, same as
an empty cell or a non-master already did.
An array formula has to give the same single #REF!. The operand's
parameter class wasn't declared, so in an array context the range
operand got turned into a matrix and the operator ran once per cell -
a dynamic-array master then spilled the error matrix or gave #SPILL!.
Declaring the operand as a reference makes the operator take the range
as a whole.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I196f67b644035fbbf87b08c605a5dd2719831ba0
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10157
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 54382bfb0bf025ee4839a6f6d86a07123e893400)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210294
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The # postfix operator was parsed at the same level as the percent
sign, which is looser than the prefix operators. Because of this
=@A1# compiled to the spill range of an implicit intersection and
=-A1# to the spill range of a negated value. Neither of those means
anything, and OOXML writes the # around the reference alone in both
cases.
The # is now parsed right after the factor it follows, tighter than any
operator that can come before it. A whole range reference goes inside,
because the lexer reads A1:A3 as a single reference. The percent sign
stays above the reference operators, so =A1%# leaves the # with nothing
to bind to and doesn't parse, and the export drops such a # (OOXML has
no spelling for it either).
A blank between two operands is only the intersection operator if both
sides yield a reference. The # does, so the checks that keep the blank
alive and that keep the operator once the operands are known had to be
told about it.
The interpreter passes the spill range on as a matrix that carries the
range it was read from. The intersection, range and union operators
only took references and refused that, so PopReferenceOperand now
hands them the carried range as a double reference.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I1a587bf291ff639b326a366b8efc332106eb5fd3
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10156
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit c589c34aaec00d60fc47f1933762b105f9d22de3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210293
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Before, it generally wasn't saving ANYTHING
because rMark is normally not marked,
and even if it is, it could be random.
The only time rMark means anything is if rSearchItem.GetSelection().
But even that doesn't help because the undo has no idea of range.
ScUndoReplace::Undo attempts to undo the entire document,
so definitely more than bOnlyMarked needs to be included.
In fact, even sheets that don't even have a match
need to be backed up. Entirely.
This seriously needs to be looked at by a Calc Pro
who could optimize this by passing rMatchedRanges
to ScUndoReplace. And only CopyToDocument a RangeList.
But of course, there is also bMatchedRangesWereClamped...
which thankfully doesn't affect styles, only text.
Change-Id: I2087e255e3e4b3387b388e1f2d28c19717e50342
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210247
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
We have added various workarounds for ScPatternAttr use after free
issues since:
commit 2e1f9da8a6
Date: Sat Dec 23 15:52:06 2023 +0100
Decouple ScPatternAttr from SfxItemPool
separated ScPatternAttr from SfxItemPool.
Prior to that an ScPatternAttr was an SfxPoolItem held in the doc's
SfxItemPool which kept every item alive for the document's whole
lifetime, so any raw const ScPatternAttr* was basically safe.
The various workarounds for the new behaviour were:
commit dca19993a4c732e95b9a47e1abdcaad6efbeebe9
Date: Sat Jan 6 14:40:28 2024 +0100
tdf#159042: crash after changing cell style (if direct formatting done)
commit 19437715eb415fe2c40b8b40dbe04ddca28f9a35
Date: Thu Sep 12 12:06:28 2024 +0100
null pattern deref seen in ScViewData::SetEditEngine
commit e384f2e8de9603ee65a3edc6dcb50b07116ee4fc
Date: Mon Mar 10 14:45:22 2025 +0000
crashtesting: crash on reimport of xlsx output of forum-pl-2758.ods
commit 7999585bd8378f1a8d04ea2a9a93a8e0bf4d8eb6
Date: Fri May 9 08:50:17 2025 +0100
crash on null pattern de-ref
commit 1bf9bbea96
Date: Tue Oct 28 16:53:49 2025 +0300
tdf#169115: sc: fix use-after-free bug in ScDocument::FillInfo
commit 9f366af81478ad218dc2ef2e37423a9ebcc84e73
Date: Sat Apr 25 14:47:02 2026 +0200
ScPatternAttr use-after-free
commit 20fe691a18fb35120d0765dd1519acd6d2986c38
Date: Tue Apr 28 08:33:34 2026 +0200
ScPatternAttr use-after-free (2)
This commit picks the class member fields that are still raw
ScPatternAttr* and converts them to CellAttributeHolder:
ScUsedAreaIterator::pPattern and pFoundPattern
ScInputHandler::pLastPattern
LotAttrCol::ENTRY::pPattAttr
ScPatternCache::Entry::pPattern
The CalcAll() workaround from 9f366af81478 then doesn't seem to be needed(?)
A new compiler plugin catches class member fields of raw type
ScPatternAttr pointer.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: Ibb9f28b8fcaa5470c7a82eee52900c2d60434e41
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3163
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
(cherry picked from commit 9c7b6313a29067bf0eef12884fc3ce7efb0374e5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209822
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Pass over an omitted argument as a missing parameter instead of a
numeric zero, so that optional parameters, their default values and the
basic function IsMissing() behave accordingly.
Change-Id: I7c4a65dfb1791f8aa900cc9eddd3007422dc41a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209457
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Allocate and fill in the mpaMemberSlimArray.
In the eager init case, where everything is initially allocated
as Slim results, it uses less memory just to create a simple
linear array rather than storing a pointer for each one.
Fixup the promotion code to move between the arrays rather
than change the pointer in the MemberArray.
On tdf#126710 this saves ~11.5GB (maxresident)
tdf#100244 (full case) this saves about 6.3GB (max resident)
In tdf#126710's case, the 'virt' column in top appeared to save
even more; possibly due to large reallocations in the vector that's
been removed?
Change-Id: I7681304310e060da191edc1fb243900ce59193a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209101
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
Convert lcl_SearchMember to use a templated core since
we're soon going to have two different types to iterate over
(One of which is a pointer, the other an object, hence
needing to parameterise the get function as well).
Change-Id: I4df6a011015ca917f5ad015393ff0f65b2a32ca9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209099
Reviewed-by: David Gilbert <freedesktop@treblig.org>
Tested-by: Jenkins
Define mpaMemberSlimArray as a span of ScDPResultMemberSlim's,
we'll use this in future instead of the Vector that might
hold pointers to any subclass of ScDPResultMember.
Make GetMember and GetMemberCount reference it.
The actual allocation of the array comes later.
Change-Id: Id2abf23e72a92fee0dc3e4326370692a3567dafd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209098
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
Use GetMember() for most cases rather than directly
accessing the member array, since soon we'll have
two member arrays.
Change-Id: I76eca012af6743b29de1e53e96a2ff46187f8a8a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209097
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
Use GetMemberCount() rather than accessing maMemberArray.size()
directly in most cases, since we're going to have two different
arrays.
Change-Id: I35541b84e3e1704c9725491444b076c05197aa27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209096
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
The hand coded linear array search in FindMember can be replaced with
std::ranges::find_if.
Note: A few months ago I added a comment saying I thought the 'IsNamedItem' check
above wass probably always true - it turns out it's not - which causes the linear
array to be used!
(I can't say I understand the case IsNamedItem is false, here, it
triggers in the tdf#126710 test)
Change-Id: Ia87998f910d1bbf9f120d70acf096d17d4ce4211
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209095
Reviewed-by: David Gilbert <freedesktop@treblig.org>
Tested-by: Jenkins
The block frames of the pivot table output used a 1pt line inside
the table and a 2pt line on the outer edges of the table, and the
field cell frames used the 1pt line. Draw all of them with the
thin line width (0.75pt) instead, which is close to the line width
that the default OOXML pivot table style uses, so the whole table
uses one slim border.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Iec99b6890ffa5c8dfc699a30e2fc58d452e5d9ff
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8255
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 411cfdb91ee02a10361c3d72e13bd64161bba4d5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209432
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The pivot table output set pivot table specific cell styles on its
cells ("Pivot Table Value", "Pivot Table Result", ...) and created
them in the document on first use. Remove this, so adding a pivot
table no longer adds any cell styles.
The attributes that these styles carried are applied as direct
formatting instead. The member cells are aligned to the left, and
the subtotal and grand total labels and results are bold. The left
alignment is also what makes the member indents visible, an indent
has no effect in a centered cell. The style name mapping in
stylehelper.cxx stays, so documents that already contain these
styles keep working.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ib33d170d2da38a60c0739eda8fa79ce4f1fcf745
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8254
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit fee8a092ac3388c873d2b0763f7ce3d8cd032b76)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209431
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
The formatting of the pivot table output was spread across
ScDPOutput: cell styles and frames were applied inline while the
table content was written, and ScDPOutputImpl drew the block
frames.
Add sc::pivot::StyleOutput, which handles all the drawing. ScDPOutput
now only records the sections of the table (layout geometry, field
cells, member spans, subtotal and grand total rows and columns,
indents and expand or collapse buttons). The cell styles are applied
while the sections are recorded, at the same points where they were
applied before, so they always come before any direct formatting
(number formats, pivot table format attributes) reaches the cells.
The block frames, the indents and the expander buttons are then drawn
by apply() in one pass over the collected sections. The drawn output
stays the same as before, and a different look, like the OOXML pivot
table styles, can later be drawn from the same sections.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ia628de6badf511d299f36bf474194ecad17a9c56
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8253
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 9f5a36c822b170835c55143716be9eca28ac3e91)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209430
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Andrea Gelmini