Image styling css... what do all these properties do?

[RbnJrg]

Originally Posted by Falkor

Is this generally not supported by RMSDK or is this only a problem for old versions that do not support EPUB3?

It's not supported by ADE 2.x/3.x. Also it's not supported by ADE 4.x if your epub is an epub2.

[RbnJrg]

Originally Posted by Falkor

I was really just wondering if vh doesn't actually work in RMSDK…

Having a fallback solution is easy enough to implement.

It’s not as if ePub3s shoulnd't exist because Kobo won’t support that format and keeps using a decade old renderer.

Kobo for Android and iOS have fabulous support for epub3 (one of the best there is) and they honor "vh" (or vw, vmin, vmax).

[DNSB]

Originally Posted by RbnJrg

Kobo for Android and iOS have fabulous support for epub3 (one of the best there is) and they honor "vh" (or vw, vmin, vmax).

If you send your epub to a Kobo ereader as .kepub.epub, those features are supported. Sadly, RMSDK even the old version in Kobo's current firmware handles fonts and justified text better than the Kobo's WebKit/Readium based renderer. You can fix most of the justified text issues by playing with various options but still a PITA. Basically, RMSDK is mostly kept to deal with Adobe ADEPT DRMmed ePub/PDF files.

[Falkor]

Originally Posted by RbnJrg

It's not supported by ADE 2.x/3.x. Also it's not supported by ADE 4.x if your epub is an epub2.

So it's supported in current versions. 4.x has been around for over a decade...

[RbnJrg]

Originally Posted by Falkor

So it's supported in current versions. 4.x has been around for over a decade...

If your epub is epub3, ADE 4.x honors vh, but if is an epub2, then ADE 4.x employs the old rendering engine and vh is not taken.

[JSWolf]

Originally Posted by Falkor

So it's supported in current versions. 4.x has been around for over a decade...

While it is supported in ADE 4.x, it's not supported in the ADE used with a Kobo. So if you want to make sure people with a Kobo can read your eBook, you have to make sure it works in both RMSDK and KePub. Some of the fallbacks that @Turtle91 speaks of don't work in the older RMSDK used on a Kobo. Also, there are people who still use a Sony Reader which has an old RMSDK. Some are so old they don't have hyphenation. And there are other old Readers thatcould be in use that have an old RMSDK.

And then we have dodgy programs for reading ePub on Android and iOS that are not good and could fail world on ePub3 then ePub2 (or fail badly on either).

So the best thing (IMHO) is to install ADE 2.0.1 for use in testing how your ePub3 looks when the program in use doesn't support ePub3.

[RbnJrg]

Originally Posted by DNSB

If you send your epub to a Kobo ereader as .kepub.epub, those features are supported. Sadly, RMSDK even the old version in Kobo's current firmware handles fonts and justified text better than the Kobo's WebKit/Readium based renderer. You can fix most of the justified text issues by playing with various options but still a PITA. Basically, RMSDK is mostly kept to deal with Adobe ADEPT DRMmed ePub/PDF files.

A pity that Kobo doesn't include in its ereader devices the same engine that is present in its android version (except for MathML, practically it suports all epub3 properties). If Kobo would do that, then the epub3 estandar would flourish.

[ElMiko]

Well, we may have reached an impasse.

As you can see from the attached image, your file viewed in my system still produces a squished image....

[theducks]

Your TOC sidebar is huge. Grab the 3 dots and make it more normal (that won't cure what is going wrong as the image normally resizes.

By any chance do you have an Absolute size (not reflowable) specified in there someplace?
Have you tried the InsertSVG plugin?

[DNSB]

Originally Posted by RbnJrg

A pity that Kobo doesn't include in its ereader devices the same engine that is present in its android version (except for MathML, practically it suports all epub3 properties). If Kobo would do that, then the epub3 estandar would flourish.

As far as I can tell, the current WebKit/Readium based renderer is very close to their iOS/Android apps in support of ePub3. Perhaps the next firmware revision will do for Kobo ereaders what Kobo has already done with their Tolino firmware and make the WebKit/Readium based renderer the default for non-Adept DRMmed epubs.

[ElMiko]

Originally Posted by theducks

Your TOC sidebar is huge. Grab the 3 dots and make it more normal (that won't cure what is going wrong as the image normally resizes.

Yep, I understand that. But my concern here is more theoretical; namely WHY is it squishing the image at all, when it does not do so for others? It's particularly puzzling in view of RbnJrg's latest response in which he stated that the squishing behavior isn't even visible on his computer.

By any chance do you have an Absolute size (not reflowable) specified in there someplace?
Have you tried the InsertSVG plugin?

To my knowledge, neither I nor RbnJrg has not made any absolute size declarations in the css. I mean, the epub test files are there to examine in case something has sneaked in without our knowledge...

Regarding the SVG plugin, as above, I realize that this would/may solve the problem of how to display a full screen image consistently. But that's not really my point here. I'm trying to understand WHY the image is being rendered inconsistently under this particular coding, not just between Sigil and Calibre but also (again, based on RbnJrg's most recent response) between Calibre on two different computers....

[RbnJrg]

Originally Posted by ElMiko

Well, we may have reached an impasse.

As you can see from the attached image, your file viewed in my system still produces a squished image....

The problem is your TOC, DNSB told you well. Close it and your image will look fine (with the TOC enabled, my image looks like yours).

[ElMiko]

Guys,

Please look at the first two images again in this post again. Both images have the huge TOC sidebar, but only one of them squishes the image. If I close the sidebar and then compress the window, we get the same issue (see new attachment). (incidentally, that post #40 should also demonstrate that I already know that the Bosch image can be unsquished by widening the window. As should several of the preceding posts which describe that behavior.)

The issue I have been asking about is WHY does narrowing the window squish one image and not the other despite having the same code. To say that the solution is not to narrow the window or to eliminate/narrow the TOC window is to solve a different question than the one I'm asking.

The question is not "Why is the image squished?" (answer: because the window has been narrowed)

The question is: "Why does narrowing the window squish one image, but not the other?"

[RbnJrg]

Originally Posted by DNSB

As far as I can tell, the current WebKit/Readium based renderer is very close to their iOS/Android apps in support of ePub3.

Really? Please, open the sample I attach (an epub3) in Kobo for Android and see what it looks like; then open the same file on one of your Kobo devices and tell me if you find any differences in what you see. It would be a really nice surprise if your Kobo device didn't add any extra blank space because of the pictures, and also avoided page breaks where they weren't needed.

[RbnJrg]

Originally Posted by ElMiko

Guys,

Please look at the first two images again in this post again. Both images have the huge TOC sidebar, but only one of them squishes the image. If I close the sidebar and then compress the window, we get the same issue (see new attachment).

The issue I have been asking about is WHY does narrowing the window squish one image and not the other despite having the same code. To say that the solution is not to narrow the window or to eliminate/narrow the TOC window is to solve a different question than the one I'm asking.

In Calibre Viewer, within the Preferences, under page structure, you may have the option to maintain cover aspect ratio enabled. And under Miscellaneous, you may have enabled the option to remember the window position and size (while I don't).