Re: [Fwd: Re: [Fwd: Re: [office] proposal: Chart Data Label Auto-Positions]]

[David Faure <faure@kde.org>]

On Monday 14 May 2007, Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> Well, I think they could. But it looks like this wouldn't be sufficient
> to cover all possibilities you have for KDChart, so would that really help?
Agreed. I realized that later on, but left it in, in case we didn't agree on the rest :-)

> > In fact the way it works in KDChart is:
> > 1. find the position point (center, north, north-west, north-east, 
> > east, etc. : 9 points)
> > 2. align to that point (right-alignment, left-alignment, center 
> > alignment, and the same vertically: top, bottom, vcenter)
> > 3. add a horiz/vert gap (distance between the point and the label)
> > On top of that, there are two sets of position/alignment information: 
> > one for positive
> > values and one for negative values.
> 
> This is close to our first idea for modeling this. One thing that is not
> so nice is the direction in 1. north is usually understood as "top", and
> even on a spherical globe (where it comes from), north points into one
> specific direction. This does not work for pie charts. How would you
> describe the "outside" or "inside" values in our suggestion with the KDE
> properties? "north" does not seem appropriate here. And if you want all
> labels in a pie on top of the anchor point, wouldn't that also be "north"?

OK, so we need two more values for position points, outside and inside, right?
(and specifying that only those make sense for pie charts, while the others don't).
That would be fine with me; the way it works in kdchart is more of a programmer
point of view indeed. But this is a minor point compared to the overall idea, which
is to separate the position and alignment, and to have separate values
for negative values.

> We had a long discussion about this topic, and we came to the conclusion
> that set we chose finally should suffice for most situations.
It's the last 20% that always create a problem :-)
I agree though that in a GUI those sets might be enough. However we are designing
a file format here, not a GUI, so better choose flexibility, IMHO (more below).

> I don't think that you would really want an automatism that positions positive
> values south-west and negative ones east.
Why? Maybe it makes sense in LTR locales...

> > This allows to model what you called "north" as "north for positive 
> > and north for negative",
> > and what you called "outside" as "north for positive and south(+bottom 
> > alignment) for negative".
> > Separating the position/alignment information for positive and 
> > negative seems like a more flexible
> > design since it allows more combinations than just those in your 
> > proposal.
> >
> > My proposal is therefore to split this attribute into four attributes ;)
> >
> > * chart:label-position-positive-values:  (center, north, north-west, 
> > north-east, east, etc. 9 points in all, plus auto)
> > * chart:label-alignment-positive-values:  { left, right, or hcenter } 
> > + { top, bottom or vcenter }
> > * chart:label-position-negative-values:  (center, north, north-west, 
> > north-east, east, etc. 9 points in all, plus auto)
> > * chart:label-alignment-negative-values:   { left, right, or hcenter } 
> > + { top, bottom or vcenter }
> >    (I didn't look it up; do we have something for h+v alignment 
> > already in ODF?)
> >  Or maybe two attributes, horizontal alignment and vertical alignment.
> >
> > For each value you suggest for label-auto-position, here's what the 
> > above 4 attributes would say, instead:
> > near-origin:  south position with hcenter+top alignment, and north 
> > position with hcenter+bottom alignment
> > center: center position with hcenter+vcenter alignment
> >    (maybe we can remove "positive-" from the first two attribute 
> > names, and say that the apply
> >     to both positive and negative values if *-negative-values isn't 
> > specified? I don't mind.).
> 
> (Making the negative attributes optional sounds good. The format should
> be as simple as possible in the default cases.)
Agreed.

> > north: north position with hcenter+top alignment
> > south: south position with hcenter+top alignement
> > west: west position with left+vcenter alignment
> > east: east position with right+vcenter alignment
> > inside: north position with hcenter+bottom alignment, south position 
> > with hcenter+top alignment
> > outside: north position with hcenter+top alignment, south position 
> > with hcenter+bottom alignment
> >
> > Ah what about the pie charts? We would have to say that "north is 
> > towards the outside"
> > and "south is towards the center", for instance. Or the other way 
> > round, as long as it's defined.
> 
> As stated above, then for pies we wouldn't have "on top of the anchor",
> but maybe we can skip that. However, "north" meaning "outside" is an
> unusual interpretation, and I wouldn't like to use that.
OK.

> > I realize that a general-purpose charting engine like KDChart 
> > (http://www.kdab.net/kdchart, which koffice uses)
> 
> KOffice uses KDChart? But KDChart is not free, do you mean you can
> replace the KChart component of KOffice by KDChart?

KDChart exists as a GPL version, so KOffice does use KDChart.
KDAB (the company I work for) licenses KDChart with the same license model as Trolltech
licenses Qt: free for free software (GPL), and commercial license for non-GPL software.

> > The underlying charting engine can either support all combinations or 
> > be limited to
> > those that the user can choose, but at least the document format 
> > allows for more cases later without
> > 50 combinations being expressed in a single attribute.
> 
> It depends. Flexibility has advantages. With more attributes you can
> model more possibilities, but you also have to take care of all those.
> If some combinations don't make sense, you have to decide how to behave
> then.
If some combinations don't make sense, we can easily specify in the specification,
like I suggested above for the case of using inside/outside with bar charts: not allowed,
since bar charts use the north/west/east/etc. values.

> I think, if we have a set of "n" automatisms, and we see later that we
> need "n+m", we can still extend them. Of course, we shouldn't have 50 of
> them, but I think there is no need for that much.
Well, basically if we settle on "n" pre-defined combinations, then KDChart
cannot use ODF for loading/saving label positions :(
Why design something limited instead of something flexible that can also,
obviously, handle the limited use case? Yes OpenOffice.org will probably have
to ignore the combinations that it can't handle, but that's the whole idea of
specifying "the most flexible solutions" rather than "the least common denominator";
KOffice also has to load ODF files that contain many features that it cannot handle,
that's to be expected with a common file format between office suites.
But this is the way to future interoperability: designing after the most featureful
implementation and letting the other implementations catch up later, or handle
only the cases they want to handle.

> More flexibility can be achieved by introducing manual positions. This
> proposal is for automatisms only. It would make sense to have a
> "chart:label" element in the future as a sub-element of a data-series or
> data-point that may also contain a position. For manual positioning it
> may make sense to have an anchor point in the chart and an alignment
> point on the label like you suggested. The offset could also be in the
> coordinate system of the chart, so that for a rotated pie the manual
> offset would behave more logically than a rectangular offset.
I'm not really sure I'm following you there. I'm not really requesting a
per-data-point setting, we are still talking about the settings that apply
to the whole chart...

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).