Difference between revisions of "Chart2"
(→Open Technical Issues in the New Chart) |
(→Application-Framework-Related Problems) |
||
| Line 17: | Line 17: | ||
== Application-Framework-Related Problems == | == Application-Framework-Related Problems == | ||
| + | |||
| + | === Identify the XDataProvider reliably === | ||
| + | |||
| + | If the chart is embedded in a container document that provides the data for this chart, the chart contains range-strings at several places in its <tt>conten.xml</tt> stream that are understood by the container, so that the data can be located there. In Calc such a string would look like this: "Sheet1.A2:A7". Such range-strings can appear in the chart:plot-area element of a chart or at a chart:series, chart:categories or chart:domain element. | ||
| + | |||
| + | If a chart has its own data, this data is stored in a local table in the XML-file. The mentioned range-strings are then of a similar form, with the fixed table-name "local_table". But, the local table is also stored, as a kind of cache, if the data comes from outside. Therefore the existence of the local table does not imply that a chart has own data. | ||
| + | |||
| + | So, neither the existence of local data, nor the existence of range-addresses (and even the content, considering that it is allowed that a sheet may also have the name local_table) determines whether or not a chart uses own data or data from the container document. | ||
== Calc- and Writer-Related Problems == | == Calc- and Writer-Related Problems == | ||
Revision as of 12:40, 15 August 2006
Chart2 is a sub-project of the OpenOffice.org Chart Project. Our goal is to develop a new Chart component for (presumably) OOo 2.6.
Charts are used for visualizing data sets from e.g. spreadsheets by two and three dimensional diagrams. There are a lot of different two- and three-dimensional chart types you can choose from. This page gathers information about the new chart implementation of OpenOffice.org. It is especially written to help new comers to the process of developping in the new OOo chart module.
If you would like to participate, if you have comments or questions related to the chart you are welcome on the graphics mailinglists: (users,dev,features,bugs,cvs)@graphics.openoffice.org. See also the section at the bottom of this page called [Some useful information].
Contents
Development in the New Chart
As the information on how to compile the new chart and on how to develop in this project have become quite lenghty, they can be found now on separate pages:
Open Technical Issues in the New Chart
There still some architectural issues left that have to be solved. This section serves for showing those problems and showing the progress in finding solutions.
Application-Framework-Related Problems
Identify the XDataProvider reliably
If the chart is embedded in a container document that provides the data for this chart, the chart contains range-strings at several places in its conten.xml stream that are understood by the container, so that the data can be located there. In Calc such a string would look like this: "Sheet1.A2:A7". Such range-strings can appear in the chart:plot-area element of a chart or at a chart:series, chart:categories or chart:domain element.
If a chart has its own data, this data is stored in a local table in the XML-file. The mentioned range-strings are then of a similar form, with the fixed table-name "local_table". But, the local table is also stored, as a kind of cache, if the data comes from outside. Therefore the existence of the local table does not imply that a chart has own data.
So, neither the existence of local data, nor the existence of range-addresses (and even the content, considering that it is allowed that a sheet may also have the name local_table) determines whether or not a chart uses own data or data from the container document.
Calc- and Writer-Related Problems
Graphic-Framework-Related Problems
The type of the com.sun.star.drawing.BitmapTable
For gradients, transparency-gradients, hatches, line-dashes and bitmaps there are tables in the chart model that contain those elements together with names. E.g., you may have a gradient with the name "My Gradient". When you set the "FillGradientName" Property of an object to "My Gradient", the object will display the corresponding gradient found in this table. The same holds for fill-bitmaps.
However, there is a problem as the table for bitmaps maps a name to a URL rather than to some real graphic object. So, when you add an element to this table, the graphic itself isn't used anywhere in the document at this time. As we have a graphic-manager that deals with all graphics, that keeps graphics only if they are used (if there is a refcount > 0), the grapghics are dropped in this case.
Solution: Change this map to a mapping from names (strings) to objects of type com.sun.star.graphic.XGraphic. As the existence of an XGraphic object ensures that the graphic is available in the graphic-manager, this will solve this problem. Only in the moment an element in this list is used in no model object and also removed from the list, the underlying graphic will be dropped by the graphic-manager.
Problem: This affects also the other applications that implement this table, namely Writer, Calc and Impress. This table is also used in xmloff for a generic facility to export and import graphics in XML.
Documentation
Some useful information
- Main Chart Project Page: http://graphics.openoffice.org/chart/chart.html
- Chart Specifications: http://specs.openoffice.org/chart/index.html
- Current CWS Name: [chart2mst3]
- IRC channel: #chart2.openoffice.org (on freenode)
