Good, Bad and Ugly things about SVG


After working with SVG for a few weeks, here are my initial impressions:



  • Includes a very friendly XML schema which is easy to implement (GOOD)

  • Nice mix of high & low level rendering capabilities (GOOD)

  • I couldn’t find a way to control the rendering DPI.. it seems locked into 72 (UGLY)

  • Spec includes both regular XML version and a compressed format for smaller footprint files (GOOD)

  • Has several different viewers with reasonable compability including Adobe and  Corel (GOOD)

  • Has NO built in printing capabilites – The SVG spec doesn’t include printing, or print control elements such as numbering, page breaks, etc. (BAD!)

  • Most viewers don’t support printing in any way or form , Adobe supports limited rastered printing. (BAD)

  • Rendering performance is problematic.  The SharpVectorGraphics library can take up to 5 seconds to render a page… Even the Adobe viewer is much slower than the PDF viewer for any given document. (BAD)

In MHO,  SVG shows a lot of promise but is still not 100% ready for prime-time.  The upcoming versions of the specs should handle many of the issues I mentioned and many vendors are joining the SVG bandwagon, so it is probably a pretty good bet going forward. However if you plan implement or consume SVG *today* then you can expect the usual grief and aggravation associated with cutting edge technologies…


Just my 2 cents 🙂


Comments (2)

  1. DonXML says:

    Addy, Totally agree with most of what you said. Just curious about the 5 seconds SharpVectors issue. Even the most complex SVG I’ve tried haven’t run 5 seconds. The only known issue we have at the momement is if you don’t provide a viewbox attribute off the main SVG element. If you did that, rendering times were terrible. It all has to do with how we have to figure out what you really wanted to do. Viewbox isn’t required (as per the spec), but there are very few times that you would want to exclude it. It controls the box that is acutally rendered. Anything outside the box is clipped.

    Also, make use of symbol elements and use elements. They provide a more object oriented way of doing things, reduces the size of the SVG, and increases the performance of the viewers.

    I would have posted this as blog entry, but most folks on DNWB don’t care about SVG.

    DonXML

  2. Jesse Ezell says:

    Don, correct me if I am wrong here, but wouldn’t the GDI+ renderer from SharpVectors allow you to print your SVG straight to a printer device?