[xep-support] floats

G. Ken Holman gkholman at CraneSoftwrights.com
Sun Jul 8 08:44:03 PDT 2007

At 2007-07-08 14:41 +0100, Dave Pawson wrote:
>On 08/07/07, G. Ken Holman <gkholman at 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 at 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 at 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

More information about the Xep-support mailing list