xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Hennebert" <vhenneb...@gmail.com>
Subject Re: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert
Date Tue, 15 Aug 2006 19:32:14 GMT
Hi Simon,

> Vincent,
>
> This page represents a good piece of work.
>
> First some nit picking regarding language:
>
> 'A, if X; B, else': change else -> otherwise (2x)
>
> 'We may choose to either differ a side-float, or ...': change differ -> defer

Thanks. Changed.


> 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.


> 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.


> Finally some thoughts on a possible algorithm:
>
> The algorithm should combine pagebreak and linebreak calculations in a
> single dynamic calculation:

Yes, I think we should try to find something like that.


> 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.

>
> It is just a rough idea. I have no clear picture what the linebreak
> calculation in combination with side floats looks like. I just have
> the feeling that it should be possible in principle. Obviously, it may

Yes. I think the biggest problem is to decide when to defer a float or
not. Otherwise, as new floats have no impact on already computed lines
the current line-breaking algorithm won't have to be too much reworked.

Of course, I'm not speaking of values other than "line" for the
intrusion-displace property. I don't even want to think about the other
values...


> be necessary to break a paragraph into lines several times, each time
> with a different side float layout. It will be necessary to store
> earlier linebreak calculations for a paragraph in a clever way, so as
> to avoid unnecessary recalculations for identical linewidths. Working
> this out into a realistic algorithm requires much more thinking.
>
> Regards, Simon

Thanks for your comments, Simon.

Vincent

Mime
View raw message