DO NOT REPLY [Bug 36082] - [PATCH] Relative URIs are not correctly resolved
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36082. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36082 --- Additional Comments From [EMAIL PROTECTED] 2005-08-16 08:55 --- (In reply to comment #15) Created an attachment (id=16053) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16053action=view) [edit] Next revision Made changes as per this conversation: Very cool! Applied. Thanks a lot. My XML Commons Resolver example works now, too. I'll expand a little on the test case to demostrate different resolution schemes. http://svn.apache.org/viewcvs?rev=232949view=rev -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: svn commit: r232950 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOTreeBuilder.java
BTW, although this change was not motivated by this I believe this fixes a memory leak. But I'll have to verify first. The effect of the removeContext() call is that all images associated with a user agent will be moved into a WeakHashMap where they can be picked up by the GC. If this isn't done the image cache keeps accumulating Context instances for each processing run. On 16.08.2005 09:33:10 jeremias wrote: Author: jeremias Date: Tue Aug 16 00:33:05 2005 New Revision: 232950 URL: http://svn.apache.org/viewcvs?rev=232950view=rev Log: Notify image cache about the expiration of a user agent (i.e. processing run). Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOTreeBuilder.java (contents, props changed) Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOTreeBuilder.java URL: http://svn.apache.org/viewcvs/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOTreeBuilder.java?rev=232950r1=232949r2=232950view=diff == --- xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOTreeBuilder.java (original) +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOTreeBuilder.java Tue Aug 16 00:33:05 2005 snip/ + +//Notify the image factory that this user agent has expired. +ImageFactory.getInstance().removeContext(this.userAgent); snip/ Jeremias Maerki
DO NOT REPLY [Bug 36120] - fix the height of cell in a table
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36120. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36120 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2005-08-16 10:12 --- Closing this issue. No feedback on my questions. Please reopen if this is not resolved for you. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: DO NOT REPLY [Bug 36082] - [PATCH] Relative URIs are not correctly resolved
Hi all, On Mon, 15 Aug 2005 08:20 pm, Jeremias Maerki wrote: This is actually not about relative paths, but actual URI resolution. If you look at the JUnit test case I committed earlier [1] I use the URIResolver to resolve an URI funky:myimage123 to one of the bgimg bitmaps in our test directory (a file URL). That's how people can specify abstract URIs instead of concrete URLs to point to resources whose location is not known at deployment time. And it's where XML Commons Resolver jumps in to provide a widely used mapping from URIs to URLs. [1] http://svn.apache.org/viewcvs?rev=232788view=rev Manuel Mall wrote: Alright, this means we need to set the FOP resolver on the SVG processor. Not sure if Batik supports the javax.xml.transform.URIResolver interface. May be any Batik people lurking on this list can shed more light on this? All Batik URL resolution is handled by our ParsedURL implementation. The only 'problem' with the ParsedURL class is that it doesn't have a very direct connection to a UserAgent, so configuration is done on a per JVM (really classloader) basis. So it would be simple to add support for URIResolver in ParsedURL but it wouldn't be a parameter on the 'batik.transcode.Transcoder' class it would be global. I'm not sure if this is a problem or not (I didn't follow all of the discussion above). There is also the potential issue of dragging in a new dependency for an interface with a single method that only takes/returns primitive types. ;)
Re: svn commit: r232952 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/image/ImageCache.java src/java/org/apache/fop/image/ImageFactory.java test/java/org/apache/fop/URIResolutionTestCase.java
[EMAIL PROTECTED] wrote: Add a method to clear all image caches for testing purposes. It shouldn't be necessary anymore to call such a method in a production environment or we have a problem with the image cache. It depends how fine grained cache control should be. If I format a lot of reports with company and division logos in the headers, I'd probably like to keep them in the cache across different rendering runs. But this can be left for later fine tuning. J.Pietschmann
Re: svn commit: r232952 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/image/ImageCache.java src/java/org/apache/fop/image/ImageFactory.java test/java/org/apache/fop/URIResolutionTestCase.java
That already happens! On 16.08.2005 23:16:44 J.Pietschmann wrote: [EMAIL PROTECTED] wrote: Add a method to clear all image caches for testing purposes. It shouldn't be necessary anymore to call such a method in a production environment or we have a problem with the image cache. It depends how fine grained cache control should be. If I format a lot of reports with company and division logos in the headers, I'd probably like to keep them in the cache across different rendering runs. But this can be left for later fine tuning. J.Pietschmann Jeremias Maerki
