Issue 96183 - strange behavior of dimension line attributes after changing them
Summary: strange behavior of dimension line attributes after changing them
Alias: None
Product: Draw
Classification: Application
Component: code (show other issues)
Version: OOo 3.0
Hardware: All All
: P3 Trivial with 2 votes (vote)
Target Milestone: OOo 3.1
Assignee: Oliver-Rainer Wittmann
QA Contact: issues@graphics
Depends on:
Blocks: 59051
  Show dependency tree
Reported: 2008-11-13 13:56 UTC by Oliver-Rainer Wittmann
Modified: 2009-01-07 12:11 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Oliver-Rainer Wittmann 2008-11-13 13:56:46 UTC
- new Draw document
- insert dimension line
- open "Position and Size" dialog of inserted dimension line
- set X to 1cm, Y to 2cm, Width to 3cm and Height to 4cm
- confirm the dialog
--> dimension line changes, but
- open "Position and Size" dialog again
--> X, Y, Width and Height do not match the set ones
Comment 1 Oliver-Rainer Wittmann 2008-11-13 14:03:52 UTC
Let Writer issue 59051 depending on it, because the Writer exports a changed
drawing object position by providing an adjusted transformation matrix at the
May be this issue causes the Writer defect.
Comment 2 Oliver-Rainer Wittmann 2008-11-13 14:12:47 UTC
Adjustment to the previous made comments about the Writer:
- The Writer also provide adjusted "StartPosition" and "EndPosition" at the
UNO-API for drawing objects. These are the properties, which are retrieved
during the save to ODF. The ODF export does not ask for the transformation of
dimension lines.
Comment 3 Armin Le Grand 2008-12-17 14:29:03 UTC
AW: Checked in aw061 (DEV300 m37). X and width are kept, but Y and height
change. This has to do with the fact that a dimension line is just a line object
(only defined by two points). I think somehow the Set...() methods are too
roughly implemented, i need to take a look. One thing is clear: The shown width
and height is the BoundRect (including created geomertry like the text, arrows,
etc...), while when setting it is meant to be model data directly.
Comment 4 Armin Le Grand 2009-01-06 12:11:33 UTC
AW: The setting of a changed size rectangle (that's what happens) is as
correctly implemented in SdrMeasureObj::NbcResize as possible. It scales the
object's geometry (two postions) using the given change. It can be compared with
a line (e.g. horizontal line) which shows the same 'strange' behaviour when You
try to set a height in the dialog (it's ignored). There is not really something
better that can be done in that case.
Still thinking about it...
Comment 5 Armin Le Grand 2009-01-07 10:45:44 UTC
AW: There could be something put together e.g to adapt the height of the
dimension line when the scale is done, but this would be difficult (many measure
object configurations, text left/right, above, etc...), inprecise (the object
maybe rotated, extremly difficult and not precise to calc back line length
changes) and difficult to do concering the object's internal constraints.

It may also not be wanted, since the two defining points of the measure object
now define the measure points of the object. Think about a scenario, where You
have a rectangle and a measure object visualizing the width of the upper edge.
When You scale/rotate both, You do NOT want the measure object's distance to the
upper edge to change, but this would happen when changing the scale as thought
about above.

I also interpret od's last entry that there is not a problem emerging from the
non-precise scaling on the API, since API uses "StartPosition" and
"EndPosition". We would have the same problem with lines if this would lead to

AW->OD: I would like to keep this functionality as it is. Please read my
conclusions above. If You still have concerns about this issue, please re-apply
to me.
Comment 6 Oliver-Rainer Wittmann 2009-01-07 12:10:49 UTC
Thus, I think this issue can be closed as WONTFIX
Comment 7 Oliver-Rainer Wittmann 2009-01-07 12:11:15 UTC