Issue 112072 - Gaps in xy chart of large data set from imported xls
Summary: Gaps in xy chart of large data set from imported xls
Status: CONFIRMED
Alias: None
Product: General
Classification: Code
Component: chart (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-03 12:47 UTC by stephan66
Modified: 2013-09-25 20:42 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
xy graph from xls after loading (22.74 KB, image/png)
2010-06-03 12:48 UTC, stephan66
no flags Details
xy graph from xls after redraw in DEV300m80 (no gaps in blue data series) (20.86 KB, image/png)
2010-06-03 12:49 UTC, stephan66
no flags Details
example showing the problem (1008.50 KB, application/vnd.ms-excel)
2010-06-09 11:12 UTC, IngridvdM
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description stephan66 2010-06-03 12:47:08 UTC
After importing a xls spreadsheet containing several xy charts of large data
sets (ca. 12000 datapoints per range) all charts contain gaps in the first data
series.

In OOO320m21 (x86-64, openSuSE 11.2, from openSuSE stable build service) these
gaps are permanent. No action make the gaps disappear.

In DEV300m80, when editing the chart (i.e. changing the plot options to include
data from hidden cells) these gaps disappear permanently. The gaps are not in
hidden cells, and most likely these actions just force Calc to redraw of the
meta-file, correcting the problem.

Saving this file to .ods and opening it again in either OOO320m21 or DEV300m80
will result in charts without gaps. Any editing in OOO320m21 will make the gaps
re-appear.

OOO320m21 clearly has problems drawing these charts correctly, but m80 can
(after some "prodding"). Could you please make it do so during the xls import
too, before version 3.3 comes out?
Comment 1 stephan66 2010-06-03 12:48:30 UTC
Created attachment 69779 [details]
xy graph from xls after loading
Comment 2 stephan66 2010-06-03 12:49:47 UTC
Created attachment 69780 [details]
xy graph from xls after redraw in DEV300m80 (no gaps in blue data series)
Comment 3 IngridvdM 2010-06-04 16:30:32 UTC
@stephan66, please attach an example document. Without the document its hard to
say whats going wrong here.
Comment 4 stephan66 2010-06-04 21:29:51 UTC
My test document is > 7 MB (large data set...), and it contains data that I
can't post on a public issue tracker. Next week I will ask for permission at the
office to send it to you directly.
Comment 5 IngridvdM 2010-06-09 11:09:59 UTC
Thanks Stephan! I received the document and was able to identify the problem. So
I could  create an abstract example document.
Comment 6 IngridvdM 2010-06-09 11:12:18 UTC
Created attachment 69884 [details]
example showing the problem
Comment 7 IngridvdM 2010-06-09 11:27:51 UTC
The problem is caused by too many points in a polygon.
When loading the example in a non pro version assertions pop up:
"Polygon::Polygon: Too many points in given B2DPolygon, need to reduce hard to
maximum of tools Polygon (!)".
The number of points is that high because smooth lines is on. This causes cubic
splines to be calculated which produce much much more points than was given by
spreadsheet data.
@stephan66, a quick workaround for you would be to not use the scatter chart
type with smoothed lines but instead use straight lines. This should speed up
working with the document also.

Comment 8 IngridvdM 2010-06-09 11:43:39 UTC
I created issue 112245 to address the problem in the general rendering code and
keep this issue to work on possible reduction of points on chart side.
Comment 9 Armin Le Grand 2010-06-09 13:48:24 UTC
AW->IHA: The problem would trigger much later when it would be possible to
express these cubic splines as bezier curves; the example shows that a polygon
from ca. 4000 points gets smoothed to one with ca. 80000 points, a factor of 20.
With beziers and 2 control points per real point this could be reduced to a
factor of three (ca. 12000 points). This would also give better performance and
better quality e.g. with printing or Metafile export. This will not solve
#i112245#, but be a useful enhancement here.

Wasn't there a mathematical usable relationship between cubic splines as bezier
curves which may be usable here..? E.g.,
http://comp.newsgroups.archived.at/graphics.algorithms/200612/0612015596.html
looks promising. HTH!