Issue 75273 - Vertical Position display wrong for vertical elongation nearby page size
Summary: Vertical Position display wrong for vertical elongation nearby page size
Alias: None
Product: Draw
Classification: Application
Component: ui (show other issues)
Version: OOo 2.2 RC2
Hardware: PC All
: P2 Trivial (vote)
Target Milestone: OOo 2.3
Assignee: christian.guenther
QA Contact: issues@graphics
Keywords: regression, release_blocker
Depends on:
Reported: 2007-03-10 12:14 UTC by Rainer Bielefeld
Modified: 2007-09-21 17:33 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

sample document (8.69 KB, application/
2007-03-10 12:24 UTC, Rainer Bielefeld
no flags Details
patch to remove wrong normalization in SetMinMaxPosition (1.07 KB, patch)
2007-04-17 18:43 UTC, philipp.lohmann
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Rainer Bielefeld 2007-03-10 12:14:16 UTC
I checked with "2.2.0RC2  Multilanguage/German version WIN XP:
[680m9(Build9124)]"  and found out that the "Size and Position" dialogue does
not work correctly for objects with vertical elongation of more than (app.) 320mm. 

Steps to reproduce:
1. open attached "sample.odg" with 2.2RC2
2. click vertical line in the middle, so that control points appear.
3. rightclick on the line, select 'Position and Size'
   'Base point top left_ should be selected, position X/Y is "180" / "0"
4. Change 'Base point' to 'middle left', position display should change to 
5. Change 'Base point' to 'middle bottom', 
   expected: position display should change to "550mm" (= object height"
   actual:  position display changes to "24.300,00mm"

Additional tests with this line show:
- 'Base point middle bottom' is more or less unusable, changes in the input 
  pane will not be accepted.
- The problem is page size dependent, with setting "A3" you will get display 
  - 5.500,00mm for 'Base point middle left' 
  - 33.000,00mm for 'Base point middle left' 
  With setting "A4" you will get display 'Y-position'
  - -11.451,00mm or 'Base point top left'
  - 11.650,00mm for 'Base point middle left' 
  - 39.150,00mm for 'Base point middle left' 
  With setting "'A0' the problem disappears
- The problem is not limited to unit "mm", I also saw it with "cm" and "inches"

Lines with vertical elongation 
I did no see those problems for horizontal lines
The problem seems to be related to the relation '"vertical object size' to
'vertical page size'". If the object size  exceeds app. 2/3 of page size, the
problem appears.
Comment 1 Rainer Bielefeld 2007-03-10 12:19:59 UTC
No problem with with "2.0.2  German version WIN XP: [680m5(Build9011)]", so

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?
Comment 2 Rainer Bielefeld 2007-03-10 12:24:02 UTC
Created attachment 43636 [details]
sample document
Comment 3 Rainer Bielefeld 2007-03-10 13:27:18 UTC
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)]" 
Comment 4 wolframgarten 2007-03-12 09:06:07 UTC
Reproducible. Reassigned.
Comment 5 kpalagin 2007-03-18 02:43:29 UTC
As this issue is regression maybe it deserves 2.2.1 target?
Comment 6 Armin Le Grand 2007-04-11 16:49:43 UTC
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?
Comment 7 philipp.lohmann 2007-04-17 18:40:17 UTC
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.
Comment 8 philipp.lohmann 2007-04-17 18:43:18 UTC
Created attachment 44489 [details]
patch to remove wrong normalization in SetMinMaxPosition
Comment 9 Armin Le Grand 2007-05-03 14:47:31 UTC
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
Comment 10 Armin Le Grand 2007-05-03 15:14:18 UTC
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...
Comment 11 Armin Le Grand 2007-05-03 15:15:33 UTC
AW: Okay, done.
Comment 12 Armin Le Grand 2007-06-26 11:43:51 UTC
AW->WG: Please verify, just as described.
Comment 13 Armin Le Grand 2007-06-26 12:15:30 UTC
AW: WG asked me for changing to CGU, doing so.
Comment 14 christian.guenther 2007-07-05 19:35:37 UTC
I reopen the issue.
Comment 15 christian.guenther 2007-07-05 19:37:11 UTC
The bug still occures in cws aw051.
Please have a look again.
Comment 16 Armin Le Grand 2007-07-06 09:45:08 UTC
AW: Okay, taking a 2nd look...
Comment 17 Armin Le Grand 2007-07-06 16:34:46 UTC
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...
Comment 18 Armin Le Grand 2007-07-06 16:37:13 UTC
AW: Okay, checking in. Building CWS...
Comment 19 Armin Le Grand 2007-07-09 09:24:58 UTC
AW->CGU: Corrected, please verify.
Comment 20 christian.guenther 2007-07-09 16:21:19 UTC
CGU: Verified in cws aw051
Comment 21 christian.guenther 2007-09-21 17:33:14 UTC
CGU: integrated in src680m228 and oog680m5