Variable/fixed image height

[ElMiko]

Originally Posted by JSWolf

Not a good idea to allow it to look bad in RMSDK. It needs to look good enough in RMSDK. You can't ignore the fact that current devices use an older RMSDK and it will be used to read eBooks.

This commentary, I'm afraid, is entirely without content.

"Good enough" for what? "Good enough" for whom? You?

I think that referring back to the beginning of the thread is instructive here.

The problem I described was I want to the dimensions of an image to be defined be a specified height and proportional width UNLESS the window size made it impossible for those height-based dimension to fit on the screen without affecting the aspect ratio, in which case the image would be resized to maintain the correct aspect ratio.

Your response was:

To solve the problem, make the image the height you want. Then the only issue will be if it has to reduced in width. You have two options. It can be reduced so the aspect ratio is correct or reduced so the aspect ratio is not correct.

So, your solution was to restate what I was trying to accomplish without providing an actionable pathway to acheiving it. Actually, I'm being overly charitable in that summary, because part of your non-solution was to say that one of my options is to "[reduce] the image so the aspect ratio is not correct" which is explicitly the option that is OFF the table in describing the desired effect... namely maintaing the aspect ratio in all circumstances while having the image be height-defined in any window that will accomodate it without skew. Truly remarkable.

Now, I'm ALL ears if you have a way acheive what you said should be acheivable in your earlier post.

Based on RbnJrg extensive and patient explanations, I am under the impression that there is no way to get ADE to have a fixed height ("make the image the height you want") but rescale (that is, override the fixed height) to fit the screen if it has to be reduced in width ("reduced so the aspect ratio is correct"). If I am wrong, no one would be happier to discover it than I.

Again, limited by my amateur understanding, it appears that RbnJrg's max-height-based solution works perfectly in non-ADE environments. And, in an ADE environment, it will simple produce an image that is alway filling 100% of the width of the viewing window, but at least is not skewing the aspect ratio, provided that it is (like the image in the original example) naturally wider than it is tall.

So, JSWolf, if you have an actionable code that—in ADE and all other ereading environments—will always accomplish a fixed height that will rescale if the screen is too small (which, as per the above response, you said is a live option), please share it.

[JSWolf]

Originally Posted by Turtle91

You still don't get it Jon. It looks good on everything else, it looks OK (but not great) on your older ADE devices. Sounds like a perfect trade off!

If you don't like the way it looks, then update the firmware/software/device model to something newer!!

You can't update RMSDK on a Kobo. People who view it on a Kobo with RMSDK could complain because it doesn't look correct. Then it will have to be fixed when enough people complain.

So how do you update software that you have no control over when the device is brand new or the firmware is brand new? You don't. You hope whoever designed the eBook knows what he/she is doing. And having to code so it works on an older RMSDK is something eBook designers have to deal with.

[ElMiko]

Originally Posted by JSWolf

You can't update RMSDK on a Kobo. People who view it on a Kobo with RMSDK could complain because it doesn't look correct. Then it will have to be fixed when enough people complain.

So how do you update software that you have no control over when the device is brand new or the firmware is brand new? You don't. You hope whoever designed the eBook knows what he/she is doing. And having to code so it works on an older RMSDK is something eBook designers have to deal with.

If you buy a pressure cooker which, due to a design flaw doesn't actually fully seal, resulting in a slightly lower cooking temperature despite it's nominally being "at pressure", is it reasonable to expect that all recipe writers should incorporate these kinds of idiosyncracies into cooktime guidelines?

Or is it more reasonable to expect the consumer to either a) complain to the manufacturer, or b) buy a new pressure cooker?

But beyond this little thought experiment, I think the more illuminating feature of this back and forth is that all of your contributions have been to say that everyone is doing it wrong; there hasn't been a single line of CSS that you have put forward as an alternative that would satisfy your criticisms while also addressing the topic at hand....

Of course, you don't owe anybody any solutions, particularly if you are a paid ebook creator who has a proprietary interest in maintaining a competitive edge. I couldn't really hold that against you. But then responding to help queries just to say that everyone's code is wrong without offering your own as an alternative seems like a bizarre way to participate in a help forum/thread. It makes more sense to just let everyone keep pumping out comparatively bad ebooks, while you reap the professional rewards for being the only that does it right... right?

[DNSB]

Originally Posted by JSWolf

Not a good idea to allow it to look bad in RMSDK. It needs to look good enough in RMSDK. You can't ignore the fact that current devices use an older RMSDK and it will be used to read eBooks.

Do you also whinge that all web pages do not render properly on Netscape Navigator 1.0?

[ElMiko]

Reluctantly reviving this thread to raise a weird behavior related to code discussed here. Namely:

.autoIMG {
	text-indent: 0;
	text-align: center;
	max-height: 32em;
	width: auto;
	margin: 0;
	}
.autoIMGimage {
	max-width: 100%;
	max-height: 32em;
	margin: 0 auto;
	display: block;
	}

This works as previously described and intended when viewed in the Sigil Preview and PageEdit (see ImageScale-PE attached). And I know it works in KOReader when viewed on a device.

BUT...

When viewed in the ReadiumReader plugin, the max-height limit is never recognized (see ImageScale-RP attached)! Does anyone know if this is a plugin error? Maybe I imagine it, but I was under the impression that the Readium plugin was an appropriate proxy for KOReader.

[RbnJrg]

You shouldn't define a height in terms of "em". What if the ereader's screen height is lower than -for example- 32em? Define the height in terms of "%" of the parent block, or better yet, in terms of "vh". According to the size of your image, a good value would be "max-height: 90vh".

Originally Posted by ElMiko

Reluctantly reviving this thread to raise a weird behavior related to code discussed here. Namely:

.autoIMG {
	text-indent: 0;
	text-align: center;
	max-height: 32em;
	width: auto;
	margin: 0;
	}
.autoIMGimage {
	max-width: 100%;
	max-height: 32em;
	margin: 0 auto;
	display: block;
	}

This works as previously described and intended when viewed in the Sigil Preview and PageEdit (see ImageScale-PE attached). And I know it works in KOReader when viewed on a device.

BUT...

When viewed in the ReadiumReader plugin, the max-height limit is never recognized (see ImageScale-RP attached)! Does anyone know if this is a plugin error? Maybe I imagine it, but I was under the impression that the Readium plugin was an appropriate proxy for KOReader.

[ElMiko]

Originally Posted by RbnJrg

You shouldn't define a height in terms of "em". What if the ereader's screen height is lower than -for example- 32em? Define the height in terms of "%" of the parent block, or better yet, in terms of "vh". According to the size of your image, a good value would be "max-height: 90vh".

Hmmm. I mean, this was your code originally... Does the VH work in epub2? Also I really don't want the image to scale infinitely with screen size, hence the em limit.

But also do you know why the max height isn't being honored in the Readium plug-in?

[JSWolf]

Originally Posted by RbnJrg

You shouldn't define a height in terms of "em". What if the ereader's screen height is lower than -for example- 32em? Define the height in terms of "%" of the parent block, or better yet, in terms of "vh". According to the size of your image, a good value would be "max-height: 90vh".

Don't use vh. There is a lot of software out there that won't handle vh. It's best to use %. Also, vh is not ePub2 compatible.

[RbnJrg]

Originally Posted by ElMiko

Hmmm. I mean, this was your code originally... Does the VH work in epub2?

You want a solution for epub2? you should start by saying that because the code you posted is not supported by ADE 2.x/3.x; your code is for epub3 (max-height and max-width are properties don't honored by ADE).

Also I really don't want the image to scale infinitely with screen size, hence the em limit.

No risk of that, because you are not using "height: 90vh" but "max-height: 90vh". So if your image is tiny, then the image will be rendered by using the height acording to "width: auto" to maintain the proportion.

But also do you know why the max height isn't being honored in the Readium plug-in?

In my system, Readium (Sigil's plugin) displays correctly the image and the text below.

[DNSB]

Originally Posted by ElMiko

This works as previously described and intended when viewed in the Sigil Preview and PageEdit (see ImageScale-PE attached). And I know it works in KOReader when viewed on a device.

BUT...

When viewed in the ReadiumReader plugin, the max-height limit is never recognized (see ImageScale-RP attached)! Does anyone know if this is a plugin error? Maybe I imagine it, but I was under the impression that the Readium plugin was an appropriate proxy for KOReader.

For what it may be worth, Sigil's Readium plugin is appropriate for Readium based renderers such as Thorium, Kobo's kepub renderer, etc. It is not even close to KOReader's CREngine based ePub renderer (based on the Cool Reader renderer).

[JSWolf]

Originally Posted by DNSB

For what it may be worth, Sigil's Readium plugin is appropriate for Readium based renderers such as Thorium, Kobo's kepub renderer, etc. It is not even close to KOReader's CREngine based ePub renderer (based on the Cool Reader renderer).

It's also not appropriate for older versions of ADE/RMSDK.

[ElMiko]

Originally Posted by DNSB

For what it may be worth, Sigil's Readium plugin is appropriate for Readium based renderers such as Thorium, Kobo's kepub renderer, etc. It is not even close to KOReader's CREngine based ePub renderer (based on the Cool Reader renderer).

Yeah, I was afraid I might have imagined that...

Do you know which of the three plugins (Bibi, EpubJS, and Readium) are the closest to KOreader?

[RbnJrg]

Originally Posted by ElMiko

Do you know which of the three plugins (Bibi, EpubJS, and Readium) are the closest to KOreader?

None. All of them are epub3 ereaders and KOReader is an epub2 one that supports some css3 properties. But if you employ only css 2.1, the three plugins will display something similar to KOReader (that is a good epub2 ereader, better than ADE).

[ElMiko]

Originally Posted by RbnJrg

In my system, Readium (Sigil's plugin) displays correctly the image and the text below.

Did your Readium plugin work with the file I attached, or did you create a new test case from scratch using the code? Because if the former, then that's really weird. If the latter, I'd love to see if there were any differences in the rest of the code that would account for it.

[RbnJrg]

Originally Posted by ElMiko

Did your Readium plugin work with the file I attached, or did you create a new test case from scratch using the code? Because if the former, then that's really weird. If the latter, I'd love to see if there were any differences in the rest of the code that would account for it.

The Readium Sigil plugin displays nice in my system the epub you posted here. But maybe your issue is because the height of your Readium's window is lower than 32em (the height you are using for the image).