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: Re: Chart Data Label Positions

On Monday 20 August 2007, Bjoern Milcke wrote:
> Hi David,
> thanks for your revised proposal.
> > <define name="labelPositions">
> >     <choice>
> >         <value>auto</value>
> >         <value>center</value>
> >         <value>north</value>
> >         <value>north-west</value>
> >         <value>west</value>
> >         <value>south-west</value>
> >         <value>south</value>
> >         <value>south-east</value>
> >         <value>east</value>
> >         <value>north-east</value>
> >         <value>inside</value>
> >         <value>outside</value>
> >         </choice>
> > </define>
> > <define name="style-chart-properties-attlist" combine="interleave">
> >     <optional>
> >         <attribute name="chart:label-position">
> >             <ref name="labelPositions">
> >         </attribute>
> >     </optional>
> > </define>
> >   
> Maybe a good idea to define a separate name for the positions.
You mean the fact that I separated labelPositions into its own define? This was necessary
anyway, for reuse from label-position-negative. I don't like duplicating code :)

> > This attribute defines the position of the labels in the chart.
> > The values inside and outside are only meaningful for pie charts,
> > the other values are only meaningful for other types of charts than pie charts.
> Why have you added this section? inside and outside make also sense for 
> net-charts (radar) and also for bar/column charts. I had some 
> screen-shots of those in my proposal. I would suggest to remove the 
> second sentence of this paragraph.


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

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.

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

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