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?