[mapserver-dev] [Support for reading SVG
symbols-MapServer-GSoC]Kiran Anjaneya Varma
Stephen Woodbridge
woodbri at swoodbridge.com
Sat May 9 10:26:16 EDT 2009
Kiran,
I think Steve L and Thomas will probably have better input on this. My
suggestion is more in the abstract that there is a good middle ground.
I suspect that you will probably want to look at the existing rendering
API and specifically at the symbol handling code. This will give you an
idea of what is handled today, then you might look at ways this could be
refactored so that it can easily be extended to support more or all the
SVG symbol features.
I don't know much about SVG or the rendering API so that means I'm not
constrained by any of the realities or facts about these things. So in
my mind, the simplistic model that I have is something like:
file.svg -> svg parser -> list of primitives -> render API -> image
+-> preprocess --/
It would seem that there is a finite list of SVG primitive features
which might be grouped into similar classes of features and that you
would need an interface for each of these added to the rendering API.
Currently the rendering API probably only has point, line, ellipse,
polygon, and text.
Some primitives might have a generic preprocessor that converts the
primitive into a sequence of API calls. Text follow path comes to mind,
arcs and splines could be converted to polylines before rendering, etc.
I'm sure these are not new ideas and the hard work is in the doing of it
and not ideal speculation.
Best regards,
-Steve
kiran varma wrote:
> hi
> yes i wanted to post it to everyone but , my mistake i just sent u
> . Anyways can u suggest me something to have a good start with the project,
>
>
>
> Thanks
> Kiran
>
> On Fri, May 8, 2009 at 10:33 PM, Stephen Woodbridge
> <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.com>> wrote:
>
> Kiran,
>
> The response only went to me, did you want it do go to the list also?
>
> -Steve W
>
> kiran varma wrote:
>
> HI all
> Great summary ..I guess our primary goal is we should
> implement an svg subset that maps to the existing render
> mapserver renderer API for GSoC..
> i guess we still need to decide about the graphics renderer we
> use i.e (cairo or someother),Tell me if something more i need to
> learn about my project and SVG symbolization
>
>
> Regards
> -Kiran
>
>
>
>
> On Sun, May 3, 2009 at 7:23 PM, Stephen Woodbridge
> <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.com>
> <mailto:woodbri at swoodbridge.com
> <mailto:woodbri at swoodbridge.com>>> wrote:
>
> Thomas,
>
> Great summary. So it sounds like if we were not constrained by
> trying to size this to GSoC effort, that we would probably
> decide to
> go with option 2. Well I would be inclined to go that direction
> based on your analysis.
>
> What would people think of pushing forward on option 2 as the
> overall mapserver plan and scoping the GSoC into a subset of that
> plan. I'm have no idea if this would be doable scope wise, but a
> natural subset might be:
>
> a. implement an svg subset that maps to the existing render
> mapserver renderer API for GSoC
> b. if time permits do a simple extension to the mapserver
> render API
> and svg parser
> c. complete the project of extenting the mapserver render API and
> svg parser in subsequent, funded? efforts.
>
> Regards,
> -Steve W
>
>
> Thomas Bonfort wrote:
>
> Hi all,
>
> I think we have three path that we could follow for
> incorporating SVG reading:
>
> * add SVG as a native format that should be rendered by each
> renderer.
> In this case, each renderer must include the logic to
> parse an svg
> file, and then use its own rendering primitives to add
> shapes to its
> generated image. This approach is very flexible, as each
> renderer can
> decide if it wants to rasterize the svg symbol, or
> transform it into
> vector primitives, or even dump the svg directly in the
> case of
> an svg
> renderer. It has the downside that each renderer should carry
> its own
> svg parser, and all svg rendering primitives.
>
> * use a higher level svg parser, that transforms the
> input svg into
> mapserver primitives. Unless we only support a subset of
> the SVG
> specification (which I think is a bad idea), we would
> have to extend
> mapserver's rendering api to support more than lines,
> polygons and
> ellipses as it is now. (cubic and quadratic beziers,
> gradients,
> filling rules come to mind, there are probably others)
>
> * use an out-of-the-box svg to pixmap rasterizer, and
> create scaled
> and rotated pixmaps at a higher level before passing them
> over to
> mapserver's low level renderers. We would have to
> leverage a pixmap
> cache to do this, so as not to repeat the svg parsing and
> rasterizing
> steps. A pixmap would be put in cache for each
> (scale,rotation)
> couple, or maybe only for each scale and rotate the
> created pixmap.
> libsvg-cairo could be an idea to explore without adding
> in too many
> dependencies.
>
> a couple of thoughts:
> - Options 1 and 2 oblige us to implement our own svg
> parsing, which
> isn't an easy task if we want to support the full svg spec.
> - I wouldn't go for option 1, as it would be hell to
> maintain, let
> alone implement.
> - Option 2 would be nice, as it would open up support for
> more
> symbology. (I'm think gradients, or postgis curves). I'm not
> sure the
> scope isn't too far fetched for a soc project though.
> - Option 3 is the easiest and least prone to failure imho.
>
> best regards,
>
> thomas
>
> www.camptocamp.com <http://www.camptocamp.com>
> <http://www.camptocamp.com>
>
> +33 4 79 26 57 97
>
>
>
> On Fri, Apr 24, 2009 at 21:38, Daniel Morissette
> <dmorissette at mapgears.com
> <mailto:dmorissette at mapgears.com>
> <mailto:dmorissette at mapgears.com
> <mailto:dmorissette at mapgears.com>>> wrote:
>
> Hi Kiran,
>
> Congratulations and welcome to the project. I meant
> to write
> an introduction
> email but have been too busy this week, so I'm glad
> you just
> did it.
>
> I think the first step for the project will be to define
> exactly what we
> mean by SVG symbol support. In your proposal you
> mentioned
> that you'd expect
> the SVG symbol to be included in the output and
> rendered by
> the browser, but
> as I think I wrote in one comment, MapServer is
> mostly about
> generating
> images, so things can't work as you expected for the
> image
> output formats
> (GIF/PNG/JPEG) which account for most usages.
>
> Instead, we'll need to find a way to efficiently
> parse and
> render the SVG
> symbol definition in a similar way to what is
> currently done
> for symbols of
> type vector in MapServer. We'll probably also need to
> define
> a subset of SVG
> that we allow for symbol definitions since we can't
> support
> the whole spec.
>
> This will require some discussion on this -dev list
> with the
> other
> developers to pick the best approach... and in the
> meantime,
> to feed this
> discussion, you could start by the following:
>
> 1- Have a look at the way vector symbols are handled in
> mapsymbol.c...
> browsing the source without a specific objejctive may
> be a
> bit of a rough
> start though, so perhaps just getting familiar with
> the use
> of vector
> symbols in a map would already be a good start.
>
> 2- Research and evaluate options for a non-intrusive open
> source library
> that can be used to parse a SVG symbol definition and
> render
> it in a
> MapServer image. By non-intrusive, I mean that the
> library
> should have a
> friendly open source license, be light-weight and
> ideally it
> should not add
> any no new dependency to the MapServer build process
> other
> than itself.
>
> 3- I wonder if Cairo or any of the new rendering stuff in
> the graphics
> branch could help with SVG symbols. I guess this is
> more a
> question for
> Thomas.
>
> Finally, I guess I need to do my homework as well if
> I want
> to guide you
> properly.
>
> Note to all other developers: all inputs and
> contributions
> welcome to make
> this a project a success.
>
> Daniel
>
>
>
> kiran varma wrote:
>
> Hi all
> I am A Kiran Anjaneya Varma 3rd year
> undergraduate ,my
> proposal[Support for reading SVG
> symbols-MapServer] has
> been accepted as
> part of GSoC 2009
> My mentor is Mr.Daniel Morissette
> Thank you for accepting me as part of your
> reputed MapServer
> project,I am very keen in working on this project .
> So what is my next step for having a good
> start
> on the project, I
> would also like to know about some of the sources and
> suggestions through
> which i can get a good flexibility on my project
> before
> coding day(May 23)
>
>
> looking forward to work successfully with u
> throughout
> this wonderful
> summer
>
> Thanks regards
> A Kiran Anjaneya Varma
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> <mailto:mapserver-dev at lists.osgeo.org>
> <mailto:mapserver-dev at lists.osgeo.org
> <mailto:mapserver-dev at lists.osgeo.org>>
>
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>
> --
> Daniel Morissette
> http://www.mapgears.com/
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> <mailto:mapserver-dev at lists.osgeo.org>
> <mailto:mapserver-dev at lists.osgeo.org
> <mailto:mapserver-dev at lists.osgeo.org>>
>
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> <mailto:mapserver-dev at lists.osgeo.org>
> <mailto:mapserver-dev at lists.osgeo.org
> <mailto:mapserver-dev at lists.osgeo.org>>
>
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>
>
>
>
More information about the mapserver-dev
mailing list