OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [Fwd: Re: [Fwd: Re: [office] proposal: Chart Data LabelAuto-Positions]]


Hi David,

Lars has forwarded your comment to Bjoern. Below is his reply. You get
it from me, because Lars is currently in vacation.

Michael



-------- Original Message --------
Subject: Re: [Fwd: Re: [office] proposal: Chart Data Label Auto-Positions]
Date: Mon, 14 May 2007 13:23:14 +0200
From: Bjoern Milcke <Bjoern.Milcke@Sun.COM>
To: michael brauer <Michael.Brauer@Sun.COM>
References: <461230D5.1090905@sun.com>

Hi Michael,

I have added some comments inline in the mail from David. Please forward
this message to him.

Thanks,
Bjoern

> -------- Original Message --------
> Subject: Re: [office] proposal: Chart Data Label Auto-Positions
> Date: Tue, 03 Apr 2007 12:15:24 +0200
> From: David Faure <faure@kde.org>
> Organization: KDE
> To: office@lists.oasis-open.org
> References: <4610F785.9010202@sun.com>
>
> On Monday 02 April 2007, Lars Oppermann wrote:
>> Dear TC members,
>>
>> I am forwarding the attached roposal created by the 
>> OpenOffice.org-Chart development team concerning automatic data label 
>> positions in charts for inclusion into OpenDocument 1.2...
>
> Very nice document, full of explanatory pictures ;)
>
> In KDChart we have a few more possibilities for label positions: 
> north-west,
> north-east, south-east and south-west. Could those be added to this 
> attribute?

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?

> 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"?

We had a long discussion about this topic, and we came to the conclusion
that set we chose finally should suffice for most situations. I don't
think that you would really want an automatism that positions positive
values south-west and negative ones east.

> 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.)

> 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.

> 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?

> 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.

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.

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.

Regards,
Bjoern


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]