xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Pepping <spepp...@leverkruid.eu>
Subject Re: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert
Date Thu, 17 Aug 2006 20:16:31 GMT

On Tue, Aug 15, 2006 at 09:32:14PM +0200, Vincent Hennebert wrote:
> Hi Simon,
> >Vincent,
> >
> >This page represents a good piece of work.
> >
> >Then a comment on the rules:
> >
> >Rule 1. Why does the rule not require not both x >= 0 and x + ipd <=
> >ipd(ref-area), for both start and end floats, unless the float is
> >wider than the ipd(ref-area)? In other words, why is rule 7 not
> >required for any start and end floats?
> Hey, you're right. Ok, rule 1 is correct: a start-float may not stick
> out of the start-edge of the ref-area, period. The constraint on the
> opposite side is given by rule 7, which actually is badly phrased. More
> precisely, the formal wording is not equivalent to the loose wording
> given between parentheses. The loose wording is quite clear and
> intuitive; the formal wording forgets the case of a float alone: it's
> not because it is alone that it may stick out of the ref-area.
> Well, now that you've pointed it out this is pretty obvious... I've
> reformulated this rule according this time to the loose wording. Tell me
> if you don't agree.

Rule 7a is logically correct, but I would say that the rule simply
states that a start float should not stick out at the end side, even
if it is not the one that is flush with the start side. Then x + ipd
<= ipd(ref-area) follows even without the condition ipd <=

Rule 7b: the conclusion does not follow. The argument should be that
an end float should not stick out at the start side, so that x > =0.

> >In 'Properties of the model': I do not see that rule 7 is satisfied.
> A start-float begins at the end-edge of the ref-area and is pulled along
> this edge (which is like a wall). So by nature it may not stick out of
> this edge.
> What the illustration attempts to show is that if previous start-floats
> occupy too much place, then the new start-float will strike against
> their after-edges (the start-guide) without being able to go beforer.

I see now that the rules are satisfied. To show that it is only
necessary to point out that it is satisfied by the initial position,
and is not violated by subsequent movements. Whether it is stopped by
the start guide is not relevant in this argument.

You say nothing about the end floats. The argument is of course the

> >Finally some thoughts on a possible algorithm:
> >
> >for each legal pagebreak
> >  for each active pagebreak node
> >    layout the page and calculate its demerits
> >
> >Laying out the page involves breaking each paragraph on the page into
> >lines; each legal linebreak/active linebreak node combination (that
> >is, each iteration in the two nested loops of the linebreak
> >calculation) is associated with a certain side float layout, and thus
> >the line widths for that case are known and the demerits can be
> >calculated.
> One issue is that some legal pagebreaks are unknown until paragraphs are
> laid out (because of widows/orphans, for example). So the "for each
> legal pagebreak" is not that simple and might involve some backtracking.

Yes, there is a problem there. The solution could be as follows: When
the legal pagebreak is in a paragraph, it is also the considered legal
linebreak. It is tested whether this linebreak could end the last line
of the page.

Regards, Simon

Simon Pepping
home page: http://www.leverkruid.eu

View raw message