Re: [xep-support] Rookie question: full page table

From: Eliot Kimber <ekimber@innodata-isogen.com>
Date: Thu Feb 09 2006 - 04:08:35 PST

Werner Donné wrote:
> Hi Tomas,
>
> You can add a block-container, containing only a non-breaking space,
> to the end of your last cell and set the height of the block-container
> to "100%".

This works with XEP but I'm not sure it should. I tested it with XSL
Formatter and Altova XML2PDF V3Beta and they both behave the same way in
that the block container is placed on the next page where it takes up
100% of the available space (that is, the block-progression-dimension
extent of the region-body).

Before I looked at the spec, I thought
block-progression-dimension="100%" meant "the full extent of the
containing reference area". However, the spec says "The percentage is
calculated with respect to the corresponding dimension of the closest
area ancestor that was generated by a block-level formatting object. If
that dimension is not specified explicitly (i.e., it depends on
content's block-progression-dimension), the value is interpreted as
"auto"." (This is consistent in the 1.0 and latest 1.1 specs).

This is text taken straight from CSS2 so I'm not sure exactly what
"generated by a block-level formatting object" means, but I think it
means in this context the table cell, which is the nearest ancestor.
Table cells establish reference areas so I think its unambiguous that
the table cell's bpd is what the block container's bpd is a percentage
of. As the the cell's bpd is unspecified, I think the "interpreted as
'auto'" provision would apply here, in which case the block container
should be at most one line deep, taking up neither the whole page nor
the remainder of the page.

So by this initial analysis, I think everybody has it wrong, just in
different ways.

It would probably be useful to have a bpd value of "remaining" or
"available" or something like that that expresses the desired result.
But given that feature, it would be specified on the table cell, not on
a block container with in it.

I think this needs further investigation.

At a minimum Werner's approach is not currently portable across FO
implementations.

Cheers,

E.

-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8841
ekimber@innodata-isogen.com
www.innodata-isogen.com
-------------------
(*) 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
Received on Thu Feb 9 04:37:07 2006

This archive was generated by hypermail 2.1.8 : Thu Feb 09 2006 - 04:37:08 PST