A bug in 1.9.30?

[Turtle91]

Originally Posted by JSWolf

But there's no reason to use vw/h when % works. Why use vw/h when it might not work and % will work?

I’m pretty sure I specifically said that it was what I used, but that if it didn’t work to change it to percent.

This is called ‘troubleshooting' Jon…

[JSWolf]

Originally Posted by Turtle91

I’m pretty sure I specifically said that it was what I used, but that if it didn’t work to change it to percent.

This is called ‘troubleshooting' Jon…

But as @Interrobang said, it didn't work with ADE (older version). So it's best to use what works with older and newer software. Your saying it's what you use may get some to use the code and then have it fail.

vw/h does not work on the version of RMSDK on a Kobo and a lot of people on MR have one and do use ePub. So it's best to go with % and it's best that your sample code does as well.

[nabsltd]

Originally Posted by Turtle91

If kobo barfs on the vw/vh, first off - complain to kobo and tell them to get their act in gear

Kindle also doesn't appear to support vw or vh, based on the list of what is supported by any CSS property that needs a length:

mm, in, cm, px, pt, %, em, rem, ex

[Turtle91]

Originally Posted by JSWolf

But as @Interrobang said, it didn't work with ADE (older version). So it's best to use what works with older and newer software. Your saying it's what you use may get some to use the code and then have it fail.

vw/h does not work on the version of RMSDK on a Kobo and a lot of people on MR have one and do use ePub. So it's best to go with % and it's best that your sample code does as well.

My saying it's what I use is specifically that. I don't use a kobo... The readers of this thread are welcome to read and use common sense. If it doesn't work on their target device, then they can change it.....which is what I said....

Unlike some here, Jon, I don't expect people to do things the way I do it...and then get all upset if they don't. I offer solutions...it is up to the reader to make sure my solution works for their situation before using it.

Using % does NOT work all the time. I do NOT use % because it was creating a problem that was solved when I used vw/vh. I don't care about older software or devices. My software handles vh/vw just fine.

[DiapDealer]

Originally Posted by nabsltd

Kindle also doesn't appear to support vw or vh, based on the list of what is supported by any CSS property that needs a length:

mm, in, cm, px, pt, %, em, rem, ex

While we try to accommodate basic compatibility with conversion to Kindlebooks wherever possible, Sigil is firstly concerned with creating spec-compliant EPUBs. We have no interest in making Sigil EPUBs work in all of the various scenarios where Amazon chooses to ignore, avoid, and/or cherry-pick the EPUB spec in their Kindlebook publishing guidelines. Sigil is first and foremost an EPUB editor. Those using the EPUBs Sigil creates as Kindlebook source-code will ultimately be responsible for tweaking things to work as expected when converting to Kindlebook formats.

[DNSB]

Originally Posted by Turtle91

I use the following - I have it set as a template so Sigil uses it when I click on Tools/Add Cover

....

If kobo barfs on the vw/vh, first off - complain to kobo and tell them to get their act in gear , second, just change them back to 100% (or 98% if you are having overflow issues)

Let us know if that works on your device(s) as well!

My Kobo's don't barf on the vw/vh, they just throw it in the bit bucket. I do use 100% and my Kobos are happy with that so I'm not going to change my workflow for now.

The usual issues with renderers doing their own damn thing.

[DNSB]

Jon, what I will use in an ebook edited for my use and what I will use in an ebook intended for distribution are often very different. I suspect most people who are editing ebooks for distribution know the differences between their target software/devices.

[Interrobang]

With regard to using percent in the height and width declaration (e.g. 100%), I found this article rather informative on the subject.

Contained within are these nuggets of information:

...setting the width to 100% before removing the margins will cause the body element to overflow. Here's the CSS reset I use:

* { 
    margin: 0;
    padding: 0;
    box-sizing: border-box;
}

For this reason, I now make sure my margin and padding values are BEFORE any height ones.

This example uses vh (viewport height) units to allow the body to set a minimum height value based upon the full height of the viewport.

body { min-height: 100vh; }

I'm going to try this in my test file and see what happens.

Thanks again for everyone's input on this. I'll keep researching this and update you with my findings.

[JSWolf]

Originally Posted by Interrobang

With regard to using percent in the height and width declaration (e.g. 100%), I found this article rather informative on the subject.

Contained within are these nuggets of information:


For this reason, I now make sure my margin and padding values are BEFORE any height ones.


I'm going to try this in my test file and see what happens.

Thanks again for everyone's input on this. I'll keep researching this and update you with my findings.

You don't need any of this for eBooks.

[Interrobang]

Originally Posted by JSWolf

You don't need any of this for eBooks.

Why not? I'm curious what you're basing that statement on. Is it for technical reasons? If so, please share what you know on the subject.

Maybe on a related note, when I tried that code my image was smaller. Most HTML code guidelines do carry over to epubs, as far as I have read, but it's the areas that don't that seem poorly documented. I won't know what works best until I've tried all the various combinations.

Must be nice to be a large publisher with a room filled with coders, each with specific knowledge about the device they specialize in...

Early on in this adventure, I came across the Blitz CSS Reset for epub. They did all the work on tweaking settings for each device. Too bad the project ended in 2020. It would have been a nice toolbox for someone like me just getting started.

[DiapDealer]

Moderator Notice
Knock it off Jon (JSWolf). Your pet rants and insistence on things being done your way are not welcome here.

[nabsltd]

Originally Posted by Turtle91

Using % does NOT work all the time. I do NOT use % because it was creating a problem that was solved when I used vw/vh.

This is likely because % and vh/vw do not mean the same thing. % means a percentage of the immediately enclosing block element's bounding box. vh/vw is supposed to be a percentage of the whole screen, although some renderers/devices might ignore the minimum outer margin that the device forces.

Full-page images (like covers) using SVG don't have a lot of extra CSS blocks around them, and what your code shows should have 0 margin from the edge of the screen, but there can be CSS in the user-agent-stylesheet that is taking effect.

It's tough to know if you can't inspect the element and figure out what is getting applied.

[igorbessa]

Originally Posted by KevinH

Hmm ... perhaps the ADE bug is platform specific?

I can assume so. I tested my epub on ADE 4.5.12.85 for MacOS and version 4.5.12.112 on Windows 11.
On Mac and all other readers I tested, the setting for the cover image not to exceed the height of the viewport was ok, but in ADE on Windows the cover image appears cropped.

Would this option of including the image in an SVG container be viable to solve this problem?

[KevinH]

The ADE bug this thread is talking about has already had a workaround added to Sigil. Have you tried the svg code added by Sigil 2.0.1 as it should include the workaround.

[CrankyLamb]

Originally Posted by elibrarian

You're right; it's not a bug in Sigil � it's a bug in ADE from � I think � version 4 and up. It renders SVG-covers very small, but I've found that putting

style="height:98vh;"

(the "98" can be any percentage) into the SVG-code forces ADE to render it correctly, and doesn't seem to bother other readers. It only works by putting it directly in the SVG-code.

Sample:

<svg version="1.1" xmlns="http://www.w3.org/2000/svg"
style="height:98vh;" xmlns:xlink="http://www.w3.org/1999/xlink"
width="100%" height="100%" viewBox="0 0 1650 2200"
preserveAspectRatio="xMidYMid meet"> <image width="1650" height="2200"
xlink:href="../Images/hawthorne-det_roede_bogstav.jpg"/>

(the code may not be "state of THE art", just state of MY art )


Regards

Kim

I'm having a problem in Calibre & ADE that this thread seems to have found the solution for.

Yesterday I reported in this thread that:

"Many of my eBooks have cover photos that appear too large, too small (thumbnail), and/or are not positioned at the center of the page."

A perfect cover page for me looks like this:



1. It is placed at the center
2. It fits the entire page

I was trying to find a solution to fix that in Calibre to no avail, until I came across this thread. I replaced the height and width % with vh and vw respectively, and it seems to work now.

The question is for how long? Will applying this fix cause me some problems later on? Say when ADE gets an update and fixes this bug?

I'd appreciate your opinion.

PS: I know nothing about code, and I'm a complete newbie.