Apache OpenOffice (AOO) Bugzilla – Issue 21284
problem with locked height/width-ratio
Last modified: 2017-05-20 11:15:26 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!
Created attachment 10351 [details] Screenshot
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
.
*** Issue 22168 has been marked as a duplicate of this issue. ***
*** Issue 22577 has been marked as a duplicate of this issue. ***
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).
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.
*** Issue 53574 has been marked as a duplicate of this issue. ***
Created attachment 44135 [details] Proposed patch to fix this issue
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,
Issue type changed to patch Target changed to 2.3
*** Issue 25391 has been marked as a duplicate of this issue. ***
Issue http://www.openoffice.org/issues/show_bug.cgi?id=25391 with 9 dups and 10 votes is dup of this one (21284).
->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%
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,
->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.
@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"?
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.
Oliver, can you give hint?
Seems I forgot to cc: Oliver. :-[
->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.
mloiseleur: do you think that the comment from Oliver is enough to help you?
-> mba : yes, I just need some times.
Fine, I just wanted to make sure that it's nothing on our side that might hinder you. Don't feel pushed. :-)
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.
Created attachment 46803 [details] second patch, works only for metrics, the PercentField component needs a patch too.
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.
Updated target, it will take some more time.
Is this issue correlated to issue 64137 in which graphics are not resized correctly when they are in a frame?
Michel, Oliver, Mathias, are we on track for 2.4 with this patch? Thanks a lot for your effort! WBR, KP.
-> kpalagin : from my side, not at all. The code needed for an all-case patch is too heavy for my little brain.
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.
"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!).
Well, maybe you are right - 3 duplicates are not that much.
So it seems that this will be something for 3.0
As mloiseleur doesn't continue, I assign this issue as "DEFECT" to os.
target 3.x
Reset assigne to the default "issues@openoffice.apache.org".