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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
