(where to start?)
Currently the svg rendering uses more memory than it should, all the
rendering data is written into a StringWriter.
--
I think in terms of the structure of FOP:
- changing the pdf generation would be a good thing, ie. adding streaming
support and linearized support (good for downloading (not generating))
would be useful.
- The separation of the object parsing/formatting/rendering is about the
data. I don't see a problem with a high level of control of when particular
parts of this flow occur as long as each page is valid and rendered
correctly. Also it should not get in the way of further development towards
full implementation of the FO spec or operation of the renderers.
The FOTreeBuilder is probably not the right place.
I guess we need to know details first.
--
There are tests but they do not test the pdf output (a bit too difficult)
only the xml area tree.
On Tue, 17 Jul 2001 16:19:46 Mark wrote:
> Hi again,
>
> Firstly I have successfully tested my changes with a ~20,000 page
> document of moderate complexity, it is in fact one of the example
> documents but I forget which one (doh) - multiplied by some silly factor
> like 5000 or something. I have also successfully tested my changes
> against a 120-odd page version of 'docs/examples/svg/embedding.fo' -
> that three page file x forty-something. I would try it on a bigger file
> but I need to sleep instead; I'll set one of my machines going on a
> really big file tomorrow just to see where the limits are. I haven't
> looked at the heap size growth yet but I expect a very small linear
> growth since the PDF still has to maintain a list of references for each
> page. Still, that's quite tiny and probably can be optimized
> significantly if it becomes a problem.
>
> I have some questions regarding the structure of FOP and how my changes
> might be integrated into the main tree, assuming of course that they are
> desired and the PDF page parent issue can be sorted out.
>
> Firstly it could be argued that I have violated one of the secondary
> design principals of FOP, namely that the separation between
> parsing/formatting/rendering has suffered a warp core breach. In fact I
> think I have managed to keep the separation pretty clear, but at some
> point control has to move from the parser to the formatter/renderer and
> this is no longer done by the caller. By this I mean that the thread
> running SAX is now running the formatting and rendering. Does anything
> see this as a huge problem? (What is the plan for FOP 0.20 anyway?)
>
> At the moment I am doing this in a horrid hack in FOTreeBuilder because
> that's just the most obvious place to find where the fo:page-sequence
> element ends. I also initialize and close the renderer in FOTreeBuilder
> using some new methods I had to add (PDF specific atm). I am not certain
> that FOTreeBuilder is the right place for this code, but it might be.
> Any suggestions? I like the idea of a bridging class actually;
> ParserRenderer or something, that FOTreeBuilder uses.
>
> Secondly, because of the change in the rendering sequence I am afraid
> that other renderers might not work any more, especially not the AWT
> renderer. I was wondering if anyone would like to help me with these
> other renderers? The changes are fairly straightforward. I am happy to
> work on the AWT renderer and can probably work out the PCL renderer, but
> if my code might be accepted into the tree then it would probably be
> beneficial if someone else knew broadly what I've been up to. I don't
> have any PCL devices handy so I would have some difficulty testing any
> changes I make. And I'm not even sure what MIF is, some sort of
> interchange format .. ?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
