Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Gaps in xy chart of large data set from imported xls|
|Component:||chart||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Version:||3.3.0 or older (OOo)|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
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!