Re: [xep-support] floats

At 2007-07-08 14:41 +0100, Dave Pawson wrote:
>On 08/07/07, G. Ken Holman <gkholman@cranesoftwrights.com> wrote:
>>Because when your second list item is completely formatted, where are
>>you in the block progression direction? You are immediately after
>>the second list item.
>
>Except that I'm left with an unformatted float?

Sorry, not sure what you mean by that.

In one of my tests with your data I added a <block-container
width="8cm"> child of float and put your text in there so that it would wrap.

>The float is an out-of-line construct and
>>jumps out of the flow, so the block progression direction doesn't
>>move ... you are still at that point immediately *after* the second
>>item. Now you format a third item and it continues from the point in
>>the block progression direction, which is to the left of the float.
>
>"jumps out of the flow" :-)
>Not spec-ese Ken? But neither is my 'steals space from' !

:{)} But at least my wording works in front of my students when I
wave my arms in front of the classroom!

>Why should it finish the second list item *before* looking
>at formatting the float?

Because your <float> element comes after the </block> of text in the
list item. So, in the block progression direction your formatting
point is immediately after the text in the list item.

The float area therefore starts at the current flowing position in
the block progression direction, but because it is out of line it
doesn't move the current flowing position.

Another way of thinking about it, how would the processor know how
far back to go if the float was somehow associated with the flowing
of information that happened before it was encountered.

>>If you swap the float with the block in item two, then the float is
>>encountered at the start of the second list item,
>
>Thanks. Good clarification.
>
>Now I'm looking at the spec to see where this logic is defined!
>
>Is the 'plain English' version that the float steals space from
>the next fo in the block-progression-direction ?

Actually, it steals space from the next FO in the
inline-progression-direction and doesn't change place in the
block-progression direct. Unless, of course, the float is so very
wide that it grows as wide as the page, in which case there is no
room left for the following non-floated block, which then forces the
following non-floated block down the page. That was why I tested
with a block container constraining the width of the float.

Reading FO 1.1 Section 6.12.2 I note the bullet points following the
paragraph "The following constriants pply to fo:float formtating
objects that generate areas with area-class xsl-side-float". Here it
talks about the width of the float being the intrinsic width of child
areas (which is why I used a block container to constrain the width),
and it talks about the impact on intrusion adjustments described in
4.4.2 to "account for the indentation that occurs as the result of
side floats".

I think the text as written does an effective job of spelling it all
out. Thankfully my students understand "the float jumps out of the
flow" and I don't have to go into such gory detail.

I hope this helps.

. . . . . . . . . . . . Ken

--
Upcoming hands-on training:  UBL Oct 1-3,5, Code lists Oct 2, 2007
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/f/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/f/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html