Re: [Geotools-devel] Rendering SVGs as vectors
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
Re: [Geotools-devel] Rendering SVGs as vectors
Milton Jonathan ha scritto: 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? Yes, and the answer is simple, as far as I know it can't. If you look at Paint it just refers to a PaintContext, which is a pure raster api (i.e., it uses the Raster class). Maybe during a print you have use bigger rasters to have better definition, but to the best of my knowledge the Paint API is not vector oriented at all. 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.. It would be a nice contribution anyways for the rest of the world you know ;) Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- 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
Re: [Geotools-devel] Rendering SVGs as vectors
Hi Milton: I am afraid I fall into the busy category. I have printed to both a printer and PDF before; but have not explored the use of Batik as an output format personally. The symbology rendering code may use a buffered image right now; but it should be capable of using a swing Icon (ie a promise to draw something in a specific location). Making this change would allow the decision to use a buffered image or not (inside the Icon) to be configured via a hint or something (or by looking at the DPI session). Cheers, Jody On Wed, Jun 17, 2009 at 11:41 PM, Milton Jonathanmil...@tecgraf.puc-rio.br wrote: 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? Cheers, Milton Milton Jonathan wrote: Hello again 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. 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? Cheers Milton -- Milton Jonathan Grupo GIS e Meio Ambiente Tecgraf/PUC-Rio Tel: +55-21-3527-2502 -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Rendering SVGs as vectors
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? Cheers, Milton Milton Jonathan wrote: Hello again 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. 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? Cheers Milton -- Milton Jonathan Grupo GIS e Meio Ambiente Tecgraf/PUC-Rio Tel: +55-21-3527-2502 -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Rendering SVGs as vectors
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 -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Rendering SVGs as vectors
Hello again 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. 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? Cheers Milton -- Milton Jonathan Grupo GIS e Meio Ambiente Tecgraf/PUC-Rio Tel: +55-21-3527-2502 -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
