Problems with SVG

[ninni]

Hello!

I've been using linked svg files in my epubs with the object tag, so that i can include fallback images as well.

Everything looks just fine in ADE, Bookworm and FBReader + sony reader prs505. However now I've tested my epubs on the Onyx Boox device and the SVG pictures seem to be "eating up" a few lines of text above the picture.

I'd really apreciate if someone could help me with this, there doesn't seem to be any proper manuals for SVG:s in EPUB, and I'm going mad testing and testing.

The object tag is in the attachment, since I wasn't able to insert the tags here.

[frabjous]

The problem might be the width="100%" part of the tag, which, if the aspect ratio is being preserved, might stretch the image vertically too, and some renderers might do that upwards.

I recommend putting in the exact width and height, e.g.:

<object data="images/graafi.svg" type="image/svg+xml" style="width: 100pt; height: 100pt;"> <img src="images/graafi.png" alt="graafi.png" /> </object>

Change "100pt" to whatever the height and width are.

You could also put in "maximum-width: 100%;" if you're worried about it overstretching the screen.

I don't know if that will help.

My own personal experience has been that SVG support is still pretty inconsistent across various renderers--and not just in ePubs, but in web browsers and plug-ins, as well. (Plus, I'm still learning.)

[DaleDe]

Exact widths are not a good solution. How do you know what size device the user is using to read the book?

Dale

[frabjous]

Originally Posted by DaleDe

Exact widths are not a good solution. How do you know what size device the user is using to read the book?

Dale

When you set an exact width on an image file, that doesn't mean that the image won't zoom when someone zooms with the device. Indeed, they usually do. It really just sets up the size of the images at "normal settings". Actually, the XML tags inside the SVG itself will have as one of its attributes a nominal exactly height and width. Because it's an SVG, it can be scaled to different sizes, and someone can be encouraged to do this, but it still has a nominal size.

But the issue is really one with SVGs in particular. Support for SVGs is very inconsistent and immature on various reading platforms. For example, Webkit based browsers like Chrome and Safari have a problem with SVGs that don't have an exact height and width specified: it usually makes them take up the wrong among of space, or even puts them inside a little frame with scrollbars on the size even when the image would have fit just fine in context without these. It's just someone I've seen from experience as an issue, so I've always felt it necessary to set the exact size.

But for the moment, I'm mainly advocating it as a first step in diagnosing the problem. If it turned out not to help with ninni's issue, I'd switch back in a heartbeat. I don't really know that much about Onyx's support of SVG.

[ninni]

Thanks for the advice! I'll try using the exact width instead of a percentual width. Previously I put a pagebreak before the SVG, so that it wouldn't strech over the text, but I don't think it's a very good idea, for instance if I wanted to have a logo in SVG format on the title page. Then the logo should always be the first element on the page, or the whole title page should be an SVG file... It's very annoying though that there seems to be so little support for SVG, since I think it would be ideal for a lot of elements in ebooks.

[georg3200]

I have also massive problems with svg-files. My svg-files do not show at all in the epub, though they show without problems in firefox. In the Epub I see only the fallback-jpgs. I used ninnis code from the objecttag.txt.
I have no problems of embedding svgs to a html-file, but I need wo use around 50 svgs in one html-file. So the 300k maximum filesize would be a problem. Splitting the files is not an option.
All the svg-files will be big tables, so screenshots are not an option too. They would be unreable.

The svg-files where created with Adobe Illustrator CS4.
Might the way I save the SVG be a problem. I have left the preferences when saving SVG in AI CS4.

Does someone has an idea?

[frabjous]

I don't know about Adobe Illustrator, but I know that in Inkscape, it's best to save the SVG as "Plain SVG" rather than "Inkscape SVG" if I want the file to work (well) with other applications.

But what program are you using to check to see if the SVGs are showing in the ePubs? Adobe Digital Editions? Have you checked the (x)html files that call the SVGs inside the ePub in Firefox or just the SVGs? Have you tried any other browsers?

[georg3200]

When I save the file as an SVG there are a lot of prefs like SVG 1.0 or SVG 1.1 or SVG Tiny 1.1 and so on... There is nothing like "Plain SVG"
Of course it might be, that the options when saving are the problem?!?

I open the SVG itself in InternetExplorer7 and it looked good. Then I use ninnis code (see objecttag.txt above) to reference the SVG in my xhtml-file. I opened the the xhtml-file in Firefox and in InternetExplorer 7 and there was the SVG as expected.
I packed everything into my epub and everything was fine except the SVG. All I could see was the dummy-fallback-image. If I do not use a fallback-image, there is only a lot of white space :-(

[georg3200]

problem solved.

it was an error in the opf-file:

I wrote:

<item href="images/img_02000008.svg" id="image_img_02000008_svg" media-type="image/svg"/>

instead of

<item href="images/img_02000008.svg" id="image_img_02000008_svg" media-type="image/svg+xml"/>

so it was just a littlle error in the media-type.

Now the SVG shows in the epub. but it seems that it makes the epub damm' slow

[frabjous]

I'd save it either as SVG 1.0 or SVG 1.1 for maximum compatibility.

But how are you opening it in IE7? As far as I know, IE7 cannot open SVGs without a plugin.

[georg3200]

I'm not sure why I can open SVGs in Internet Explorer 7. There is a plug-in "SVG Document" installed. Maybe that's the trick.

[frabjous]

Yep, that's why. I think Internet Explorer 9 will be able to view them without a plug in (like all other web-browsers do).