[svg] is there any interest in a Scalable Vector Graphics library?
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 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 <olegmax@gmail.com> 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
2015-03-04 23:00 GMT+03:00 Damian Vicino <damian.vicino@inria.fr>:
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.
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.
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.
2015-03-05 18:00 GMT+03:00 Phil Endecott <spam_from_boost_dev@chezphil.org>: 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
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/
2015-03-07 1:23 GMT+03:00 Roger Martin <roger@quantumbioinc.com>:
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
On Wed, Mar 4, 2015 at 8:23 PM, Oleg Maximenko <olegmax@gmail.com> 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.
2015-03-07 14:30 GMT+03:00 Klaim - Joël Lamotte <mjklaim@gmail.com>:
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
participants (6)
-
Damian Vicino -
Dhruv Kohli -
Klaim - Joël Lamotte -
Oleg Maximenko -
Phil Endecott -
Roger Martin