dvschultz / 99problems

99 Problems and e-reader rendering are all of them
60 stars 3 forks source link

iBooks is selective about where xmlns:xlink should go in embedded SVG #46

Open gimsieke opened 9 years ago

gimsieke commented 9 years ago

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.

caraya commented 9 years ago

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

gimsieke commented 9 years ago

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.

teytag commented 7 years ago

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"/>