Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | 0.01 cm displacement when pasting | ||
---|---|---|---|
Product: | Draw | Reporter: | Unai <unai> |
Component: | editing | Assignee: | Armin Le Grand <Armin.Le.Grand> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | Major | ||
Priority: | P3 | CC: | Armin.Le.Grand, rb.henschel, unai |
Version: | 3.4.0 | Keywords: | needmoreinfo |
Target Milestone: | 4.0.0 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- | ||
Issue Depends on: | |||
Issue Blocks: | 121425 |
Description
Unai
2012-07-28 10:25:30 UTC
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. |