Age | Commit message (Collapse) | Author |
|
In order to indicate the entire row or column
(for the benefit of a spreadsheet program that may eventually
increase the supported number of rows or columns it supports)
a short-handed form of the range can be used
like "B:B" for the entire column,
or "1:10" for the first 10 rows of all columns.
Shorthand is nicer for humans
and allows for future expansion of row/column space
This reverts 24.8 commit a29d91ac403f1ed431ca95b8b9c290bd354c3ae7
xlsx export: never export short-hand version of range address
which reduced the likelihood that we will ever see
such a range, because Excel seems to always
write out the full address.
However, the shorthand version is definitely valid for Excel.
Earlier patchsets checked that the new method and the old method
returned the same values for all existing unit tests.
Change-Id: I7677dfc207771a32222095416f728f7cd34a4f75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166570
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
After the change of tdf#139858 the comments checkbox was not remembered anymore after closing the dialog. In order to fix this issue, additionally check not only the NOTE flag but also for the ADDNOTES one.
Change-Id: I8b24d231313b57a05b7e527c0865686762e5a2b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166762
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Tested-by: Jenkins
|
|
I had done these a while ago, when I looked into extending loplugin:ostr to do
more automatic rewriting, and these were places where I needed to do something
manually, for one reason or another, because the automatic rewriting would not
pick it up correctly.
However, I got distracted, and a wholesale automatic rewrite would still run
into cases where an _ostr/_ustr instance from a library's .rodata would still be
referenced after the library has already been dlcose'd. So I never came around
to finishing all that.
But there appears to be renewed interest in (automatic) rewritings here now, so
it probably makes sense if I share this part of my work anyway.
Change-Id: I3da9d38398e4bca373cb0000a9d34b49a36ad58a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166792
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
|
|
Add new function called SEQUENCE to the function list.
(TODO: dynamic array in separate patch, oasis proposal)
Change-Id: I9fa6f2c83536536987542cc00a9eec5c196ada8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166245
Tested-by: Jenkins
Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
The trouble was that even if commit
b13c7b31f9ce3c3a25cffd0c35e7ee6b8c2a1895 (cool#8789 sc lok: fix copy for
multi-selections, 2024-04-19) made multi-selection copy work, just 2
cells in a multi-selection was classified as a complex selection at a
LOK level, while 2 cells next to each other is a simple selection, which
is inconsistent. (A LOK client can provide a simpler UI for simple
selections.)
What happens is that the multi-selection clipboard document had no
selection ranges defined, so ScDocument::GetClipArea() returned early,
so the numbers in the ScTransferObj ctor were left initialized, which at
the end lead to a >1000 cells in ScTransferObj::isComplex(), because we
were calculating uninitialized data.
Fix the problem by passing a range (that covers all ranges of the
multi-selection) to ScViewFunc::CopyToTransferable(), which avoids the
wrong col/row start/length, so the selection is classified as simple.
Also adapt testRowColumnSelections, which was just meant to check we
don't crash, but now the cell under the cell cursor is returned, so the
assert about the empty selection would fail.
Change-Id: If98212c623fa75adb2ddf628a6e90f3eef450e59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166581
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
even if no content was changed after pasting special. Otherwise, the undo functionality crashes due to undoing a cell with no content where the annotation indicator will remain (unod/redo of note captions are handled via drawing undo).
Change-Id: I7007fce510d6e9896cbda11a1e14a61b5ccb34a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166469
Tested-by: Jenkins
Reviewed-by: Stéphane Guillou <stephane.guillou@libreoffice.org>
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
If all the columns are in focus, LO was exporting
A10:XFD11 as 10:11.
Amazingly, we can't read that. Seriously?
Doesn't Microsoft ever export in shorthand?
I thought it would be helpful to find any instances
where LO is exporting shorthand, to verify that
we really do break import of round-tripped files.
I made a brief attempt at fixing the import,
but it will require lots of changes
and break lots of assumptions.
Obviously it can't be a hugely common problem
because I didn't find any bug reports about it...
I abandoned my attempt because it is too prone to disaster.
Change-Id: If59c316d0af466e5cf71ecc459bdf57bb2cd5144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166269
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The problem is with conditional formatting using icon set, as the icons order is fixed.
It is solved by using comboBoxes for condition mode in ScIconSetFrmtDataEntry for every icon, and adjusting the UI file.
A function that compares according to the currnt mode is added.
Related CppunitTest files are updated.
For every cell, last valid condition is applied.
Change-Id: I489206d349a46092b307203c180705f42883183d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165701
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
This adds support for selecting whole rows/columns, where the field
reference is set but no indices are present. This means that all
the data cells apply (selecting the whole thing), which are not
subtotals. For this the support for multiple matching and maybe
matching results was added (previously max 1 would apply), which
would apply the pattern to multiple cells in the pivot table.
In addition handle labels of columns with multiple data fields
correctly.
This also adds many more test scenarios, which all cover the
changes mentioned above.
Change-Id: Ibcdaa933c69991eaa55a2ad18b9f9a838308d478
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166384
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I2532bae611bc815b270187dc6b9a07b47837962d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166383
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
And introduce GetTextWidth / GetTextHeight variants returning double.
It allows to avoid premature rounding.
At least in one case - testTdf145111_anchor_in_Fontwork - it allowed
to make the test DPI-independent (at least in my testing on Windows,
using 125, 150, and 175% UI scaling).
Change-Id: I973d2c729ec6bb7114b4f99b9027f1ead7c1d061
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166237
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Select A1+A3 in Calc, copy, try to paste in B1, nothing happens.
This is because lok::Document::getSelectionTypeAndText() for a Calc
document ends up in ScViewFunc::CopyToTransferable(), which only handles
the SC_MARK_SIMPLE* cases.
Fix the problem by implementing support for SC_MARK_MULTI, similar to
what ScCellShell::ExecuteEdit() does in the SID_COPY case, which also
calls CopyToClip().
Keep the test highlevel as the Calc shell doesn't seem to have an easy
function to do the same as the Ctrl-click on a cell without duplicating
lots of code in the testcase.
Change-Id: I641d9db95ca391a4f39d96aeeb33422129262288
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166279
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Make XLOOKUP function able to search for empty cells.
Change-Id: Iefa71b938fe658a59d52e0bf605dbef7a62742c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166263
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
Fix was added with [1][2] and this adds the tests to make sure
this keeps working in the future.
[1] 1d5630c5deeec5dca724c29ec8c886bfa71a2099
[2] https://gerrit.libreoffice.org/c/core/+/166138
Change-Id: I0a7e62ee6139cc5334c03e7022ce49306d578e1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166149
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This adds support for multiple cell format reference indices, so
the same cell format is applied to multiple cells (defined by
indices) so that each doesn't need to be defined by its own
reference (as they are all the same anyway and only differ by
single index).
The solution is to create multiple format outputs for one format
entry - each for a selection index, but have other data still the
same. This is a bit tricky as previously it was one format output
for one format entry, which is not the case anymore.
Change-Id: I074ac03e7d81e26562a6a6cc395b11cfed16766d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166131
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
The patch improves the pivot table cell format matching with the
output data, so we check if there is a complete match or a partial
match. A partial match is when we found one match for a field, but
other fields are not set, and if this partial match is found in
exactly 1 line of output data, then we treat it as a complete match.
This also refactors the code so there is code no duplication for
column and row matching code - they work in the same way, just
in a different orientation.
This also adds checking of empty cells to the tests, so we can
make sure there is no other cell in the pivot table that got the
pivot table cell format applied to. A new test case was also added
to the test class.
Change-Id: I102ec8e33bc7a3f26bc898568ee0e33abe08bd27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166086
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This change adds the "formats" element tree export for a pivot
table. The source are the formats (sc::PivotTableFormats) added to
the pivot table - in the ScDPSaveData class. This are currently set
on import but in the future hopefully those are also set through
the UI.
Change-Id: I5ed8f7e8d7ac248b0222a884fb97555ef6bb8427
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166035
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I1cbc299e7e64eae48f0f6c896a8160bbe6e19c97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165938
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This adds the PivotTableFormatOutput, which main responsibility
is to resolve the reference for which the pivot table format is
set to. It first prepares the format data into such a structure
that it is easier to match with the pivot table fields and data.
Then the pivot table data is filled during the output, where we
remember the cell positions of the pivot table output. The last
step is to resolve the pivot table format references with the
filled data, where the cell formats are applied to the output.
PivotTableFormatsImportExport was added to test the correctnes of
the functionality.
Change-Id: Ie67ea15b3aa74739f15937800d03d256b8f68277
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165992
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Double refs with operators only trimmable in case of one root paramater.
Follow up of: ba0ec4a5d2b025b675410cd18890d1cca3bc5a2f
Change-Id: If61fb39696d9539ffc9d32a6ecad79bfa1bf92e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165957
Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
|
|
Seems to be not used since 2016 commit
52871b360c73efd59bfbc811b8b89a02b6375b29
Change-Id: Ie1f95ece6d9b6efe93dd16adcdacd644deb21fdb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165914
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
|
|
we moved to not forcing a redraw on switching tabs
at:
commit 9f3ee2b27ceeab175fb865a55cfeabd66fbb128d
Date: Sun Jan 14 16:29:56 2024 +0000
don't invalidate when switching tabs
but in a scenario (to which two_sheets.ods is updated to capture) where
there is no view/user active on a sheet B that depends on cells in sheet
A, then when A is updated, B does not update automatically to reflect
the changes in A.
So, on switching to a tab, do the check for out of date formulas on
the switched to tab.
Change-Id: Ibbba83119adbd323b42314dbd9bcba6f797e5934
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165911
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I03478dd4c8e3c2ac88c0fe5e51efd53b09888475
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165695
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
|
|
Prior to this patch, all named ranges/expressions associated with solver models were visible by default, which clutters the UI with various names in the Manage Names dialog.
Now all such named ranges/expressions are hidden by default, thus mimicking what MSO does.
Change-Id: I79727b375c48527632c4967d174c61f99ff41050
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165621
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
The position and size of a group needs to be temporarily changed when
saving because ODF does not treat hidden rows/cols as zero, but LO does.
After saving, these changes have to be undone. The error was that the
restore was performed with GetGeoDate/SetGeoData. But SetGeoData
includes a broadcast that triggeres recalculations that should not be
performed here. Now the change and restore are both done with NbcMove
and NbcResize.
The import had set a 'logical rectangle', but that is nonsense for a
group, because a group does not have a 'logical rectangle'.
For a group, none of the special corrections in
ScDrawLayer::InitializeCellAnchoredObj are needed.
Change-Id: I00adf39e83011112492822d2900e41242d188e84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165872
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Change-Id: Ie8451b3d30e390d363d8f9e5ec8bdf47350ca3a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164936
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
In case of cell formulas which have a string result, we need to
get the value from the formula result, for sorting/comparing.
folow up of commit: 45435a680be065e44eba385bb2523b27b77fb451
Change-Id: I30502dfb013ef78de0e5f2f9d5151cfc60e46942
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165816
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
'sc' module was cleaned.
Change-Id: Ia491d741a4c1c5314f35ebb4baa82dd516948ae7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165699
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
|
|
Since bug 154449 was fixed, Calc now supports hidden named ranges. However, named expressions were not considered in the original patch and it would be useful to support hidden named expressions as well.
This patch adds suppport for hidden named expressions (import and export).
Change-Id: I2580416dcd5db0fcb2aa9061085cdc9975fb03c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165239
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
to reproduce the underlying problem: data, calc, recalculate hard:
which asserts that cell I367 is dirty during parallel calc
checking the dependencies for a parallel calc is supposed to find what
cells it depends on and either: ensure they are not dirty or detect its
not possible to do the parallel calc
checking starts in J9 where::
J9: =SUM(H$8:H9)-SUM(I9:I$9)
J10 =SUM(H$8:H10)-SUM(I10:I$9)
for the first sum it detects that the input range is H9:H367 and checks
that for dirty results, but for the second sum it detects a range of
just I9 and the dirty I367 is not detected and the problem arises on
calculation
The code to detect the range is:
// The first row that will be referenced through the doubleref.
SCROW nFirstRefRow = bIsRef1RowRel ? aAbs.aStart.Row() + mnStartOffset : aAbs.aStart.Row();
// The last row that will be referenced through the doubleref.
SCROW nLastRefRow = bIsRef2RowRel ? aAbs.aEnd.Row() + mnEndOffset : aAbs.aEnd.Row();
where for the I9 case has nFirstRefRow true and nLastRefRow false so we
just get a range of I9:I9 instead of I9:I367.
Trying to create a doc from scratch to reproduce this case proves
tricky, so trim down the original document to the sheet and subset
of columns that can trigger it.
Change-Id: I44bfd1f6d3a3ee13db9024c5b2efa2588cc30521
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165510
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
This is the same problem as described in:
commit 22a185a977f90d706c3e9d182adeaac310b6f348
Date: Thu Jan 11 15:08:21 2024 +0900
sc lok: set the GridWindow size to the client area size + test
except that the size of the GridWindow gets reset by UpdateFormulas
via UpdateHeaderWidth to the width of the "frame" which is remains
at the nominal 800x600 initial size throughout.
That only happens if there are enough rows in the document to trigger
a check against this, so add some extra content into the test document
to trigger the problem, and then guard against this reset for the kit
case.
Change-Id: Ibf80849929a4c987fd0fe977518336e5115ebdce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165240
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: Ic8a88e112f413a9ec0a77e3be5d8a586312cfe0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165301
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
TODO/WIP: oasis proposal
More information about how this new function works:
https://support.microsoft.com/en-au/office/sortby-function-cd2d7a62-1b93-435c-b561-d6a35134f28f
https://exceljet.net/functions/sortby-function
Change-Id: I4538a32f7f75056d3055369fc5f4483d24fd1089
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165069
Tested-by: Jenkins
Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
TODO/WIP: oasis proposal
More information about how this new function works:
https://support.microsoft.com/en-au/office/sort-function-22f63bd0-ccc8-492f-953d-c20e8e44b86c
https://exceljet.net/functions/sort-function
Note: Move ScSortInfoArray class to sortparam.hxx, which is a more
logical place.
Change-Id: I70e720e93ba0414d54cb3437de0bfa066508fe30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164778
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
and for the duration of Threaded calculation where there will be
no new formats required we can drive number formatting with the
unlocked RO policy.
Change-Id: Ic0e449acdcf834bc569d13b4a984f13c55316801
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165160
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
operators which need to be checked if they are next to a trimmable
DoubleRef arguments or not.
Example:
=SUMPRODUCT(($D:$D>M47:M47)*($D:$D<M48:M48)*($I:$I=N$41)) -->
$D:$D and $I:$I columns are trimmable.
Recalculation of formulas with a lot of SUMPRODUCT where we comparing
full columns could take minutes during editing a sheet. With reducing
the size of the compared ranges to the actual data could significantly
speed up the recalculation.
This takes the recalculation time from ~50 sec to <1 sec on my machine.
Note: probabaly the same could be applied to the SUM function.
Change-Id: I758660d0b638ef7255bd5a41a96755289b5a2b41
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165074
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
Change-Id: I1bef38a21179bb725c7fb7a08fe90309d26239ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164616
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
'sc' module was cleaned.
Change-Id: I072dcc0bfb8395b88cba18f212aa23f8edf0d32a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164793
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
|
|
Conversion of hex/dec colour notation
(example entry Color( 255, 255, 255), Color(0xFFFFFF) - COL_WHITE)
For the other available colour definitions.
Change-Id: I9eed0cd64adcbc8d25e1c22143a000906a457586
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163729
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
During export from Calc to XLS, ensure that the print range
is converted to a valid XLS print range. If the print range
exceeds XLS format limitations, it will be appropriately cropped
to fit within the constraints.
Change-Id: I2b233e4d57dfbe30f491448d2ee2972b8b717ea3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164469
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
Conversion of only one colour, Color(0, 0, 0), Color(0x000000) - COL_BLACK
Change-Id: I4ba2412929522532d32304734b0269c70d75e5ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163460
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
When solver models are imported from XLSX, ranges come with sheet names even when they belong to the same sheet, which clutter the solver dialog.
This patch checks when this happens and remove sheet names when the solver model is imported.
Change-Id: I3994f1312667946aab330c734ff820e94673d018
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164610
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I948190b31f45cf05ba24d1fbc4a84dfe91eb3876
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164557
Tested-by: Jenkins
Reviewed-by: Nagy Tibor <tibor.nagy.extern@allotropia.de>
|
|
Change-Id: I30e452534e09aa349a85f0862ed09291506203dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164654
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I91d5f4572edff99deb21dd2507c3216ef0d9e4c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164465
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
To be used in a follow-up commit
Change-Id: Ie6c74ebb0f91ec24e6ed3ec973bc47685cd9e91f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164452
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
When bug tdf#38948 was originally fixed, the solvers DEPS and SCO were not considered. This caused a regression, because setting engine options for these solvers made them never be saved, even in its own sheet.
This patch fixes that by incorporating the engine options for DEPS and SCO.
Change-Id: I93af712f91da2f7b1ac57ed74f6c2c2d7d411bba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164376
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ic9460d36ef1df18a05126bc06a5214c1d87317db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164331
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
When a formula cell gets copied from Calc to google docs, only the
formula result was copied, not the formula.
There is a data-sheets-formula attribute on <td> that can describe the
formula we have.
Fix the problem by extending ScHTMLExport::WriteCell() to emit that.
This is more or less the export equivalent of commit
7812adb2ed11a3e08be24d3f2f94d14bfd740c55 (tdf#159483 sc HTML paste:
handle data-sheets-formula attribute, 2024-02-12).
Change-Id: Iab373ce8a028deb6a2874a8c690e928edf5d79f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164363
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
..whether a page anchored object is contained in the to be copied area.
Change-Id: I816e342770332e6d751b57a38e5ebabe33feb16a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164307
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|