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.
