html img tag versus svg wrapped image tag

[hobnail]

1) Why do some books use an html img tag for the cover page while Calibre's cover page generator, Calibre's Generate Cover plugin, and Sigil all use the svg wrapped image tag? (With an img tag Calibre's editor's preview window shows it full size with scroll bars when the image is too big for the window while Sigil's preview window and Calibre's reader resize it to fit the window.)

2) In the body of a book what are the advantages or disadvantages to using an svg wrapped image tag versus an html img tag? Complexity of the svg method is probably one disadvantage with it. I've never seen this done so I'm assuming that the advantages aren't there.

[Turtle91]

SVG wrapped images will be able to fill the screen without distorting the aspect ratio. Great for full page images like cover/title/maps.

Some devices don't like svg in anything except the cover. Also, if you want an embedded image that doesn't take up the whole page, I would just style a div as a container.

There are several discussions of this topic on MR if you do a quick search.

[Hitch]

Originally Posted by Turtle91

SVG wrapped images will be able to fill the screen without distorting the aspect ratio. Great for full page images like cover/title/maps.

Some devices don't like svg in anything except the cover. Also, if you want an embedded image that doesn't take up the whole page, I would just style a div as a container.

There are several discussions of this topic on MR if you do a quick search.

And if you're making a file that will find its way to Amazon/Kindle, you cannot assume that the device upon which your book will end up can handle SVG at ALL.

Hitch

[Tex2002ans]

Originally Posted by hobnail

1) Why do some books use an html img tag for the cover page while Calibre's cover page generator, Calibre's Generate Cover plugin, and Sigil all use the svg wrapped image tag?

See my 2018 post in "SVG images - why?".

Also read the rest of the discussion in that thread.

Originally Posted by hobnail

2) In the body of a book what are the advantages or disadvantages to using an svg wrapped image tag versus an html img tag? Complexity of the svg method is probably one disadvantage with it.

If you're making it for Amazon... don't use the SVG-wrapped images inside the book. (SVG-wrapped cover is fine, because that's treated specially.)

If you're creating a pure EPUB, or designing the EPUB for personal use, then you may want to use the SVG wrapper.

Originally Posted by hobnail

I've never seen this done so I'm assuming that the advantages aren't there.

It's done occassionally. There's even a whole Sigil plugin dedicated towards it:

InsertImageSVG

You rarely see it because people are usually designing books for max compatibility across devices (plus conversion to Kindle).

SVG Wrappers also have some other advantages such as "keeping image and caption together", like RbnJrg has written about many times over the years (especially his Post #5):

https://www.mobileread.com/forums/sh...d.php?t=314639

[JSWolf]

Originally Posted by Turtle91

SVG wrapped images will be able to fill the screen without distorting the aspect ratio. Great for full page images like cover/title/maps.

Sorry, but that is incorrect. SVG wrapped images can have the wrong aspect ration very easily.

The default of Calibre is to make the cover full screen even if that is not aspect ratio correct. You have to change the option to make it the correct aspect ratio.

[DNSB]

Originally Posted by JSWolf

Sorry, but that is incorrect. SVG wrapped images can have the wrong aspect ration very easily.

The default of Calibre is to make the cover full screen even if that is not aspect ratio correct. You have to change the option to make it the correct aspect ratio.

As long as the image size is specified correctly and the code included 'preserveAspectRatio="xMidYMid meet"', I've never seen an SVG wrapped image use an incorrect aspect ratio. Fail to fill the screen yes since the image aspect ratio may not be the same as the screen aspect ratio.

[JSWolf]

Originally Posted by DNSB

As long as the image size is specified correctly and the code included 'preserveAspectRatio="xMidYMid meet"', I've never seen an SVG wrapped image use an incorrect aspect ratio. Fail to fill the screen yes since the image aspect ratio may not be the same as the screen aspect ratio.

You don't actually need preserveAspectRatio="xMidYMid meet" as that is the default.

Covers don't fill the screen (in most cases) because of the aspect of pBooks vs. the aspect of Readers, Also, given that pBooks aspect has gotten taller, the cover will fill even less of the screen.

[DNSB]

Originally Posted by JSWolf

You don't actually need preserveAspectRatio="xMidYMid meet" as that is the default.

Covers don't fill the screen (in most cases) because of the aspect of pBooks vs. the aspect of Readers, Also, given that pBooks aspect has gotten taller, the cover will fill even less of the screen.

Yes, Jon, I know it's the default. I also know that I've seen too many ebooks where it's been set to "none" or other equally useless for my purposes value. Hence when I start editing an ebook, I run a saved search to set it to "xMidYMid" just to save me from having to re-edit. It is a waste of bytes but I think I still have enough gigabytes of storage that wasting 4 or 5 compressed bytes doesn't concern me.

As for your second point, considering the number of ebooks that do not have a pbook variant but still use a 16:9 or higher aspect ratio for the cover image, I'm not sure if the pbook aspect ratio has much if anything to do with the odd choices used by whomever created the cover image. I tend to suspect that they wanted the cover image to fill a 16:9 or 16:10 phone/tablet display. As the 18-19.5:9 phone displays get more common, I suspect we will find more covers sized to fit those displays.

And here we are with our humble eInk ereaders with a 4:3 (though I've seen one referred to as having a 12:9) aspect ratio.

[JSWolf]

Originally Posted by DNSB

Yes, Jon, I know it's the default. I also know that I've seen too many ebooks where it's been set to "none" or other equally useless for my purposes value. Hence when I start editing an ebook, I run a saved search to set it to "xMidYMid" just to save me from having to re-edit. It is a waste of bytes but I think I still have enough gigabytes of storage that wasting 4 or 5 compressed bytes doesn't concern me.

As for your second point, considering the number of ebooks that do not have a pbook variant but still use a 16:9 or higher aspect ratio for the cover image, I'm not sure if the pbook aspect ratio has much if anything to do with the odd choices used by whomever created the cover image. I tend to suspect that they wanted the cover image to fill a 16:9 or 16:10 phone/tablet display. As the 18-19.5:9 phone displays get more common, I suspect we will find more covers sized to fit those displays.

And here we are with our humble eInk ereaders with a 4:3 (though I've seen one referred to as having a 12:9) aspect ratio.

The reason I mentioned not needing preserveAspectRatio="xMidYMid meet" is that if you are editing an SVG wrapper and cannot remember the correct form, you can just remove it.