It appears that the ownerIdx attribute of <cx:series> is used to indicate
that series share data. At least that seems to be the case with pareto
charts, which have both a clustered column and a pareto line series. Going
on that assumption, implement parsing/export of ownerIdx, and don't write
a dataId tag when ownerIdx is present. That fixes round-tripping of
pareto charts, at least based on what I've seen.
Signed-off-by: Kurt Nordback <kurt.nordback@collabora.com>
Change-Id: Ie948d2e5992b778462e34e1ef90681631c867332
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5900
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 8c37a25ffb7711f69de978045b4e3dc8d52759da)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209240
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
The word “outline” in LibreOffice can refer to either the lines of the
shape of something or an overview of something. When the string is quite
short it’s difficult for translators to know which meaning is intended.
There seems to be quite a lot of cases where the translators have got
this wrong. In order to help them this patch adds translator comments to
a bunch of the strings to explain which meaning should be used.
Change-Id: I4b75cc829128633bc9382817fc574d55a09af8a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209037
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
to fix
- Expected: 3819
- Actual : 3820
- Delta : 1e-08
- Reference: /Users/jtrzebiatowski/programowanie/libreoffice/lode/dev/core/chart2/qa/extras/xshape/data/reference/tdf90839-1.xml
- Node: /XShapes/XShape[2]/XShapes/XShape[3]/XShapes/XShape[1]/XShapes/XShape[2]/XShapes/XShape/XShapes/XShape/XShapes/XShape[5]/pointSequence[1]/point[10]
- Attr: positionY
on Apple ARM64
it started to fail with
after
commit 4c395887a3
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Tue Jan 20 09:57:34 2026 +0200
improve shape dumping
Similar to
commit ccce752f42
Author: Stephan Bergmann <sbergman@redhat.com>
Date: Fri Dec 10 16:15:06 2021 +0100
Allow for presumably more precise results of some layout calculations
Change-Id: I3ad4a9aca68f1fe0b552d5f363d7301322132fc2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208868
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The dialog can be triggered like this:
* start Calc
* "Insert" -> "Chart..."
* for "Choose a Chart Type", choose "Line"
* for "Line type", select "Stepped"
* press the "Properties..." button
Change-Id: I0bbef11445f7cf184e46b955dd32fcd8fbb474f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208548
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Set the mnemonic widget, which e.g. makes the Orca screen
reader announce what the combo box is about ("Line Type")
when it receives focus with the gtk3 or qt6 vcl plugins on Linux.
For qt6 and the use of native Qt widgets
(SAL_VCL_QT_USE_WELDED_WIDGETS=1) this also fixes
that the labels text was previously shown as a literal
"Line &Type".
Change-Id: I2e699a10bdec27663b38a92d4091e647a6b7c49e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208497
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The dialog can be triggered like this:
* start Calc
* "Insert" -> "Chart..."
* for "Choose a Chart Type", choose "Line"
* for "Line type", select "Smooth"
* press the "Properties..." button
Change-Id: I4bad77d57fb6f33dea653ad48f6dd0e32a8085c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208495
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
RangeSelectionListenerParent::enableRangeChoosing both sets the
dialog's visibility and modality. So far, it was first setting
the modality and then the visibility.
However, changing the modality while the dialog is shown
doesn't work as expected when using the qt6 vcl plugin
with native Qt widgets with upcoming commit
Change-Id: I53cbd9061ef473deba2124f17976f24b11c1712a
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jul 22 17:27:01 2026 +0200
tdf#130857 qt weld: Support chart "Data Ranges" dialog
in place and would result in an inability to select the
data area as the main window would remain insensitive/disabled
for the following case:
* start Calc
* "Insert" -> "Chart"
* confirm with "Finish"
* with chart still selected, press the context menu key
(or click with right mouse button) to open the context menu
* select the "Data Ranges..." context menu entry
* in the "Data Range" tab, press the "Select data range" button
* try to click into the document and drag to make a selection
The native Qt implementation wouldn't require changing
modality back and forth, but gtk3 and the gen vcl plugin
would show the same problem as described above when not
setting the dialog to non-modal in the case it gets hidden.
Make all of them work by setting the modality, but always
doing that while the dialog is hidden (not shown), i.e.
either before showing it or after hiding it.
Change-Id: Ia368a919c497d51c4560536995e90f60e3b85768
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208493
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This is used for the "Data Series" tab page of the
the dialog that can be triggered like this:
* start Calc
* "Insert" -> "Chart"
* confirm with "Finish"
* with chart still selected, press the context menu key
(or click with right mouse button) to open the context menu
* select the "Data Ranges..." context menu entry
Change-Id: I15ebfe1eac3a83f5e0a2ee03d0548c8bc0e499f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208487
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This is used for the "Data Range" tab page of the
the dialog that can be triggered like this:
* start Calc
* "Insert" -> "Chart"
* confirm with "Finish"
* with chart still selected, press the context menu key
(or click with right mouse button) to open the context menu
* select the "Data Ranges..." context menu entry
Change-Id: Ia5f78fdf141eeb0e35cfe5dab990d73e991fe885
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208486
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The dialog can be triggered like this:
* start Calc
* "Insert" -> "Chart"
* confirm with "Finish"
* with chart still selected, press the context menu key
(or click with right mouse button) to open the context menu
* select the "Data Ranges..." context menu entry
Change-Id: I339bbd6d64344eeb33449fc829f06fe9041e0282
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208485
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When a chart shows a data table, it is drawn as a strip at the bottom of
the diagram, so the plot-area-plus-axes rectangle grows to include it. The
vertical axis title was centered on that rectangle and thus ended up shifted
downwards compared to MS Office, which centers it on the plot area alone.
Center the left- and right-aligned axis titles on the plot area rectangle
(which already excludes the data table) instead of on the plot area plus
axes, so the title stays centered on the axis.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: If21ba0938cea16abc382e686b9c4e2b84caf2dca
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6978
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 48953636f24d522426d5f5e4ed9f0fc5ec6f30f5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208241
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Switch the weld::Entry and weld::TextView handlers
that are called when the text changes due to user
interaction to pass a weld::TextWidget& param
instead of a weld::Entry& and weld::TextView&
one respectively.
Adjust related methods across the code base accordingly.
This unifies the behavior for both of these
weld::TextWidget subclasses and prepares for
deduplicating the logic and moving it to the
common base class in an upcoming commit.
That will also ensure they stay in sync.
(Change also motivated by the fact that their behavior was
differing before
Change-Id: I03d2a13cd84d53d806eb9e363f49c4b6be28d938
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jul 9 13:08:58 2026 +0200
tdf#130857 weld: Don't signal about programmatic TextView text change
.)
Change-Id: I5572fc88caf577fae9a23a39f1ec4f2179935a99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207936
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Read underflow and overflow attributes from the histogram chart
type properties.
Export the same properties back to <cx:binning> so chart roundtrip
preserves optional edge bins.
Signed-off-by: Devansh Varshney <varshney.devansh614@gmail.com>
Change-Id: I963febac4987da23dce2571928982973f7ea67d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207153
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Add model properties for optional underflow and overflow bins on
histogram chart types, and expose them through the HistogramDiagram
wrapper.
Pass the new settings through the existing histogram pipeline:
HistogramChartType snapshots the properties, HistogramDataSequence keeps
that snapshot, and HistogramCalculator creates optional edge bins around
the normal bin range.
Generated category labels now distinguish special bins from normal ranges,
e.g. "<= 11", "(11-13]", and "> 14".
Add a model-level test that sets fixed bin width together with underflow
and overflow bins, then verifies that the generated bin labels are rebuilt
correctly.
Signed-off-by: Devansh Varshney <varshney.devansh614@gmail.com>
Change-Id: I65eac9607daa4f4be6320304c9e9682549f479a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207151
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
HistogramDataSequence snapshots the histogram binning
settings when the calculated-y and category sequences
are created. Rebuild those sequences when BinWidth,
BinCount, or FrequencyType changes, so fixed-bin settings
take effect immediately.
For XLSX import, use the regenerated histogram series
categories as the X axis categories. Keeping the existing
axis categories can preserve stale bin labels, e.g. after
reloading a chart exported with cx:binCount.
Extend the histogram roundtrip test to verify that fixed
bin count creates the expected bin labels after ODF
and XLSX reload.
Signed-off-by: Devansh Varshney <varshney.devansh614@gmail.com>
Change-Id: I718bbfe537d847de6c17ea7742a9c4d231b57b7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207007
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
The ODF chart export (SchXMLExport::exportTable) and import
(SchXMLTableContext) both read/write "DisableDataTableDialog" on the
chart document, but the wrapper only exposed the inverse
"EnableDataTableDialog". Every access fell through to the
"found no inner property set to map to" warning in WrappedPropertySet
and the table-protected state was silently dropped.
Register "DisableDataTableDialog" as a WrappedIgnoreProperty, matching
the existing treatment of EnableDataTableDialog. Behavior is unchanged
(the flag was already being discarded) but the spurious warnings on
chart save are gone.
Change-Id: I93be0d19872ebbe68994dd88a190c4bf85ef5a78
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1449
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
(cherry picked from commit 27ccb0ce32081549f14f51166a4459a8828acd47)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207071
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
After
commit e052641d460d8111d3333705aea03ad24822ebbb
Author: Michael Stahl <michael.stahl@collabora.com>
Date: Thu Apr 16 14:55:25 2026 +0200
xmloff,package,xmlsecurity,oox: add Collabora extension namespace
For both ODF and OOXML export, add a new "coext" namespace.
New features saved in Collabora Office will not work in LibreOffice
Also add a test for it
Change-Id: I5626dbcf5e87e06ef94e33d1ce09a091c1557688
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206987
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Add multi-chart histogram fixtures for ODF and XLSX, each containing three
histograms backed by separate source ranges.
The ODS-to-XLSX export test verifies that each exported ChartEx histogram
writes its own direct values-y range. This covers the failure mode where
multiple histograms could all point to the same _xlchart.v1.0 formula.
The XLSX roundtrip test verifies the same source-range separation for
native ChartEx histogram documents.
Signed-off-by: Devansh Varshney <varshney.devansh614@gmail.com>
Change-Id: Iaa0d8cf69ee1879cd389b2fe1c6697d723440c5b
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4100
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 992a4edb821c97bf7132306c414b47c69e22111c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206715
Tested-by: Jenkins
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
ODF round-trip: assert the series carries a categories sequence
with the expected bin range labels after reload. Without the late
histogram template re-application, that sequence is missing.
XLSX round-trip: assert the X axis Categories hold the bin range
labels. Without the axis converter preserving them, they get
replaced with generic "1", "2", ... labels.
Add testHistogramODSToXLSXExport: the exported chartEx1.xml must
carry a real cell range in the numDim formula, not an
_xlchart.v1.N alias with no matching definedName in workbook.xml.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ic01880ca40cc84fa83fe305fabd3dbfb796164e2
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3704
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit f037c36b5b14d69ef7e766e2cf6eab3bb0e87973)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206338
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when one class changes.
By now, only weld::Button is left in weld.hxx.
Rename the header to Button.hxx.
Drop weld.hxx includes and instead add Button.hxx
includes (or weld::Button forward declarations) where
weld::Button is used.
(Don't simply replace all weld.hxx includes with
Button.hxx ones, since many of them were for the
use of other widgets that have since been moved
to their own headers.)
Add further includes where needed now that the
(direct or transitive) includes of weld.hxx were removed.
Change-Id: I8ea6201446a418d5e38b46337059dcd517ee29d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205937
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses,
as well as a few helpers.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when anything in weld.hxx
changes.
Move the weld::toId and weld::fromId helpers from
weld.hxx to weldutils.hxx, in preparation of getting
rid of weld.hxx altogether in an upcomcing commit.
Change-Id: I408fe20a74ff104cbfe07bde3105317a1922ff61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205936
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This makes it easier to keep an overview and reduces
what needs to be recompiled if the class changes in
the future.
Change-Id: Ie8d0aad9bca3e990f78d4ffc006a04b0a8086fd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205935
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Add missing includes/forward declarations in places
previously depending on transitive includes that
are now dropped.
Change-Id: I3215b358e0fa45ffce08756218c386e1a4d7ebc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205928
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
These are not needed inside weld.hxx itself. Instead
add the required includes/forward-declarations to those
files actually needing them, instead of relying on the
now dropped ones.
Change-Id: I5e4cea030867d14057b2bdcc2a2a4cd98843651d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205906
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I34876c5bef75e30e758029b0fe5afeecc92d509d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205903
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class definition and implementation out of weld.hxx
and weldutils.cxx into its own header and source file, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I97768bf75dac492e32e1d387853d123481aa643a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205902
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Adjust includes in files that were implicitly depending
on transitive includes that are no longer present because
the more specific include/weld/Container.hxx is included
further down now instead of include/weld/weld.hxx.
Change-Id: I04e6bb72ce446b746dfdf88b45c7df9d0ccda473
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205899
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins