Hi Simon,

2006/8/17, Simon Pepping:
> >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 <=
ipd(ref-area).

Hmmm. If the ipd of a float is greater than ipd(ref-area), then it /is/
allowed to stick out at one side (end-side for start-floats, start-side
for end-floats). On the contrary, if ipd <= ipd(ref-area), then the
float is not allowed to stick out at any side. That's why there is the
condition. Don't you agree?


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.

Same here: x must be >= 0 unless ipd > ipd(ref-area).

Re-thinking of that, I think the normative wording of rule 7 actually is
correct, even if it doesn't say exactly the same thing as the
non-normative one; when coupled with rule 9, it becomes equivalent.
I think I'm going crazy.


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

Well the illustration was making sense when rule 7 was written the
previous way. Now it could well be removed... unless I rewrite rule 7 as
previously.


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

Will add a word.


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

And deactivate the node if it turns out that this linebreak corresponds
to (e.g.) the next-to-last line of the paragraph? Hmmm, that could work.
I'll think about that.


Thanks,
Vincent

Reply via email to