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
