On 13 Jun 2011, at 12:05, Vincent Hennebert wrote:
On 10/06/11 18:32, Andreas L. Delmelle wrote:
The area tree XML stores the specified id as a prod-id attribute. There
can definitely be multiple areas with the same prod-id, as a block can be
broken over multiple columns or pages.
Since
Wondering if it's possible to programmatically identify which blocks in
the areatree output correspond to fo:table-row calls, given that the
entire page is a single fo:table.
-
To unsubscribe, e-mail:
Hi Rob,
On 10/06/11 17:12, Rob Sargent wrote:
Wondering if it's possible to programmatically identify which blocks in the
areatree output correspond to fo:table-row calls, given that the entire page
is a single fo:table.
There’s no way AFAICT, as an fo:table-row element does not generate any
Thanks Vincent.
Related to the flow-sideways issue. A stab at an alternative: was
hoping grab to the block progression value of the row.
Consider this thread closed, though I find the news that fo:table-row
calls don't generate area both enlightening and confusing.
On 06/10/2011 10:28
Hello Andreas,
Thanks for the clarification and spec. reference.
On 06/10/2011 10:49 AM, Andreas L. Delmelle wrote:
On 10 Jun 2011, at 18:40, Rob Sargent wrote:
Hi Rob
snip /
Consider this thread closed, though I find the news that fo:table-row calls
don't generate area both enlightening
On 06/10/2011 12:49 PM, Andreas L. Delmelle wrote:
It does make perfect sense, but from FOP perspective, also poses the
challenge of properly implementing id on fo:table-row... Since
there is no area to attach the id to, we currently have no location
in the area tree that ref-ids can point to.
On 10 Jun 2011, at 18:55, Christopher R. Maden wrote:
Hi Chris
On 06/10/2011 12:49 PM, Andreas L. Delmelle wrote:
It does make perfect sense, but from FOP perspective, also poses the
challenge of properly implementing id on fo:table-row... Since
there is no area to attach the id to, we
