Issue 21284 - problem with locked height/width-ratio
Summary: problem with locked height/width-ratio
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 1.1
Hardware: PC Windows XP
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 22168 22577 53574 (view as issue list)
Depends on:
Reported: 2003-10-15 21:57 UTC by norbert2
Modified: 2017-05-20 11:15 UTC (History)
7 users (show)

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

Screenshot (10.53 KB, application/octet-stream)
2003-10-15 21:58 UTC, norbert2
no flags Details
Proposed patch to fix this issue (1.63 KB, text/plain)
2007-04-01 18:16 UTC, mloiseleur
no flags Details
second patch, works only for metrics, the PercentField component needs a patch too. (3.83 KB, text/plain)
2007-07-15 17:51 UTC, mloiseleur
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description norbert2 2003-10-15 21:57:25 UTC
There is a chekcbox "Abgleich" in the german version in the graphic-options-
window (screensot), that should lock the height/width-ratio. But if I increase 
the hight or width so that the other dimension which is automatic increased 
due to this option reaches its limit (254%), the increasing is not stopped. 
The result is a changed height/width-ratio that should be prevented by this 
Comment 1 norbert2 2003-10-15 21:58:36 UTC
Created attachment 10351 [details]
Comment 2 jack.warchold 2003-10-17 10:23:15 UTC
confirmed on OOo1.1

if keep ratio is checked just press the up button of the lowest value. 
this increases even if the higher value reaches the max relativ value.

same with decreasing the values.

reassigend to os
set status to new
set target to OOo later
Comment 3 Oliver Specht 2003-10-17 10:29:19 UTC
Comment 4 jack.warchold 2003-11-07 09:59:05 UTC
*** Issue 22168 has been marked as a duplicate of this issue. ***
Comment 5 jack.warchold 2004-03-01 10:51:50 UTC
*** Issue 22577 has been marked as a duplicate of this issue. ***
Comment 6 t_morley 2004-06-30 13:37:13 UTC
Just stumbled on the same problem. This comment is to confirm that the problem 
is still present in OOo 1.1.1 (running on WinXP).
Comment 7 sci 2005-08-12 09:15:31 UTC
This comment is to confirm that the problem is still present in OOo 1.9.122
(running on WinXP). Would be nice if priority / target milestone could be set 
higher / earlier.
Comment 8 michael.ruess 2005-08-22 11:25:25 UTC
*** Issue 53574 has been marked as a duplicate of this issue. ***
Comment 9 mloiseleur 2007-04-01 18:16:14 UTC
Created attachment 44135 [details]
Proposed patch to fix this issue
Comment 10 mloiseleur 2007-04-01 18:17:48 UTC
Hello there,

   Here is a small fix to this issue. This issue was also present without
percentage ratio. The patch fix both case for both box (width and height).

Comment 11 Oliver Specht 2007-04-02 07:01:04 UTC
Issue type changed to patch
Target changed to 2.3
Comment 12 kpalagin 2007-04-04 19:33:56 UTC
*** Issue 25391 has been marked as a duplicate of this issue. ***
Comment 13 kpalagin 2007-04-04 20:17:58 UTC
Issue with 9 dups and 
10 votes is dup of this one (21284).
Comment 14 Oliver Specht 2007-04-12 10:24:29 UTC
->mloiseleur: The patch doesn't work correctly. 
The line 
if ( nHeight != aHeightED.Denormalize(aHeightED.GetValue(FUNIT_TWIP)) )
ignores rounding errors that will almost always occur when metric measurement is
(the same applies to the width check) 
I'd suggest to set a max. Value to the width/height controls.

->kapalagin: I doubt that issue 25391 is a duplicate of this one. The problem
mentioned there is not related to relative values higher than 254%
Comment 15 mloiseleur 2007-04-12 18:07:28 UTC
os : Are you sure of your point ? 
The value I have seen was an int64 one, not a float or a double. Do you mean
during the normalize/denormalize step ? I have taken a look at the
Normalize/Denormlize methods, and, according to my understanding, they take care
of the problem. 
The code is in vcl/source/control/field.cxx:635.

But ok, let's say I am a noob and I didn't understand those 2 methods.
My first try was to see if this was possible to return a boolean during a set,
but oh my god : the SetPrcntValue call 5 methods before getting a
NumericFormatter::ImplSetUserValue in vcl/source/control/field.cxx:568.

So I have left this way but I don't have any other : I don't really understand
your suggestion. There is alreday a max setted for both values (the max an
unsigned char can support : 254). Would you please be more precise for a noob
like me ?

Comment 16 Oliver Specht 2007-04-13 08:30:21 UTC
->mloiseleur: Make width absolute and height relative. Change the width.
The height field gets the new value as percent value. The comparison is based on
the twip value. Therefor the aHeightED.GetValue(FUNIT_TWIP) converts the
relative back to an absolute value. This does result in rounding errors. My
comment was not based on guessing but on actually doing that;-)

With max-settings I mean the max height and width have to be set according to
the possible 254%. They are currently set in RangeModifyHdl according to the
absolute possible size. 
Comment 17 Mathias_Bauer 2007-05-14 09:17:50 UTC
@mloiseleur: are you still working on this patch? Or should we leave it up to OS
to fix the problem and set the type to "DEFECT"?
Comment 18 mloiseleur 2007-05-14 09:21:39 UTC
the fact is that I have searched but did not found how to do what os wants. 
I have not found how to get and set the good max value for both controls.

Comment 19 Mathias_Bauer 2007-05-14 09:33:32 UTC
Oliver, can you give hint? 
Comment 20 Mathias_Bauer 2007-06-06 11:29:02 UTC
Seems I forgot to cc: Oliver. :-[
Comment 21 Oliver Specht 2007-06-11 09:29:47 UTC
->mloiseleur: In RangeModifyHdl() there are the lines (around line 1870): 

		SwTwips nTmp = aHeightED.Normalize(nMaxHeight);
		aHeightED.SetMax(nTmp, FUNIT_TWIP);
		nTmp = aWidthED.Normalize(nMaxWidth);
		aWidthED.SetMax(nTmp, FUNIT_TWIP);

They set the max. Value of the controls to a maximum allowed value of the object. 
At this point depending on the 'relative' checkboxes these maximum values have
to be reduced to a value that equals 254 percent. They should be 2.54 times the
GetRefValue() of the MetricField. This RefValue is set some lines above.
Comment 22 Mathias_Bauer 2007-06-27 12:01:34 UTC
mloiseleur: do you think that the comment from Oliver is enough to help you?
Comment 23 mloiseleur 2007-06-27 17:01:11 UTC
-> mba  : yes, I just need some times.
Comment 24 Mathias_Bauer 2007-06-27 17:37:48 UTC
Fine, I just wanted to make sure that it's nothing on our side that might hinder
you. Don't feel pushed. :-)
Comment 25 mloiseleur 2007-07-15 17:49:38 UTC
Well ... It seems I manage to put the good Max, but the component PercentField
is so obscure and not consistent : I feel like that when I fix on the right
side, the left side becomes broken.
The patch is not so easy, but I'll do it, even If I have to rewrite the
PercentField component entirely ;).

  You'll find in the attachment the patch for the frmpage.cxx side. The patch
for pctfield.cxx is on this way. With this current patch, you have the correct
limits _only_ in metric mode.

Comment 26 mloiseleur 2007-07-15 17:51:48 UTC
Created attachment 46803 [details]
second patch, works only for metrics, the PercentField component needs a patch too.
Comment 27 pavel 2007-08-02 12:43:42 UTC
What is the status of this issue please?

It has target 2.3. The code freeze for 2.3 is today. What cws is this in?

Please adjust target accordingly.
Comment 28 mloiseleur 2007-08-02 12:46:20 UTC
Updated target, it will take some more time.
Comment 29 parity 2007-10-06 18:38:39 UTC
Is this issue correlated to issue 64137 in which graphics are not resized
correctly when they are in a frame?
Comment 30 kpalagin 2007-12-16 17:58:52 UTC
Michel, Oliver, Mathias,
are we on track for 2.4 with this patch?

Thanks a lot for your effort!
Comment 31 mloiseleur 2007-12-17 17:15:26 UTC
-> kpalagin : from my side, not at all. The code needed for an all-case patch is
too heavy for my little brain.
Comment 32 kpalagin 2007-12-19 12:18:14 UTC
Code freeze for 2.4 is on 17th of January.
Is there a chance you can make it so that this highly desired feature would 
not slip to September 2008?

Comment 33 Mathias_Bauer 2007-12-19 12:26:17 UTC
"Highly" desired? Hard to judge. It is a bug, yes. We have much more of them. It
has zero votes and only a few dupes. So "highly desired"? I don't see data
backing that up. My personal assessment is: this is an issue of medium
relevance. I would have been pleased to see the fix in 2.4 but I don't get
sleepless nights if it the target is moved to 3.0.

As the patch seems to be stopped and nearly all developers of the Writer team
are on vacation now I doubt that we will have a fix for 2.4. Given the limited
interest I also doubt that QA would accept a fix so late (last week before code
Comment 34 kpalagin 2007-12-19 13:00:47 UTC
Well, maybe you are right - 3 duplicates are not that much. 
Comment 35 Mathias_Bauer 2008-01-09 16:59:23 UTC
So it seems that this will be something for 3.0
Comment 36 Mathias_Bauer 2008-04-15 10:04:23 UTC
As mloiseleur doesn't continue, I assign this issue as "DEFECT" to os.
Comment 37 Mathias_Bauer 2008-04-25 11:19:04 UTC
target 3.x
Comment 38 Marcus 2017-05-20 11:15:26 UTC
Reset assigne to the default "".