I'm beginning to feel I've stirred a hornet's nest. Not sure if that's
a bad thing though. ;)
On 06/13/2011 03:54 PM, Andreas L. Delmelle wrote:
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
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.
On 10/06/11 18:32, Andreas L. Delmelle wrote:
> 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:tab
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,
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 poin
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
Consider this thread closed, though I find the news that fo:table-row calls
don't generate area both enlightening and conf
On 10 Jun 2011, at 18:40, Rob Sargent wrote:
Hi Rob
>
> Consider this thread closed, though I find the news that fo:table-row calls
> don't generate area both enlightening and confusing.
It is literally defined so in the Recommendation: see "Areas" at
http://www.w3.org/TR/xsl/#fo_table-row.
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 AM,
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
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: fop-users-unsubscr...
10 matches
Mail list logo