Hi Jeremias, Jeremias Maerki <[EMAIL PROTECTED]> wrote on 12/07/2008 09:04:57 AM:
> Ok, I've created a Bugzilla issue to track this issue in FOP: > https://issues.apache.org/bugzilla/show_bug.cgi?id=46360 Ok, Thanks. > A short test shows that I can't easily clone the document if it has a > document type. The following is a patch the would fix the exception. [...] > And I don't even know if the patch here is even plausible. I strongly suspect that it's intentional that the document will not create a DocumentType Node as this should be provided when the document is created. > But I guess I'll need to work around that outside of Batik as we'd have > to wait for a Batik release before we can release a new FOP with the fix > applied. So I'm planning to do this: I suggest using: batik.dom.util.DOMUtilities.deepCloneDocument (Document doc, DOMImplementation impl); This has been in Batik for quite a while and has code to work around this exact problem. > On 07.12.2008 14:44:53 thomas.deweese wrote: > > Hi Jeremias, > > > > Jeremias Maerki <[EMAIL PROTECTED]> wrote on 12/07/2008 08:09:48 AM: > > > > > Thanks a lot, Thomas. So the safest way would be to clone the (cached) > > SVG > > > document. > > > > Correct. This is what we do when we cache documents - mostly because > > we > > do deal with dynamic documents. > > > > > As an optimization step one could investigate if some sort of > > > caching the GVT tree is doable (see my other post just a few minutes > > ago). > > > I assume the second option would take quite a bit of effort (including > > > benchmarks beforehand to determine the optimization potential). > > > > So the work would be knowing that you can reuse the GVT tree because > > the destination format matches (so the 'added' bridges would match). > > The other potential issue would be the viewBox fitting (the affine for > > that lives in the 'CanvasGraphicsNode'). You would probably want to > > handle that outside of the GVT tree. > > > > As far as the boost this would give you, the actual construction > > of the GVT tree is pretty quick, but some of the stuff that is done > > the first time through (calculating BBoxes, text layout, etc) can be > > fairly time consuming. > > > > > On 07.12.2008 13:53:12 thomas.deweese wrote: > > > > Hi Jeremias, > > > > > > > > Jeremias Maerki <[EMAIL PROTECTED]> wrote on 12/07/2008 06:53:04 > > AM: > > > > > > > > > Is that a sure thing that the DOM is not modified? > > > > > > > > It is 100% certain that you can't have one document with > > > > two attached GVT tree's - which I think you would need to do > > > > with your current approach. The actual DOM infoset shouldn't > > > > be modified but internally we attach additional structures to > > > > handle the CSS & SVG DOMs. Also some items (particularly in > > > > the SVG DOM) may be lazily constructed (so the two threads might > > > > collide when 'reading' those items). > > > > > > > > > If yes, we'd have to ask the question whether attaching the CSS > > engine > > > > > to the DOM is the right thing to do. And is the CSS Engine as such > > not > > > > > thread-safe or is only the setting of the CSS engine not thread safe > > > > > > (method > > > > > BridgeContext.initializeDocument(Document))? > > > > > > > > Once again no attempt was made to make the CSS Engine thread safe, > > it > > > > might be thread safe for some set of operations but I can't give any > > kind > > > > of guidelines. Of course you must attach the CSS Engine otherwise the > > > > > > CSS DOM (which we use to render the document) won't be available. > > > > > > > > In Batik it is 100% required that people access DOM/CSS/GVT through > > > > > > one thread. > > > > > > > > > Maybe an idea could be to attach the CSS engine to the thread > > (thread > > > > > local) instead of to the DOM if only one thread uses the CSS engine > > in > > > > > a single rendering run and the CS engine is not thread-safe. > > > > > Just brain-storming.... > > > > > > > > The only thing that might work would be to attach the CSSEngine > > once > > > > and build the GVT tree once and keep that in the cache. But even with > > > > that the GVT tree may well not support multiple concurrent renderings > > > > (although for a static document it should come close). > > > > > > > > > On 07.12.2008 12:32:43 Peter Coppens wrote: > > > > > > As in another post mentioned - I have been debugging the code. The > > dom > > > > is > > > > > > not modified. The dom caches a Parser object which is not thread > > safe. > > > > > > > > > > > > > > > > > > > From: Jeremias Maerki <[EMAIL PROTECTED]> > > > > > > > Reply-To: <[email protected]> > > > > > > > Date: Sun, 07 Dec 2008 12:17:48 +0100 > > > > > > > To: <[email protected]> > > > > > > > Subject: Re: Batik exception when using fop with svg images in > > > > threaded > > > > > > > environment > > > > > > > > > > > > > > Thanks for your input, Thomas! > > > > > > > > > > > > > > On 06.12.2008 20:00:01 thomas.deweese wrote: > > > > > > >> Hi Jeremias, > > > > > > >> > > > > > > >> Jeremias Maerki <[EMAIL PROTECTED]> wrote on 12/05/2008 > > > > 03:55:42 AM: > > > > > > >> > > > > > > >>> I can reproduce the issue with this test case. It really only > > > > happens in > > > > > > >>> the multi-threading case (running against Batik Trunk). As > > soon as > > > > you > > > > > > >>> place break-points before the exception > > (NumberFormatException) > > > > can > > > > > > >>> happen, it won't. I'm not sure where to start looking for the > > > > problem. > > > > > > >>> Maybe we can do something in FOP to avoid this. Help/hints > > would > > > > be > > > > > > >>> appreciated. > > > > > > >> > > > > > > >> I don't know how FOP loads and rasterizes SVG documents. If > > > > > > there > > > > > > >> is a global cache of Documents that have been read so the same > > > > Document > > > > > > >> Object ends up being used in both threads that would cause this > > > > > > problem. > > > > > > > > > > > > > > Hmm, I wonder why we've never had that before (to my knowledge). > > > > > > After > > > > > > > all we have an image cache which caches and reuses the SVG DOM > > for > > > > years. > > > > > > > Even FOP versions before 0.20.5 did that. > > > > > > > > > > > > > > I mean I can understand that SVGs with scripts or animation > > might > > > > modify > > > > > > > the DOM but static SVGs with no script, no animation, no CSS > > parts? > > > > > > > > > > > > > > Anyway, FOP does have (0.94 or earlier) an image cache or uses > > the > > > > one > > > > > > > in the image loading framework from XML Graphics Commons (since > > FOP > > > > 0.95). > > > > > > > In the case of SVG documents, the DOM is reused with the > > intention > > > > of > > > > > > > improving performance. > > > > > > > > > > > > > >> Checking the source it appears that fop.image.ImageFactory > > does > > > > this. > > > > > > > > > > > > > > You're looking at old source code (before 0.95). This has been > > > > replaced > > > > > > > by the XG Commons image loading framework. > > > > > > > http://xmlgraphics.apache.org/commons/image-loader.html > > > > > > > > > > > > > >> There seem to be some options for sharing (or not) of images > > > > between > > > > > > >> contexts but it's not obvious to me how that works. > > > > > > > > > > > > > > Images are cached with their original URI as the key. When the > > same > > > > URI > > > > > > > is requested the cached image (with a reference to the SVG DOM) > > is > > > > > > > returned if it hasn't already been claimed by the garbage > > collector. > > > > > > > Image subclasses indicate if they are cacheable or not: > > > > > > > https://svn.eu.apache. > > > > > org/viewvc/xmlgraphics/commons/trunk/src/java/org/apache > > > > > > > /xmlgraphics/image/loader/Image.java?view=markup > > > > > > > > > > > > > >> Another option would be to deep clone the Document the > > second > > > > time > > > > > > >> (deciding that it's the second time is left as an exercise for > > the > > > > > > >> user of Batik ;). > > > > > > > > > > > > > > That depends. If you're saying that the DOM can actually be > > > > manipulated, > > > > > > > even in case of a "static" SVG, then that might not always be a > > good > > > > > > > idea. To be on the safe side, I think I'll always have to clone > > the > > > > SVG > > > > > > > document. > > > > > > > > > > > > > > I hope the performance penalty for the cloning is not too high. > > > > > > > > > > > > > > Do you think it is feasible to modify Batik to treat the SVG > > > > document as > > > > > > > read-only? If yes, where would we have to dive in? > > > > > > > > > > > > > >>> Peter, there's one problem in your test case: You reuse the > > > > FOUserAgent > > > > > > >>> for all documents. That's not how it's supposed to be. You > > have to > > > > > > >>> create a new FOUserAgent for each processing run. Too bad, > > that > > > > doesn't > > > > > > >>> already fix the problem. ;-) > > > > > > >> > > > > > > >> This might let the 'context' stuff I mentioned above kick > > in. > > > > > > > > > > > > > > No, the image cache is attached to the FopFactory, not the > > > > FOUserAgent. > > > > > > > The old image cache used to create a hard reference on an image > > when > > > > it > > > > > > > was preloaded during layout to block garbage collection. That > > hard > > > > > > > reference was released (leaving the soft reference in the image > > > > cache) > > > > > > > when the image was rendered. I didn't reimplement that feature > > to > > > > lower > > > > > > > the memory requirements for images that have to be fully loaded > > at > > > > > > > "pre-loading time". > > > > > > > > > > > > > >> > > > > > > >>> > > > > > > >>> On 04.12.2008 23:58:57 Peter Coppens wrote: > > > > > > >>>> > > > > > > >>>> We have been able to reproduce with the following files > > > > > > >>>> > > > > > > >>>> http://www.nabble.com/file/p20844449/TestPijltje.java > > > > TestPijltje.java > > > > > > >> > > > > > > >>>> http://www.nabble.com/file/p20844449/pols.xml pols.xml > > > > > > >>>> http://www.nabble.com/file/p20844449/pols.xslt pols.xslt > > > > > > >>>> http://www.nabble.com/file/p20844449/pijltje.svg pijltje.svg > > > > > > >>>> > > > > > > >>>> TestPijltje.java is the test program. It starts two threads > > each > > > > of > > > > > > >> which > > > > > > >>>> will generate a pdf based on the pols.xslt stylesheet, > > pols.xml > > > > en > > > > > > >>>> pijltje.svg input file. > > > > > > >>>> > > > > > > >>>> If changing the code to only start one thread it always works > > > > > > fine. > > > > > > >> With two > > > > > > >>>> threads regular exceptions are thrown > > > > > > >>>> > > > > > > >>>> Stack trace is always something like > > > > > > >>>> > > > > > > >>>> Dec 4, 2008 11:54:33 PM org.apache.fop.svg.SVGUserAgent > > > > displayError > > > > > > >>>> SEVERE: SVG > > Errorfile:/Users/pc/Downloads/fop-0.95/pijltje.svg: > > > > > > >>>> The attribute "enable-background" represents an invalid CSS > > value > > > > > > >> ("new 0 0 > > > > > > >>>> 47.403 26.361"). > > > > > > >>>> Original message: > > > > > > >>>> Invalid number. > > > > > > >>>> org.w3c.dom.DOMException: > > > > > > >> file:/Users/pc/Downloads/fop-0.95/pijltje.svg: > > > > > > >>>> The attribute "enable-background" represents an invalid CSS > > value > > > > > > >> ("new 0 0 > > > > > > >>>> 47.403 26.361"). > > > > > > >>>> Original message: > > > > > > >>>> Invalid number. > > > > > > >>>> at > > > > > > >> > > org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown > > > > > > >>>> Source) > > > > > > >>>> at > > > > > > >> org.apache.batik.css.engine.CSSEngine.getComputedStyle(Unknown > > > > > > >>>> Source) > > > > > > >>>> at > > > > > > >> org.apache.batik.bridge.CSSUtilities.getComputedStyle(Unknown > > > > > > >>>> Source) > > > > > > >>>> at > > > > > > >> org.apache.batik.bridge.CSSUtilities.convertVisibility(Unknown > > > > > > >>>> Source) > > > > > > >>>> at > > > > > > >>>> > > > > org.apache.batik.bridge.SVGSVGElementBridge.createGraphicsNode(Unknown > > > > > > >>>> Source) > > > > > > >>>> at org.apache.batik.bridge.GVTBuilder.build(Unknown > > > > Source) > > > > > > >>>> at > > > > > > >>>> org.apache.fop.render.pdf.PDFSVGHandler. > > > > > > >>> renderSVGDocument(PDFSVGHandler.java:188) > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> Any help warmly welcomed! > > > > > > >>>> > > > > > > >>>> Thanks > > > > > > >>>> > > > > > > >>>> Peter > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> -- > > > > > > >>>> View this message in context: http://www.nabble.com/Batik- > > > > > > >>> > > exception-when-using-fop-with-svg-images-in-threaded-environment- > > > > > > >>> tp20809049p20844449.html > > > > > > >>>> Sent from the Batik - Users mailing list archive at > > Nabble.com. > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > Jeremias Maerki > > > > > > > > > > > > > > > > Jeremias Maerki > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
