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