Perhaps a custom URL Protocol? http://xmlgraphics.apache.org/batik/using/extending.html#urlProtocols
On Fri, Oct 1, 2010 at 8:59 PM, Maass, Adam (Snapfish) <adam.ma...@hp.com>wrote: > OK, so this is something of an odd request: > > > > > > I have an application in which I want to, at runtime, dynamically replace > an embedded image: > > > > <image xlink:href="data:image/jpeg;base64,/9j/4AAQSkZJ…. > > > > I have a solution that works but is sub-optimal: I read the image I want to > substitute, determine a content type for it, base-64 encode its data, and > replace the xlink:href attribute of the image element. > > > > > > What this means is that I have at least two (usually three!) > representations of the image data in-memory – even before a subsequent > transcode operation! (That is, one in a ByteArrayOutputStream to accumulate > the data, one in the byte[] that ByteArrayOutputStream returns, and a third > in the base-64 encoded version of that byte[].) The subsequent transcode > operation will necessarily base-64 decode the data I just encoded, create a > bitmap out of it, and presumably blit the bits into the resulting JPG. > > > > This is far too many large data structures floating around! To reduce the > count of large data structures, I really want to specify in the href element > that the image data should come from some InputStream I have at hand. Then > when Batik processes the image element, it reads the InputStream directly, > and creates only the one or two copies of the image data it really truly > needs. Is there a way to do this? If not, can someone point me in the right > direction if I were to take this on on my own? > > > > > > -Adam Maass > > > > >
