Variable/fixed image height

[ElMiko]

In the Kindle OS, images with a fixed height (and no specified width) that would exceed the screen width are resized proportionally to fit the screen width. In other words the fixed height is functionally overwritten to fit the image proportionally to the screen if honoring it (proportionally) would result in the image's exceeding the screen width. Otherwise, the fixed height value is honored as long as the implied image width is less than the width of the screen.

How would someone code this kind of conditional behavior in css for epub2 to acheive similar outcomes on non-Kindle, epub-based readers?

[Turtle91]

Try an svg wrapper.

[ElMiko]

Okay, so lets say i want the attached image to have a height of 4em (unless this would results in a concomitant width that exceeded the device's screen width)...

how would this work with an svg wrapper, bearing in mind this is not a standalone image, but one that occurs with normal text above and below it?

[Jellby]

What's wrong with "max-height: 4em; max-width: 100%"? Is the natural height of the image less than 4em?

[ElMiko]

As I understand it, "em" isn't a absolute unit, it's a relative unit. So, I mean, I guess it's as natural as any other em value.

Regarding max-width, the issue is that setting it at 100% means that the image will appear to stretch vertically if the screen width is too narrow relative to the defined height. See the attached images: test1 has a viewing window that accomodates both the defined 4em height and the proportionally scaled width; test2 shows what happens when the viewing window is narrower than a 4em height and a proportional width would allow—namely, it preserves the height and squishes it width-wise to fit it all on the screen.

[JSWolf]

Originally Posted by ElMiko

As I understand it, "em" isn't a absolute unit, it's a relative unit. So, I mean, I guess it's as natural as any other em value.

Regarding max-width, the issue is that setting it at 100% means that the image will appear to stretch vertically if the screen width is too narrow relative to the defined height. See the attached images: test1 has a viewing window that accomodates both the defined 4em height and the proportionally scaled width; test2 shows what happens when the viewing window is narrower than a 4em height and a proportional width would allow—namely, it preserves the height and squishes it width-wise to fit it all on the screen.

Why not just make it real text? One thing I dislike is graphics taking the place of text when there's no good reason for it.

[Jellby]

Originally Posted by ElMiko

As I understand it, "em" isn't a absolute unit, it's a relative unit. So, I mean, I guess it's as natural as any other em value.

With "natural" height, I mean the height of the image if you don't specify any height. If it's smaller than 4em, setting max-height:4em will not do anything.

Regarding max-width, the issue is that setting it at 100% means that the image will appear to stretch vertically if the screen width is too narrow relative to the defined height.

Not in Firefox, or in the calibre viewer, or in KOReader, at least with the attached test, as far as I can see.

[ElMiko]

Originally Posted by JSWolf

Why not just make it real text? One thing I dislike is graphics taking the place of text when there's no good reason for it.

JSWolf, for pete's sake just imagine it's an image that is not text based and doesn't have a wingding equivalent and, and, and.... I created it as a simple illustrative example.

But even if it were the exact case, this is the kind of advice that is really crazy-making:

-- Question: How do i solve problem X?
-- Answer: By deciding you no longer want to solve problem X.

The issue I described in my original post was not "I want to make a image of text behave a
certain way" it was "I want to make an image behave a certain way", so telling me not to use text images is a non-sequitur.

@Jellby - I think I'm seeing the difference between our two codes, and I don't really understand what the implications are:

Basically, in your test version the height is defined at the <div> level, not the <img> level, resulting in the correct scaling that you observed. I'm confused, though, why definiing the height at the <img> level would result in squishing, and I'm wondering if there are any other unintended consequences depending on which level the height/width values are assigned. Do you know?

EDIT: Welp, I've found unintended consequences...

Whatever protocol PageEdit is using to parse height/width values defined at the <div> results in the image going off the screen (see test3, attached).

And in the EpubJSReader Sigil plugin it cuts off part of the right-hand side of the image (see test4).

[JSWolf]

Originally Posted by ElMiko

JSWolf, for pete's sake just imagine it's an image that is not text based and doesn't have a wingding equivalent and, and, and.... I created it as a simple illustrative example.

But even if it were the exact case, this is the kind of advice that is really crazy-making:

-- Question: How do i solve problem X?
-- Answer: By deciding you no longer want to solve problem X.

The issue I described in my original post was not "I want to make a image of text behave a
certain way" it was "I want to make an image behave a certain way", so telling me not to use text images is a non-sequitur.

@Jellby - I think I'm seeing the difference between our two codes, and I don't really understand what the implications are:

Basically, in your test version the height is defined at the <div> level, not the <img> level, resulting in the correct scaling that you observed. I'm confused, though, why definiing the height at the <img> level would result in squishing, and I'm wondering if there are any other unintended consequences depending on which level the height/width values are assigned. Do you know?

EDIT: Welp, I've found unintended consequences...

Whatever protocol PageEdit is using to parse height/width values defined at the <div> results in the image going off the screen (see test3, attached).

And in the EpubJSReader Sigil plugin it cuts off part of the right-hand side of the image (see test4).

I did give you a solution because it's sans-serif text. You may not like it, but it's a valid solution.

[ElMiko]

It's not a valid solution to the original problem as it was articulated. Has nothing to do with what I might like or not. It has to do with your addressing the topic. You might as well have objected to my creating an ebook out of a fraction of the "Lorem ipsum..." text. Its content was as relevant to the question as the visual content of the image.

Instead, you have taken the liberty of inventing your own problem to solve, namely: someone desperately wants to know if JSWolf thinks an image file is the worst way to display text in an ebook, and is annoyed by it. So, I guess on that count you absolutely nailed the answer.

[JSWolf]

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.

[RbnJrg]

Well, you want a solution for epub2. With this restriction in mind, you'll need to use an SVG wrapper and assign it the "display: inline-block; width: 100%; margin: 1em 0; text-indent:0" properties. This seems to work:

Inlined_Block_SVG.epub



Crop to content the image before including it in the svg wrapper and use margins (or paddings) to add blank spaces. Of course, I set "margin; 1em 0" but you can set the values you want.

[JSWolf]

Originally Posted by RbnJrg

Well, you want a solution for epub2. With this restriction in mind, you'll need to use an SVG wrapper and assign it the "display: inline-block; width: 100%; margin: 1em 0; text-indent:0" properties. This seems to work:

Attachment 218369

Attachment 218370

Crop to content the image before including it in the svg wrapper and use margins (or paddings) to add blank spaces.

That's a rather good solution.