Victor Mote wrote: I appreciate that! Unfortunately, I have implemented what I needed by doing a custom URL. I had actually never done this with Java before, but it wasn't bad. So, I "register" my own URLConnection type with Java, and then when FOP hits that URL for the image, my code gets instantiated. I can then dynamically generate the image and return the InputStream to it. It works great and I don't have to mess with the FOP code. As a "side effect" I can use that same strategy with our library outside the FOP code.Irv Salisbury III wrote:It seemed like most of the readers would read the image into memory. So, one thought on an "enhancement" might be to always read the bytes in from the URL and then just hand that off instead of opening the URL again.Of course, this doesn't allow for future enhancements where it doesn't need to read the whole thing into memory.Hi Irv: I spent the last couple of days refactoring my graphics package (not FOP, but derived from FOP) a bit. It needed to be done anyway, and your question gave me a good excuse to dive in. The upshot is this: 1. As you have suggested, I have changed most of the Readers (Factories in my package) to open the stream once in most cases, read what it needs, and reset. One of them (I think TIFF) still opens another stream later. That can probably be fixed also, but I don't have time to do it now. 2. More importantly, I replaced all of the class-loading stuff with pluggable factories, which means that you can create your own factory, register it, and, as the URL goes by, have it look at it to decide if it is one of your special cases. If so, create a Graphic instance that talks to your own classes, and you are on your way. The method that makes the Graphic instance (i.e. that manages the Factories) has a boolean that can be set to either cache the instance or not. If you decided to use any of this, you still have the non-trivial task of integrating my work back into FOP's code. It is very doable, but it will probably take some time. I'm not really suggesting that this is an efficient way to go -- I just wanted to let you know that it an option. You can see the code here: http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-graphic/src/java/org /foray/graphic/ Email me off-line if you need help finding out how to download the code. Victor Mote I hope to get some time at some point to give back to FOP. I have given back to most of the other open source projects I have used. We are on such a tight deadline with a few different projects that it won't be for awhile. However, I am hoping our current project will be a nice addition to the success stories of FOP. We are going to be printing about 3 million pages per month with a major company, right at the heart of its business. Once it is further along, I can discuss more, but I am hoping it will be a huge success for both FOP and open source. I am sure this won't be the last question I have! By the way, I found out the technology I had to integrate had a public URL. So, you can see it at: http://www.parc.com/research/istl/projects/dataglyphs/ So, we are using FOP to print the pages with the dataglyphs encoded within. Irv --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] |
- Re: Image callback for each page? The Web Maestro
- RE: Image callback for each page? Victor Mote
- RE: Image callback for each page? irv
- RE: Image callback for each page? irv
- Re: Image callback for each page? J.Pietschmann
- Re: Image callback for each page? Irv Salisbury III
- Re: Image callback for each page? J.Pietschmann
- RE: Image callback for each page? Victor Mote
- RE: Image callback for each page? Victor Mote
- Re: Image callback for each page? Irv Salisbury III