[mapserver-dev] SVG symbol support in MapServer: libsvg and librsvg

Tom Payne tom.payne at camptocamp.com
Mon Jan 23 12:29:02 EST 2012


Hi All,

Short version: it would be very helpful if MapServer's SVG symbol support
could use librsvg as an option. See the conversation below for more
information.

Comments welcome.

Regards,
Tom

Forwarded conversation
Subject: SVG symbol support in MapServer
------------------------

From: *Tom Payne* <tom.payne at camptocamp.com>
Date: 19 January 2012 11:12
To: zjames at dmsolutions.ca, yassefa at dmsolutions.ca
Cc: Alexandre Saunier <alexandre.saunier at camptocamp.com>, Emmanuel Belo <
emmanuel.belo at camptocamp.com>, thomas.bonfort at gmail.com


Hi Zak and Yewondwossen,

I'm a geospatial/sysadmin at Camptocamp and have been trying to build
MapServer with the SVG symbol support patch. We'd like to test it.
However, I've run in to some problems compiling it. Could I pick your
brains for a moment?

We're primarily a Ubuntu/Debian Linux shop, and both Debian and Ubuntu
provide packages for the Cairo graphics library, around version 1.8.10
or so. As far as I can tell, the SVG support in MapServer is based on
a library called libsvg-cairo, which was last updated in June 2005
[1]. Unfortunately, this library is not available for Ubuntu/Debian,
and it's proving problematic to package these old libraries from
scratch.

>From what I can devine, the primary library for generating images from
SVG files is librsvg [2] which are still more-or-less maintained
despite the ancient home page. Furthermore, from what I understand,
librsvg provides a more complete implementation of the SVG
specification than libsvg:
 http://old.nabble.com/libsvg-status--td29085398.html

Is there any interest in using librsvg as a backend for MapServer's
SVG symbol support rather than libsvg? If this posed problems for
Windows developers, another option would be to support both libsvg and
librsvg. The APIs are not too dissimilar.

Regards,
Tom

[1] http://cairographics.org/snapshots/
[2] http://librsvg.sourceforge.net/
--
Camptocamp SA
Tom PAYNE
PSE A
CH-1015 Lausanne

+41 21 619 10 13 (direct)
+41 21 619 10 10 (centrale)
+41 21 619 10 00 (fax)

----------
From: *Zak James* <zjames at dmsolutions.ca>
Date: 19 January 2012 15:18
To: Tom Payne <tom.payne at camptocamp.com>
Cc: yassefa at dmsolutions.ca, Alexandre Saunier <
alexandre.saunier at camptocamp.com>, Emmanuel Belo <
emmanuel.belo at camptocamp.com>, thomas.bonfort at gmail.com


Hi Tom,

I'll defer to Thomas on the question of which library makes the most sense.
I know we looked at both during the code sprint where we discussed the
implementation. As I recall libsvg-cairo was easier to compile on my os x
development box.

Can you describe the problems that you're having? Do the functions we're
using in libsvg-cairo have close matches in the librsvg? I think it's quite
a small set.

zak
--
Zak James
Applications and Software Development
DM Solutions Group Inc.
http://www.dmsolutions.ca
http://research.dmsolutions.ca

----------
From: *Tom Payne* <tom.payne at camptocamp.com>
Date: 19 January 2012 17:45
To: Zak James <zjames at dmsolutions.ca>
Cc: yassefa at dmsolutions.ca, Alexandre Saunier <
alexandre.saunier at camptocamp.com>, Emmanuel Belo <
emmanuel.belo at camptocamp.com>, thomas.bonfort at gmail.com


Hi Zak,

It certainly makes sense to use libsvg-cairo on Windows: its has fewer
dependencies. librsvg depends on a number t of the Gnome libraries,
and so I imagine that it's more of a pain on Windows.

The specific problems that I'm having relate (currently) to libsvg
version 0.1.4 (the latest), specifically src/svg_image.c, which calls
PNG and JPEG functions (e.g. png_check_sig, jpeg_std_error), without
(as far as I can tell) ever explicitly linking to these libraries.
Similarly src/svg.c calls gzlib functions (e.g. gzdopen) without
linking to the appropriate library. This later confuses Debian's
automatic dependency calculation system when building the packages: it
finds the calls to the functions, but cannot find the associated
libraries. I think it can be fixed with a bit of autotools magic, but
my autotools knowledge is a bit rusty at the moment. If you develop on
Debian/Ubuntu I can share the packaging code with you.

Regarding APIs, it's my first close look at the SVG code, but the APIs
seem to provide similar functionality. libsvg exposes an underlying
cairo context which the renderSVGSymbolCairo function in mapcairo.c
manipulates with a translate and scale transformation to ensure that
the symbol is correctly sized. Although at the high level librsvg
seems more focused on rendering SVG images to bitmaps (GdkPixbufs), it
does seem to have a function rsvg_handle_render_cairo which allows the
loaded SVG (use rsvg_handle_new_from_file) to be rendered to a cairo
context.

Regards,
Tom

----------
From: *Zak James* <zjames at dmsolutions.ca>
Date: 23 January 2012 18:10
To: Tom Payne <tom.payne at camptocamp.com>
Cc: yassefa at dmsolutions.ca, Alexandre Saunier <
alexandre.saunier at camptocamp.com>, Emmanuel Belo <
emmanuel.belo at camptocamp.com>, thomas.bonfort at gmail.com


Tom,

Sorry for the delay in getting back to you on this. I agree that there are
good reasons for the inclusion of both libraries but this will probably
require an additional or ammended RFC. Perhaps we should move the
discussion to the mapserver-dev list to get input from other developers.
Can you post your response there?

zak
--
Zak James
Applications and Software Development
DM Solutions Group Inc.
http://www.dmsolutions.ca
http://research.dmsolutions.ca







-- 
Camptocamp SA
Tom PAYNE
PSE A
CH-1015 Lausanne

+41 21 619 10 13 (direct)
+41 21 619 10 10 (centrale)
+41 21 619 10 00 (fax)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20120123/45147629/attachment.html


More information about the mapserver-dev mailing list