AAh, I have a working multi -threaded memory patch that i developed and its
been lying around with me simply because i just dont want to figure how to
commit from my stupid windoze machine. If anyone wants to see the work i
have done, committers included, pls take it from me and commit it!
sesha
----- Original Message -----
From: Mark <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, July 16, 2001 8:56 AM
Subject: Re: How FOP renderred my 17,344 page document...
> Hi Fopsters
>
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
