Hey Andrea, hey Jody Thanks a lot for the suggestions, especially considering how busy you are :)
I just realized that, aside from SVG and other ExternalGraphics, the same issue also applies to Marks when they are used as a fill for a PolygonSymbolizer - they become an image-based TexturePaint! This is really bad for us, since we wanted to draw hatches and print them nicely, but the hatches are turned into images before printing, too bad.. So, I think we will have to spend some time to come up with a general approach that applies to ExternalGraphics and/or Marks used both as PointSymbolizers and as fills. Actually, I got a little confused since I didn't find an obvious way of drawing vector hatched-filled shapes with the Java API (that is, using a Paint different from the image-based TexturePaint). Do you guys know how this could be done? Oh, to let you know: we were implementing here a generic hatch ShapeMarkFactory, i.e., it does what Andrea's one does but for any angle (yeah, we were coping with computing the right shape size depending on the angle). Too bad it comes ugly on the printer.. Cheers Milton Andrea Aime wrote: > Milton Jonathan ha scritto: >> Hi there >> >> Hmm, nobody seemed to notice this e-mail (or everybody was too busy to >> answer). Could someone give me a hint as to whether there is any known >> alternative to this issue, or if you would like us to provide one? > > The second one (too busy to breath, luckily that's automated). > >>> We've tried recently to render our maps on Graphics other than the >>> screen (e.g., Batik's SVGGraphics and Graphics for printing). Almost >>> everything shows up nicely, BUT.. all the SVGs used as >>> ExternalGraphics in our SLDs suck big time. >>> >>> It looks like all SVG ExternalGraphics are rendered first to an image >>> (ending up as a GraphicStyle2D) and only then drawn on the target >>> Graphics. In my view, this has several problems: >>> 1. As expected, sending this to a printer with 1200dpi will really >>> not yield the results we would like to see >>> 2. Right now, the procedure ignores any previous scaling applied to >>> the Graphics >>> 3. Now that we have nice PointSymbolizers with variable size (due to >>> the UOM feature), we end up with the annoying effect of blowing up >>> memory when we come too close, since the BufferedImage used to store >>> the rendered SVG becomes way too large. > > Hmmm... this will happen with external PNGs as well. They are not > uncommon. Some JAI magic is going to be necessary to rescale the image > without the need to use a ton of memory. > >>> >>> I have some ideas of how to fix this, but I've seen previous posts >>> talking about this already. >>> http://www.mail-archive.com/geotools-devel@lists.sourceforge.net/msg13468.html >>> >>> >>> >>> So, my question (mainly to Andrea) is: what is the current status of >>> these changes? Is there a way to make SVGs render as vectors right >>> now? Is there partial work already done that we should build on? > > There is nothing at all. There is no funding on rendering coming in, > the few things I've done in the last months rendering related I've done > in my spare time. > > The resolved styles (Style2D subclasses) should learn to deal with > Icon instead of an image, a SVG Icon subclass should be generated > and returned by the SVG renderer, and the StyledShapePainter should be > modified to use it. > And oh, since rendering SVG is quite slow, there should be > a flag to decide whether to activate the above path, or keep the more > efficient one we have now. > > Cheers > Andrea > > -- Milton Jonathan Grupo GIS e Meio Ambiente Tecgraf/PUC-Rio Tel: +55-21-3527-2502 ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
