Apache OpenOffice (AOO) Bugzilla – Issue 111688
Snap to grid drift
Last modified: 2013-02-02 15:38:58 UTC
I have noticed this over the years and have never reported it as a bug until now. I can use the snap-to-grid option, then create a complex drawing with thousands of objects. Things progress over days fine, saving, loading, editing, etc. But at some point, the grid will change position ever so slightly and throw off all my objects. I never touched the grid settings nor origin. If, for example, I had a perfect square, drawn with 4 lines, so some later load, the grid will shift a pixel or two and then if I move one of the corners and place it back to where it was, the lines are no longer straight and the square is no longer a perfect square and it is impossible to fix. I have seen this happen multiple times, across multiple versions of Draw. I have no explanation. More frustrating is that it is then impossible to ever "fix" the drawing back to the grid again. And if you have many thousands of objects, like a blueprint or floor plan, it causes a big mess. In addition to a fix for this bug, it would be nice to have an enhancement tool that will allow the user to select certain objects or all objects, then perform a correction that will snap every point in those objects to each nearest grid point.
Sorry, nothing official, just a comment... Are you working with metric or English units for the grid? (Tools > Options > OOo Draw > General > Unit of measurement) I've noticed some problems, although not this one specifically, when Draw has to work with English units, or if I switch between English/metric. Also, changing the page margins seems to shift the grid origin: Draw normally aligns the grid to the top+left page margins. Any chance that the margins changed?
I am working with English units, not metric and have never changed it. I also never changed the margins and never touched the origin. I showed the issue to a co-worker today, who said "oh, yes, it has done that to me also in drawings, but the shift was so small I thought I did something wrong." In this particular (last) case, the grid was shifted up (vertically) a few pixels. It stayed the same horizontally. I could attach a sample drawing in which the shift has occurred but I am not sure that would help.
@crxssi: that is the point. If we cannot reproduce the problem we cannot fix anything.Please attach the document and mark the problem. Thanks.
Created attachment 69624 [details] Example of all objects off the grid slightly
@wg, I have attached a sample document for which every object on the page is no longer snapped to the grid. If you zoom in to max zoom, select a horizontal line, and move one end point, you will see that it moves ever so slightly to re-snap that point to the grid. Unfortunately, I don't know how the document became that way. I have several saved revisions and if I go back far enough, it seems to have happened when all the objects were moved down on the page. But every object on the page was landing on a grid point, the grid never changed, and they would have been moved while the snap to grid was in effect, so it should not have moved off the grid. More unfortunately, I didn't notice that it moved off the grid and spent a hundred hours adding many more layers and objects. And now it is impossible to get all the objects back onto the grid :( I don't know what you mean by "mark the problem", hopefully I have covered your request.
The problem is easy to see with the sample document, as described. I still wonder if the problem comes from using English measurement units and a small grid that requires more precision than is available. The sample document specifies a square grid, with major divisions of 0.500" and 25 minor divisions. That gives 0.5"/26, or 0.01(923076)" per fine grid square. Is it possible to represent such a grid accurately in Draw's internal coordinates? I'm not sure. If I make a new document and look at some object coordinates in the xml and compare them with the grid settings, I don't always get a clean integer multiple. Is there a better way to check that the object's coordinates fall cleanly on the grid? Maybe I just did the calculations wrong, but the same analysis works as expected for a similar grid using metric distances.
@jes Well, I am glad it is a real issue and I am not losing my mind :) Fixing it so it doesn't continue to happen would be great (if possible). I still wonder if I should create a new "enhancement" issue with the request for a new feature that will fix existing documents in which the objects are no longer snapped to the grid. I was thinking Modify-> Arrange-> Snap points to grid "This option will move every point in every selected object so that they land on the nearest currently defined grid point"
This Issue requires more information ('needmoreinfo'), but has not been updated within the last year. Please provide feedback as requested and re-test with the the latest version of OpenOffice - the problem(s) may already be addressed. You can download Apache OpenOffice 3.4.1 from http://www.openoffice.org/download Please report back the outcome of your testing, so this Issue may be closed or progressed as necessary - otherwise the issue may be Resolved as Invalid in the future.
I am not sure it will be possible to "replicate" the problem, since I don't know what caused it. Opening the test document in the much newer OO 3.4.0 shows the problem, but the issue is what was done at the time before it was saved. Something damaged the drawing. I believe that opening the test document and will always show the problem, regardless of which version or when. Acts the same with LO 3.5.5.3. The only way to truly test if it is fixed is if *newly* created Draw documents never get corrupted such that the objects lose their snap or the grid moves slightly without moving the objects. It is hard to prove a negative. The issue was certainly not invalid, but I can understand if you want to close it now. At least it will hang out there for future reference and can be reopened if someone else discovers the same problem, but with newer versions of Draw.