Problems rendering SVG images in trunk

[woodbri]

I am running into some odd behavior using SVG symbols and trunk Revision: 13272.

I created a bunch of SVG symbols and in mapserver some display fine without a problem, some display partially ok but part of the symbol is distorted or missing and in one case the symbol does not display at all. I all cases the symbols display fine in Inkscape and render without a problem in Firefox.

So far I have just been playing with the images reconstructing them from scratch, etc to try and get them to work because initially I assumed it was my issue not being very knowledgeable about using Inkscape, and it might still be my issue. But I'm starting to wonder if I'm running into a mapserver bug.

I get nearly identical results on Debian Lenny and Squeeze. The H for hospital symbol has slightly wider verticals on Lenny.

I have attached an image that has two palettes of symbols side by side. The left is an html table with img tags in the cells displaying the svg symbol directly via Firefox. The right set are all rendered via mapserver and a mapfile. Some images do not display at all, some are badly broken and some have only minor issues.

I've done a lot to build these and to fix some that were broken and I have some ideas on what is working and what is not. I seems like polygons with fill seem to most of the time, but not always, lines with width do not seem to work but these may be because multiple paths do not seem to work and if the lines are represented as multiple paths that might be part of their problem.

I'll supply svg symbols and mapfile used in the test image to the developer that is working on this.

[woodbri]

All my svg symbols are reasonably simple, they all have been worked on in Inkscape and render correctly in Inkscape and Firefox and they all validate through W3C.

I have tried to look at the code, but I get as far as the fact that they are all getting rendered via: msRenderSVGToPixmap() which is basically calling Cairo code to process the svg. So this leads me to believe that is a bug in Cairo or the way it is setup and getting called or my svg files or something like that.

libcairo2/lenny uptodate 1.6.4-7
libcairo2-dev/lenny uptodate 1.6.4-7
libqt4-svg/lenny uptodate 4.4.3-1+lenny1
librsvg2-2/lenny uptodate 2.22.2-2lenny1
librsvg2-bin/lenny uptodate 2.22.2-2lenny1
libsvga1/lenny uptodate 1:1.4.3-27
svgalibg1/lenny uptodate 1:1.4.3-27

I get identical rendering results on squeeze with these packages

libcairo2/squeeze uptodate 1.8.10-6
libcairo2-dev/squeeze uptodate 1.8.10-6
libqt4-svg/squeeze uptodate 4:4.6.3-4+squeeze1

and the follow installed from source:

libsvg-0.1.4/
libsvg-0.1.4.tar.gz
libsvg-cairo-0.1.6/
libsvg-cairo-0.1.6.tar.gz

MapServer version 6.1-dev OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=CAIRO SUPPORTS=FREETYPE SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=GEOS INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE

cat /u/software/doit-mapserver-6.2
./configure \
  --enable-runpath \
  --enable-ignore-missing-data \
  --with-httpd=/usr/sbin/apache2 \
  --with-proj=/usr \
  --with-agg \
  --with-gd \
  --with-freetype \
  --with-postgis \
  --without-tiff \
  --with-wmsclient \
  --with-fribidi-config=/usr/local/bin/fribidi-config \
  --with-gdal \
  --with-wfs \
  --with-ogr \
  --with-experimental-png \
  --with-geos \
  --with-cairo=yes \
  --with-libsvg-cairo=yes \
  --with-java-include-os-name=no \
  --enable-debug

[sdlime]

Really need the SVG devs to speak up I think. Can you post the symbols with the bug or is that an issue? Does Cairo itself have any utilities that would let you render a symbol with the library independently of MapServer. I think that would be helpful in isolating the problem.

Steve

[woodbri]

Here are the SVG symbols and support files to create the palette of symbols in the attached png image above.

[zjames]

There's a utility that accompanies the libsvg-cairo library called svg2png. I don't recall if it's built by default but I ran it on Steve's symbols and got the same output as generated by mapserver.

That suggests we're looking at bugs or limitations in libsvg-cairo which is no longer under development. The alternative library is librsvg which is more up to date, but has a long list of dependencies that made us settle on libsvg-cairo in the first place. Perhaps a good next step would be to build librsvg and run these symbols through it to see if it handles them properly. It appears to have its own svg2png utility.

[woodbri]

These symbols are pretty simple and if libsvg-cairo is dead, I think we need to look at alternatives as a priority. I see this as a show stopper for a 6.2 release as I do not think we want to abandon SVG support after just adding it at 6.0.

Looks like the command svg2png command associated with librsvg is called rsvg.

[zjames]

I haven't had a chance to try it, but this project is maintaining an updated fork of libsvg-cairo that covers more of the spec than the original.

​http://svg2swf.sourceforge.net/

[woodbri]

Zak,

I have download the svg2swf stuff and built that and it works much better. See attached image ms-trunk-svg-bug-2.png and now all but two of the images are good (I discount the serif vs sans font issue).

That said, it was a pain to build the svg2swf forked packages because they had a large number of additional packages that I had to install just to get the newer libsvg-0.5.0 and libsvg-cairo to build and install. I assume that most of these extra packages are because of the needs to svg2swf rather then just for libsvg and libsvg-cairo, but I might be mistaken.

If we think this is going to be the long term way to go, we might want to consider forking a version of this into our tree to cut out the dependencies we don't care about, or working with the svg2swf developers to be able to configure the code doe our use without the dependencies that we do not need.

[woodbri]

Here is the results using libsvg and lobsvg-cairo from svg2swf package.

[woodbri]

Here is what I had to install to get the svg2swf libraries to compile and install:

# needed to build libsvg-0.5.0
sudo apt-get install liburiparser-dev liburiparser1
# No package 'libcroco-0.6' found


# building svg2swf-libcroco.tar.gz, I needed to add:
sudo apt-get install gnome-common
sudo apt-get install gtk-doc-tools docbook-dsssl docbook-to-man docbook-xml jade libosp5 libostyle1c2 libsp1c2 openjade sp
sudo apt-get install libglib2.0-0 libglib2.0-data libglib2.0-dev

# After this I was about to build and install libcroco, libsvg and libsvg-cairo and then for good measure rebuilt mapserver from an updated svn.
}}

[tbonfort]

Replying to woodbri:

These symbols are pretty simple and if libsvg-cairo is dead, I think we need to look at alternatives as a priority. I see this as a show stopper for a 6.2 release as I do not think we want to abandon SVG support after just adding it at 6.0.

Steve, cairo SVG output and SVG symbols are two completely unrelated topics, and the bugs you are seeing here are related to svg symbols which are a new feature of 6.2 . For me this isn't a showstopper for 6.2, unless you want to delay the release until sufficient funding is found for a more complete svg-symbol library.

[woodbri]

Replying to tbonfort:

Replying to woodbri:

These symbols are pretty simple and if libsvg-cairo is dead, I think we need to look at alternatives as a priority. I see this as a show stopper for a 6.2 release as I do not think we want to abandon SVG support after just adding it at 6.0.

Steve, cairo SVG output and SVG symbols are two completely unrelated topics, and the bugs you are seeing here are related to svg symbols which are a new feature of 6.2 . For me this isn't a showstopper for 6.2, unless you want to delay the release until sufficient funding is found for a more complete svg-symbol library.

Thomas, thanks I finally figured that out when SteveL added Zak and Assefa to the CC list. I have no desire to delay the release, but releasing a new feature SVG symbols that does not work does not make sense. It will generate a lot of noise and issues for users that try to use it. We also need to document what libraries are needed to build it and get all the packagers to support it with appropriate libraries that hopefully work. One of the drivers for adding SVG symbols is for better rendering output and symbol scalability for DPI changes. I'm not sure we should drop this feature but if we can not support it maybe we should. This is why I think it is a show stopper, but I'm just one person and Zak and Assefa have not had time to check in on it.

[tbonfort]

I somewhat agree with you Steve. My concern is that as the bugs seem to be in libsvg-cairo itself, there's not much we can do to release 6.2 rapidly with svg symbol support. Basically our two options are either :

• fix libsvgcairo upstream, and given it has not been updated in years this isn't going to be easy
• switch mapserver to use another svg parser/renderer

While waiting for one of these solutions to happen, we should clearly publicize in the release notes that the current SVG parser has some limitations we are aware of.

[zjames]

Steve W, thanks for taking the time to try svg2swf. I agree that the dependencies are pretty heavy but the key question is whether the modifications make for an acceptable parser. I'd be interested in your opinion on that. If not, use of librsvg may be inevitable, though I'm sure there are symbols that it too will render improperly. I note that the svg2swf fork hasn't been updated since 2009 so it may no longer be maintained either.

As a stopgap, couldn't the 6.2 release notes point to svg2swf and Steve's installation notes? No mapserver code needs to be modified to use that version and benefit from the improved output.

[sdlime]

I think the last suggestion is a good one for the time being- handle as a documentation issue. -Steve

[woodbri]

Using the svg2swf is significantly better. I was able to remake the two symbols that still had problems without too much effort, although there is some art to know how to modify the images. For me personally, I can probably live with svg2swf, because I have already work through most of the issues and I have all the dev tools loaded on my servers.

Zak, to address your question, we might be able to live with svg2swf from a parsing point of view. I have a large library of cartographic svg symbols that I will setup a test can see how it does overall and post the results.

My bigger concern is that it will be difficult or impossible for most users to be able to consider using it and it is unlikely that package developers will be able to deal with building it into packages.

If libsvg-cairo is dead, and svg2swf has been inactive since 2009 do we really want to base mapserver on it?

If we do not have the resources to do it right (whatever that is), I suppose we could document it as experimental and subject to change like we have with other features that were not ready for prime time with a separate page on how to build and install it.

I see a few of options based on what we know now. Listed in increasing levels of effort:

• document that it requires svg2swf and how to install it and whatever limitations we are aware of, maybe list it as experimental
• fork svg2swf and embed what we need in the mapserver tree
• Figure out what it takes to use librsvg

[woodbri]

I just ran a library of 300 svg symbols through the comparison of render in Firefox vs rendered via mapserver and 7 of 300 failed in mapserver using the svg2swf libraries.

I did an additional 186 images that were from other sources and they were more problematic with 31 failures. This just goes to show that svg files behavior is probably subject to the author and/or the authoring tool used to create them. Of the failures in this group most could be classified into what appear to be a few class problems like: positioning and/or scaling issues, use of text in the image, use of a polygon object rather than a path. I have not tried to fix these so I'm not sure how accurate this assessment is yet.

So I would have to conclude that this is probably an acceptable failure rate and that using svg2swf does a pretty good job of parsing and rendering svg images.

[tbonfort]

Steve, If you can try out ​https://github.com/dov/agg-svg on your test svg images and find out that it performs better or not very worse than svg2swf, I will volunteer to investigate using that rather than the current cairo based svg renderer. It would have the enourmous advantage of not requiring an external dependency.

[woodbri]

Thomas, Here is a side by side comparison of SVG, MS6.2 and agg-svg. ​http://imaptools.com:8080/svg-test/index-agg-svg.html

The table is set to a medium gray background so if the cell is white it generated an image and likely there is a scaling or other problem. For the agg-svg results, I ran the svg file through their svg2ppm and convert to get a png file. 189 of the files reported "svg parsing error!" message out of the 486 files processed.

Out of the box it looks worse than svg2swf, but it is hard to tell because somethings worked with agg-avg and not with svg2swf and vica versa. I might be the case that fixing a couple of class problems makes it look a lot better.

# Makefile to build svg2ppm

CPPFLAGS=-g -Wall -Wno-reorder
CPPPATH=/usr/include/agg2
LIBS=-lagg -lexpat

SRC=svg2ppm.cpp agg_svg_parser.cpp agg_svg_path_renderer.cpp agg_svg_path_tokenizer.cpp

svg2ppm:  $(SRC)
    g++ -o svg2ppm $(CPPFLAGS) -I$(CPPPATH) $(SRC) $(LIBS)

[tbonfort]

there seem to be some scaling issues with agg-svg. the white background is added by svg2ppm as ppm does not support transparency, so that does not seem to be an issue.

can you determine which svg operators caused the parsing errors?

[tbonfort]

I was able to compile libsvg-cairo from svg2swf without the multiple additional dependencies by specifying --without-libcroco . There was a need for the uriparser libs to be installed which I did not have, but it has no external dependencies. The code in libsvg and libsvg-cairo is still being maintained (last commits from january 2012).

The results we are getting with the svg2swf libsvg fork is on par with what agg-svg can propose, with the added advantage that the SVG does not need to be rasterized when being inserted in our vector outputs (pdf and svg). As such I would suggest we keep our current libsvg-cairo implementation, and investigate in ways to make it easy for our users to install the libsvg/libsvg-cairo librairies from svg2swf (either by forking, or by documenting)