HELP: svg file in Sigil for epub on Kobo

[philm]

I'm new to Sigil and would like to add vector graphics to epub (2 or 3).
I make SVG with inkscape.
It works fine in Sigil preview (except for font), but Kobo displays only a part of it.
I read various threads here and this code seems OK in the xhtml, but not the displayed SVG format:

<svg xmlns="http://www.w3.org/2000/svg" preserveAspectRatio="xMidYMin" version="1.1" viewBox="0 0 203 297" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
      <image height="297" width="203" xlink:href="../Images/drawing.svg"/>
    </svg>

Any idea?

Here's the result on Kobo Clara:


And here's the epub3:

[KevinH]

What happens if in the xhtml you replace that svg code with just an img tag with href pointing to your drawing.svg?

Also by default, Inkscape saves svg in its own format. Try re-saving the drawing in inkscape as standard svg 1.1 eliminating the width and height in the resulting svg file so it will scale to its parent tag properly.

[DNSB]

One other item is if you send the file to your Kobo as a kepub, it will work happily.

[philm]

Thank you vey much KevinH and DNSB for your attention,

I forgot to say I tried various svg format with inkscape before writing this post. Actually rhe svg in the epub is plain 1.0 svg format. I think this actual svg format is correct because we can see the svg content.
I also tried various XHTML tags, starting with <img/> in the past.

I also tried changing .epub to .kepub.epub (.kepub alone is not seen by kobo) before posting.

BUT, you were also both right
Actually, having "ebook3.epub" AND a copy renamed "ebook3.kepub.epub" on the same device, Kobo didn't see the second as a "KOBO epub" but as a simple epub despite its name. Deleting the first one "forced" the device to see it as a KOBO epub.
Secondly, my svg was 293px width. I didn't care since it's vector graphics and should scale fine whatever the original size.

Except that scale doesn't seem to work at all.
I made a copy of this SVG, this time scaled it up to 12000x10000px (same file size of course) and only kept minimum working tags in XHTML:

<img alt="basicdrawing" width="100%" src="../Images/basicdrawing.svg"/>
<img alt="basicdrawing" src="../Images/basicdrawing.svg"/>

And now both are displayed identically, width 100% on Kobo, while Sigil preview has the second one at the right size, only displaying the upper left corner of it.

Of course, with these tags, I tried switching the filename to the previous one, and it didn't work, displaying small images. Width=100% is simply not working on Kobo.

I guess I'd need to know the minimum acceptable width by Kobo to make svg illustrations working in Sigil preview and Kobo.

Thank you for pushing me into re-trying all those parameters

Cheers from France

[JSWolf]

@philm, try adding the following CSS code to your eBook and see how the SVG works.

img {
  max-height: 100%;
  max-width: 100%;
}

[jhowell]

I don’t know much about Kobo, but I know that an attribute of width="100%" is not correct HTML.

[Turtle91]

Originally Posted by jhowell

I don’t know much about Kobo, but I know that an attribute of width="100%" is not correct HTML.

nvm....I thought you were referring to Wolfies post...I just saw it was for philm's.


Not sure why you would consider that incorrect? (definition) It is simply saying the maximum width of the image is 100% of the parent container. If you don't specify a height, it will automatically adjust height to keep the proper aspect ratio.

I regularly set a specific width and a max-width on my images and haven't had any issues with it.

width:50%;
max-width:1000px
max-height:100%

[enuddleyarbl]

Originally Posted by jhowell

I don’t know much about Kobo, but I know that an attribute of width="100%" is not correct HTML.

Oh oh. I haven't researched it properly yet. But, I just blindly grabbed some stuff out of a book I was editing that uses that:

.imgfull {
/* Class for getting an image to take up most of screen */
	height:	90%;
	background-position:	center;
	background-repeat:	no-repeat;
	background-size:	cover;
	max-height:	100%;
	max-width:	100%;
}

Could you point me to somewhere talking about why width="100%" is badness? There's a lot of stuff in that css I grabbed that I haven't researched yet.

[Turtle91]

It is preferred to have that in the CSS rather than the HTML. Ideally you would have ALL styling in your CSS and only structural elements in your html.

in the HTML tag:
<img alt="basicdrawing" width="100%" src="../Images/basicdrawing.svg"/>

in CSS:
img {width: 10%; max-width: 1000px;}

I think at one point 'they' were trying to deprecate it in the html tag (???), but as far as I know it is still allowed...just a little gauche.

[Tex2002ans]

Originally Posted by enuddleyarbl

<svg xmlns="http://www.w3.org/2000/svg" preserveAspectRatio="xMidYMin"[...]

Try:

preserveAspectRatio="xMidYMid meet"

See if that fixes your Kobo rendering issue.

Originally Posted by enuddleyarbl

Oh oh. I haven't researched it properly yet. But, I just blindly grabbed some stuff out of a book I was editing [...]

Could you point me to somewhere talking about why width="100%" is badness? There's a lot of stuff in that css I grabbed that I haven't researched yet.

Are you trying to create a cover?

Or are you trying to do a "full-page image"... like a giant chart/graph?

If a cover:

Back in 2018, I showed why HTML "width=100%" and/or "height=100%" distorts especially when you turn your device landscape:

• 2018: "SVG images - why?"

If you're trying to get a "full-paged image", it depends on the case and what you're trying to accomplish.

See a lot of my discussion of what to look out for in:

• 2017: "Universal Solution for Centering Text Under Image"

- - - -

If you want more info on SVGs specifically...

RbnJrg has written a lot about SVGs + SVG Wrappers:

• 2020: "html img tag versus svg wrapped image tag"

or you can type this in your favorite search engine to find even more topics/examples:

SVG RbnJrg site:mobileread.com
SVG Tex2002ans site:mobileread.com

But let it be known: Amazon devices don't like SVG.

So if you're going the SVG route, this solution would be an EPUB-only thing.

Originally Posted by philm

Actually, having "ebook3.epub" AND a copy renamed "ebook3.kepub.epub" on the same device, Kobo didn't see the second as a "KOBO epub" but as a simple epub despite its name. Deleting the first one "forced" the device to see it as a KOBO epub.

Thanks for that info. I had a similarly odd thing back on my original Nook. When 2 books had the same UUID/metadata, the Nook wouldn't recognize the "new" file.

So sometimes I would have to:

• Delete both files.
• Reset device.
• Plug back in device.
• Transfer file/s back.

That would usually get the version I wanted working again.

[DNSB]

Originally Posted by philm

BUT, you were also both right
Actually, having "ebook3.epub" AND a copy renamed "ebook3.kepub.epub" on the same device, Kobo didn't see the second as a "KOBO epub" but as a simple epub despite its name. Deleting the first one "forced" the device to see it as a KOBO epub.

Out of curiosity what firmware version are you using? I copied the epub you generated and renamed it to .kepub.epub. I then copied both of them to my Sage at the same time and they showed up correctly. See attached images for the results.

[Turtle91]

Originally Posted by Tex2002ans

...
But let it be known: Amazon devices don't like SVG.
...

I know that was true at one time, but according to the current Image Guidelines they encourage SVG use:

Image Guidelines
For a rich reading experience, provide the best available version of the images in your Kindle eBooks, using these guidelines:

• Images that are pictorial in nature (e.g., Photographs, historical images) should not be blurry, smudged, or unclear to the point that it distracts the reader from the narrative. We recommend these type of images occupy at least 60% width of the screen for high quality reading on smaller devices.
• Images with text containing letters, numbers, or symbols should be legible and readable (e.g., Graphs, technical diagrams or Maps). We recommend these type of images occupy at least 80% width of the screen for high quality reading on smaller devices.
• Computer-generated visuals are best represented as Scalable Vector Graphics (SVG) however, SVG tags can lead to errors. We recommend removing SVG tags and using the image tag in HTML for images.
• Do not render text as images. If text can be separated from the surrounding art, it shouldn't be an image. Instead, it should be HTML.
• Figure caption, table, and title image should be in HTML. You can find details on tables in the reflowable table’s section Table Guidelines - Reflowable.
• For accessibility, all images must have text in the alt attribute in the HTML tag. For decorative images, set alt = “” or role = “presentation” in the image tag so that it can be ignored by assistive technology.
• For the best user experience across Kindle devices and applications, use color images whenever possible and relevant.

I didn't see an example of "removing SVG tags" but I would assume that means <img alt="" src="someimage.svg"/> rather than putting the svg code directly on the html sheet...

Have you seen kindles still having problems in recent testing???

edit: I did some more looking at the only restriction I found was that they require you to remove any SVG namespace references.

[jhowell]

Originally Posted by Turtle91

It is preferred to have that in the CSS rather than the HTML. Ideally you would have ALL styling in your CSS and only structural elements in your html.

in the HTML tag:
<img alt="basicdrawing" width="100%" src="../Images/basicdrawing.svg"/>

in CSS:
img {width: 10%; max-width: 1000px;}

I think at one point 'they' were trying to deprecate it in the html tag (???), but as far as I know it is still allowed...just a little gauche.

My understanding is that the "width" and "height" attributes for an "img" element in HTML 5 only allow an integer value without a unit.

[JSWolf]

Originally Posted by jhowell

My understanding is that the "width" and "height" attributes for an "img" element in HTML 5 only allow an integer value without a unit.

Using height and width with % and images works with ePub 2.

[Quoth]

Originally Posted by jhowell

My understanding is that the "width" and "height" attributes for an "img" element in HTML 5 only allow an integer value without a unit.

I'd only have width" and "height" attributes for an "img" in CSS, never in the actual HTML. That is "automatic" when converting docx to epub2 in Calibre. All the regular types of unit work. Also auto on height OR width if the other value is set. Obviously the result rendering CSS with say 80% width and auto height may only make sense in portrait and actual size may depend on the scope of anything enclosing the HTML where the CSS is used. Curiously px isn't always exactly pixels. Some units never make sense (like physical size).

This Wikipedia extract is inaccurate:

Some units – cm (centimetre); in (inch); mm (millimetre); pc (pica); and pt (point) – are absolute, which means that the rendered dimension does not depend upon the structure of the page; others – em (em); ex (ex) and px (pixel)[clarification needed] – are relative, which means that factors such as the font size of a parent element can affect the rendered measurement.

Many renderers use 12pt = 1em, though kepub rather than epub on Kobo seems to use a non-standard conversion.
px is not always a physical pixel

I think cm (centimetre), in (inch) and mm (millimetre) should only be used in media Paper/Print. They make no sense on webpages or ebooks on screens.
The pc (pica) is obsolete. Use em or if converting from docx to epub or html use pt (point) if the WP styles don't allow em.

We use pt (and for images only % and px) for docx styles for ebooks and the copy docx for PDF export uses mm for page sizes, margins, padding, images etc.

Never use px or mm etc etc for font sizes, only em or pt.