This issue is at least partially addressed when I posted the code earlier today for my FOP extension element fop:WritePageNumber which currently I use to create a Table of contents and index for pdf books. The books are processed through FOP one "section", e.g. Introduction, Preface, Chapter 1, at a time. In each section numerous WritePageNumber elements are inserted with associated id's. When FOP encounters these elements, an XML file is created or appended to which has a series of elements, their id's, and the page numbers they occur on.
After all sections are processed, I can then generate the Table of Contents and Index from information in the XML file just created. With other references across sections a two pass system would work, wherein if "see page x in Document B" is encountered, a dummy value is inserted to keep the formatting relatively stable during the first pass. Then after all sections are processed, a second pass could grab the page number values from the xml file with the page numbers. This process could be made better in the case where Document B has been processed "before" the current reference to it, if I could figure out how to create a valid xml file from the start and merely insert the child elements into it. You could then check to see if the id already exists and, if so, insert the page number and if not wait until the second pass. This process works for TOCs and indexes so I don't see why it could be generalized some more. Anyhow, that's my 2¢ for what it's worth, Matthew L. Avizinis <mailto:[EMAIL PROTECTED]> Gleim Publications, Inc. 4201 NW 95th Blvd. Gainesville, FL 32606 (352)-375-0772 www.gleim.com <http://www.gleim.com> > -----Original Message----- > From: Victor Mote [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 31, 2002 3:23 PM > To: mailing list fop-dev > Subject: forward references & related design issues > > > FOP Developers: > > Seeing all of the posts about performance issues, esp. related to forward > references, has brought to mind some design musings I had on a > related topic > several months ago, a subset of a bigger issue that is important for work > that one of our clients does. They publish several related documents in a > collection, with cross-references between them -- for example, document A > might say "See page x in document B". Now if document A references 20 such > documents, one could conceivably end up with 21 documents in memory at the > same time, each being processed, and lots of fun dealing with dependencies > between them. I realize that FOP doesn't handle this scenario, > but thinking > through the solution to this problem might provide a general solution for > both issues. > > FrameMaker handles this issue very nicely. You actually have to > have all 21 > documents open at the same time (although I doubt that the entire document > is loaded into memory). However, FrameMaker lives in a state where its > layout is already computed and stored, so all it has to do is lookup the > page object related to a target. It seems that what is needed for FOP (and > probably XSL-FO in general) is an XML document that contains this target > information (and perhaps other formatting-specific information as > well). FOP > would have to run once to compute the targets & write this XML > target file, > then run again to use it. This XML document can be serialized and persist, > so that it can be used in the rendering of other documents that > might point > to its parent. The user would have to be responsible to make sure that the > XML document containing the targets is properly updated before being used. > (FOP would need a mode that, instead of rendering the document, merely > recomputed the target file -- thus a series of documents could be > recomputed > before any of them are rendered). > > Obvious issue #1: The content of the target can change the layout of the > document, and thereby change the location of the target. The > layout manager > must explicitly or implicitly estimate the size of the text so that it can > continue with the layout work on subsequent pages. This issue > exists whether > the information is stored in memory or written to a file, so this is not > really an issue with the proposed solution. > > Obvious issue #2: Some (perhaps most) documents will not benefit from a > 2-pass solution and persistent layout information. This could be > handled in > a configuration option (for defaults), and a command-line option (for > overrides). > > Obvious issue #3: Development time. I am not up to speed on the FOP > implementation yet, so I don't have a good feel for this issue. However, I > see that performance is one of the goals of the redesign, and this might > help with that in some cases. > > Obvious issue #4: Standards compliance / extensions. This or something > similar that addresses cross-document references is probably > needed as part > of the XSL-FO standard, but I do not know whether or when it will be > addressed at that level, or how far ahead of that process FOP > wants to get. > As far as the current standard, I think it could be considered an > implementation detail. > > I apologize if this has already been discussed / coded, etc. I haven't > stumbled across it yet. > > Victor Mote (mailto:[EMAIL PROTECTED]) > Enterprise Outfitters (www.outfitr.com) > 2025 Eddington Way > Colorado Springs, Colorado 80916 > Voice 719-622-0650, Fax 720-293-0044 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]