Apache OpenOffice (AOO) Bugzilla – Issue 120393
0.01 cm displacement when pasting
Last modified: 2022-10-28 12:54:31 UTC
Scenario: You have a 1 cm grid with 10 subdivisions, thus having a 1 mm snap, because you want to be able to create objects aligned on a 1mm grid and you want to move them around with your keyboard arrow keys, staying 1mm-aligned. Let's say you have a line (or any other object, for that matter) at position 5.1/7.3. If you resize or move it around, it snaps at 1mm intervals, always keeping the tenths of mm to 0. However, if you copy such object and than paste it (because you need to clone it around), it's position will be misplaced by 0,01cm (0.1mm); in the previous example, it would be something like 5.09/7.31. Then if you move it around with your mouse or arrow keys (which do 1mm steps) you find yourself "out of phase" with the rest of the drawing (which respects snap rules). To work around this issue and fix alignment: right after pasting you have to manually enter "Position and Size" and fix the coordinates with a 1mm multiple. And that is a pain in the... buttocks. Especially if you have to do that hundreds of times. Furthermore, if you forget to do that for some objects, you'll end up with a drawing with misaligned objects: going on copy-pasting those, it will lead to an additional displacement, adding up to 0.2mm, 0.3mm and so on, drifting your lines towards chaos!).
I cannot confirm it. I use AOO3.4 on WinXP. Here the position and size of the copied object is identical to the original. Which operating system do you use?
Hi Regina, I'm using AOO 3.4 build 9590 on Windows 7 x64. I forgot to mention one important thing, in order to be able to reproduce the behaviour deterministically (which might have been intended as a feature when designed, but I only can see that as a defect): it only happens with lines (or, in general, objects) that have a thickness greater than zero. E.g. with hairline (0.00cm) lines, issue doesn't show up, while with 0.01cm lines (or greater) it does. I guess the point is that, instead of keeping into account actual vector-position of the line ("centered", disregarding of thickness), OO looks at the encumbrance/bulk (visual size taking thickness into account -- I don't know how to say that), which really makes very little sense, especially considering that line thickness is something you might want to (and will!) change over time (as opposed to your precise sub-millimeter alignment).
ALG: Indeed, happens e.g. with rectangle. With hairline, copy/paste is in the same place, with some linewidth it gets an offset. Need to investigate, taking over.
ALG: Took a look. Basic problem is that copy uses BoundRange to fill the clipboad data (which seems correct) while paste uses SnapRange to calculate the positions. There is an old comment at GetAllObjSnapRect usages mentioning task #104148#, but i could find no information about that old task other than it's from 2002. OTOH there is a hint on #112978# on GetAllMarkedBoundRect usage on copying with a reproducable problem (see there). I would argue that the full size (bound range) of the object is the correct data in the clipboard buffer, thus I tend to fix the paste part to also use bound range to make all correct again. Checking...
ALG: Checked that the paste position is the same with overboarding geometry (e.g. fat lines). Checked that the task #112978# is still solved. Looks good, preparing commit.
ALG: Okay, done.
ALG: Also adapted for aw080 since it would conflict there anyways with the new double precision tooling for ranges.