The rasterizer uses the default Java2D rendering hints of the platform. This results in lower quality graphics (depending on the platform I guess), which is especially noticable when drawing small (in terms of pixels) shapes. The rasterizer should have options that allow setting the rendering hints to use. A number of fast presets (highest, lowest, etc.) could be used to set known sets of rendering hints at once. See the following thread for more information: http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-users/201002.mbox/%3c002701caa5d9$eee2d5d0$d08d664e@hanz%3e
(In reply to comment #0) > The rasterizer uses the default Java2D rendering hints of the platform. I don't think this is correct. AFAIK, the rasterizer uses the rendering hints specified by content [1]. > The rasterizer should have options that allow setting the rendering hints to > use. A number of fast presets (highest, lowest, etc.) could be used to set > known sets of rendering hints at once. Let's try to clear this up a bit. As I've stated within the same thread [2], the idea was to allow these rendering hints to *override* the hints already provided by the content (even if not specified, the lacuna values will be used, so this is implicit). Providing a mechanism to override the rendering hints, possibly through the proposed presets would then be cool to allow optimizing for a few use-cases (somehow already stated [2] also): * Batch or high volume conversion, where speed could be required/desirable over quality; * Printing, where optimal quality would be highly desired given the usually high resolution available in most output devices; * Etc.. I've rephrased the bug's summary to reflect this clarification. :-) [1] http://www.w3.org/TR/SVG/painting.html#RenderingProperties [2] http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-users/201002.mbox/%3C2a1ddf8a1002071046t499e6580i66c8bc9e8a1dbd23@mail.gmail.com%3E