View Full Version : XHTML fallback for SVG


Iznogood
09-09-2012, 04:42 PM
Lately I have been messing about with pdurrants solution for full-screen cover images. (http://www.mobileread.com/forums/showpost.php?p=590355&postcount=44) Some readers does not "do" svg, e.g. Stanza and others. So I would like to have a sort of fallback to XHTML where SVG cannot be rendered.

I save the following as cover_front.svg:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?xml-stylesheet href="stylesheet.css" type="text/css"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="100%" height="100%" viewBox="0 0 617 900" preserveAspectRatio="xMidYMid meet">
<image width="617" height="900" xlink:href="cover_front.jpg"/>
<text x="300" y="450" text-anchor="middle" color="white" style="font-size:75px;color:white;">This is a test</text>
</svg>


This file contains most of pdurrants code snippet to make an SVG image. In this case I have just used a plain image with some example text, drawn in a standard viewBox, but it could be a more complex layout. My plan is to use SVG more in my books, not only for covers but for other "stuff" that has a graphical layout, like title pages and so on. But first the fallback must be settled. The main goal using this technique on covers is providing the alt-attribute for text-to-speech.

This svg-file is referenced in cover_front.xhtml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Back Cover</title>
<link href="stylesheet.css" type="text/css" rel="stylesheet"/>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8"/>
</head>
<body>
<div class="svg_outer">
<div class="svg_inner">
<object style="background-color:yellow" data="images/cover_front.svg" type="image/svg+xml">
<img src="images/cover_back.jpg" alt="Some text to describe the contents of the cover"/>
</object>
</div>
</div>
</body>
</html>


This is the relevant stylesheet:

.svg_outer {
display: block;
margin-bottom: 0;
margin-left: 0;
margin-right: 0;
margin-top: 0;
padding-bottom: 0;
padding-left: 0;
padding-right: 0;
padding-top: 0;
text-align: left;

background-color:red;
width:100%;
height:100%;
max-width:100%;
max-height:100%;
}
.svg_inner {
display:block;
text-align:center;
background-color:blue;
}
.svg_inner object{
margin:0 0 0 0;
display:block;
width:100%;
height:100%;
background-color:green;
}


If the <object> tag cannot be rendered, the contents of the tag should be rendered instead. In other words, if the svg file cannot be processed, it will be replaced with an <img> tag.

The problem is that it doesn't work. In ADE (desktop) it doesn't resize to full screen, in iBooks it doesn't show up at all, the only place it works as expected is Calibres ibook reader and Stanza:eek:
I wonder why Stanza suddenly started rendering books as described in the CSS:rolleyes:

Have any of you had experiences with the <object> tag indicating that it will be ignored by iBooks? Or have any of you tips on how to scale the .svg file? The object tag itself fills the entire screen (the style="background-color:yellow" in <object> fills the entire screen. It's the svg file referenced in the data attribute of the object tag that does not scale to full screen). Any tips on what to do?

Toxaris
09-10-2012, 02:02 AM
Something else I noticed. Text-anchor: middle doesn't work in ADE. I remember reading about this on an Adobe forum that this was deliberate and that there is no intention to change that. I can't find the thread anymore of course...

Iznogood
09-10-2012, 02:28 AM
Something else I noticed. Text-anchor: middle doesn't work in ADE. I remember reading about this on an Adobe forum that this was deliberate and that there is no intention to change that. I can't find the thread anymore of course...

No it doesn't, which is unfortunate. Not text-anchor:end either. But it works in the version of ADE that e.g. BlueFire Reader uses.

The implementation of SVG in epub readers is, it seems, immature and unreliable. This is sad, because there are so many places it could have been used. That's why I would like to have a fallback to strict xhtml

Jellby
09-10-2012, 04:20 AM
If a reading system does not support SVG, which is required by the ePub spec, will it support fallbacks? I wouldn't count on it...

Toxaris
09-10-2012, 06:31 AM
Does Bluefire uses ADE? In that case they must have adapted it with regards to the SVG. I suspect they use another engine.

Most readers support SVG to a certain point, only not the more fancy stuff. Also, according to the specs of ePUB2 not the complete set of SVG must be supported. Text-align however should be and I think it is a big mistake from Adobe. If you want to keep the image and the caption together on the same page, this can be used. However, without the align it is impossible to center automatically.

Iznogood
09-10-2012, 06:53 AM
Does Bluefire uses ADE? In that case they must have adapted it with regards to the SVG. I suspect they use another engine.

Most readers support SVG to a certain point, only not the more fancy stuff. Also, according to the specs of ePUB2 not the complete set of SVG must be supported. Text-align however should be and I think it is a big mistake from Adobe. If you want to keep the image and the caption together on the same page, this can be used. However, without the align it is impossible to center automatically.

Bluefire has support for Adobes DRM, and I thought only ADE had that?

I know that the full power of SVG has not yet been unleashed in ebook platforms, but the problem is that SVG is unreliable.

Toxaris
09-10-2012, 08:41 AM
I believe that Adobe DRM is not related to ADE. It is a separate product.

JSWolf
09-10-2012, 10:15 AM
Does Bluefire uses ADE? In that case they must have adapted it with regards to the SVG. I suspect they use another engine.

Bluefire does use a version of ADE.

Jim Lester
09-17-2012, 02:05 AM
Bluefire does use a version of ADE.

Or rather both Bluefire and ADE use RMSDK. ADE 1.7 uses a really old version of RMSDK (9.1 IIRC). Bluefire and ADE 1.8/2.0 user a much later version (9.3.x).

JSWolf
09-17-2012, 10:41 PM
Or rather both Bluefire and ADE use RMSDK. ADE 1.7 uses a really old version of RMSDK (9.1 IIRC). Bluefire and ADE 1.8/2.0 user a much later version (9.3.x).

I think Adobe botched things big time with the RMSDK. They should have made it mandatory for anyone using the RMDSK to keep it updated. Because of this botch, we'll have old versions floating around for a long time and ePub eBooks may have to stay compatible to the old versions because of this.

Micah
10-01-2012, 06:32 PM
I think Adobe botched things big time with the RMSDK. They should have made it mandatory for anyone using the RMDSK to keep it updated. Because of this botch, we'll have old versions floating around for a long time and ePub eBooks may have to stay compatible to the old versions because of this.

We regularly update the version of RMSDK we use in Bluefire Reader, including in the most recent update of Bluefire Reader last week. Adobe did take quite a while to update ADE to the latest version of RMSDK, but they have now done so.

JSWolf
10-04-2012, 03:54 PM
We regularly update the version of RMSDK we use in Bluefire Reader, including in the most recent update of Bluefire Reader last week. Adobe did take quite a while to update ADE to the latest version of RMSDK, but they have now done so.

I have the new Bluefire Reader. Given that the version of ADE is updated, why is it not displaying hyphens? Is it not updated enough?

Micah
10-05-2012, 12:49 AM
I have the new Bluefire Reader. Given that the version of ADE is updated, why is it not displaying hyphens? Is it not updated enough?

We could simply "turn on" hyphens now, but it can actually suck if you don't really dial it in - and that takes real work. So it did not make it into the last release as the number of requests for that were way smaller than other things like export annotations, simple highlighting, better search, more font choices, definition lookup, etc.

JSWolf
10-06-2012, 09:17 AM
We could simply "turn on" hyphens now, but it can actually suck if you don't really dial it in - and that takes real work. So it did not make it into the last release as the number of requests for that were way smaller than other things like export annotations, simple highlighting, better search, more font choices, definition lookup, etc.

How about a second version that supports hyphens? I for one would use it. Oh and another thing Bluefire needs is iPhone 5 support for the bigger screen.

Jellby
10-07-2012, 03:43 AM
Or how about a setting that can be enabled/disabled?

I read somewhere (I think it was in a book about Photoshop) that "popular" feature requests tend to be quite dull, uninteresting, and sometimes useless or already possible. In this case, I believe most users will not demand better typesetting (we can include hyphenation there), but that shouldn't be a reason not to implement it...

JSWolf
10-08-2012, 07:52 PM
Or how about a setting that can be enabled/disabled?

That is a very good idea along with iPhone 5 support for the new screen size.