Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||problem with locked height/width-ratio|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||blockopenoffice.1.urwald, issues, kpalagin, Mathias_Bauer, os_ooo, pavel, werbung|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
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 option!
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). Regards,
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 http://www.openoffice.org/issues/show_bug.cgi?id=25391 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 used. (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 ? Thanks,
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! WBR, KP.
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? WBR, KP.
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 freeze!).
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