OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only
Expand all | Collapse all

proposal: Chart Data Label Auto-Positions

  • 1.  proposal: Chart Data Label Auto-Positions

    Posted 04-02-2007 12:31
      |   view attached

    Attachment(s)



  • 2.  Re: [office] proposal: Chart Data Label Auto-Positions

    Posted 04-03-2007 10:16
    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?
    
    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 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.).
    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.
    
    I realize that a general-purpose charting engine like KDChart (http://www.kdab.net/kdchart, which koffice uses)
    aims for much more flexibility than a charting functionality in an office suite (the koffice component certainly
    doesn't give the user all the above flexibility). However it seems that the best solution is to give the full
    flexibility in the XML, so that it can be used by everone, and still provide to the office suite user only a few
    combinations. 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.
    
    -- 
    David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
    Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
    


  • 3.  Re: [office] proposal: Chart Data Label Auto-Positions

    Posted 04-03-2007 12:34
    Lars,
    
    A couple of quick editing comments on the proposal:
    
    Data Label Position
    
    "For the positioning of data labels there are several automatisms."
    
    ?automatisms?
    
    Suggest: "...there are several default positions."
    
    I would prefer that over, "....there are several automatic positions." 
    since the value "auto" is assumed where no position is specified and to 
    say "automatic positions" invites confusion on the part of the reader. 
    Default covers what is actually meant.
    
    The following paragraph states:
    
    "When the label position is auto, the chart should use the algorithm 
    with the best results for
    positioning depending on the chart type."
    
    That seems rather vague to me. It implies that there is more than one 
    algorithm that can be chosen depending on the chart type (which I assume 
    to be true).
    
    That vagueness is aggravated by the next paragraph:
    
    "Not all chart types support all possible values for this property. In 
    such a case the chart type uses the same algorithm as the value auto does."
    
    OK, that's probably true as well but shouldn't we say which chart types 
    don't support which possible values?
    
    While I am acutely aware of the separation of content from display that 
    is a given for XML encoding of documents, I am also aware that appearing 
    to build in certainty, such as "north," "south," etc., while allowing 
    applications to decide that for some unspecified type of chart that is 
    not a supported value and so it has recourse to some unspecified 
    algorithm is a recipe for really divergent display of content by 
    different applications.
    
    I guess my point would be that unless we are going to specify layout 
    with a layout model and mean *that* layout and no others for conformance 
    purposes, then let's not appear to be doing layout when it is merely 
    suggested positioning that is under specified and that the application 
    can ignore.
    
    Hope everyone is having a great day!
    
    Patrick
    
    PS: Note that in the following Example,  "...the effect of the different 
    automatisms." should be changed to read: "...the effect of the different 
    default positions." with or without further revisions to this proposal.
    
    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...
    >
    > Bests,
    > Lars
    >
    
    -- 
    Patrick Durusau
    Patrick@Durusau.net
    Chair, V1 - Text Processing: Office and Publishing Systems Interface
    Co-Editor, ISO 13250, Topic Maps -- Reference Model
    Member, Text Encoding Initiative Board of Directors, 2003-2005
    
    Topic Maps: Human, not artificial, intelligence at work!