[svg] is there any interest in a Scalable Vector Graphics library?

older
Mailing List For GSoC 2015

Oleg Maximenko

4 Mar 2015 4 Mar '15

7:23 p.m.

Hi, I developed library that carries out large amount of tasks related to SVG reading - parses various SVG syntaxes (with Spirit), makes some conversions and implements few non-trivial algorithms common to SVG reading applications. Using this library developer may focus on importing/drawing tasks, leaving SVG details to library. I believe that it is (almost) generic enough for Boost standards, but not sure if there is a place for it in Boost collection. Should I move toward library proposal? Any feedback is welcome. http://svgpp.org/ https://github.com/svgpp/svgpp Thanks, Oleg

Show replies by date

Damian Vicino

4 Mar 4 Mar

8 p.m.

New subject: [svg] is there any interest in a Scalable Vector Graphics library?

I think the idea of having something like that is very cool. I saw in your code base a directory called third_party. Do you plan to replace the use of the third_party dir with boost only code? Would it be too much work to do that?

...

On Mar 4, 2015, at 8:23 PM, Oleg Maximenko wrote:

Hi,

I developed library that carries out large amount of tasks related to SVG reading - parses various SVG syntaxes (with Spirit), makes some conversions and implements few non-trivial algorithms common to SVG reading applications. Using this library developer may focus on importing/drawing tasks, leaving SVG details to library. I believe that it is (almost) generic enough for Boost standards, but not sure if there is a place for it in Boost collection. Should I move toward library proposal? Any feedback is welcome.

http://svgpp.org/ https://github.com/svgpp/svgpp

Thanks, Oleg

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Oleg Maximenko

5 Mar 5 Mar

6:19 a.m.

New subject: [svg] is there any interest in a Scalable Vector Graphics library?

2015-03-04 23:00 GMT+03:00 Damian Vicino :

...

I think the idea of having something like that is very cool. I saw in your code base a directory called third_party. Do you plan to replace the use of the third_party dir with boost only code? Would it be too much work to do that?

Hi. Nice to know that someone is interested. Libraries from third_party dir are used only in samples and tests - they are not part of the library. Only Boost is required.

Dhruv Kohli

7:48 a.m.

New subject: [svg] is there any interest in a Scalable Vector Graphics library?

Hi, In gsoc 2014, I developed a general png to svg converter from scratch using a new algorithm (we call it mindthegap). You can have a look at it: https://github.com/INCF/Vectorization-of-brain-atlases or here : https://github.com/chiggum/mindthegap . Please tell me if any further info about algorithm or usage of software is required. Regards.

Phil Endecott

3 p.m.

New subject: [svg] is there any interest in a Scalable Vector Graphics library?

Hi Oleg, Oleg Maximenko wrote:

...

I developed library that carries out large amount of tasks related to SVG reading - parses various SVG syntaxes (with Spirit), makes some conversions and implements few non-trivial algorithms common to SVG reading applications. Using this library developer may focus on importing/drawing tasks, leaving SVG details to library. I believe that it is (almost) generic enough for Boost standards, but not sure if there is a place for it in Boost collection. Should I move toward library proposal? Any feedback is welcome.

SVG is an XML format. Boost doesn't have an XML library. Have you created your own XML parser, using Spirit? Is that usable by itself? Regards, Phil.

Oleg Maximenko

4:05 p.m.

New subject: [svg] is there any interest in a Scalable Vector Graphics library?

2015-03-05 18:00 GMT+03:00 Phil Endecott : SVG is an XML format. Boost doesn't have an XML library. Have you

...

created your own XML parser, using Spirit? Is that usable by itself?

Hi Phil, Of course this library doesn't handle XML parsing itself. I've chosen way of using arbitrary XML library through compile-time configured traits. This way we can easily extend support for any XML DOM parser with zero runtime overhead. The library at the moment includes traits for libxml2, MSXML, Xerces and RapidXML NS parsers . Single-header RapidXML NS parser proved itself to be reliable and fast and can be shipped with the library as default choice. Oleg

Roger Martin

6 Mar 6 Mar

10:23 p.m.

New subject: [svg] is there any interest in a Scalable Vector Graphics library?

On 03/05/2015 11:05 AM, Oleg Maximenko wrote:

...

The library at the moment includes traits for libxml2, MSXML, Xerces and RapidXML NS

pugixml? http://pugixml.org/

Oleg Maximenko

11 Mar 11 Mar

12:15 p.m.

New subject: [svg] is there any interest in a Scalable Vector Graphics library?

2015-03-07 1:23 GMT+03:00 Roger Martin :

...

pugixml? http://pugixml.org/

I know about pugixml, but it lacks XML Namespaces support, which is widely used in 'xlink:href' SVG references. So I decided to not implement restricted traits for pugixml for the moment. Oleg

Klaim - Joël Lamotte

7 Mar 7 Mar

11:30 a.m.

New subject: [svg] is there any interest in a Scalable Vector Graphics library?

On Wed, Mar 4, 2015 at 8:23 PM, Oleg Maximenko wrote:

...

Hi,

I developed library that carries out large amount of tasks related to SVG reading - parses various SVG syntaxes (with Spirit), makes some conversions and implements few non-trivial algorithms common to SVG reading applications. Using this library developer may focus on importing/drawing tasks, leaving SVG details to library. I believe that it is (almost) generic enough for Boost standards, but not sure if there is a place for it in Boost collection. Should I move toward library proposal? Any feedback is welcome.

http://svgpp.org/ https://github.com/svgpp/svgpp

Thanks, Oleg

I am more interested in the techniques you used to build this library than by svg itself (I have a similar format that I want to make a similar library for) but I think this can be useful provided that it have a lot of traits for a lot of XML libraries, and maybe some JSON and YAML libraries. (because as soon as you have this kind of library, what prevent you to store the data in another format than xml?) I wouldn't make this a requirement though. I am reading this http://svgpp.org/lesson01.html but it seems pretty difficult to undestand to me. For example, would there be a way to simplify how to specify processed_elements_t ? The first example feels cryptic (a bit like Boost.Graph actually). The links to the sample sources and most reference links don't seem to work.

Oleg Maximenko

11 Mar 11 Mar

12:45 p.m.

New subject: [svg] is there any interest in a Scalable Vector Graphics library?

2015-03-07 14:30 GMT+03:00 Klaim - Joël Lamotte :

...

I am more interested in the techniques you used to build this library than by svg itself

You may take a look on svgpp\include\svgpp\policy\xml\rapidxml_ns.hpp to see how I implemented universal XML access, but I doubt that it is generic enough to reuse it. For SVG reading only small subset of XML DOM features is need, so it can be covered with single interface without affecting performance.

...

I am reading this http://svgpp.org/lesson01.html but it seems pretty difficult to undestand to me. For example, would there be a way to simplify how to specify processed_elements_t ? The first example feels cryptic (a bit like Boost.Graph actually).

I must admit that processed_elements_t part was unreasonable complex for the tutorial, I made some changes. There are no links to sample sources in tutorial, just paths in repository. Other links should be valid, could you please point to invalid ones. Oleg

3550

Age (days ago)

3557

Last active (days ago)

List overview

Download

9 comments

6 participants

participants (6)

Damian Vicino
Dhruv Kohli
Klaim - Joël Lamotte
Oleg Maximenko
Phil Endecott
Roger Martin