[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] surface plots
Hi Andreas, On Wednesday, 2009-07-22 14:22:19 -0600, Andreas J. Guelzow wrote: > > Hm, I think this needs to be specified more precisely. > > I think this is important to do, especially since if this is what > OpenOffice implements then it differs from other implementations. > > > It should be understood as: > > > > <chart:series chart:values-cell-range-address="S1.$A$1:S1.$A$16" /> > > <chart:series chart:values-cell-range-address="S1.$B$1:S1.$B$16" /> > > <chart:series chart:values-cell-range-address="S1.$C$1:S1.$C$16" /> > > <chart:series chart:values-cell-range-address="S1.$D$1:S1.$D$16" /> > > This seems to be unnecessarily complicated. Since these series all > belong together wouldn't it make more sense to record them as > <chart:series chart:values-cell-range-address="S1.$A$1:S1.$D$16" /> > Otherwise we introduce and artificial dissymmetry between the base > coordinates. > > > > > where A1 gives the altitude (y coordinate) at x=1, z=1 > > and A2 gives the altitude at x=2, z=1 > > and B1 gives the altitude at x=1, z=2 > > and B2 gives the altitude at x=2, z=2 > > and D3 gives the altitude at x=3, z=4 > > ... > > > > Let me try to give a more precise description for the specification: > > This specification may describe OpenOffice's implementation but differs > from Gnumeric's implementation. I don't know how other implementors have > chosen to understand the description. Again, here the answer from Ingrid: ---%<---snip---%<--- Hi Andreas, all, It is not OpenOffice.org that has implemented the surface chart differently. OpenOffice.org does not at all implement the surface chart type so far. But Mircosoft does for example. They do create ods surface charts like I have described for the 3D case - where in addition they set the attribute chart:deep="true" (what is a good thing to do here I think). Having multiple series forming one surface has the advantage that the data structure is the same as for other deep 3D charts. That makes it easy to switch between those types. Applications that do not implement a surface chart can easily use a bar chart instead ( I am on a jump to implement that for OpenOffice.org ). I think the multiple series approach has furthermore the advantage that the accessory grid locations are defined more precisely. With the single series approach the grid locations are quite unclear so far. This must be specified further if we allow for it. Regarding the 2D case: Microsoft does not create real 2D surface charts. Instead they create 3D surfaces with a perspective looking from the top. At least for performance reasons I think it would be good to allow and to define real 2D case for surface charts (contour chart). What do others think about this? If there are already different implementation out there, one thing that could be done is to allow for both interpretations in the specification. But this puts an extra burden on all applications, so I would not prefer that way. It would be interesting what others do think about this issue. In case we anyhow allow for multiple interpretations I need your help to give a complete suggestion for the specification. Could you fill in the missing parts for the Gnumeric interpretation, please? This is a suggestion for a definition that allows for both known interpretations of the surface chart (missing parts to be completed): ---------------------- surface – The values of multiple <chart:series> (marked as being of type chart:surface) are interpreted as a 'altitude' at a specific grid location. The graph may visualize these using colors for height intervals, creating color bands. In case of chart:three-dimensional="true" a left handed three dimensional cartesian coordinate system is used. The attribute chart:deep has to be set to true in this case. The given values for a series are interpreted as y-coordinates (representing the 'altitude'). In case multiple series with type surface are given the accessory x and z coordinates are determined as follows. The accessory x-coordinates are generated from the positions in the altitude-value sequence starting with 1.0. The first altitude value gets an x value 1.0. The second altitude value is associated with an x value of 2.0 and so forth. The z-coordinates are generated from the positions of the series elements starting with 1.0. The first series has an associated z coordinate of 1.0. The second series has a z-coordinate 2.0 and so forth. In case only one series with type surface is given x and z coordinates are determined as follows. ... please enter a suggestion to describe how the x and z values are determined in this case ... In case of chart:three-dimensional="false" each altitude value is located on a Cartesian x-/y-grid. In case multiple series with type surface are given the accessory x and y coordinates are determined as follows. The x-coordinates are generated from the positions in the altitude-value sequence starting with 1.0. The y-coordinates are generated from the positions of the series elements starting with 1.0. In case only one series with type surface is given the accessory x and y coordinates are determined as follows. ... please enter a suggestion to describe how the x and y values are determined in this case ... ---------------------- Kind regards, Ingrid ---%<---snap---%<--- Eike -- OpenOffice.org / StarOffice Calc core developer and i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]