DO NOT REPLY [Bug 43651] NPE without manually clearing image cache
https://issues.apache.org/bugzilla/show_bug.cgi?id=43651 --- Comment #2 from M.H. [EMAIL PROTECTED] 2008-10-21 02:15:11 PST --- With FOP 0.95 I also have a problem with the image cache: when I run a second document with the same SVG image file name but different image content, the subsequent documents always use the first image. Clearing the image cache via org.apache.fop.image.ImageFactory.clearCaches() doesn't work anymore as FOP 0.95 doesn't have this class/method. (This also disables multi-threading of FOP document generations.) How can I clear the image cache in FOP 0.95? The FAQ (http://xmlgraphics.apache.org/fop/faq.html) doesn't tell also.) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 --- Comment #1 from Jeremias Maerki [EMAIL PROTECTED] 2008-10-21 02:42:06 PST --- Have you tried the suggested work-around at http://xmlgraphics.apache.org/fop/stable/graphics.html#caching already (adding a unique dummy URL parameter)? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 --- Comment #2 from M.H. [EMAIL PROTECTED] 2008-10-21 02:51:09 PST --- (In reply to comment #1) Have you tried the suggested work-around at http://xmlgraphics.apache.org/fop/stable/graphics.html#caching already (adding a unique dummy URL parameter)? No, because I can't set a unique URI in the XSL for each report generation. I try to achieve this with my custom URIResolver. But I noticed that for the second call (i.e. the second report) the custom URIResolver's resolve() is not called!!! This is another hint, that the image cache uses the URI before changed by a custom URIResolver! This would explain the the image cache lokks into the cache with the (non-unique) URI and finds it there and doesn't need to call the custom URIResolver.resolve(). If the cache would use the custom URIResolver's resolved URI, this would probably work. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46048] New: Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 Summary: Wrong images used (how to clear image cache?) Product: Fop Version: 0.95 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: images AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] The problem: if an (SVG) image with the same file name (but different file path!) is generated more than 1 times, FOP always uses the (wrong) first image. We use relative paths in our XSLs to reference SVG images. This worked good in FOP 0.20.5 but doesn't work in FOP 0.95 anymore (well, it works with FOP 0.95 when called via FOP.bat but it doesn't work when called from within a Java app via the FOP Java API). So I wrote a custom URIResolver to change the file name to the current unique file path. This solves the problem of the (so far) not working relative paths for images. However, if a subsequent document generates the same report with the same file but with different data, FOP doesn't use the newly generated file content but the old image of the first report. I guess the internal image cache doesn't use the resolved image file name but the first generated one. Example: 1. XSL content: svg:image width=170mm height=120mm xlink:href=C_PerfRiskCons_M.svg xmlns:xlink=http://www.w3.org/1999/xlink/ 2. custom URIResolver changes 'file:/D:/Tmp/iComps/amc/reports/C_PerfRiskCons_M.svg' to 'file:///D:\Tmp\iComps\amc\reports\dVwIIqKYfobFQDzUFJDQ5Er60ovA0G7YMpAVypnaMhY=\C_PerfRiskCons_M.svg'. with dVwIIqKYfobFQDzUFJDQ5Er60ovA0G7YMpAVypnaMhY= being a unique GUID for each report. = it seems FOP 0.95 uses 'file:/D:/Tmp/iComps/amc/reports/C_PerfRiskCons_M.svg' for the image cache which would explain the faulty behaviour. I tried to work around this by serializing report generation and clearing the image cache before each report, but there is no org.apache.fop.image.FopImageFactory.resetCache() anymore in FOP 0.95 and I didn't find any other resetCache() method in the API. How can I work around this? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 M.H. [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |blocker -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 Jeremias Maerki [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #3 from Jeremias Maerki [EMAIL PROTECTED] 2008-10-21 03:05:35 PST --- Ok. What you describe is all expected and correct behaviour. Obviously, it doesn't cover 100% of all requirements. I must say I'm not ready to believe that it wouldn't be possible to add a unique value for the report. You managed in the URIResolver. One idea could be to add a set of regular expressions to match URIs that should not be cached. We've also talked about an extension attribute on fo:external-graphic to disable the cache for certain images. But that's all not implemented, yet. To put you out of you misery ;-) here's the code to clear the image cache: fopFactory.getImageManager().getCache().clearCache(); -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43651] NPE without manually clearing image cache
https://issues.apache.org/bugzilla/show_bug.cgi?id=43651 Jeremias Maerki [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #3 from Jeremias Maerki [EMAIL PROTECTED] 2008-10-21 03:07:37 PST --- Please upgrade to FOP 0.95 where this problem should be solved by the introduction of the new image loader framework. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 --- Comment #4 from Vincent Hennebert [EMAIL PROTECTED] 2008-10-21 03:18:08 PST --- Doesn't the cache check for the modification date of file: URIs? Seems like a natural thing to do. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 --- Comment #5 from Jeremias Maerki [EMAIL PROTECTED] 2008-10-21 03:23:26 PST --- (In reply to comment #4) Doesn't the cache check for the modification date of file: URIs? Seems like a natural thing to do. No. Natural it may be if you only look at file URLs, but not all URLs provide a modification date. And we're actually working with URIs, not URLs, which don't have a modification date. Maybe this can be improved. Experiments welcome. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048
--- Comment #6 from Vincent Hennebert [EMAIL PROTECTED] 2008-10-21 03:31:39
PST ---
(In reply to comment #5)
(In reply to comment #4)
Doesn't the cache check for the modification date of file: URIs? Seems like
a
natural thing to do.
No. Natural it may be if you only look at file URLs, but not all URLs provide
a
modification date. And we're actually working with URIs, not URLs, which don't
have a modification date. Maybe this can be improved. Experiments welcome.
That's why I said /file:/ URIs. Something like:
if (uri.getScheme() == file) {
check the modification date of the corresponding file
}
Doesn't seem complicated, but I'm obviously missing the big picture.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048
--- Comment #7 from M.H. [EMAIL PROTECTED] 2008-10-21 03:34:37 PST ---
As there is no method to clear the image cache, I now have a working
workaround:
iin my custom FOP class I introduced a new constructor to create a new
FopFactory to finally get rid of all cached images:
---
/**
* Constructor.
*
* Workaround image cache problem: each FopFactory has its own image cache.
As a custom URIResolver (to set unique image file names)
* is not considered by the imageCache (FOP 0.95), the image cache must be
cleared. But as there is not such clear method anymore (FOP 0.95)
* we create a complete new FopFactory.
*
* This constructor should be called with parameter 'true' for serialized
FOP calls to avoid image caching problems.
*
* @param newFactory If true, create a new FopFactory and try to copy
config values from the former FopFactory and UserAgent.
*/
public FOP(final boolean newFactory) throws Exception {
super();
if (newFactory) {
final FopFactory ff = FopFactory.newInstance();
final FOUserAgent ua = ff.newFOUserAgent();
ua.setBaseURL(fopUserAgent.getBaseURL());
ua.setURIResolver(fopUserAgent.getURIResolver());
ff.setStrictValidation(fopFactory.validateStrictly());
if (fopFactory.getFontBaseURL() != null) {
ff.setFontBaseURL(fopFactory.getFontBaseURL());
}
ff.setUserConfig(fopFactory.getUserConfig());
fopFactory = ff;
}
}//FOP()
---
I guess the problem is the image caching of FOP not taking custom URIResolvers
into account.
(Why is this bug resolved worksforme? This is a clear bug as I described it
...)
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 --- Comment #8 from Jeremias Maerki [EMAIL PROTECTED] 2008-10-21 04:20:50 PST --- (In reply to comment #7) As there is no method to clear the image cache, I now have a working workaround: iin my custom FOP class I introduced a new constructor to create a new FopFactory to finally get rid of all cached images: snip/ I guess the problem is the image caching of FOP not taking custom URIResolvers into account. (Why is this bug resolved worksforme? This is a clear bug as I described it ...) Would you care to look at my reply #3 again? I gave you the code necessary to clean the image cache. Here it is again: fopFactory.getImageManager().getCache().clearCache(); -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 --- Comment #9 from M.H. [EMAIL PROTECTED] 2008-10-21 04:22:26 PST --- (In reply to comment #3) To put you out of you misery ;-) here's the code to clear the image cache: fopFactory.getImageManager().getCache().clearCache(); Thanks, that did also the trick! Is there hope to fix this issue when using custom URIResolvers? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 --- Comment #11 from M.H. [EMAIL PROTECTED] 2008-10-21 04:48:06 PST --- (In reply to comment #10) The URIResolvers are completely irrelevant for image caching, they just provide access to the actual resource when given a URI. Thanks for this clearing up! Now I can stop playing around with the URIResolver in hope to get it somehow fixed. Then I don't understand your comment #3: as I can't write a unique path to the XSL (as the XSL never changes because it is the layout of the report), we use relative paths (as they worked with FOP 0.20.5 Java API flawlessly). These relative paths result in the very same image file name for the same report but other data. The only workaround I see here, is to make an additional XML transformation of the XSL to find such relative paths and replace them with temporary full paths, which is not very elegant. I wonder, how I can get FOP working to process multiple documents in multiple threads. I guess, the only promising approach so far (FOP 0.95) is, to use new FopFactories and UserAgents for each thread and each report generated. But the note in http://xmlgraphics.apache.org/fop/0.94/embedding.html#multithreading (Apache FOP may currently not be completely thread safe.) is not very encouraging. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 --- Comment #10 from Jeremias Maerki [EMAIL PROTECTED] 2008-10-21 04:35:22 PST --- (In reply to comment #9) (In reply to comment #3) To put you out of you misery ;-) here's the code to clear the image cache: fopFactory.getImageManager().getCache().clearCache(); Thanks, that did also the trick! Is there hope to fix this issue when using custom URIResolvers? Not the way you thought. A URIResolver returns a JAXP Source object and that can't be cached. It's not even guaranteed that the resulting Source object has a system ID. I wouldn't even know where to start to approach this the way you explained. If there's anything that can be improved then it's either looking at Vincent's proposal about checking the last modified date for file URLs (which would only solve this special case) or bypassing caching for certain URIs as I suggested. The URIResolvers are completely irrelevant for image caching, they just provide access to the actual resource when given a URI. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re:
Thanks for your reply. In that you believe the Antenna House formatter implementation is correct, do you know how I would, in theory, be able to get the table-cell border displayed below the block-container (current Fop behaviour)? Thanks again - Original Message From: Jeremias Maerki [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Tacio Naja Domingos [EMAIL PROTECTED]; fop-dev@xmlgraphics.apache.org Sent: Monday, October 20, 2008 6:09:14 PM Subject: Re: As much as it hurts to admit it (being a FOP developer), Antenna House is right, I believe. The section in the spec that defines the layering is this: http://www.w3.org/TR/xsl11/#rend-layer I guess that slipped through the cracks and we'll need to see to it that this gets fixed. Thanks for bringing this up. On 20.10.2008 12:20:53 Tacio Naja Domingos wrote: I am running the below peace of code in both Fop 0.94 and Antenna house formatter, but get a rather different behaviour. I was hoping someone could point out which implementation is correct by directing me to the correct sentence in the FO spec. In Fop the table border is drawn below the block-container. In Antenna house formatter, the table-cell border is above the block-container but the table-cell contents are below the block-container. The code is: fo:table width=5cm table-layout=fixed fo:table-body fo:table-row fo:table-cell border-style=solid border-color=black border-width=1pt fo:block color=red background-color=yellowBelow fo:block-container absolute-position=absolute top=0.15cm left=0.25cm fo:block text-align=left fo:inline background-color=grey keep-together=alwaysAbove/fo:inline /fo:block /fo:block-container /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table Thanks for your help in advance. Tacio Jeremias Maerki
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 --- Comment #12 from Jeremias Maerki [EMAIL PROTECTED] 2008-10-21 05:12:39 PST --- (In reply to comment #11) (In reply to comment #10) The URIResolvers are completely irrelevant for image caching, they just provide access to the actual resource when given a URI. Thanks for this clearing up! Now I can stop playing around with the URIResolver in hope to get it somehow fixed. Then I don't understand your comment #3: as I can't write a unique path to the XSL (as the XSL never changes because it is the layout of the report), Hint: XSLT parameters we use relative paths (as they worked with FOP 0.20.5 Java API flawlessly). These relative paths result in the very same image file name for the same report but other data. The only workaround I see here, is to make an additional XML transformation of the XSL to find such relative paths and replace them with temporary full paths, which is not very elegant. I'd simply determine a unique ID for each report instance (something simple as a counter) and pass that in as an XSLT parameter. The stylesheet can then append that to the URI: file:myimage.png?id=12345, file:myimage.png?id=12346 I wonder, how I can get FOP working to process multiple documents in multiple threads. That's what I was thinking, too. You're not going to be happy when you always write the same file. IMO that's a really bad idea. The trick with the different directories is not a bad idea if you actually have to write the image to a file in the first place. I guess, the only promising approach so far (FOP 0.95) is, to use new FopFactories and UserAgents for each thread and each report generated. But the note in http://xmlgraphics.apache.org/fop/0.94/embedding.html#multithreading (Apache FOP may currently not be completely thread safe.) is not very encouraging. That's just to cover our collective asses. FOP is thread-safe (if no little bug has sneaked in somewhere due to some oversight, multi-threading testing is not part of our normal test suite). But that doesn't mean it's not a good idea to do careful multi-threading testing of your application as a whole. I'm afraid I can't give you the best idea with the information I currently have. I don't know how you create your image. I assume you generate it before you call FOP. Assuming you have some information that lets you identify the data that needs to be turned into an image, consider passing that information [1] into the XSLT stylesheet as a XSLT parameter (similar to what I suggested above) but this time, you use this information to build up a private URI that holds all information to uniquely identify the image belonging to that report. Then, write a URIResolver that can deal with this private URI scheme to generate the image on the fly. That might actually allow you to bypass writing the image to a file, thus making the whole thing faster. [1] I'll try to show this by example: Assuming you can gather all your data from your database (assuming you use one) you could pass in the ID of the main record. my:report?id=873468color=red could then be your unique URI for the report 873468 and some data shall be highlighted in red (random example feature). Your URIResolver will listen to the my scheme and parse it, then return an InputStream (or for example a DOM (DOMSource) in case of SVG) that accesses the finished image. Maybe that helps. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 --- Comment #13 from M.H. [EMAIL PROTECTED] 2008-10-21 05:35:24 PST --- Thanks for all these ideas! We first create all data (XSL, XML, SVG) in a temporary directory for each report. Then we call FOP to transform the XSL+XML to PDF. The references to the external SVG files are in the XSLs (as relative paths to these files). With this approach, other developers first design the report offline on their workstation with their tools. We can also re-create the PDF anytime later with third party tools like fop.bat instead of our Java application. For debugging, we can look in any xsl, xml and svg as the files are there. Anyway, I wonder how you can generate the SVG on the fly and pass the SVGDOMSource to FOP, as the image cache is ignoring the URIResolver anyway (as I learned now). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 --- Comment #14 from Jeremias Maerki [EMAIL PROTECTED] 2008-10-21 06:01:55 PST --- (In reply to comment #13) Thanks for all these ideas! We first create all data (XSL, XML, SVG) in a temporary directory for each report. Then we call FOP to transform the XSL+XML to PDF. The references to the external SVG files are in the XSLs (as relative paths to these files). With this approach, other developers first design the report offline on their workstation with their tools. We can also re-create the PDF anytime later with third party tools like fop.bat instead of our Java application. For debugging, we can look in any xsl, xml and svg as the files are there. This sounds like we might have to rethink how we treat the URI when caching the image. If it's a relative URI, we'd have to prepend the base URI and only use the absolute URI in the image cache. I don't think we do that now. That could actually solve your problem. Anyway, I wonder how you can generate the SVG on the fly and pass the SVGDOMSource to FOP, as the image cache is ignoring the URIResolver anyway (as I learned now). The thing is: We assume that a resource can be identified uniquely by its URI. After all there's the word identifier in URI. If the same URI comes back, we assume it's the same image. The URIResolver is only used when we have to load the image (which is done once). The image loader framework then puts the loaded image (subclass of org.apache.xmlgraphics.image.loader.Image) into the cache under this URI, further identified by the ImageFlavor (as multiple representations of the same image can be stored in the image cache). So if you re-request the same URI again, the cache returns the image directly. No detour through the URIResolver. So, to pass in an SVG DOM, your URIResolver will create a DOMSource instead of a StreamSource. PreloaderSVG can make use of a DOMSource, so it doesn't have to be serialized to a stream first, in case you build your SVG as a DOM somewhere. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Active node tree pruning in FOP trunk
Hi all, after noticing that the layout tree pruning in the prototype [1] was improving performance I decided to implement it in FOP trunk to see how it was behaving in the real world. The concept I've applied to the general breaking algorithm can be defined as a last-n-lines fit algorithm; if n=5, when the algorithm find the first node for the sixth line it choose the final active node for the first line that have the best active node as child (this is a correction from the prototype implementation). Other nodes for line 1 gets discarded with relative children. When the algorithm determine a line break for line 7 the pruning is performed for line 2. This is equivalent to say that line 1 is chosen as the best in the context of lines 1-5, line 2 in the context of lines 2-6, and so on. While this algorithm won't give you the best possible layout (well, not always, depending on n value) as total fit do, it can improve performance and shrink memory usage by reducing the number of active node in some cases. Anyway it gets nice layouts, surely better than best fit, and by choosing the value of 'n' we can set the trade off between performance and quality. In the tests I've done I saw a sensible improvement when two conditions were satisfied: 1) the layout constraints was leading to an high number of active nodes (short lines, hyphenation enabled, non justified alignment); 2) the paragraph was long enough to produce many lines (if n is greater than the total number lines the pruning doesn't even get activated). As worst case I considered an A4 page with a single column with justified text split in many paragraphs: no performance improvements. Even if I process a single paragraph that is 8 page long the processing time is the same as if pruning was disabled, while the layout result is slightly different (but not bad). As best case I considered an A4 page with two columns, hyphenation enabled, left aligning for a single paragraph 8 page long. Here the performance boost is embarrassing: | cpu t | mem -+---+ No prune | 2'20 | 570 MB -+---+ n = 30 | 0'12 | 35 MB -+---+ n = 1| 0'07 | 35 MB Well, this is a really extreme test that unlikely will represent a use case, let's look at more tests: Just | 1 col | 1 par || no pru | n=30 | n=1 --+---+---+++--+-- X | X | X ||67 | 66 | 66 --+---+---+++--+-- X | X | ||66 | 66 | 67 --+---+---+++--+-- X | | X || 144 | 71 | 69 --+---+---+++--+-- X | | ||79 | 73 | 69 --+---+---+++--+-- | X | X || 326 | 90 | 67 --+---+---+++--+-- | X | ||99 | 90 | 66 --+---+---+++--+-- | | X || 2'202 | 120 | 70 --+---+---+++--+-- | | || 210 | 130 | 70 The test was done with the same text modified as follows: justified or left aligned, 1 or 2 columns, within a single block or split in 9 blocks of the same size. I've attached the patch to be applied to trunk: to enable pruning you can set the system property from the command line with -DtreeDepth=1 or any other number you choose for 'n'. If you don't define treeDepth the pruning doesn't get enabled. I've also attached the test fo files so you can check the resulting layout for the tests I reported above. Dario [1] http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200810.mbox/[EMAIL PROTECTED] pruneTrunk2.diff Description: Binary data fo-test.tar.bz2 Description: Binary data
DO NOT REPLY [Bug 46048] Wrong images used (how to clear image cache?)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46048 --- Comment #15 from M.H. [EMAIL PROTECTED] 2008-10-21 09:36:39 PST --- (In reply to comment #14) The thing is: We assume that a resource can be identified uniquely by its URI. After all there's the word identifier in URI. If the same URI comes back, we assume it's the same image. The URIResolver is only used when we have to load the image (which is done once). The image loader framework then puts the loaded image (subclass of org.apache.xmlgraphics.image.loader.Image) into the cache under this URI, further identified by the ImageFlavor (as multiple representations of the same image can be stored in the image cache). So if you re-request the same URI again, the cache returns the image directly. No detour through the URIResolver. Okay, I think I fully understood this and this is basically okay. So, the URIResolver is no suitable way of changing these URIs, alas. So what is a URIResolver good for, if it's just ignored in some cases (here: image cache already has URI and doesn't call URIResolver anymore)? Even the first time my URIResolver is called, the image cache still has the original URI instead of the changed URI from the URIResolver. Or is this behaviour also as intended? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43651] NPE without manually clearing image cache
https://issues.apache.org/bugzilla/show_bug.cgi?id=43651 --- Comment #4 from Sebastian Fuchs [EMAIL PROTECTED] 2008-10-21 10:39:54 PST --- (In reply to comment #3) Please upgrade to FOP 0.95 where this problem should be solved by the introduction of the new image loader framework. verified in the scope of comment #0 not sure if M.T.'s request is solved Sebastian -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43651] NPE without manually clearing image cache
https://issues.apache.org/bugzilla/show_bug.cgi?id=43651 --- Comment #5 from Jeremias Maerki [EMAIL PROTECTED] 2008-10-21 14:26:44 PST --- (In reply to comment #4) (In reply to comment #3) Please upgrade to FOP 0.95 where this problem should be solved by the introduction of the new image loader framework. verified in the scope of comment #0 Thanks for the feedback! not sure if M.T.'s request is solved That is being addressed as part of Bug #46048. Sebastian -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
