Hmm, not sure what to do with this. You're essentially replicating what we do in the area tree of FOP Trunk where areas are adjusted in width once the page number is known, except that we have more info about an area in the area tree than you have in iText. However, this approach does not work satisfyingly every time, yet. There's room for improvement, but I think we may need to resort to a full two-pass/multi-pass mechanism where the first pass only records the page numbers which are then filled in the second pass. I'd rather you invested that kind of energy into the FOP source code instead of home-brewing. Improving FOP Trunk is clearly a better way for that kind of investment. If you reconsider your current plan, I can dump everything I have in my head about the multi-pass approach onto a Wiki page.
It would really be cool if people thought twice before starting some kind of work-around instead of trying to fix FOP. On 12.05.2006 11:02:25 Foucault, Sebastien wrote: > Hello, > > Here is the complex problem I have to deal with. > > A few month ago, I encountered the well-know performance issue due to > forward references when using fo:page-number-citation to include in document > footers the number of pages of the generated documents. > > To cope with this issue, we recently changed the way to handle that feature. > For that, we simply replaced the fo:page-number-citation by a text marker > included in an fo:block (<fo:block>¤</fo:block>) and post-processed the PDF > using iText to substitute the "¤" character by the real number of pages. > > It works perfeclty except for following aspect. Because the length of the > marker and the length of the substituted string are not the same, in some > situation, the length increase generates an offset of text areas located > after the marker (in another fo:block). > > The precise situation in which the problem occurs is the following : > > <table> > ... > <table-row> > ... > <table-cell><fo:block>¤</fo:block></table-cell> > ... > <table-cell><fo:block>Another cell</fo:block></table-cell> > </table-row> > ... > </table> > > It seems that the PDF contains a single area with all the elements of the > row (I'm not familiar at all with the internals of the PDF format). > > My question is the following : is there a way to force FOP to generate two > distinct areas in the PDF making the substitution impacts of the length > increase neutral toward other cells position of the same row. > > Thank's in advance > > PS : I use FOP 0.20.5 > > > Regards > -- > Sébastien FOUCAULT > > > Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
