Re: Image Cache issue - Latest Release after 0.20.3

2002-06-13 Thread Keiron Liddle

Hi Rishi,

The changes to the image caching you are referring to are in the
redesign code and not in the maintenance branch where releases are
currently coming from.
Unfortunately that code won't help you if you need it soon.


On Thu, 2002-06-13 at 00:48, Athalye, Rishi wrote:
 Hi,
 
 We are using fop 0.20.3 and it appears to be working fine for our purpose
 except for 1 major point.
 Caching of Images.
 Here's what I am doing :-
 Based on the program logic, I am creating multiple PDF documents applying
 the same XSL but different XML data feeds.
 If I am not mistaken, in an XSL using FO, there's no way to pass a parameter
 to the fo:external-graphic, thereby having a dynamic filename and path. (if
 anyone has done that, I would appreciate your tips)
 This is what we use.
 lt;fo:external-graphic src=url(images/firm_logo.gif)/gt;
 The base directory for each document is also different and that's set during
 program execution of each file.
 Program works fine, but, all 20 documents get the same images (i.e. the 1st
 document's).
 I did read about some people coming up with a solution for Image Caching
 and also that it's a known issue.
 How can I get the latest code with the bug fix. I tried building from the
 CVS snapshot, but I got some errors.
 Is there a build I can get from some location which works. I also saw there
 are significant differences now in the 
 ImageFactory Class implementation. So it's difficult for me to modify the
 code for our purpose.
 When is the next release going to happen ? We are going live shortly, hence
 would like to know our options.
 Sorry for the questions, but I am under a lot of pressure.
 I would appreciate any help in this direction.
 
 Rishi



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




RE: Image Cache issue - Latest Release after 0.20.3

2002-06-13 Thread Athalye, Rishi

Thanks a heap, Mike.
This solution worked. In any case, we do not need caching as we are not
reusing the same image in a
document.
Really appreciate it.

Rishi


Hi Rishi,

Athalye, Rishi wrote:
 
 We are using fop 0.20.3 and it appears to be working fine for our 
 purpose except for 1 major point. Caching of Images.

Yep, I was going to have a look at improving this, but haven't had the 
time lately.

 I did read about some people coming up with a solution for Image 
 Caching and also that it's a known issue.

There isn't a fix for it AFAIK, but you can turn off caching altogether 
with a recompile. Comment out line 196 in FopImageFactory on the 
maintenance branch like so:

   // m_urlMap.put(href, imageInstance);

and recompile FOP.

Note that this will slow down rendering and increase short-term memory 
usage if you use the same image multiple times in a document. It will 
get worse the more you use the same image.

Unless someone comes up with an actual fix (or applies an existing fix 
if there is one out there in the wild) sometime real soon now, then this 
will still be a problem in the next release.

Mike.

-- 
Michael Gratton [EMAIL PROTECTED]
Recall Design http://www.recalldesign.com/
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Image Cache issue - Latest Release after 0.20.3

2002-06-13 Thread Paul Reavis

 Athalye, Rishi wrote:
  
  We are using fop 0.20.3 and it appears to be working fine for our 
  purpose except for 1 major point. Caching of Images.
 
 Yep, I was going to have a look at improving this, but haven't had the 
 time lately.
 
  I did read about some people coming up with a solution for Image 
  Caching and also that it's a known issue.
 
 There isn't a fix for it AFAIK, but you can turn off caching altogether 
 with a recompile. Comment out line 196 in FopImageFactory on the 
 maintenance branch like so:
 
// m_urlMap.put(href, imageInstance);
 
 and recompile FOP.
 
 Note that this will slow down rendering and increase short-term memory 
 usage if you use the same image multiple times in a document. It will 
 get worse the more you use the same image.
 
 Unless someone comes up with an actual fix (or applies an existing fix 
 if there is one out there in the wild) sometime real soon now, then this 
 will still be a problem in the next release.

 Mike.

I ran into the same problem; I solved it in the current code by adding
a static method that clears the cache. I call this method before I run
fop. Unfortunately, the caching code in the stable assumes that you
are only calling fop once (e.g. from the command line) or, at least,
that external files aren't changing. This is also a big memory leak -
if you have a lot of large (in my experience, 1024x map pngs)
snapshots, and use different urls for each run, then each is loaded
into heap and the whole thing gets enormous.

-- 

Paul Reavis  [EMAIL PROTECTED]
Design Lead
Partner Software, Inc.http://www.partnersoft.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Image Cache issue - Latest Release after 0.20.3

2002-06-12 Thread Michael Gratton


Hi Rishi,

Athalye, Rishi wrote:
 
 We are using fop 0.20.3 and it appears to be working fine for our purpose
 except for 1 major point.
 Caching of Images.

Yep, I was going to have a look at improving this, but haven't had the 
time lately.

 I did read about some people coming up with a solution for Image Caching
 and also that it's a known issue.

There isn't a fix for it AFAIK, but you can turn off caching altogether 
with a recompile. Comment out line 196 in FopImageFactory on the 
maintenance branch like so:

   // m_urlMap.put(href, imageInstance);

and recompile FOP.

Note that this will slow down rendering and increase short-term memory 
usage if you use the same image multiple times in a document. It will 
get worse the more you use the same image.

Unless someone comes up with an actual fix (or applies an existing fix 
if there is one out there in the wild) sometime real soon now, then this 
will still be a problem in the next release.

Mike.

-- 
Michael Gratton [EMAIL PROTECTED]
Recall Design http://www.recalldesign.com/
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555



smime.p7s
Description: S/MIME Cryptographic Signature