> I'm personally only offended by being referred to as a "fopsicle". Just > kidding. :-)I just love the word 'fop', it has so many literary possibilities. :-)
> Seriously, this is great stuff. You should be aware that the initial memory > buffering that you see with the -buf switch is only a limited portion of > more extensive work that has yet to be folded into FOP.[snip]
OK. I believe it will be necessary for the two systems to be aware of one another. I actually had to back out the changes to FOText that related to BufferManager because BufferManager was holding onto the text well past it's use-by millisecond. As I understand things, the BufferManager stuff will help with long, single page-sequences, and my stuff will help with multiple page sequences. This should satisfy everyone! (famous last words if ever i've written them!)
> This is open-source; nobody should be offended by people hacking away at code."should be" being the operative word. Some "open source" project participants don't like getting critiqued by outsiders - and a patch is basically a critique written in Java. So I'm very pleased and excited with your reaction to these ideas.
> Specific comments; IDReferences have mostly to do with > <fo:page-number-citation/>, that is, the possibility is there that you need > the page number that contains the results of rendering the block with > id="foo356", and you're currently on page 44, and the block with id="foo356" > will end up on page 887, although you don't know that yet. You're right, > this kind of stuff can cause major issues for pipelining. Nothing > insurmountable, though.OK. For my own personal 'itch' I don't care about page-number-citations, but obviously it must be supported. So I would propose that I work out how to deal with the citations in a PageSequence queue and use deferral for the time being. This would mean that documents that contain references to future page-sequences will consume more memory, but should otherwise work just the same.
> The code you see in Root.java should not require page-sequence N+1 to be > formatted before you render page-sequence N. All that's going on there is, > if the "force-page-count" property on page-sequence N is "auto", it needs to > know about the "initial-page-number" property on page-sequence N+1. This > doesn't require any formatting to take place at all.OK, well with the deferral mechanism the page-sequence will be parsed but not formatted/rendered immediately. I'll look at the code path for the force-page-count property and see how i can optimise it under this queue scheme.
So this is how I plan to proceed:
o Try to get the PDF renderer serializing much sooner. This appears to be a current bottleneck in complex documents, but I haven't run the profiler against them yet since I only started processing large numbers of examples last night.
o Look at the IDReferences again and see if I can design a neat implementation that addresses the queuing issues.
So far all my work has been an unstructured hack (there are some nasty public statics in there to hold things together - um ahh), so - if I can show that the approach works, I intend to reimplement it from scratch against the latest CVS. I think what I'll do is, once I make everything work using my hacks, I'll post a summary of the changes I intend to make, so that people can give me feedback on the ideas.
Also, I have run some of the tests from the examples directory and they appear to look fine, except that I don't know what they're *supposed* to look like!! So how would I go about getting my code validated against XML:FO? (I think there was a thread about this a little while ago but sadly I didn't read it ):
Regards
Mark
