image scaling problems: due to PNG format

[stumped]

i have an epub ( was epub 3 but I converted to epub 2 ) which has many large PNG images
the authors intent, I believe is to display each image as a single "page" - that is how they are in the matching paperback version.
sigil reports the properties for a randomly selected one as
1236 x 1900 colour 24bpp

these are problematic in almost all apps and viewers. ADE does not scale them to screen, moon+ reader renders them as tiny little squares ( but will expand then if double clicked ). only Bookari seems to handle them well

I am not sure of the root cause or of the simplest fix.
is it because thay are .PNG or simply because they are large, or because they are coded with div, not with SVG ?
the relevant code for each display is div class="image-full"...<img....
defined as
.image_full {
clear: both;
display: block;
height: 98vh;
margin-bottom: 0;
margin-left: auto;
margin-right: auto;
margin-top: 0;
padding-bottom: 0;
padding-left: 0;
padding-right: 0;
padding-top: 0;
page-break-inside: avoid;
text-align: center;
width: 100%
}
can I improve the rendering via code or CSS tweaks , or must I remove, shrink,replace each image ?

[fbrzvnrnd]

Originally Posted by stumped

i have an epub ( was epub 3 but I converted to epub 2 ) which has many large PNG images
the authors intent, I believe is to display each image as a single "page" - that is how they are in the matching paperback version.
sigil reports the properties for a randomly selected one as
1236 x 1900 colour 24bpp

these are problematic in almost all apps and viewers. ADE does not scale them to screen, moon+ reader renders them as tiny little squares ( but will expand then if double clicked ). only Bookari seems to handle them well

I am not sure of the root cause or of the simplest fix.
is it because thay are .PNG or simply because they are large, or because they are coded with div, not with SVG ?
the relevant code for each display is div class="image-full"...<img....
defined as
.image_full {
clear: both;
display: block;
height: 98vh;
margin-bottom: 0;
margin-left: auto;
margin-right: auto;
margin-top: 0;
padding-bottom: 0;
padding-left: 0;
padding-right: 0;
padding-top: 0;
page-break-inside: avoid;
text-align: center;
width: 100%
}
can I improve the rendering via code or CSS tweaks , or must I remove, shrink,replace each image ?

there is no CSS selector for img?

If not, try to remove the height: 98vh; and add:

.image_full img {width:100%}

And see what is gonna happen.

[Tex2002ans]

If this is intended purely as an EPUB, then you should have no problems using an SVG Wrapper.

There is a recent Sigil Plugin, InsertImageSVG, which should help speed up the process of creating much of the SVG Wrapper code for you:

https://www.mobileread.com/forums/sh...d.php?t=283333

Each PNG should then stretch to fill up the entire screen.

Originally Posted by fbrzvnrnd

If not, try to remove the height: 98vh; and add:

.image_full img {width:100%}

And see what is gonna happen.

I agree with fbrzvnrnd's recommendation.

And vh is a CSS3 measurement and probably won't work on a vast majority of EPUB readers.

[stumped]

thanks guys, this is a out-of-curiosity study of an existing book's code, it's not something I created or something I plan to keep. Just wanting to understand the rendering mechanics here.
i did read some mostly old threads on shrinking via calibre conversions, but I really wanted to know if the rendering can be made more app friendly just by simple regex/ css changes.


i had not encountered vh before & guessed it means vertical height- google tells me it actually means viewport height - so what is 98vh asking the rendering engine to do, exactly

to answer another question: in the source epub3 format there is no css class for img.

if i have calibre do an epub to epub conversion - thus making it epub 2, the post conversion version actually renders better in ade 2.0.1, i.e. the images then do scale to fit PC window, but is still unviewable in moon+ reader.
calibre leaves the div css unchanged but adds this CSS for img
display: inline;
height: auto;
max-height: 100%;
max-width: 100%;
page-break-inside: avoid;
width: auto

the book is a huge, over 100Mb file, because of the over-the-top images used ( it's only 50 pages! ) so I am not wanting to share it even privately for study, just wanting to understand how it could have been done better / made much smaller to suit a typical tablet or eink device. Most images are 24 bit colour, some are 32 bit - that., plus the dimensions seems overkill - as if someone said lets just put the master print images into the ebook , unscaled.

& i thought that most professionals used svg tags nowadays to pair with .png, not basic img ?

[fbrzvnrnd]

Actually I do not use images > 150k. You can use images bigger than 150k, but I suggest to test the speed in rendering and memory usage of e-ink device, especially on older e-ink device. If a chapter has got many big images, it could be very slow to load and sometimes it can crash an ereader if it uses too much memory.

The SVG is a XML markup language to draw vectors. It is wonderful and full of things, like links, animation and "zoom". Some of this things are supported by e-reader, most not. You can also use it to "embed" bitmap, but it is only a thing you can do with it. Actually I use div and img to handle png or jpeg images in ePub2, not svg.

vh is viewport. 100vh is all the viewport. 50vh is 50% of viewport. what is viewport? is the web-page a user view. what is viewport in ebooks? well, it depends. I see testing with javascript that some ebook application thinks viewport is everything is inside the application window (the toc for example), other application only the page, other all the side-by-side pages. but, as Tex2002ans said, this is CSS3, so: no ePub2. Maybe EPUB3 (EPUB3 uses only a subset of CSS3).

f.

[JSWolf]

Don't limit based on file size. You need to use high-resolution images and the file size needs to be as large as it needs to be.

[JSWolf]

does vh work with ADE? The thing is, why use vh when you know % works and is the same thing?

[fbrzvnrnd]

Originally Posted by JSWolf

Don't limit based on file size. You need to use high-resolution images and the file size needs to be as large as it needs to be.

I disagree. You have to scale your images for the hardware you are working for.

[fbrzvnrnd]

Originally Posted by JSWolf

does vh work with ADE? The thing is, why use vh when you know % works and is the same thing?

In CSS % is referred to the parent of the html element. So, a img with a 50% height theoretically is 50% of the body, so 50% of the chapter height. Usually ebook reader "stop" themselves to the page's height, or images pixel height, sometimes not.
As you know there is nothing in CSS to handle selectors related to the "virtual page" of an ebook (except the poor subset of paged media). vh could be a good step in right way.

f.

[DiapDealer]

For what it's worth ... some of the commercial epubs I buy seem to have a separate css file that seems to use media queries to attempt to define a viewport size based on screen size. I have no idea if it works (or if it's practical at all), though. *shrug*

[stumped]

Originally Posted by DiapDealer

For what it's worth ... some of the commercial epubs I buy seem to have a separate css file that seems to use media queries to attempt to define a viewport size based on screen size. I have no idea if it works (or if it's practical at all), though. *shrug*

there may have been some media stuff that I did not grasp, I will have to take another look back at the original epub 3 CSS. & try to puzzle it out with a side order of google searches

the book construction has one large image per chapter, I guess that addesses some of the loading speed and RAM issues.

I guess it presents badly in ADE 2.0.1 as that version predates epub3. I am reluctant to install ADE 3 or 4.5 in case that zaps my current version

The book "works" ok on my 2Gb RAM tablets; I don't have anything low spec to hand to see how robust the design is for older devices,

I'll see if there is an amazon kindle sample version available to see what if anything is done differently there

[JSWolf]

Originally Posted by DiapDealer

For what it's worth ... some of the commercial epubs I buy seem to have a separate css file that seems to use media queries to attempt to define a viewport size based on screen size. I have no idea if it works (or if it's practical at all), though. *shrug*

It's not practical. ADE doesn't do media queries.

[JSWolf]

Originally Posted by fbrzvnrnd

I disagree. You have to scale your images for the hardware you are working for.

That's why you use % as needed. the problem is that ADE does not do media queries. Also, if you are selling the ePub, you'll have no idea the hardware people are using. Can be a smartphone, tablet, Reader, computer all with different resolution screens. So no, you cannot scale for any specific screen.

[DiapDealer]

Originally Posted by JSWolf

It's not practical. ADE doesn't do media queries.

So the worst thing that could happen is that ADE ignores it. That's not the end of the world.

[JSWolf]

Originally Posted by DiapDealer

So the worst thing that could happen is that ADE ignores it. That's not the end of the world.

That depends what you are trying to do. You could end up with things going pear shaped.