Created attachment 53893 [details]
sample document showing problem

I see the same error in OOo3.0 Beta on WinXP. It can be reproduced directly and
is independent of scaling.
Goto Tools > Options > Draw > General and set "Unit of measurement" to inch.
Draw a dimension line of 6 inch.
Goto position and size and make sure that the dimension line has no rotation and
really a width of 6 inch.
Goto style of dimension line and set the display unit to foot and the decimal
places to 7. You get 0.5ft, which is correct.
Goto Tools > Options > Draw > General and set "Unit of measurement" to foot.
Back to the drawing the dimension line shows 0.5013158 ft. (Sometimes you must
reassign the style to update the view.)
Goto position and size and see that rotation is still 0 and width is still 0.5ft.

What unit is used internally?

I believe this has the same origin as:
Issue 26783 - Dimension/Grid is off when using inches, but not cm.

Quote:
AW: This is just a numerical problem, but not solvable ATM. Internally,
DrawingLayer is working on 1/100th mm, thus using a metric entity. All scalings
to metric work well, then. This is used in Calc and Draw/Impress, regardless of
the UI measurements used (this is just for the UI). In Writer, twips are used as
the base and everything which is a multiple of twips will work.

Thanks--yes, I'm aware of that issue, but I think that's a different problem.
Unfortunately, I don't quite know how to prove it, but here's why I think this
is different:

1) The sizes shown in the Position and Size dialog are exactly correct. Only the
dimension size display is wrong. If it were a fundamental limitation, then any
calculation of the size should have the error.

2) Some sizes have no inherent error. The example I gave in the description,
6.50" is exactly 165.10mm, and can be represented exactly using OOo's 0.01mm
grid. Scaling that to a different unit should introduce any error. Of course
there are the normal floating point issues, but that (I think) 

3) The magnitude of the error seems wrong. The maximum error in an object size
is 0.005mm (half of a grid square); that's 0.00001640ft. Regina's example has an
error of 0.0013158ft: >80x larger.

4) The grid error is accumulated: any error in the grid spacing is accumulates
across longer distances. In this case, there is one conversion with no
opportunity for any error to accumulate.

If I stack several objects and use a dimension on each increment, there seems to
be a large delta comparing the dimension display to the actual size of the
stacked objects, and a much smaller delta comparing the dimension displays for
each increment (see second attachment).

Created attachment 53908 [details]
Sample of stacked objects

Oops, that should have been:

Of course there are the normal floating point issues, but that (I think) would
manifest itself as a much smaller magnitude error.

Reproducible. Reassigned.

AW: Checked again and digged deeper. Problem is SdrModel::ImpSetUIUnit() where
the ancient ones prepare a aUIUnitFact fraction, bUIOnlyKomma and nUIUnitKomma
values at the SdrModel to have all data for quick string conversion of numbers
for UI presentation. For that, SdrModel::TakeMetricStr() uses those prepared
values (this also means all other users of TakeMetricStr() show the same error).
As You may see when looking at SdrModel::ImpSetUIUnit(), it's not well
documented and i will have to guess what is done why (short: it's a mess).
The error happens where the dividend and divisor are forced to be less than 1000
by looping, dividing them by 10 and correcting the comma value. With the values
from the given task, this reduces the divisor (in nBigDiv) from 3048 by division
by 10 to 304 which loses the trailing '8'.
My guess is that this 'shortening' is done because below a switch..case is used
which tests the dividend and divisor being one of three cases, 10, 100, or 1000
(as You may have noticed, 1000 cannot even happen diue to the reduction loop
before forcing the values to be smaller than 1000).
I will try to replace this stuff using sal_Int64 to get rid of BigInt and to
reduce only when %10 == 0, so that no info is lost. This will also lead to the
switch..case to have to be done in a loop, too. I do not want to change too much
(e.g. completely rewrite using doubles) since i am currently not too sure what
that comma value exactly does...

AW->jes: Indeed, this problem was different from the numeric problem, it's for
all places which use ImpSetUIUnit(). This includes dimension lines, but also
(from the code) while dragging objects, distorting objects, cropping objects and
polygon creation.

AW: Adapted SdrModel::ImpSetUIUnit now to a more modern form. The loops and
switch..cases at the end are all for removing trailing zeroes (i think), so i
changed it to just do that. Works as expected. Doing some more checks with the
other usages...

AW: Looks safe so far. Did some more minor tweaks, checked again. Checking in. Done.

AW_>WG: Please verify. To verify, follow teh steps from the start scenario.
Caution: You need to switch off grid snapping and activate object snapping to
produce a correct dimension line.

Verified in CWS.

Tested in OOO310_m1. Closed.

Yes! Looks great in OO310_m1--the problem document shows all the expected
dimension values.

Thanks!

AW->jes: Thanks for Your feedback! I'm happy if this makes OOo more usable with
dimension lines :-) If You had voted for this task, think about another one to
vote for...