Let Writer issue 59051 depending on it, because the Writer exports a changed
drawing object position by providing an adjusted transformation matrix at the
UNO-API.
May be this issue causes the Writer defect.

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.

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.

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

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

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.

Thus, I think this issue can be closed as WONTFIX

closing