Image Not Visible - Using SVG

[RbnJrg]

Originally Posted by Jellby

That's no (general) solution, I'm afraid.

Hi Jellby;

My solution was for the old .mobi format, but...

The problem is not whether the image is taller or wider, which you can know in advance, but whether it is taller or wider than the screen, which you cannot know in advance.

...unless one ereader device has a square screen, then my solution would be valid, no matter the screen size; I can't think in anything that invalidates that. But don't take my answer as if I don't want svg wrappers. You can find lots of posts about svg written by me where I encourage its use (in fact, I use svg a lot).

Regards
Rubén

[Jellby]

I don't want to be argumentative, but imagine a 400x350 image, and an 800x600 screen.

How would "height:100%" make it fit the screen? It would be shown at double size, and that'd make it 800x700 (matching the screen's height, 800, assuming that's portable in ePub) and it would be 100 pixels too wide. It's only if the device tries to be smart (and in doing so ignores the CSS) that it may fit

[RbnJrg]

Originally Posted by Jellby

I don't want to be argumentative, but imagine a 400x350 image, and an 800x600 screen.

How would "height:100%" make it fit the screen? It would be shown at double size, and that'd make it 800x700 (matching the screen's height, 800, assuming that's portable in ePub) and it would be 100 pixels too wide. It's only if the device tries to be smart (and in doing so ignores the CSS) that it may fit

Hi Jellby;

Of course, in that case, the image won't fit the screen, because it can't if it must retain proportions. But even with a svg wrapper, that kind of images (400x350) also won't fit the screen (assuming a 800x600 size). However, in both cases (with or without a svg wrapper) the image will be fully showed and without distortion (in both, portrait and landscape mode). The image will have a showed size of 685.71x300 in portrait mode and a showed size of 400x350 in landscape mode. Do the try with the Obama image I attach:



It has a size of 400x350 and this is how it looks in Kindle Previewer:



Below you can check the respective .mobi

Regards

EDIT: When we use percentage to establish the height of an element, that element take the height of its container element. But if the height of this last element is not established, then the height is ignored and replaced by the value "auto". As we don't establish a height for the block element that contains the image, then the image takes the values height="auto" and width="auto" and for that reason the ereader device doesn't ignore the css rules; instead it's obeying rules. But one different thing is when we establish the width of an object in percentage; that case if different from the "height case" and the ereader must respect the width we establish.

I apologize for my english. It's not good and very probably what I wrote above has many grammar errors.

[exaltedwombat]

I've just made up an epub file in Sigil using SVG around the cover image. The latest version of Kindle Previewer happily spits out a mobi file, which displays perfectly well on an (actual) early-model Kindle. So the problem seems to have gone away. Might as well use SVG.

[RbnJrg]

Originally Posted by exaltedwombat

I've just made up an epub file in Sigil using SVG around the cover image. The latest version of Kindle Previewer happily spits out a mobi file, which displays perfectly well on an (actual) early-model Kindle. So the problem seems to have gone away. Might as well use SVG.

Take in count that Kindle doesn't use the svg cover you have in Sigil. That is a .xhtml cover and Kindle doesn't use it. Instead, it utilizes the image you have in the Sigil's "Images" folder. To be short, doesn't matter if you use or not a svg wrapper for your cover image regarding Kindle and .kf8/.mobi. Read this thread:

https://www.mobileread.com/forums/sho...d.php?t=215088

and specially this post (of the same thread) by Hitch (maybe the bigger expert regarding Kindle in this forum):

https://www.mobileread.com/forums/sho...0&postcount=17

[exaltedwombat]

Is it my imagination, or did the mobi conversion previously object to the presence of SVG? Conversion runs smoothly now, and the result seems as good as would be got by any other means. So why did I used to make a version without SVG for the Kindle conversion? Perhaps I'm going mad :-)

[BetterRed]

Originally Posted by exaltedwombat

Perhaps I'm going mad :-)

You'd be in exalted company then - Henry VI, George III, Nero, van Gogh, Dostoevsky... and me of course

BR

[RbnJrg]

Originally Posted by exaltedwombat

Is it my imagination, or did the mobi conversion previously object to the presence of SVG? Conversion runs smoothly now, and the result seems as good as would be got by any other means. So why did I used to make a version without SVG for the Kindle conversion? Perhaps I'm going mad :-)

As I told you before, doesn't matter if you use or not svg for a cover; anyway Kindle won't use it (AS COVER). Another thing is to use svg INSIDE the ebook. In this last case, the modern Kindle format (.kf8) will use svg but the old Kindle format (.mobi) won't. So, if you want that your ebook will be compatible with the .mobi (the old .mobi, for Kindle 1, Kindle 2 and Kindle DX) format, then you'll have to write a fallback in case you employ svg (and .svg is more, much more than a wrapper ).

[Hitch]

Originally Posted by RbnJrg

As I told you before, doesn't matter if you use or not svg for a cover; anyway Kindle won't use it (AS COVER). Another thing is to use svg INSIDE the ebook. In this last case, the modern Kindle format (.kf8) will use svg but the old Kindle format (.mobi) won't. So, if you want that your ebook will be compatible with the .mobi (the old .mobi, for Kindle 1, Kindle 2 and Kindle DX) format, then you'll have to write a fallback in case you employ svg (and .svg is more, much more than a wrapper ).

The problem is, really:

How does it get there from here? If we are discussing COVER images, then you have a whole other issue, which is the supplanting of the (designed by the perfectly competent book designer) cover PAGE and image with the cover image that is uploaded by the user at the KDP. That's where the mascara hits the fan, because the "coverpage.html" page (for a quick description) goes bye-bye. Thus, where goeth all that good ol' SVG coding, she wondered???? Sadly, it goes to code-heaven, where perfectly good coding goes to die.

If we are discussing images in the book file itself, then, yes, you can use SVG, but as Ruben mentions, you gotta use a fallback, and width=100% absolutely is not it. (And if you really want to see why, open any book with that coding on Kindle for PC or K4Mac on a honking big monitor, and go single-column/page. THAT's a real doozy of an experience. Particularly if you're talking something wee, like a fleuron for chapter ends, or what-have-you.

Let me tell you: image use is something we're discussing rather heavily around here, ever since Apple came out a few months ago with its latest dictates, which forces the images to break (across pages) on ADE and many other devices (yes, I'm talking to you, Kobo!). The refusal of the vendors to adhere to ANY BLOODY REGULARIZED STANDARDS at all is just...headache city. And the whole, "cover-image as SVG" issue is one of them (the headaches).

Hitch