Forgot your password?
typodupeerror
Graphics Operating Systems Programming Software Windows IT Technology

Lightweight C++ Library For SVG On Windows? 130

Posted by timothy
from the put-a-choke-on-your-tla-dectector dept.
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."
This discussion has been archived. No new comments can be posted.

Lightweight C++ Library For SVG On Windows?

Comments Filter:
  • Inkscape? (Score:3, Insightful)

    by PinkPanther (42194) on Thursday May 28, 2009 @03:00PM (#28127861)
    I haven't looked at the code, but is there something that you can leverage from Inkscape [inkscape.org]?
    • Re: (Score:3, Informative)

      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

      • by ciroknight (601098) on Thursday May 28, 2009 @05:19PM (#28130411)

        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.

        You bash Cairo for being "too immature" (wtf, really? It's one of the most advanced 2D vector libraries out there), and then recommend a rendering library that is written exclusively to render to Cairo. Well played sir.

        • *I* didn't "bash" Cairo for being too immature, the Inkscape developers did. In their Wiki [inkscape.org]. I actually had no idea that librsvg used Cairo for rendering.

          But I will say that I make heavy use of SVG and many advanced features, and when an application uses Cairo (like the Gnome Image Viewer) they never render correctly.

    • Are you out of your mind?

      The overhead in Inkscape will surely be greater than the 2MB required for Cairo (which for some reason the OP finds unacceptable). Furthermore, Inkscape, like other similar applications, probably stores its graphics in an internal data structure. The SVG reading and writing are only a front-end for constructing and translating the internal data structure. The code that draws the image will be using the internal data structure, not actual SVG data. All of these things coupled togeth

    • by goldaryn (834427)
      > I haven't looked at the code, but is there something that you can leverage from Inkscape?

      Not looking at the code: +1.
      Answer indicative of having RTFA: -10.
      ---
      Net gain/loss: -9
      • This AskSlashdot was about "SVG C++ code for Windows". What is it you claim I missed?
        • by fractoid (1076465)
          He was shooting for teh funnay. You're not conforming to the slashdot stereotype of "I didn't RTFA" but he gave you a bonus point for not reading the code. I presume you could have scored additional points by saying that Natalie Portman accidentally a word while running Linux is like a car made out of hot grits.
    • 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...

    • by drakaan (688386)
      If I recall correctly, Firefox can display SVG...maybe a talk with Mozilla devs is in order?
  • Trim cairo? (Score:3, Interesting)

    by EkriirkE (1075937) on Thursday May 28, 2009 @03:01PM (#28127887) Homepage
    It looks like your needs/game only use basic vectors, nothing fancy like blends, blurs. Could you just strip out much of the code from the SVG source that does stuff you don't foresee using?
    • by redblue (943665)

      That's just a side effect of using David Bellot's SVG cards which only uses basic paint effects.

      The intent is to be able to use all the fancy effects if they are present in an SVG file and supportable by the rendering hardware. Thus full SVG compliance is always a worthy goal, long term.

  • Webkit? (Score:3, Informative)

    by EsbenMoseHansen (731150) on Thursday May 28, 2009 @03:02PM (#28127915) Homepage

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

    • Re:Webkit? (Score:4, Interesting)

      by Carewolf (581105) on Thursday May 28, 2009 @03:21PM (#28128361) Homepage

      Pulling QtWebkit in is not exactly light weight. But Qt actually has another SVG rendered that implements the SVG tiny standard. Using QtSvg is still several megabytes of Qt libraries though, so except for the nice C++ interface, not the solution for the original question.

    • QT/Webkit once you've got all of the dependencies down is over 20 megs. Cairo is an order of magnitude smaller.

      The fact is, vector art isn't cheap. Not computationally, not memory wise. Making a real go at it (not just faking a bunch of it, as many libraries do for speed) takes time, it takes work, it takes a bunch of libraries (XML parser, CSS parser, layout engine, etc). Putting any size constraint on it should at least take these things into account, which this developer quite clearly has not.

      I'd s
      • by redblue (943665)

        ...Cairo is an order of magnitude smaller.

        And I want it an order of magnitude smaller still.

        The fact is, vector art isn't cheap... (not just faking a bunch of it... it takes a bunch of libraries ...

        Actually, I did do it cheap, I did fake it, and it didn't take a bunch of libraries (not counting OS). I'll admit that a compromise will probably need to be made for size reasons, though I'd rather leave them as compile time options. But most of those compromises have to do with outlying SVG features. A subject worthy of discussion when a full featured (or slightly less so) library is on the anvil.

        I'd suggest he do his homework and look into the libraries that currently exist.

        Believe me, I did do the homework. It may have been inadequa

      • by jgrahn (181062)

        The fact is, vector art isn't cheap. Not computationally, not memory wise.

        Really? Why not? I would have thought it's just Bresenham and a bunch of other familiar algorithms (splines, clipping, antialiasing and stuff) into a raster buffer. ("Cheap" is relative. I'm thinking "cheap" as in "insignificant load on a computer from this millenium"; I remember that my Amiga 500 wasn't all that good for rendering Postscript.) We're talking 2D, non-animated, right?

        it takes a bunch of libraries (XML parser, CSS parser

    • by redblue (943665)

      In the process of developing the library, I built an SVG viewer to test it. The nice thing about having a GDI+ based SVG viewer is that it becomes trival to generate EMF+ files using it. Something that I can't do with any SVG renderer out there.
      Also, having restricted myself to Windows, I was able to leverage MSXML. Though I am seriously pondering using tinyxml or some such library.
      With that aside, QT has it's share of issues. It's not completely free and it has a heavy file size footprint, at least on Wind

    • by BitZtream (692029)

      Webkit is not the best bet for anything SVG related, its SVG support is absolutely horrid, as is Gecko's. It works for primative shapes, but move anywhere beyond that and they both failure to be useful. Scripting in webkit? Have fun. Filters? Yea right. Text alignment, whats that? If you want nothing more than to draw single color polygons, maybe with some borders you'll probably be okay, but even going so far as to add rounded corners to a rectangle and you've already ventured off of what Webkit can

  • by El Cabri (13930) on Thursday May 28, 2009 @03:03PM (#28127935) Journal

    That's just ideological drivel. The point is, SVG is a " standard " with a nice w3c.org - hosted spec and a nice diversified, academy-industry panel of contributors, but the fact remains, that in the 10 years since it became a standard, nobody really cares. Even browsers that support it officially only support subsets of it. The pragmatic reality is that it's a standard only in name, not in fact. If you want something with a clean, complete, consistent documentation describing a real, working, complete, multi-platform implementation, then what you call " proprietary" solutions are actually the way to go. Read the actual license terms for them and you'll see there's actually NOTHING that they prevent you to do, that you'll likely to have any interest in doing.

    • by Kludge (13653) on Thursday May 28, 2009 @03:19PM (#28128309)

      The pragmatic reality is that SVG is becoming standard very quickly. Have a look at wikipedia.org. (Have you heard of it?)

      " proprietary" solutions are actually the way to go. Read the actual license terms for them and you'll see there's actually NOTHING that they prevent you to do, that you'll likely to have any interest in doing.

      Yes, I'm sure that Adobe will have no problem with him using their library in his program that he gives out to all his friends and clients.

      • Yes, I'm sure that Adobe will have no problem with him using their library in his program that he gives out to all his friends and clients.

        The Flash player? Go right ahead: "Adobe provides a free license to allow you to redistribute Adobe Flash Player or Adobe Shockwave Player on your company's intranet, or with your software product or service." (here) [adobe.com]

        Ditto the XAML solution: the render is included in .NET 3.

        The pragmatic reality, to borrow your phrase, is that more people have a Flash player installed than an SVG renderer.

    • Re: (Score:3, Insightful)

      by theskipper (461997)

      Read the actual license terms for them and you'll see there's actually NOTHING that they prevent you to do, that you'll likely to have any interest in doing.

      Maybe not but I'd argue it's a tad naive. Out here in the real world, there's nothing stopping a for-profit company from changing terms on their proprietary format license. After all, it's theirs. If they can make a profit by altering the terms in the future then why shouldn't they?

      And proprietary formats work surprisingly well. Witness .doc as well

    • We're using Batik [apache.org] and it's great. It's real, working, (mostly) complete, and multi-platform. Does it cover absolutely everything? No, it doesn't (see their status page), but it has done everything that we want it to do.
      • Re: (Score:3, Funny)

        Yeah, I guess the OP would just have to convert his C++ project over to Java which is pretty much trivial! (since they both use C-based syntax)

        • And of course, while he's worried about Cairo eating 2 MB of RAM, I'm sure the massive amount of RAM consumed by the JVM won't bother him in the least...
          • by redblue (943665)

            A minor correction. The 2MB issue was for file size. Rendering vector graphics can be very RAM intensive. I have posted my thoughts on this in a separate place. Sorry about the confusion.

            To remain in context, I'm hoping to do for C/C++ what Batik has done for JVM. Or at least a usable approximation of such. In a very light package. Or be pointed to the same if someone else has already done that work.

    • by eggnoglatte (1047660) on Thursday May 28, 2009 @05:41PM (#28130695)

      ...Even browsers that support it officially only support subsets of it.

      Exactly. The root cause is that "lightweight" and "SVG" are mutually exclusive. SVG is an incredibly complex standard, and implementing it to spec is going to take incredibly complex code.

      • by redblue (943665)

        You may be right, but...
        Having implemented a subset of SVG I found that most of the hard parts were in the absence of certain functions/functionality in GDI+. But I never felt that they can't be made whole with focused effort. It might require better brains than mine, and it might take a whole year. But it's doable.
        As long as you are clear and focused about the objectives -- render {static,dynamic} SVG on {GDI+,OpenGL, Quartz, etc}. The key is to be focused.

    • by Shados (741919)

      The point is, SVG is a " standard " with a nice w3c.org

      You've never tried implementing a w3c spec I think. HELLOOOOO SWISS CHEEZE!

    • by redblue (943665)

      It's as easy as 1-2-3 to use the many variety of bitmap formats because there is either built-in OS support for them or good focused free open source libraries out there.
      It has not been so for vector art. I just can't do a Draw(VectorFile, HDC/Gdiplus::Graphics), though I can do so for bitmaps. EMF+ gives you that functionality, but is non-portable and non-editable.
      GDI+ implements so many SVG contructs close to spec it's scary. It's almost as if XAML was designed to spite SVG. That "intent" is so clear to m

  • by Anonymous Coward on Thursday May 28, 2009 @03:10PM (#28128093)

    ..about ripping the V8 and Skia engines from Chrome and making a standalone vector graphics system. Skia is light by design. V8 is fast and easy to embed by design. It's all C++ from the ground up. Implement the SVG interpreter in Javascript. Provide a JSON based alternative for the XML haters. Merge ongoing improvements from Chrome et al.

    Just need a year of funding...

    • by BitZtream (692029)

      And in six days of waitting for your javascript to render a single flowRegion or text element, you might get to see the first letter. SVG via javascript would be absolutely painfully slow and worthless for anything of value.

  • minimal system requirements

    2. Flash/SWG, 3. Silverlight/XAML

    Does not compute.

  • by The End Of Days (1243248) on Thursday May 28, 2009 @03:15PM (#28128205)

    2 megabytes of overhead? It ain't 1988 anymore, 2MB barely even registers these days.

    I get the whole Slashdot obsession with bloat, but there's a limit.

    • Re: (Score:1, Troll)

      by EkriirkE (1075937)
      I sure hope you are not a developer or never plan to be one.

      It is ideology like that that give us bloatware and forces us to upgrade our hardware so we are able to run your program(s), assuming we want or need to, alongside others uninhibited.
      • It is ideology like that that give us bloatware

        No, actually it's not. Saying that 2 megs is a trivial overhead is not the same as saying you should accept 500 meg programs that require dual core machines and gigs of memory. They aren't even in the same league.

        and forces us to upgrade our hardware so we are able to run your program(s), assuming we want or need to, alongside others uninhibited.

        If you have to upgrade your hardware to account for a 2 meg overhead in a program, you should consider upgrading to technology at least from the late 90s.

        • Re: (Score:3, Insightful)

          by mzs (595629)

          But this is solitaire. When I was a kid I wrote a version of solitaire in less than 300 lines. This should not be a 2+ MB program, and see he did it around 650K of object code.

          • You didn't have resolution-independent graphics, either.

            It's all fine and dandy to write code that runs in a terminal and lets you play solitare in codepage 437 graphics, but this is 2009 and people expect more from their thousand dollar computers, and application developers like to have their software scale seamlessly to devices like phones, PDAs, Netbooks, etc.
            • by spitzak (4019)

              Actually very early solitarie games certainly *did* have resolution-independent graphics. A few vectors to describe a card image took less space than a bitmap (granted the card images were usually a rectangle with a suit symbol and number). Vectors could easily be scaled to different sizes.

          • by Kjella (173770)

            But this is solitaire. When I was a kid I wrote a version of solitaire in less than 300 lines. This should not be a 2+ MB program, and see he did it around 650K of object code.

            Let me try to care.... nope, can't do it. I'd rather have a solitaire that did something new and exciting in 20MB than the 4k compo. I don't think even my phone cares about 650kb vs 2mb anymore. On an odd coincidence, I just remembered making a card game in Java as one of my first exercises, lol. Never stayed with that language though.

          • by redblue (943665)

            The core logic of the game is less than 300 lines. Most of the space is the graphics or its support.
            One motivation for doing vector graphics is reducing the file size for large displays apart from modeling convenience. In addition to that I am seeking a smaller file size for the executable that renders the vector graphics. Hence the original askslashdot.

            • by mzs (595629)

              I am actually impressed that you got your solitaire in 650K or so since it does so much. My version was on a Casio graphing calculator.

              I get annoyed when people do not consider: what does my software do, what is reasonable in time and space

              Many people decide as long as it is always below some arbitrary number, that is good enough.

              They fail to realize that DRAM is not the only resource nor that they share it with all other processes. In particular a much more limited shared resource is the L1 cache. When sof

        • If you have to upgrade your hardware to account for a 2 meg overhead in a program, you should consider upgrading to technology at least from the late 90s.

          A lot of handheld platforms still in use have capabilities comparable to that of technology from the mid-1990s. For example, Nintendo DS has 4 MB of RAM and similar GPU throughput to the original PlayStation and N64.

      • This is 2MB on disk that we're talking about here. That's the second most useless metric for a library I can imagine. Maybe I should choose my libraries based on how many lines of source went into them?

        But don't let facts get in the way of your attitude.

    • by mpapet (761907) on Thursday May 28, 2009 @03:25PM (#28128441) Homepage

      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.

      • SVG is pretty broad. There's lots of pieces, and so the library is going to be big. 2M of C++ holds a huge amount of functionality. So, I'd think that the choices are either to pick a subset of the functionality or take the 2M.
        • by redblue (943665)

          You are probably right. But through conditional compilation, an open source library will give you that ability. The trouble comes in when you have a general purpose agent (like a browser) which must support the full spec. If all the SVG creatives are in your control, you can specify restrictions at source and achieve optimal file size/good-looks tradeoff.
          I was unsuccessful in that attempt with Cairo, but I'll admit I may have given up too easy after about a week's worth of effort.

      • by Blakey Rat (99501)

        Good thought, but the summary specifically says he's coding Windows C++ programs. In which case, 2MB is such a drop in the bucket it doesn't matter.

      • Even phones have plenty of RAM. What they lack is CPU power, so any sort of acceleration he can take advantage of will help.

        And acceleration usually means even more memory usage. :P

        • by tlhIngan (30335)

          Even phones have plenty of RAM. What they lack is CPU power, so any sort of acceleration he can take advantage of will help.

          And acceleration usually means even more memory usage. :P

          You assume that, but 2MB is a huge chunk if you're coding for say, Windows Mobile. Until WinMo 7 comes out, every application in WinMo is limited to 32MB total. That is code, stack, heap, and associated DLL's required, memory-mapped files, etc.

          So even if your WinMo phone has 128MB of RAM, each application's memory area is only 32

          • Well, he freed up a whole megabyte and a half.

            If memory usage is that tight, then I congratulate you for saving roughly 4.7% of the available memory.

      • 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.

        Except we know he's not programming for something other than a "big-old desktop PC" because the title of the post is "Lightweight C++ Library for SVG On Windows?" Even for the crappiest/oldest Windows systems still in use, 2 MB is comically small. I I actually thought that spec was some sort of typo, but I guess not!

    • 2 megabytes of overhead? It ain't 1988 anymore, 2MB barely even registers these days.

      A lot of people outside metropolitan areas still can't get an Internet connection faster than 0.05 Mbps.

      • Satellite, anyone?

        Yes, some people are on the wrong side of a mountain, but I am guessing the number is significantly smaller.

  • While on the subject, I would like to ask what other open formats there are for vector graphics. I'm especially interested in efficient formats (avoiding the overhead of XML) and in formats that do more than just represent images (e.g. that allow animation and/or scripting).

    • I would like to ask what other open formats there are for vector graphics. I'm especially interested in efficient formats (avoiding the overhead of XML) and in formats that do more than just represent images (e.g. that allow animation and/or scripting).

      There are representations of an element tree other than XML; one of them is called JSON. You could represent the SVG DOM in one of those, and then you could gzip it for further savings. And then use JavaScript to manipulate the DOM.

      • Problem is, by the time you make JSON a 1:1 mapping of the XML, you lose some of the advantages of JSON, I would think.

        Or does SVG always use elements, instead of attributes?

        Either way, a new standard would probably help in other ways.

    • PostScript, PDF are still the winners in terms of adoption and efficiency. PostScript is more burdensome code-wise, so most everyone today will recommend PDF (it's essentially "PS-lite") or even a subset of PDF (most commonly throwing out things like quadradic Bezier curves and higher-level filtering).

      Most modern Windowing systems are heavily influenced by these as well; Cairo is essentially DisplayPDF (using slightly different compositing operators; closer to the original Porter-Duff ones), Quartz even
    • by redblue (943665)

      I had that same dilemma going in since I dislike the verbose XML syntax. I hope my experience is of some help.
      One of the ideas I had early on was, after reading in the SVG in memory, to save it back in a different "superior" file format to save space. The intent was to read this easier format and render it with no XML overhead. Turns out there was little gain, if any. SVG is fairly lean, as is, after compression. All the repetitive elements get compressed away to nothing by arithmetic compression.
      The XML pr

  • Mobile SVG (Score:2, Interesting)

    by SpaceToast (974230)
    I'd suggest looking at projects for bringing SVG to smartphones. You may find an SVG library for Windows CE that would compile under (vanilla) Windows -- probably not feature complete, but chances are the Mobile SVG specs are enough for your needs. I believe there is at least one very trim branch of Firefox underway, though SVG support may be one of the things that it trimmed. Good luck.
  • Antigrain rules (Score:5, Informative)

    by Cyberax (705495) on Thursday May 28, 2009 @03:48PM (#28128939)

    The author of Antigrain is a perfectionist.

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

    • Re: (Score:3, Interesting)

      by RAMMS+EIN (578166)

      How would you say AGG [antigrain.com] compares to Cairo [cairographics.org]?

      • Re:Antigrain rules (Score:5, Informative)

        by ciroknight (601098) on Thursday May 28, 2009 @08:24PM (#28132683)
        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.
    • by redblue (943665)

      I looked at AGG brief. No doubt a work of a person more qualified and talented than yours truly. He has even implemented an SVG renderer.

      Unfortunately, it suffers from three problems:
      1. Even though the AGG renderer is superior visually to GDI+, it is extra baggage in file size and the visual differences not great enough to justify that difference.
      2. Inability to use hardware acceleration that GDI+ gives.
      3. The SVG processor is woefully inadequate, even less than my humble efforts. It really only highlight A

      • by Cyberax (705495)

        GDI+ does not use hardware acceleration, and AGG is actually faster ;)

        • I doubt that GDI+ does not use any hardware acceleration, as it must go through (hardware-accelerated) GDI.
          • by Cyberax (705495)

            Yes, you are correct. However, GDI is capable of accelerating only very basic operations (flood fill, bitblits). It can't accelerate antialiased line drawing and gradient fills.

            And it's quite ironic, because internally GDI+ has a lot of hooks for hardware acceleration. Only no one has ever implemented it.

  • by 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.

  • works for me. http://sdlsvg.sourceforge.net/ [sourceforge.net]
  • Juce (Score:1, Informative)

    by 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

    • by redblue (943665)

      Thanks. Hearing about it for the first time. It looks like a solid piece of work. However (ignoring GPL for the moment), it says it has an "Importer for simple SVG files...", implying it probably only has a fraction of SVG.
      It's demo programs are also coming in at ~650-900K. It might be too heavy. Perhaps if there was just a demo of an SVG viewer a proper evaluation can be done...

  • At the risk of offending the geek-gods, would anyone be able to answer the same question, but for C#/.NET? Everything I've found so far for rendering SVG written in C# is either "under development" or "abandoned".

    • by Orne (144925)

      If you're playing in Windows C#Net, you really want to take a look at WPF. Microsoft basically "embraced" the SVG spec into the System.Windows.Media objects, and "extended" the objects to mesh with the rest of the architecture, and wrapped it all with binding properties so it can do some pretty interesting stuff. http://msdn.microsoft.com/en-us/library/ms742562.aspx [microsoft.com]

    • by redblue (943665)

      Probably because Silverlight/XAML is the correct answer if you are doing any .Net work. Just a no brainer if you are an ISV. SVG start looking superfluous.
      It is also fairly easy to take an unmanaged C++ SVG engine and put CLR bindings for it. But a world of pain vice versa.

      Silverlight is an obvious long term strategy to extinguish SVG and supplant it with XAML. Same as they did to OpenGL with DirectX. Or tried to.

  • Some of you have responded negatively to the need of rejecting a library with >2M overhead. Allow me to address that instead of responding individually.
    Regrettably, I was unclear about what that 2M referred to. I totally meant the file size, not the memory footprint. The real utility of vector graphics shows up on large displays, meaning large buffers in the 5-30M RAM range, so imposing a RAM limitation is not wise per se.
    The reasons for wanting a small file size are threefold:
    1. Lower bandwidth cost
    2. B

    • by johannesg (664142)

      I'm all in favor of having a small linkable SVG library! I've been looking for something like that for a while, but haven't found anything acceptable for my needs. So instead of displaying the SVG's directly I prerender to PNG and show that instead. That makes the icons the only part of the user interface that don't scale.

      I've considered ripping the rendering engine out of Inkscape and building a standalone library out of that. Problem is, it is a lot of work for a cosmetic gain...

  • OpenVG (Score:1, Informative)

    by Anonymous Coward

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

  • My SVG Library (Score:2, Interesting)

    by JM Apocalypse (630055)

    I've been working on a similar problem in my spare time for quite some time now. I needed a SVG library that was BSD-compatible, could draw any Adobe Illustrator SVG, and selectively enable or disable objects by their ID that was suitable for inclusion in a 3D game.

    I couldn't find any library that fit the requirements, so I ended up writing a C++ library called Donner SVG. It is heavily based on librsvg except written with SVG DOM in mind and for minimal dependencies. It's only dependencies are Cairo, ra

  • I would think that if you are looking at C++ in Windows that you would probably consider using GDI+ as the basis for an SVG style render. GDI+ fits in nicely with Windows DC model, but is very cleanly object oriented.

    And um, I would think that, by its nature, SVG is not going to be all that small....

Help stamp out Mickey-Mouse computer interfaces -- Menus are for Restaurants!

Working...