Quoting [EMAIL PROTECTED]: > Quoting Victor Mote <[EMAIL PROTECTED]>: > > > [EMAIL PROTECTED] wrote: > > > > > We have an api that generates a sort of "barcode" image that > > > needs to be put on the bottom of each page. However, each > > > image is unique and needs to be generated with some > > > information from the xml document. I know I can do this by > > > using a REST api call and putting a URL in the fo:graphic > > > that dynamically generates the image. However, I'd rather do > > > it right in the Java code that sets up the Driver. So, is > > > this possible? Some thoughts I have, but don't know if they exist: > > > > My guess is that markers with a URL would be the easiest and most standard > > way to do this. But I'll take your word for it that you want the callback. > > > > > 1. Can I get a callback that calls my Java code when a > > > certain fo:graphic element is hit and let me dynamically put > > > the XSL:FO content in there? This would allow me to > > > dynamically generate the images on the fly and put the > > > appropriate image content in . > > > > I think you can do this, but again, it seems like a pain. IIRC correctly, > > the FONode class has a getParent() method which can be used to recursively > > go up the tree until you get to the Root (keep in mind that this is XML/FO > > inheritance, not Java inheritance). I would cache the object that will > > generate the image in Root, and, if it does not exist already, write an > > FONode method called getRoot() which will recursively go up the tree to > Root > > and return Root. Then, you'll need to modify the code that creates the > image > > in the AreaTree, and then use your (presumably) ExternalGraphic node to do > > something like the following: > > YourGraphicMaker ygm = > > externalGraphic.getRoot().getYourGraphicMaker(); > > Image image = ygm.makeGraphic(externalGraphic); > > // pass the image instance where it needs to go. > > > > I have used the above technique successfully to handle global items like > > loggers and subsystem servers. > > > > > 2. Can I put custom xsl:fo elements in the document and then > > > register my own "renderers" for dealing with those types? > > > > The renderers are more oriented toward a given output medium, so you are > > more likely going to be modifying or extending one to handle your custom > > elements, but yes, this general technique could work as well. My guess is > > that this is probably even more of a pain than option 1 above. Some > > information is here: > > http://xml.apache.org/fop/dev/extensions.html > > > > Victor Mote > > > > You are correct that doing a custom servlet REST style api for generating > the > images would be the cleanest. However, we have some serious performance > needs, > and I am reluctant to throw another piece in this that introduces http with > something that could be a local method call. > > Looking through the source code, it seems like the > org.apache.fop.image.analyser > .ImageReaderFactory class might be something I could use. It looks like if > I > write my own custom URL, and register my class as a reader, I will get > called > through the verifySignature method of ImageReader. As long as I am the only > one that can deal with the image, I should be all set. > > The other thought I had with looking at the code is regsitering my own > custom > URL through the JDK mechanisms. > > Irv >
One more question: While looking into this code, it looks like the FopImageFactory opens up a stream to the image using the URL class, then the specific ImageReader implementation reopens the stream again. So, if I did a REST style interface to generate my images, it looks like it would be called twice. Am I missing something here? It looks like this is a little inefficient. Irv --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
