Hi Eike,
thank you for looking at it.
Eike Rathke schrieb am 02-Apr-20 um 14:50:
Hi Regina,
On Tuesday, 2020-03-31 16:56:59 +0200, Regina Henschel wrote:
Does anyone know, whether there exists a scenario (besides sx* import
filter) where it makes a difference for LibreOffice, whether the attribute
exists or not?
Of the places that git grep -w XML_CELL_RANGE_ADDRESS lists there may
be one of interest
xmloff/source/chart/SchXMLImport.cxx
SchXMLImportHelper::GetPlotAreaAttrTokenMap() has
{ XML_NAMESPACE_TABLE, XML_CELL_RANGE_ADDRESS, XML_TOK_PA_CHART_ADDRESS },
XML_TOK_PA_CHART_ADDRESS is used in
xmloff/source/chart/SchXMLPlotAreaContext.cxx
SchXMLPlotAreaContext::StartElement() to set mrChartAddress and
m_rbHasRangeAtPlotArea = true (that both are references, so wherever
used outside..) and m_rbHasRangeAtPlotArea being true _may_ lead to an
internal data provider not being created as a last fallback further
down. >
I don't know of the consequences or how things are later used from there.
I have made some tests. I seems the "normal" charts are currently always
written with the needed chart:value-cell-range-address attribute of
<chart:series> element.
One problem are charts in reports. The report builder has severe
problems with charts that make testing impossible.
Another problem are pivot charts. But their use of
table:cell-range-address is faulty anyway. So a rework can use a
solution without it.
I have put all these into
https://bugs.documentfoundation.org/show_bug.cgi?id=131862
Kind regards
Regina
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
