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 Fri, 18 Aug 2006 17:04:56 GMT
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

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


View raw message