How to determine which block are fo:table-row from XML-AT output?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

How to determine which block are fo:table-row from XML-AT output?

rsargent
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to determine which block are fo:table-row from XML-AT output?

Vincent Hennebert-2
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
area. What exactly do you need to do?


Vincent

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to determine which block are fo:table-row from XML-AT output?

rsargent
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, Vincent Hennebert wrote:

> 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
> area. What exactly do you need to do?
>
>
> Vincent
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to determine which block are fo:table-row from XML-AT output?

Andreas Delmelle-2
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 and confusing.

It is literally defined so in the Recommendation: see "Areas" at http://www.w3.org/TR/xsl/#fo_table-row.

I can see what you mean.
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.


Regards

Andreas
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to determine which block are fo:table-row from XML-AT output?

rsargent
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 and confusing.
> It is literally defined so in the Recommendation: see "Areas" at http://www.w3.org/TR/xsl/#fo_table-row.
>
> I can see what you mean.
> 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.
>
>
> Regards
>
> Andreas
> ---
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to determine which block are fo:table-row from XML-AT output?

Christopher R. Maden
In reply to this post by Andreas Delmelle-2
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.

I hadn’t really thought about that.  But IMO, the ID ought to attach to
the first cell within the row.  More generically, if any FO element has
an ID but no area, the ID ought to attach to the first area generated by
any of its descendants.

That raises the possibility of a single area having multiple IDs... is
that a problem in PDF?

~Chris
--
Chris Maden, text nerd  <URL: http://crism.maden.org/ >
“Before I built a wall I’d ask to know / What I was walling in or
 out, / And to whom I was like to give offence.” — RF, Mending Wall
GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to determine which block are fo:table-row from XML-AT output?

Andreas Delmelle-2
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 currently have no location
>> in the area tree that ref-ids can point to.
>
> I hadn’t really thought about that.  But IMO, the ID ought to attach to
> the first cell within the row.  More generically, if any FO element has
> an ID but no area, the ID ought to attach to the first area generated by
> any of its descendants.

Indeed! Just pondering over that here, too. Perhaps it's not that much of a challenge, after all.

> That raises the possibility of a single area having multiple IDs... is
> that a problem in PDF?

I don't think this is an issue. As far as I recall, the id is only used internally to track locations on pages. As far as PDF is concerned, if the id is never referenced, it does not result in anything even being written to the stream (unless a fox:destination is used to externalize it).

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 prod-id is FOP proprietary anyway, I don't immediately see anything against a convention of allowing this to be a separated list of producer-ids.



Regards

Andreas
---

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to determine which block are fo:table-row from XML-AT output?

Vincent Hennebert-2
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: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.
>>
>> I hadn’t really thought about that.  But IMO, the ID ought to attach to
>> the first cell within the row.  More generically, if any FO element has
>> an ID but no area, the ID ought to attach to the first area generated by
>> any of its descendants.
>
> Indeed! Just pondering over that here, too. Perhaps it's not that much of a challenge, after all.
>
>> That raises the possibility of a single area having multiple IDs... is
>> that a problem in PDF?
>
> I don't think this is an issue. As far as I recall, the id is only used internally to track locations on pages. As far as PDF is concerned, if the id is never referenced, it does not result in anything even being written to the stream (unless a fox:destination is used to externalize it).
>
> 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 prod-id is FOP proprietary anyway, I don't immediately see anything against a convention of allowing this to be a separated list of producer-ids.

Section 6.1.1 of the XSL-FO 1.1 Recommendation [1] mentions the
‘generated-by’ and ‘returned-by’ traits that XSL-FO processors are
supposed to create, and that would probably prove handy in such
situations.

[1] http://www.w3.org/TR/xsl11/#define-returned-by


> Regards
>
> Andreas


Vincent

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to determine which block are fo:table-row from XML-AT output?

Andreas Delmelle-2
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 prod-id is FOP proprietary anyway, I don't immediately see anything against a convention of allowing this to be a separated list of producer-ids.
>
> Section 6.1.1 of the XSL-FO 1.1 Recommendation [1] mentions the
> ‘generated-by’ and ‘returned-by’ traits that XSL-FO processors are
> supposed to create, and that would probably prove handy in such
> situations.
>
> [1] http://www.w3.org/TR/xsl11/#define-returned-by

Interesting catch! Yep, generated-by almost seems synonymous to the current prod-id, if we substitute the 'formatting object' with its 'id'. Granted, we do not auto-generate ids just yet...

For the returned-by trait, in order to be able to serialize/externalize it, there is obviously the question of the format for the separator. Have to make sure to point out to users that they should preferably not use those (sequences of) characters in values for the 'id' property, if they use the AT or IF formats. Or at least, make the implementation robust enough to account for the (remote) possibility of brackets and commas appearing in an ID.


Regards

Andreas
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to determine which block are fo:table-row from XML-AT output?

rsargent
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 "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 prod-id is FOP proprietary anyway, I don't immediately see anything against a convention of allowing this to be a separated list of producer-ids.
>> Section 6.1.1 of the XSL-FO 1.1 Recommendation [1] mentions the
>> ‘generated-by’ and ‘returned-by’ traits that XSL-FO processors are
>> supposed to create, and that would probably prove handy in such
>> situations.
>>
>> [1] http://www.w3.org/TR/xsl11/#define-returned-by
> Interesting catch! Yep, generated-by almost seems synonymous to the current prod-id, if we substitute the 'formatting object' with its 'id'. Granted, we do not auto-generate ids just yet...
>
> For the returned-by trait, in order to be able to serialize/externalize it, there is obviously the question of the format for the separator. Have to make sure to point out to users that they should preferably not use those (sequences of) characters in values for the 'id' property, if they use the AT or IF formats. Or at least, make the implementation robust enough to account for the (remote) possibility of brackets and commas appearing in an ID.
>
>
> Regards
>
> Andreas
> ---
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]