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.
Agreed.
> 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, , sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
