Re: How to determine which block are fo:table-row from XML-AT output?
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: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
How to determine which block are fo:table-row from XML-AT output?
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...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: How to determine which block are fo:table-row from XML-AT output?
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: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: How to determine which block are fo:table-row from XML-AT output?
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: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: How to determine which block are fo:table-row from XML-AT output?
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: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: How to determine which block are fo:table-row from XML-AT output?
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: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: How to determine which block are fo:table-row from XML-AT output?
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: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
