ePUB & SVG

The OPS specification states that compliant Readers MUST support SVG. Other than ADE, none of the free and open Readers support SVG display (some don't even support CSS or images).

eBook readers are meant to handle resizing, and reflowing as core values. SVG is a major contributor to delivering these values now and in the future. There are a number of reasons for using SVG (and this list is not comprehensive):

• Bitmap images in SVG will render much better on resizing
• Covers with SVG text over a background raster image resize stunningly; and a book is judged by its cover.
• SVG icons and repetitive images look great no matter how much they are scaled
• Line art never degrades on resizing (unless made ridiculously small of course)
• Equations and formulas rendered in SVG look fabulous, and can be resized clearly
• SVG Tiny for mobile devices is the best way to get sharp icons and images rendered onto a small screen

Some reasons SVG is not used more, or even a consideration are:

• It's hard to create. That has been addressed with some good supporting tool now available, but its still not the same a resizing an image.
• Its really hard to make a reader with SVG support - which is why ADE is the only game in town at present. All the open source ePUB readers, including Mobipocket, just don't display SVG.
• It's only really needed for certain types of content, so we get by with raster images
• The content that is being published in ePUB is simple novels. There is no education, corporate or heavily illustrated content out there yet.

SVG has long been a "political" standard, and vendors of proprietary vector format applications fought it one way or another for a long time. This poor cousin treatment got to the stage where people were questioning whether the standard was relevant. This changed dramatically with the new trend to standards compliant pages on the Web. While the standardization push has been driven mostly by governments insisting on accessibility standards being deployed (for their websites), the rise of Mozilla/Firefox as a truely standards compliant browser and viable option was a strong contributor and has breathed life back into SVG.Opera has also always been there in the background pushing standards compliance as well.

Back when IE was the only browser game in town and not supporting PNG or SVG, there was no real reason to work with SVG in a content delivery environment. Adobe had their SVG plugin, with it's non-standard behaviours, and that was enough for the little spot of SVG here and there.

Now that Opera, Safari, Chrome and Firefox all have excellent SVG support, the ground is shifting. This is matched with these browsers equally avid standards support of all things CSS. The compliance is now very high, and getting better everyday. The decision to support SVG as a mandatory format in ePUB was timely and appropriate. 

ePUB is basically a collection of standards - mostly W3C, which have been "dumbed down" for the current state of eReader devices. It primarily takes the approach that eBooks are electronic versions of print books, but does make some concessions to where eContent could go.

It will be interesting to see if/when the open source Readers support SVG. Rendering an SVG canvas is probably the most difficult part of an eReader engine, but the best SVG rendering sourcecode is available in Webkit and Mozilla open source products and works superbly. The catch, it must be rendered as XML in the reader, and the open source ePUB eReaders I have seen use the SGML rendering of the XHTML. If this is not handled correctly - no SVG, even if using a power engine like Webkit. But that is a subject for another blog.

Comments

[Liza Daly]

Bookworm (http://bookworm.threepress.org) supports SVG insofar as the user's browser does: http://bookworm.threepress.org/publishers/epub

[R. Stephan]

Firefox is actually behind, as you cannot zoom into loaded SVGs with it. Chrome and Safari can, they apparently have a different engine.

Another difficulty is alignment of inline math, as a truly portable SVG consists of paths only, and paths have no font typesetting info like baseline etc. Maybe this will be solved using Unicode characters with only displayed math using SVG...