-
-
Notifications
You must be signed in to change notification settings - Fork 362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems rendering SVG images in trunk #4252
Comments
Author: woodbri 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.
I get identical rendering results on squeeze with these packages
and the follow installed from source:
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
|
Author: sdlime Steve |
Author: zjames 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. |
Author: woodbri Looks like the command svg2png command associated with librsvg is called rsvg. |
Author: zjames |
Author: woodbri 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. |
Author: woodbri
|
Author: tbonfort
|
Author: woodbri
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. |
Author: tbonfort
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. |
Author: zjames 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. |
Author: sdlime |
Author: woodbri 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:
|
Author: woodbri 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. |
Author: tbonfort |
Author: woodbri 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.
|
Author: tbonfort can you determine which svg operators caused the parsing errors? |
Author: tbonfort 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) |
attachment http://trac.osgeo.org/mapserver/attachment/ticket/4252/svg-bug.tbz :
|
attachment http://trac.osgeo.org/mapserver/attachment/ticket/4252/ms-trunk-svg-bug-2.png :
|
Reporter: woodbri
Date: 2012/03/17 - 04:03
Trac URL: http://trac.osgeo.org/mapserver/ticket/4252
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.
The text was updated successfully, but these errors were encountered: