Fwd: Re: Chart Data Label Positions

[David Faure <faure@kde.org>]

Forwarding answer from Bjoern Milcke <Bjoern.Milcke@sun.com> as requested.

----------  Forwarded Message  ----------

Subject: Re: Chart Data Label Positions
Date: Monday 20 August 2007
From: Bjoern Milcke <Bjoern.Milcke@sun.com>
To: David Faure <faure@kde.org>

Hi David,

>> I noticed that you dropped "near-origin". What is the suggestion to 
>> replace this? Using "south" for positive and "north" for negative values 
>> would work for a column chart, but once you switch to bar this would no 
>> longer match. I would suggest to re-add "near-origin" again. An implementation can do 
>> the same as for (+south,-north) or (+west,-east) depending on the chart 
>> type. The advantage of having this additional value is that it is 
>> chart-type-independent.
>>     
> Hmm. This could be said to be a GUI issue rather than a file format issue; 
> the file format as I suggest it -can- express the right thing for horizontal bars
> by using east and west, so the application could switch from south/north to
> west/east when choosing some "near origin" setting in the GUI.
>   

Well, I see this differently. What I want to have expressed in the file 
is that the labels are positioned near the origin, no matter what 
chart-type I have. It is up to the application to render this correctly. 
If I want positive numbers "north" and negative one "south", then I 
would expect an application to leave it this way for all chart types, 
because I wanted it that way.

It is like when you have a bold word, and you also have a style 
"emphasis" which is bold, then the application says "Aha, I set the 
emphasis style at this word, because it has the same attribute". Then 
you change "emphasis" to italic and your word becomes italic. That's not 
what you specified in the file.

> However if you cannot live without it I am ok with re-adding near-origin as long
> as it is clearly defined as "a shortcut for +south,-north for vertically-oriented chart types
> and for +west,-east for horizontally-oriented chart types). If we make the file format
> redundant (two ways to express the same thing) then we must make that redundancy
> explicit and define it precisely.
>   

Well, it is not redundant (see above) the same way that an attribute 
"bold" and a character style "emphasis" are not redundant. Why does it 
have to be clearly defined? I am asking especially as I think of chart 
types which may come in the future of which we have never thought. We 
wouldn't have a clear definition for them as well, and I think we don't 
need it, do we? Near origin means the values are displayed as close to 
the origin-value (usually 0) as possible.

[from the other mail:]
> To be honest I'm not sure why we use north/west/south/east instead of top/left/bottom/right.
> Both the Sun proposal and the KDChart code do use north/west/... for some reason  :) 

What you learn in school is that California is west of Arizona, it is 
not left. That's just a coincidence, as on maps north usually points up. 
But California could also be right, above or below Arizona. In other 
words, the wind directions are relative, not absolute. That means that 
"north" in a bar chart could be seen as "right". Well, we don't want 
that, do we?

At least it was not our intention when defining the attributes. So, 
maybe we should indeed use left/right/top/bottom instead. What about SE, 
NE, SW and NW: top-left, right-bottom etc.?

-Bjoern

P.S.: I am not subscribed, can you please forward this to the list.


-------------------------------------------------------

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