|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Vertical Position display wrong for vertical elongation nearby page size | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Draw | Reporter: | Rainer Bielefeld <rainerbielefeld_ooo_qa> | ||||||
| Component: | ui | Assignee: | christian.guenther | ||||||
| Status: | CLOSED FIXED | QA Contact: | issues@graphics <issues> | ||||||
| Severity: | Trivial | ||||||||
| Priority: | P2 | CC: | issues, kpalagin, philipp.lohmann | ||||||
| Version: | OOo 2.2 RC2 | Keywords: | regression, release_blocker | ||||||
| Target Milestone: | OOo 2.3 | ||||||||
| Hardware: | PC | ||||||||
| OS: | All | ||||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||
| Developer Difficulty: | --- | ||||||||
| Attachments: |
|
||||||||
|
Description
Rainer Bielefeld
2007-03-10 12:14:16 UTC
No problem with with "2.0.2 German version WIN XP: [680m5(Build9011)]", so REGRESSION. this makes DRAW unusable for technical sketch and other applications, where an exact positioning is required grid snap works too imprecisely for this), so release_blocker; at least my company will not use a version where this is not fixed. Related to Issue 75086? Created attachment 43636 [details]
sample document
I was able to reproduce the problem with 2.2RC2 on an other PC The problem already existed with "2.2.0 Dev. Snapshot WIN XP: [680m7(Build9118)]" Reproducible. Reassigned. As this issue is regression maybe it deserves 2.2.1 target? AW: Checked: Happens with m204, does not happen in m145. AW->PL: It's in the position and size dialog, maybe it has to do with the changes for the input field values for integer values? Actually the problem gets introduced by the fixes for issue 69437 and issue 71046 . The normalization now done in SetMinMaxPosition actually seems to be wrong since maRect already is in normalized coordinates. However removing the normalization again (see attached patch), will open up issue 69437 again, the reason being twofold - first the rectangle gotten in SvxPositionSizeTabPage::Construct is too small; it won't allow the rectangle to be lower. This might be a calc issue, or perhaps drawing layer. - second you're in trouble anyway if the maRect member of SvxPositionSizeTabPage is in normalized values, because to profit from the MetricField now being 64 bit capable you'd need to have a Rectangle that is also able to hold 64 bit values. As far as I can see this issue can only be solved by changing SvxPositionSizeTabPage so its Rectangle and other members are changed to be 64 bit capable and second, the (false?) reported Rectangle in the :Construct method needs to be correct. And of course the appended patch needs to be applied since it will remove the wrong normalization in SetMinMaxPosition. Also in the current state I would consider this a 2.2.1 issue. Created attachment 44489 [details]
patch to remove wrong normalization in SetMinMaxPosition
AW: I see, i will be the one who has to redefine large parts of the PosSize Dialog. Internal usages of Rectangle and Point are at their end, changing to basegfx::B2DRange and basegfx::B2DPoint will be needed. The internal usages of SetValue() and SetMetricValue() together with conversions between UI and pool units and scalings will need to be redefined to use more precision. Doing that AFAIC... AW: This was hard. I have it running now, most stuff expanded to double precision/int64. Seems to work well, also checked with PL and the old bug (#i69437#) which is also fixed wit this change. AW: Checking in... AW: Okay, done. AW->WG: Please verify, just as described. AW: WG asked me for changing to CGU, doing so. I reopen the issue. The bug still occures in cws aw051. Please have a look again. AW: Okay, taking a 2nd look... AW: OOOkay, a 2nd look was worth the trouble. I found out that the basic error is not the numeric (also needed to be fixed, so it stays), but the normalization (in the sense of SpinField value, not linear algebra :-) of the min/max values for size and position. This leaded to a scaling of the values by 100. Since in the example the minY value gets bigger 0 (not negative) due to the object height, it seems smaller then the minimum which was scaled by 100. This is the reason the minimum gets corrected even when not necessary. AW: Setting pl on copy, he might be interested. AW: Checking once more with the fixed version... AW: Okay, checking in. Building CWS... AW->CGU: Corrected, please verify. CGU: Verified in cws aw051 CGU: integrated in src680m228 and oog680m5 |