Apache OpenOffice (AOO) Bugzilla – Issue 71782
new chart: roles in stock chart are wrong
Last modified: 2013-02-24 21:21:37 UTC
Create a stock chart as described in the help of StarOffice5.2 (OOo and newer StarOffice don't offer a guide). I'll attach a copy of that help text (German) and spreatsheets, which are build following that guide. On the right side I inserted pictures, how the charts look in SO52 and in OOo2.1. The German terms mean: Eröffnung - Open, Schluss - Close, Höchst - High, Tiefst - Low. Now open the documents in the new chart modul and click the left chart to edit it. Open "Data Range", tab "Data Series". You can see, that the roles of High and Low are exchanged.
Created attachment 40774 [details] stock chart guide in SO52
Created attachment 40775 [details] document gnerated with 2.1(m2)
Created attachment 40776 [details] generated with SO5.2
@BM: Indeed, the High and Low Values are changed.
->regina: Thanks for this detailed error report. The order in the help of StarOffice 5.2 is High, Low. In MS Excel 2003 it is also High, Low. Unfortunately in the old UNO API it is Low, High. (http://api.openoffice.org/docs/common/ref/com/sun/star/chart/StockDiagram.html). I think the latter made us use this order in the new chart. We maybe should change the order back.
I checked the ODF 1.0 Standard. There is a sentence describing the stock-chart in section 10.2 (pg. 367). There the order is also Low, High! I think we should stick to the ODF standard. ->regina: It looks like apart from the role names that disturb you, there is no visual difference. Is that right? Or do you have any problems with old documents apart from the role-names in the dialogs (the source-range dialog and the data dialog for charts with own data)?
->bm: At the moment I see no visual difference in the range-line. It seems to me, that the algorithm for drawing the range line does not depend on the property, which is low and which is high. Because the odf description has the order "opening, minimum, maximum and closing" OOo should use this order for new charts. But the question remains, what to do with import from old chart module or from Excel. This has two aspects, user and programming. Up to now the user doesn't notice that there is a difference between guide and API, because he doesn't see any role name. Will he now be confused, if he edit old charts or Excel charts? I don't know. Assigning it in the old guide order, when importing such chart, is perhaps saver. Concerning programming it would make a difference, if the algortihm uses the property of being low or high, like always drawing from the high series point down to the low series point, which would be broken, when they are exchanged. Now it works right too, if the series are exchanges, but in future? Perhaps a comment in the source code would prevent problems.
The Excel import works, i.e. low and high values in Excel are correctly assigned to the corresponding roles. Copying such a chart from Calc to Impress also shows the correct assignment in the data dialog. The import of old XML files (OOo XML, like .sxc and ODF, like .ods) should work, as the specification for those old files said the order is low, high. So, on import we must assume that this is the correct order in the file. As we do not have any versioning for old files, we cannot find out if the file was exported correctly or not. We have to say here: the files are "corrupt" (in a quite harmless way, though), which is a pity, but I see no other solution to fix old files. (We have a versioning now, but no version does not automatically mean "old file", it could also be a correct file from a different creator like KOffice) We could only fix the import of binary files (SO 5.2), but I think the effort is not worth the effect here.
Fixed, also the order in the data editor dialog for charts with own data is correct now. The order of the ranges might be displayed in a different order in the Data Series tab of the data range, but the role association is correct now.
changed target to 2.3
Please verify in chart2mst3 Milestone 10_3
Changed to TASK, as this is not a regression over the old implementation.
verified
This Issue is 'Verified' and not updated in 1yr+, so Closing. A Closed Issue is a Happy Issue (TM). Regards, Andrew Cleaning-up and Closing old Issues as part of: ~ The Grand Bug Squash, pre v3 ~