Issue 26783 - Dimension/Grid is off when using inches, but not cm.
Dimension/Grid is off when using inches, but not cm.
Status: CONFIRMED
Product: Draw
Classification: Application
Component: ui
OOo 1.1
PC Windows XP
: P3 trivial with 6 votes (vote)
: AOO Later
Assigned To: Armin Le Grand
: oooqa
: 102240 (view as issue list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-22 03:48 UTC by ooo_user
Modified: 2013-02-07 22:13 UTC (History)
6 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description ooo_user 2004-03-22 03:48:33 UTC
I had also posted this input on the forum webpage (oooforum.org), under the 
user 'ooo_user', but had not seen a single response to my comments and 
questions. 

I've tried all of the following with versions 1.1 and 1.1.1rc3.

When Drawing in inches, I'm seeing odd behavior in how the grid and dimensions 
are being handled.  The issues I'm seeing happen when using inches as the unit, 
but do not happen when using 'cm' as the unit.

To begin, I'm finding the snap grid does not match the ruler grid. For example, 
I've setup at page so that it has 0.25" margin all around, which leaves a 8 x 
10.5 in. page. I've set the Unit of mea. to Inch. 

The Grid Resolution is set to 0.01", and the subdivisions is set to 0 = which 
means the grid equals the snap to points. 

When set to 1:1 scale, the grid snap works fine. All the objects I place snap 
to exactly 0.01" grid. When I change the scale to 1:10, so that I have an 
effective space of 80 x 105 inches, and the grid is now 0.1". In this case, 
when I place objects, it still snaps to the grid, but the grid is not exactly 
0.1". For example, if I try to add a box which would show dimensions of 1.80 x 
1.00 it might show dimensions of 1.79 x 0.98. 

I began looking at the snap to grid and the ruler grid and realized that they 
are different ... the spacing is slightly off between them. For example, what I 
tried to do was draw a box that is 1.00 x 1.00. As I watch it snap to the grid, 
I can see that it doesn't exactly match the ruler grid. Then, if I turn off the 
Snap to grid, and move the box to line up with the ruler grid, it will line up 
to exactly 1.00 x 1.00. 

Now, I further tested dimensioning (drawing a dimension line and not just a 
box) on the same setup.  Below are the descriptions of 4 test cases that show 
the differences I am seeing when using different scales and inches.  The funny 
part is, I don't see a problem when using cm as the unit, as is discussed below.

1) Inch 1:1 Scale 
Unit : Inch 
Scale: 1:1 
Tabs: 1 inch 
Grid resolution, horiz and vert : 0.01 in 
Number of points, horiz and vert : 0 (so that grid is exactly 0.01 in steps) 

If I add a dimension line, it only shows resolution to 1 decimal point. Even 
though the properties show it set to 2. I've tired changing it to 4, but no 
change. So, even though the grid resolution is setup to 0.01 in, I can only get 
the dimensions to show to 0.1 in resolution. The dimensions of the line show in 
the bottom of the Draw window show the dimensions in 0.01. So, I'm stumped as 
to what I need to do to get the dimension line to show the 0.01 resolution. 

2) cm 1:1 scale 
Unit : cm 
Scale: 1:1 
Tabs: 2.54 inch 
Grid resolution, horiz and vert : 0.01 cm 
Number of points, horiz and vert : 0 (so that grid is exactly 0.01 in steps) 

Now, with a dimension line, I get 2 decimal places of resolution to 0.01 cm. 

3) inch 100:1 scale 
Unit : Inch 
Scale: 100:1 
Tabs: 1 inch 
Grid resolution, horiz and vert : 0.01 in 
Number of points, horiz and vert : 0 (so that grid is exactly 0.01 in steps) 

So, with a 100:1 scale, the grid should show up at 0.0001 in steps. And, the 
resolution in the dimensions should be in 0.0001 in steps. But, all I can do is 
get the dimension resolution to 0.001 in., even if I set the number of decimal 
places to 4 ... it only shows to 3. 

4) cm 100:1 scale 
Unit : cm 
Scale: 100:1 
Tabs: 2.54 inch 
Grid resolution, horiz and vert : 0.01 cm 
Number of points, horiz and vert : 0 (so that grid is exactly 0.01 in steps) 

So, again, with 100:1 scale, the grid should now show up at 0.0001 cm steps. 
And, it does. All dimensions, when I change the number of places to 4, show in 
steps of 0.0001 cm. And, the grid appears to continue to work correctly.
Comment 1 wolframgarten 2004-03-26 11:45:08 UTC
I persume that this is some kind of rounding error. The described behaviour is
reproducible. Just set up a Grid with 0.01" resolution and sub = 0. Set the
scaling to 1:10 and have a look at the rulers and the shown grid: they start to
differ obviously between 1 and 2 inches of the rulers already.
Reassigned to Christian.
Comment 2 ooo_user 2004-04-07 21:15:37 UTC
The user 'ekim' on the OOO Forum logged the following observations as well:

I think I can exactly reproduce this. However even at 1:1 I notice alignment 
issues between object boundaries and grid lines. 

I would summarize the issues as follows: if units are inches NOT possible to 
draw objects with integer dimensions {note: at 1:1 scale problem is hidden by 
precision of measure, changing scale to 1:10 or 1:100 reveals issue}, if units 
metric objects can be integer dimensions at all scales. 

I did notice that the pixel setting impacted the problem but no combination 
would produce integer dimension objects. 

Would you agree with this? If so I will file a report. If not we should see if 
we can clearly define the issue or see if this is two different problems.
Comment 3 caeshmer 2004-04-13 16:36:31 UTC
I've noticed something like this behavior as well.  (I'm currently using ooo
1.1.0 under Linux.) This problem is extremely frustrating when I'm trying to
create precise diagrams.  I've also noticed that if you go to Tools, Options,
Drawing, Grid, and set the grid spacing to 0.125" (1/8) it rounds this to 0.13"
as soon as you click on some other item in the window.  I can't tell whether
this is simply a GUI glitch (as in it uses 0.125" but rounds the number before
displaying it) or if it rounds the length off and stores that.  Either way, I
see no reason why I shouldn't be alowed to have a 1/8 inch grid and see
confirmation that that's what I have.
Comment 4 mbandsmer 2004-05-12 20:19:15 UTC
I came across a related issue: Setting the grid to 6.0pts (1/12 of an inch), 
with a 1440x1440pt (20"x20") sized drawing, objects align to x- and y-offsets 
which are not multiples of 6pts.  In fact, the further I get away from the 
(0,0) point of the drawing, the larger the deviations from the expected 
multiples of 6pts.

E.g. Objects which should align at 1254.0 points align at 1253.0 pts.  This is 
consistent with the grid size being rounded off from 6pts to about 5.9952pts.  
In mm, the grid seems to be rounded from 2.116666... mm to 2.1150 mm, which 
suggests that the code might be rounding all values off to the nearest .005mm.
Comment 5 ooo_user 2004-08-03 17:25:06 UTC
I'm still kinda new to using the Issues and Bug tracking for OO, so my question
may not be appropriate, but I'm not sure where/how else to ask it.

I've seen this issue remain at unconfirmed since its entry in March, and haven't
seen any mention of it in the 2.0 codeline (as best I can find).

So, may I inquire if, how, and where this issue will be fixed (assuming it is
confirmed at some point)?  Will it be in a later release of 1.1.x?  Will it make
it into 2.0, or will the same grid/dimension issue remain in 2.0?  If not fixed
in 1.1.x or 2.0, will it be considered for a later product codeline (3.0)?

The reason I ask is because this particular issue is keeping me from applying
OOo 1.1.x to my projects, and I'm continuing to use Microsoft Visio products. 
I'd like to integrate OOo into my work flow and move away from Visio, but with
this issue outstanding am unable to.  I need to consider making a GO/NO GO
decision on Open Office within the next year, and since I've seen this issue sit
for almost 5 months now, I thought I'd inquire a little further about how it
will/will not be addressed.

Thanks for considering me inquiry.
Jim.
Comment 6 clippka 2004-10-18 07:35:30 UTC
Armin, please have a look at this one.

Jim, this issue is currently not scheduled for OOo 2.0
Comment 7 Armin Le Grand 2004-10-18 18:08:01 UTC
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.
The basic problem is that internal coordinates are up to today integer-based and
the unit is choosen different from the applications to work on an acceptable
range of values. The precision is limited by this fact.
We are working in the direction to migrate from this (in the old cores) to
double precision, but this takes time. We are talking about Years here, millions
of lines need to be changed. Thus, there will be no change for 2.0, sorry.
Comment 8 Armin Le Grand 2004-10-21 17:18:04 UTC
.
Comment 9 keithh 2005-11-26 22:02:47 UTC
I do not understand why such a fundamental and serious flaw is being left at
such a low priority. I'm sorry, but this one problem renders the tool useless
for much of my work. And no, abandoning metric isn't an option: too many
materials come in imperial units. Much as I prefer millimeters, I can't escape
inches. In fact, I often need to mix imperial and metric in the same diagram.

I have a few questions and a possible work-around:

1. Why are measurements being stored internally without units?

2. Why is the internal representation coupled to the presentation so inextricably?

3. How can it *possibly* require changing "millions of lines of code"? Just how
bad is this code?

4. How about you do an end-run around the problem by adding a presentation
option which would convert measurements to the *closest* quarter-inch,
eighth-inch, sixteenth-inch, thirty-second-inch, sixty-forth-inch, or "thou"?
(the user would choose the smallest appropriate measurement)

This latter idea really should be implemented anyways. It would be much
preferable to display three-eighths-of-an-inch as 3/8" instead of 0.375" anyways.
Comment 10 Armin Le Grand 2007-01-25 10:18:44 UTC
AW->keithh: Be ensured, we do not leave it at low priority, there are much more
tasks going to the same root than this one, the integer-based cores. To answer
qour questions:

1. Why are measurements being stored internally without units?
AW: They are not, internal units are application-specific, Draw/Impress and calc
use 1/100th mm, Writer uses twips.

2. Why is the internal representation coupled to the presentation so inextricably?
AW: Please ask the people who designed this ten years ago.

3. How can it *possibly* require changing "millions of lines of code"? Just how
bad is this code?
AW: Feel free to look at the millions of lines of code, it's OpenSource. Think
about the fact that maybe 150-200 people are working on it, so maybe 10 to 5 in
this area. You are welcome to help changing this instead of just complaining
about something offered free to You. Until then, trust my guess, i know the
code. Like all code, it's like a pyramid and the basic numerics are
integer-based, so all the layers above are integer-based, too. To change that,
You need to change/enable the base to offer better precision, then change the
whole rest of the office to make use of it. Since this is a too big step to do
in one run, think about doing it in multiple steps, offering two (or more)
interfaces to the not-yet-changed layers to keep them working. This by itself
implies new errors in each Version. Nonetheless, we are making progress to
change the numerical base.

4. How about you do an end-run around the problem by adding a presentation
option which would convert measurements to the *closest* quarter-inch,
eighth-inch, sixteenth-inch, thirty-second-inch, sixty-forth-inch, or "thou"?
(the user would choose the smallest appropriate measurement)
AW: This needs to be evaluated how far this is feasible. I think it's something
completely different from enchancing the numerical base. It would be a
completely new measurement display option ad would require a feature task. This
task describes a bug for who's solution a change of the numerical base is required.
Comment 11 ace_dent 2008-05-24 11:23:01 UTC
Different problems but same cause(?):
Issue 21292 - default tabstops missaligned to ruler
Issue 52990 - a dimension line of 200" will display as 199.9"
Issue 89872 - dimension lines may show large errors for foot unit

- Is it worth making this Issue more generic to cover these metric / imperial
measurement unit problems? This would allow other issues to be closed
(duplicates) and just focus attention on the one underlying problem...

Cheers
Andrew
Comment 12 Armin Le Grand 2009-06-17 15:38:34 UTC
*** Issue 102240 has been marked as a duplicate of this issue. ***