[Patch] Webcore bug 3587: Frameset size calculation does not resize or distribute evenly

[Niels Leenheer]

On 6/22/05, Maks Orlovich <maksim at cs.cornell.edu> wrote:
> On Tuesday 21 June 2005 22:25, Maks Orlovich wrote:
> > On Tuesday 21 June 2005 22:04, George Staikos wrote:
> > > On Tuesday 21 June 2005 08:02, Niels Leenheer wrote:
> > > > Attached is a ported KHTML version of the patch attached to for
> > > > Webcore bug 3587:
> > > > http://bugzilla.opendarwin.org/show_bug.cgi?id=3587
> >
> > This one is supposed to fix http://bugs.kde.org/show_bug.cgi?id=60113; I
> > can not comment on the implementation, though, as I don't understand it...

Yes, this problem is fixed by the new calculation algorithms. The
first thing the algoritm does is to add up all fixed frame lengths. In
case of the example:
*,900,100,* this means the total length is 1000.

Assumption A: we have a view of 750 pixels. The total length is
reduced in proportion. So 900,100 becomes 675,75. Then we look a
frames with percentages of which there are none. And finally we look
at relative frames of which we have two. Unfortunately there is no
space remaining, so these two columns will become 0px. The result:
0,675,75,0.

Assumption B: we have a view of 1500 pixels. After we substract the
total fixed length from the total view we still have 500 pixels
remaining. Then we look a frames with percentages of which there are
none. And finally we look at relative frames of which we have two. We
need to spread the remaining view evenly over the two relative
columns, making each exactly 250 pixels. The result: 250,900,100,250.
 
> http://bugs.kde.org/show_bug.cgi?id=69074 may or may not be fixed by it, don't
> know..

Unknown. The website exhibiting this problem is no longer online and
there is no reduced testcase attached to the bug.

-----------------------------

> > #3370 one addresses http://bugs.kde.org/show_bug.cgi?id=76530 (I can
> > probably commit that one after some testing after we exit the
> > regression-sort-out-freeze)

Correct. if the parser encounters digits, it will skip any whitespace
before it checks for the presence of a '%'. So '22 %' will be
interpreted as 22%.

> Likely also fixes #61823... Niels, it handles " *" for a width
> properly, right?

Yes, if the parser encounters "   *" it will skip over all the initial
spaces until it encounters a non-space character. Then it will skip
over all digits, of which there are non. This triggers a check for the
current character. If it is '*' it will be interpreted at Length(1,
Relative).

BTW the patch containing the new length parser was committed today to Webcore.

Niels
niels.leenheer at gmail.com