Apache OpenOffice (AOO) Bugzilla – Issue 26783
Dimension/Grid is off when using inches, but not cm.
Last modified: 2017-08-04 18:13:46 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.
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.
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.
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.
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.
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.
Armin, please have a look at this one. Jim, this issue is currently not scheduled for OOo 2.0
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.
.
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.
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.
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
*** Issue 102240 has been marked as a duplicate of this issue. ***
Reset assigne to the default "issues@openoffice.apache.org".
Created attachment 86195 [details] AOO Draw points snap precision This file shows the imprecision of snap in AOO Draw when using points as the unit of measure.
I'm using AOO 4.1.3 on macOS Sierra 10.12.5. This is a very old issue, but it has been revisited here lately. So I am adding a comment instead of creating a new issue. The precision of snap in AOO Draw is way off when using points as the unit of measure. For example, when I attempt to draw an 18 x 24 point rectangle at X = 6 points and Y = 12 points, its position snaps to X = 5.95 points and Y = 11.91 points, and its dimensions snap to 17.86 x 23.81 points (see attachment). My understanding is that AOO is metric-based, and converts to other units. The solution may simply be to increase the decimal places in AOO Draw's conversion factor, or using a formula instead of a fixed number. mm per point: 25.4 mm per inch / 72 points per inch, or 0.352(7) points per mm: 72 points per inch / 25.4 mm per inch, or 2.(834645669291338582677165354330708661417322) - a mathematician in the user forum kindly calculated the 42-place repeating decimal By refining the conversion factor, Draw could get so close to exact points that position and size would display as "N.00" numbers. That would be a great help to me. Thanks.