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