99problems
99problems copied to clipboard
iBooks is selective about where xmlns:xlink should go in embedded SVG
Our ebook production people complained that iBooks 4 on iOS 8 would choke on the following embedded SVG:
<div …>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1"
width="100%" height="100%" viewBox="0 0 1000 1594">
<image xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="images/000-0-0000-0000-0_front.jpg"
width="1000" height="1594"></image>
</svg>
</div>
Where “choking” means that once you’re trying to zoom in on that image, iBooks’ UI will freeze.
They found out that it can be fixed by moving the xmlns:xlink declaration up to the svg element:
<div …>
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"
width="100%" height="100%" viewBox="0 0 1000 1594">
<image xlink:href="images/000-0-0000-0000-0_front.jpg"
width="1000" height="1594"></image>
</svg>
</div>
Moving the namespace declaration up to the surrounding XHTML didn’t help.
It shouldn’t matter at all where this namespace is declared, as long as the declaration is in scope when the image element is being read. This indicates that iBooks is not using a “real” XML parser.
If you’re using XSLT 2 or 3 for creating/splitting your EPUB content files, this can be achieved by copying all elements except svg with copy-namespaces="no" and explicitly adding the xlink namespace declaration to the svg element (see example ← wow, it took me less then 4 attempts to get the brackets, parentheses, link and text thing right. I’m getting proficient in this “markup” language).
XML namespaces are kind of tricky, admittedly. But what is much worse than the XML namespace complexity alone: That some applications that pretend to be XML-aware expect literal namespace declarations at certain locations. The XML might be equivalent from an XML parser’s perspective, but not for these pseudo XML processors.
Have you tried using a self closing image? Something like this
<div …>
<svg xmlns="http://www.w3.org/2000/svg"
width="100%" height="100%" viewBox="0 0 1000 1594">
<image xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"
xlink:href="images/000-0-0000-0000-0_front.jpg"
width="1000" height="1594"/>
</svg>
</div>
I've also seen the spec use examples without closing tag for image altogether
That’s exactly the point. EPUB 3 content documents are specified as HTML5 in XHTML syntax. SVG must be XML when inline in XHTML. Contrary to XHTML where there are distinctions between <div></div>
, <meta/>
, or <img/>
, it does not matter for SVG whether you serialize the image element as <image/>
, <image></image>
, or even <image> </image>
.
However, an image element that is not closed or self-closing is not permitted, because of the X in XHTML.
The best solution is below. We always use this code for iBooks. Works fine.
<div>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="100%" height="100%" viewBox="0 0 916 1197" preserveAspectRatio="none">
<image width="916" height="1197" xlink:href="image/cover.jpg"/>
</svg>
</div>
Also OPF file manifest properties must be svg:
<item id="coverPage" href="cover.xhtml" media-type="application/xhtml+xml" properties="svg"/>