complete the support of the SVG symbols

[assefa]

From what I can see a lot of the pieces needed to be able to support SVG symbols in Mapserver are there. The big missing part seems to be the rendering function, which from what I gather could be based on the agg svg example. There was an effort in this sense (​http://trac.osgeo.org/mapserver/wiki/GSoC_SVG_Symbols_SECOND_DRAFT_OF_THE_MS_RFC). I believe the general ideas still apply although the implemenation details are different:

• read an svg file (symbol type SVG)
• rasterize it into a pixmap (based on the agg svg example)
• caching (I am not sure yet about this one)
• place pixmap on the map.

[assefa]

note that there is some work done in ​http://trac.osgeo.org/mapserver/ticket/3343

[zjames]

svg symbols patch against [12103]

[assefa]

patch against r12756

[assefa]

committed in r12841

[assefa]

some info for docs:

in the symbol file

symbol
    name "svgsymbol"
    type svg
    image "interstate.svg"
end

in the map file

 STYLE
    SYMBOL "svgsymbol"
    ANGLE 40
    SIZE 10
    ....

[tbonfort]

fyi, the pixmap buffer has to be in un-premultiplied state, otherwise you get rendering artifacts on pixels where alpha!=0 && alpha!=255

fixed in r12843

[tbonfort]

autotests added in r12845

[assefa]

Thanks.

[schpidi]

Starting with r12841 I get the following (with/without --with-cairo and/or --with-libsvg-cairo):

g++: @LIBSVG_CAIRO_INC@: No such file or directory
make: *** [renderers/agg/src/clipper.o] Error 1

[tbonfort]

Replying to schpidi:

Starting with r12841 I get the following (with/without --with-cairo and/or --with-libsvg-cairo):

g++: @LIBSVG_CAIRO_INC@: No such file or directory
make: *** [renderers/agg/src/clipper.o] Error 1

the configure script was not commited to trunk, you'l have to regenerate it by running autoconf.

[assefa]

should we commit the configure file generated by autoconf (v 2.67)? I never committed that file so I am not sure if I should do, there seems to be a lot of changes when doing a diff.

[zjames]

Updated configure.in and configure have been committed in r12865 and r12866

[havatv]

Added to trunk symbol documentation in r13306.

[tbonfort]

In r13309 I have refactored the SVG code so it does not have to store scale and rotation in the symbol->pixmap_buffer rasterBufferObj. SVG cached data is stored in symbol->renderer_cache as planned, and there is no mixing up between SVG and PIXMAP types in symbol->type.

This is not a minor change, so concerned people might want to check everything is ok on there own end.

[zjames]

I built with this changeset and can verify that output is as before, specifically checking the case where the same symbol is used in several rotations and scales in the same layer. That was the scenario that led us to add the extra elements in the rasterBufferObj. Thanks for implementing the much cleaner solution you suggested at the code sprint in the first place!