block-containers with BPD set

[Jeremias Maerki <de...@greenmail.ch>]

Thanks for all the comments so far on my questions. I'm afraid I have to
postpone some of the issues, however.

Now, I've got a different problem. I run accross a bug in layout
concerning block-containers with height/BPD specified
(absolute-position="auto"). I tried to fix it but I can't find the
passage in the spec that tells me how to deal with the space that is not
allocated by descendant FOs inside the block-container.

Is this space considered as part of the padding-after, and if yes with
what conditionality?

The problem is page/column breaking. Normal blocks can be broken between
lines which is probably also the case for plain block-containers (no
properties specified). But as soon as the BPD is predefined
(autoheight=false) it is unclear to me how to handle it.

I also saw that in the 1.1 WD there is an issue (see block-container)
that may be related to this, but it didn't help.

Any pointers are appreciated.

Jeremias Maerki

RE: block-containers with BPD set

[Victor Mote <vi...@outfitr.com>]

Jeremias Maerki wrote:

> Given a block-container where the BPD is specified, are its 
> children subject to column/page breaking if the whole 
> block-container doesn't fit into the available area in BP 
> direction? If yes, how is the remaining space in BP direction 

My reading of the passage cited is that, while it may be possible for there
to be more than one immediate child viewport, each of the immediate child
viewports fits into exactly one rectangle on one page, i.e. it cannot be
broken into more than one piece. Now, if by "children" you are referring to
(for example) a block object that is inside the block-container, then yes,
that block could generated areas that are inside more than one of the
immediate child viewport(s). In other words, the contents of the
block-container could flow from one viewport area to another, but each
viewport area itself must remain in one piece.

So, the direct answer to your question is (I think) "no". If the BP
constraints cannot be satisfied in the current column/page, the viewport
must be moved to a subsequent one. That may seem klunky, but the user can
prevent it by making the BPD a <length-range>.

> direction? If yes, how is the remaining space in BP direction 
> which is not taken up the BC's children to be handled?
> 
> The quote you provided above probably point in the right 
> direction. But I guess my problem is that I haven't found the 
> part of the spec, yet, that establishes this constraint for 
> block-progression-dimension. I've searched the spec back and 
> forth and haven't found anything. After a lot of thinking I 
> believe it's chapter 4.3.2 "Overconstrained 
> space-specifiers", but I don't understand how this explains 
> whether to do breaking inside the block-container or not.

AFAICT, space-specifiers aren't part of the question. In my mind
block-container is analogous to an external-graphic. You wouldn't split an
image into two pieces. If the user has said
block-progression-dimenension="6cm", he/she has deliberately placed a
constraint on the viewport. The default behavior is that there is no such
constraint, that the viewport expands and contracts as needed to contain the
contents.

The use-case for block-container may help also. Suppose you are rotating the
contents 90 degrees so that you can show, for example, a wide page in
landscape mode. You might want the contents to use the whole page, so
specifying the BPD/IPD allows you to insist upon that.

I'm not sure I am right about this, and don't mean to sound dogmatic. This
is just my understanding of the matter.

Victor Mote.

RE: block-containers with BPD set

[Victor Mote <vi...@outfitr.com>]

Andreas L. Delmelle wrote:

> In either case it seems to make little sense to speak of 
> 'remaining space'
> as in 'the space not allocated by descendant FOs inside the 
> b-c', unless you mean the space remaining on the _page_ after 
> the first child viewport for the b-c is added. The sum of the 
> b-p-d of the two child viewports will be five units, period.

Just to be clear (not argumentative), I was saying something quite
different. For the example that Andreas has given, my understanding is that
there would only be one child viewport area, containing the entire contents
of both blocks, but that it would be pushed onto the following column/page.
Only if the contents didn't all fit into the first viewport would additional
ones be created (and then only if the overflow properties are set properly).
The user has dogmatically told us how big the viewport(s) should be.

Victor Mote

RE: block-containers with BPD set

["Andreas L. Delmelle" <a_...@pandora.be>]

> -----Original Message-----
> From: Jeremias Maerki [mailto:dev.jeremias@greenmail.ch]


> ...Anyway, maybe I should ask the question in a different way:
>
> Given a block-container where the BPD is specified, are its children
> subject to column/page breaking if the whole block-container doesn't fit
> into the available area in BP direction?

So the question is, given an input like

fo:block-container b-p-d="5"
  fo:block
    block A, with b-p-d of max. 3 (specified/calculated?)
  /fo:block
  fo:block
    block B, with b-p-d of max. 2 (specified/calculated?)
  /fo:block
/fo:block-container

What should happen when the block-container as a whole doesn't fit on the
page, and the area for block A is too small to fill up all of the remaining
space (say, a remaining space of 4 units)? A space of at least one unit will
be carried over to the next page, but...
Should block B be split in two areas of one unit, or should the break occur
before the single area (2 units) for block B?
And what should happen with the space remaining after area A is added, and B
as a whole shifts to the next page?

> [Victor:]

> My reading of the passage cited is that, while it may be
> possible for there to be more than one immediate child viewport,
> each of the immediate child viewports fits into exactly one
> rectangle on one page, ... Now, if by "children" you are
> referring to (for example) a block object that is inside
> the block-container, then yes, that block could generate
> areas that are inside more than one of the immediate child
> viewport(s). In other words, the contents of the block-
> container could flow from one viewport area to another,
> but each viewport area itself must remain in one piece.

I very much agree with this assessment. It seems the answer lies in the fact
that:
a. either the second block is split over the two child viewports
b. or it is moved as a whole to the child viewport on the next page

In either case it seems to make little sense to speak of 'remaining space'
as in 'the space not allocated by descendant FOs inside the b-c', unless you
mean the space remaining on the _page_ after the first child viewport for
the b-c is added. The sum of the b-p-d of the two child viewports will be
five units, period.
In that case, the space of one unit could still play a role in the layout of
the nearest ancestor reference-area --may be the area generated by the
immediate parent FO, but could also be the current-page area.
In that context, the question of what to do with that extra space suddenly
becomes meaningful, but it may lead one to look for pointers in other places
...?


HTH

Greetz,

Andreas

Re: block-containers with BPD set

[Jeremias Maerki <de...@greenmail.ch>]

On 26.01.2005 18:43:58 Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > Now, I've got a different problem. I run accross a bug in 
> > layout concerning block-containers with height/BPD specified 
> > (absolute-position="auto"). I tried to fix it but I can't 
> > find the passage in the spec that tells me how to deal with 
> > the space that is not allocated by descendant FOs inside the 
> > block-container.
> > 
> > Is this space considered as part of the padding-after, and if 
> > yes with what conditionality?
> 
> BPD and IPD both specify the size of the content-rectangle, so no part of
> unused BPD could be considered part of padding.

Makes sense.

> > The problem is page/column breaking. Normal blocks can be 
> > broken between lines which is probably also the case for 
> > plain block-containers (no properties specified). But as soon 
> > as the BPD is predefined
> > (autoheight=false) it is unclear to me how to handle it.
> > 
> > I also saw that in the 1.1 WD there is an issue (see 
> > block-container) that may be related to this, but it didn't help.
> 
> I'm not sure I understand the question or know the answer. What I think you
> have described is an area with an absolute size and a relative position that
> does not fit in the current column or page, but that may not use all of the
> available BPD. Regardless of how well the contents fit inside the area,
> doesn't such an area have to be forced to the next page or column (unless it
> floats and can be moved so that it does fit)? The 1.1 spec (6.5.3) clarifies
> this a bit by saying "All generated viewport-areas are subject to the
> constraints given by the block-progression-dimension and
> inline-progression-dimension traits of the fo:block-container". I take this
> to mean that a block-container might generate more than one such
> viewport-area if the contents are too big to fit into one (subject to the
> 1.1 issue that you mention), but that, in any case, if the contents are too
> small, the generated viewport-area must meet the IPD and BPD constraints.
> The user can specify IPD and BPD as <length-range> if they want to allow the
> rectangle some flexibility in how it is sized.
> 
> HTH.

It does, at least a bit. Anyway, maybe I should ask the question in a
different way:

Given a block-container where the BPD is specified, are its children
subject to column/page breaking if the whole block-container doesn't fit
into the available area in BP direction? If yes, how is the remaining
space in BP direction which is not taken up the BC's children to be
handled?

The quote you provided above probably point in the right direction. But
I guess my problem is that I haven't found the part of the spec, yet,
that establishes this constraint for block-progression-dimension. I've
searched the spec back and forth and haven't found anything. After a lot
of thinking I believe it's chapter 4.3.2 "Overconstrained space-specifiers",
but I don't understand how this explains whether to do breaking inside
the block-container or not.

Thanks,
Jeremias Maerki

RE: block-containers with BPD set

[Victor Mote <vi...@outfitr.com>]

Jeremias Maerki wrote:

> Now, I've got a different problem. I run accross a bug in 
> layout concerning block-containers with height/BPD specified 
> (absolute-position="auto"). I tried to fix it but I can't 
> find the passage in the spec that tells me how to deal with 
> the space that is not allocated by descendant FOs inside the 
> block-container.
> 
> Is this space considered as part of the padding-after, and if 
> yes with what conditionality?

BPD and IPD both specify the size of the content-rectangle, so no part of
unused BPD could be considered part of padding.

> The problem is page/column breaking. Normal blocks can be 
> broken between lines which is probably also the case for 
> plain block-containers (no properties specified). But as soon 
> as the BPD is predefined
> (autoheight=false) it is unclear to me how to handle it.
> 
> I also saw that in the 1.1 WD there is an issue (see 
> block-container) that may be related to this, but it didn't help.

I'm not sure I understand the question or know the answer. What I think you
have described is an area with an absolute size and a relative position that
does not fit in the current column or page, but that may not use all of the
available BPD. Regardless of how well the contents fit inside the area,
doesn't such an area have to be forced to the next page or column (unless it
floats and can be moved so that it does fit)? The 1.1 spec (6.5.3) clarifies
this a bit by saying "All generated viewport-areas are subject to the
constraints given by the block-progression-dimension and
inline-progression-dimension traits of the fo:block-container". I take this
to mean that a block-container might generate more than one such
viewport-area if the contents are too big to fit into one (subject to the
1.1 issue that you mention), but that, in any case, if the contents are too
small, the generated viewport-area must meet the IPD and BPD constraints.
The user can specify IPD and BPD as <length-range> if they want to allow the
rectangle some flexibility in how it is sized.

HTH.

Victor Mote