Using absolute units in img width tends to fail

[DNSB]

For me, the only time I use absolute units for images is for ebook files that intended to be distributed by Amazon AND the author is worried about the minuscule number of people who still use Kindles that require .mobi format.

I do have and use a test epub which uses various ways to display a series of images. If a renderer does not handle that test epub properly, it is a pile of steaming well-aged bovine manure and should not be used.

[JSWolf]

Originally Posted by RbnJrg

In that case, I must say you don't know how to use them properly. Cantook, Reasily, and PocketBook aren't just good e-readers; they're convenient and very easy to use. I can concede that while Lithium, BookFusion, and Infinity Reader display epub files well, they might be a bit basic (and Kobo for Android is quite basic, even though its epub3 support is great), but the other apps are very good.



Well then, I must say—and please don't take this the wrong way—that you don't know much about epub. No, the application you use to open an ebook is not irrelevant. Why don't you try opening the sample chapter I'm attaching in Cantook, Reasily, or Lithium and see what you get? Then do the same in FB Reader or Moon+. There's a world of difference (and try changing the font size)! The reading experience on the e-readers I recommend is infinitely superior to what you can get on FB Reader and Moon+ (although I acknowledge that Readest, as a derivative, a fork of Foliate, can display an epub well, it is no easier to use than the readers I recommend).



Cantook, Reasily, Lithium, PocketBook are also free and easier to use than Readest.

While BookFusion has a subscription model, you can use it without subscribing. It's what I use on my iPhone and iPhad. What do you think makes it a bit basic?

Does anyone have a good ePub3 test ePub to try?

[RbnJrg]

Originally Posted by JSWolf

Does anyone have a good ePub3 test ePub to try?

The sample I posted is a good epub3 to test; here you have it again:

Alice Sample.epub

It has all the code needed to avoid fragmentation, even with "L" images. And the drop cap should look perfect with a proper ereader (no matter the font or the font-size because it uses the property "initial-letter").

[JSWolf]

Originally Posted by RbnJrg

The sample I posted is a good epub3 to test; here you have it again:

Attachment 221023

It has all the code needed to avoid fragmentation, even with "L" images. And the drop cap should look perfect with a proper ereader (no matter the font or the font-size because it uses the property "initial-letter").

Thank you! It works well in Thorium.

[RbnJrg]

Originally Posted by JSWolf

Thank you! It works well in Thorium.

No problem!

[QuietShelfLife]

The SVG wrapper approach mentioned above is probably the most reliable cross-reader solution I've found. Something like:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 400" width="80%">
  <image href="image.jpg" width="600" height="400"/>
</svg>

This lets you define the aspect ratio in the viewBox while controlling the display size with a percentage width on the SVG element itself. Most readers handle SVG sizing much more consistently than they handle img with absolute units. The fallback for readers that don't support inline SVG is just to use max-width in % and accept that you lose fine-grained sizing control on those platforms.

[RbnJrg]

Originally Posted by QuietShelfLife

...The fallback for readers that don't support inline SVG is just to use max-width in % and accept that you lose fine-grained sizing control on those platforms.

I'm afraid of that ereaders that don't support inline svg, they also won't support the property max-width. So you'll have to find another kind of fallback.

[QuietShelfLife]

Originally Posted by RbnJrg

I'm afraid of that ereaders that don't support inline svg, they also won't support the property max-width. So you'll have to find another kind of fallback.

That's a fair point -- you're right that if a reader chokes on inline SVG, its CSS support is probably limited enough that max-width won't help either.

In practice, the fallback chain I've settled on is:

1. SVG wrapper with viewBox (best control over sizing and aspect ratio)
2. CSS max-width: 100%; width: auto; height: auto; on the <img> element (covers anything with basic CSS2 support)
3. HTML width attribute as a percentage directly on the <img> tag (last resort)

The key insight for that third level is that the width attribute (not the CSS property) with a percentage value is actually handled reasonably well even by very old EPUB readers, since it's basic HTML rather than CSS. So <img src="cover.jpg" width="80%" /> tends to work even where CSS-based sizing doesn't.

You lose fine-grained control with that approach -- you can't set a specific pixel-equivalent size that scales proportionally. But at least the image won't overflow the viewport, which is usually the main concern for readers at that end of the spectrum.

[icearch]

It is surly complicate. Sometimes inline style works, othertimes css works, it can vary from device/app or tags. In the end of day you need to test on your subject environment.

[RbnJrg]

Originally Posted by QuietShelfLife

In practice, the fallback chain I've settled on is:

1. SVG wrapper with viewBox (best control over sizing and aspect ratio)
2. CSS max-width: 100%; width: auto; height: auto; on the <img> element (covers anything with basic CSS2 support)
3. HTML width attribute as a percentage directly on the <img> tag (last resort)

But with that aproximation, the width of the element will be controlled by:

<img src="cover.jpg" width="80%" />

That statement will have priority over the css properties.

And how do you handle your XHTML code to have the image enclosed in an SVG container on one hand, and the fallback code based on the <img> tag on the other? I'd be interested to know how you solved that problem.