>>>>> "P" == Petilon <[EMAIL PROTECTED]> writes:
P> I want to make a Java Image object out of an SVG file. At first I P> thought org.apache.batik.transcoder.image.ImageTranscoder would be P> able to do it. However, it turns out this is an abstract class. It is an abstract class that takes care of rasterizing an SVG to a BufferedImage so you can stick in the few lines of code needed to write it to the format you want (such as your BMP encoder). P> If I want to rasterize, I am forced to choose between JPEG, TIFF P> and PNG. Why? Why can't Batik just give me an Image object and then P> let me do whatever I want with it? That I will be able to leverage P> my existing BMP output class (which takes a BufferedImage as P> input), instead of writing my own subclass of ImageTranscoder. There are a number of reasons the simplest to explain is that SVG is a scalable format (i.e. it has no strong notion of what size it should be rendered at) a lot of what the ImageTranscoder baseclass does is try and figure out a good mapping to pixels it also provides hooks to adjust this output. P> Why doesn't Batik do this obvious thing? Or can it already render P> into a BufferedImage? I don't understand why you are so offended that you need to write a subclass to plug in your own output format, Java is an object oriented language, this is entirely natural (it's not like the subclass is particularly complex, take a look a the PNG encoder, it's about a page of real code and it's one of the more complex outputs. There are other routes to a BufferedImage as well, one is the batik.gvt.StaticRenderer class, but then you need to figure out the mapping from user space to device pixels. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
