Lightweight C++ Library For SVG On Windows?

redblue writes "I would like to display vector graphics in my Windows C++ programs with minimal system requirements. Some of the possibilities are: 1. Enhanced Metafile Format format/EMF+, 2. Flash/SWG, 3. Silverlight/XAML, 4. SVG. The non-open proprietary nature of #2 & #3 make them unattractive. Since EMF+ is not amenable to easy editing, it leaves SVG as the only format worth pursuing. The trouble is that the major vendors have a lock on the market with their proprietary formats; leaving SVG high and dry with no easy native OS support. At least not on Windows. From what I could learn on the intertubes, Cairo is the best, if not only, reasonable system that may enable compiled SVG support. Unfortunately, AFAIK, it comes with a price tag of >2MB overhead and the C++ bindings are not straightforward." Read on for the rest of redblue's question; can you improve on his home-brewed solution? "In a flash of the NIH syndrome, I rolled my own SVG processing engine and it has addressed my needs. You can see the result on http://www.arosmagic.com/Solitaire. A simple breakdown is: Framework+CRT(150K), SVG engine(100k), SVG art(350k). My SVG library is sufficient for me for now. But I can't help wonder:
1. Is there a better SVG library out there already available for easy inclusion?
2. If not, is there a need, i.e. market demand, for a lightweight (~200K) C++ SVG library that does not have the baggage of Silverlight or Flash?

If the answers are No/Yes, it may be worth it to make this library fully SVG compliant and release it as an open source alternative to the offerings from the entities that we shall not name but just collectively refer to as The Microbe. Please help out by letting me know if such a component is something that you would personally want to use in your current/future projects."

Comments

Webkit?

[EsbenMoseHansen]

IÍ'd say QT/Webkit is the best bet currently. That will give you XML tools and a decent SVG view(er).

Re:TWO WHOLE MEGABYTES?

[mpapet]

Yeah, 2 whole megabytes may be too much. Remember there are *vastly* more small/dumb computing devices out there than the big-old desktop PC. So, maybe he's programming on a phone platform or some such and making a sincere effort to make something different.

I don't quite know what you are after, but I'll throw out SDL as a platform and SDL_svg. It may not fit in the requirements, but hey, it's worth a look.

Re:If you have the time/energy, then yes, please d

[erebus24]

Like SDL_svg? http://www.linuxmotors.com/SDL_svg/

Re:Inkscape?

[morgan_greywolf]

The Inkscape project is huge, but it almost sounds like you could rip livarot, Inkscape's current renderer, right from the code and use it. Inkscape itself doesn't even use Cairo because they consider it too immature (and, IMHO, it is, at this point).

OTOH, you could simply use librsvg to render the SVG graphics to PNG (or some other supported format) and display with the appropriate library calls.

Using librsvg this way always seemed like a bit of a kludge to me, but lots of projects use it for rendering.

So, to answer the OPs question as to whether or not there is a need for a lightweight C/C++ renderer -- I'd say yes.

Antigrain rules

[Cyberax]

The author of Antigrain is a perfectionist.

Just look here - http://www.antigrain.com/svg/index.html . And version 2.4 is under BSD license.

Re:Antigrain rules

[ciroknight]

Shortlist: AGG is a software renderer, and is a bit faster than Cairo-Pixman, though is less accurate than Cairo (Cairo is designed for correctness over performance, where possible, but does have an extensive regression and performance testing framework).

Cairo has multiple backends: Pixman which is software, X11 (through XCB or XLib), Windows, Mac OS X, BeOS, PDF/PS/SVG, DirectFB, SDL, OS/2, several OpenGL backends (Glitz though it's unmaintained, and at least two 'plain' OpenGL backends from different hackers), an OpenVG backend and an in-progress DRI2 backend (which directly uses the graphics hardware in Linux). In addition, it has very rich font support, supporting the default font system on the platforms above, and includes support for user-defined fonts. AGG's font support is rather mediocre, supporting only Freetype and Win32. Neither library does much extensive layout code, though Pango uses Cairo to produce (arguably) the best text layout experience in the (FOSS) world.

AGG has a richer set of vector-related features, such as Gaussian filtering (which has been a todo item for Cairo for quite some time), Type-6/7 meshes with Gouraud shading and image warping, and provides Gamma correction. Some work has been done on adding Gamma and color correction to Cairo, but I don't believe there's anything deliverable at this point.

Cairo has a richer set of bindings; being written in C, it has bindings to practically every commonly used programming language, and a few uncommonly/rarely used ones, such as OCaml and Keith Packard's Nickel language.

All-in-all, it's about what you're going to do with the two libraries. AGG is written more towards a graphics package, like Inkscape or the GIMP. Cairo is written more to be the backend of a display system, like Quartz2D.

What about CGM aka ISO 8632:1992

[Anonymous Coward]

CGM exists since about 1985, is standardized by ISO and supported by many applications (Corel, AI, Freehand,...). Binary and ascii representations exist.

Might be worth a look.

Inkscape uses Cairo

[Giant Electronic Bra]

Inkscape uses Cairo for all its rendering. Thus it is not going to be lighter weight than Cairo. There may be code in there that would provide a more useful interface, especially for C++ code. Reuse is always a good idea...

Juce

[Anonymous Coward]

Im surprised no one has mentioned the Juce library. It has svg support for multiple platforms.
http://www.rawmaterialsoftware.com/juce/index.php

OpenVG

[Anonymous Coward]

http://www.khronos.org/openvg/