Jeremias Maerki wrote:
On 07.09.2004 21:11:09 Finn Bock wrote:I think that restriction is implicit in the XSL Recommendation, because fo:instream-foreign-object [1], has the requirement that its child be from a *non-XSL* namespace. If the rec intended FO documents to be processed recursively, they wouldn't have had a non-XSL namespace requirement (i.e., why bother to require users to have a <finn:fodocument> that would just wrap <fo:root/>, if you can just use the latter tag directly?) Indeed, this restriction could be an argument *for* using ThreadLocals.
[Jeremias Maerki]
Question to everyone: We currently don't have a multi-threaded designA (farfetched) argument against ThreadLocals would be that they prevent one FOP processing run to occur recursively during another independent processing run. Like an extension element that itself will attempt to process another fo document.
like Peter West's approach. Can anyone think of a reason that all the
FO-building and layouting process for one processing run may run within
more than one thread? I don't think threre is one if the SAX event
delivery is always within one thread (big if). If there isn't I believe
we could make use of a ThreadLocal to put some shared data that will be
easily accessible from all involved components. Initialize the
ThreadLocal in startDocument() and clear it in endDocument(). I realize
there's a certain risk involved but it could really shorten the access
ways for shared data especially for the FO tree, if that's really a
problem (I'd also like to know if it really is. Anyone?).
[1] http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo_instream-foreign-object
Good point, actually. IMO FOP should support rendering documents
snippets. One use case for this is an FO paragraph or two within SVG (FO
embedded in SVG embedded in FO).
I don't think we should be encouraging that use case or developing in that direction. Shouldn't the standard be to write your document using FO, and incorporate images using SVG as you need them? Or, if the text handling capability of SVG is too primitive, to have subsequent versions of the SVG recommendation improve upon it, rather than have users move to the FO namespace within their SVG?
We *could* code to have FOP embed SVG embed FOP embed SVG over and over again, but I'm not sure it would buy the user anything over proper document planning as described above.
I also don't like the idea of "snippets"--non portable divergences from the XSL standard of having fo:root be the top of all FO documents. We should not be encouraging users to starting their work with fo:blocks (it is only speculative what such FO's would mean absent their parents anyway.) Let's wait until the XSL rec defines snippets first--they might do that someday, actually.
And what a coincidence: I've had a discussion exactly today where we talked about rendering FO snippets to EMF (Windows enhanced metafile format) for inclusion in a Win32-based reporting engine.
I would see another application calling FOP, providing a default fo:root-based structure around the snippet that the user provides (say, an fo:block). But asking FOP to process a snippet with nothing else is kind of like asking javac to compile a class snippet (say, just an "if" statement.). Too much to ask--compilers and FO Processors both have grammars to follow.
My preference would be to explicit pass the shared data (in this case the FOEventHandler) to the classes that needs it. If the recursion Glen discovered is deemed too slow, then store the FOEventHandler in an instance field for each FONode.
My preference, too. But having too much in FONode will generate a lot memory consumption. Just the logger instance in the maintenance branch takes up a lot of memory. As long as we can keep such a reference to count one I don't think this is such a big problem, however.
The ThreadLocal was just an intriguing idea but your comment already lets me dismiss it. It's probably more trouble than it's worth.
Jeremias Maerki
I'm not sure I would mind ThreadLocal here. According to [2], it is kind of fast, at least in 1.4. That, or returning to the old recursion method, appear to me to be the best options.
[2] http://www-106.ibm.com/developerworks/java/library/j-threads3.html
A third option, which may also have nice benefits, is getting rid of startElement() and endElement() within the FO's, and doing that all in FOTreeBuilder.
Glen
