When my personal need comes, I surely will, although now I have other things to do. If others want to write a more detailed proposal (Luca for example) please do.>
The *real* fact is that if I do:
xml data -> chart transformer -> batik -> png
It's 10x SLOWER than
xml data -> chart serializer -> png
This is not peanuts, this is a real need.
And the serializer should be configurable as the chart transformer (same functionality).>
Of course, we could make a transformer that creates a png image, puts it in the context, and then a serializer serializes it, but it seems to really stink.
So, how would you tackle the above real-world problem?
I would not write a transformer but a serializer. In fact, a chart package image rendere *is* a serializer, since the output of a chart transformer will not need to be further processed anyway.
What's wrong with this?
Stefano.
