Register Guidelines E-Books Today's Posts Search

Go Back   MobileRead Forums > E-Book Software > Sigil

Notices

Reply
 
Thread Tools Search this Thread
Old 06-14-2025, 08:07 AM   #31
Turtle91
A Hairy Wizard
Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.
 
Turtle91's Avatar
 
Posts: 3,339
Karma: 20171571
Join Date: Dec 2012
Location: Charleston, SC today
Device: iPhone 15/11/X/6/iPad 1,2,Air & Air Pro/Surface Pro/Kindle PW & Fire
Quote:
Originally Posted by JSWolf View Post
I've already proved to you that this is wrong and it's not an ADE bug.
Jon....
Did you READ Diap's message??

Quote:
Originally Posted by DiapDealer View Post
Your "bug" theory has been completely and competently disproven, Jon. Any further attempts by you to pretend everyone else (including experts in the field) "is wrong" are going to be deleted. Your petty coding vendettas will not be tolerated here. Take it somewhere else.
Turtle91 is online now   Reply With Quote
Old 06-14-2025, 09:21 AM   #32
ElMiko
Evangelist
ElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileRead
 
ElMiko's Avatar
 
Posts: 427
Karma: 65460
Join Date: Jun 2011
Device: Kindle
So... I used the the html/body 100% approach, and there were a couple idiosyncracies...

Code:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
  "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <style type="text/css">
html, body {
        height: 100%;
	margin: 0;
	padding: 0;
        }
  p.imagefull {
	display: block;
        height:100%;
        text-align: center;
        margin: 0;
	padding: 0;
        }
  .imgfull {
        height: 100%;
	width: auto;
        }
</style>
</head>

<body>
  <p class="imagefull"><img src="../Images/00.jpg" class="imgfull"/></p>
</body>
</html>
In Sigil and PageEdit, this appeared to work except the image extended a few pixels below the window; setting the height in ".imgfull" to 99% seems to fix this, but i don't know why 100% is, well, more than 100% of the screen height. Additionally, if i narrow the window to the point that so that its narrower than the image, instead of shrinking the image to fit the window, it just adds a horizontal scrollbar. (see fullpageimg1.jpg)

In Calibre, narrowing the window beyond the image's natural dimensions doesn't resize the image, but rather smooshes it (see fullpageimg2.jpg). Otherwise, it seems to work like Sigil/PageEdit

Now, bearing in mind that the perhaps an svg wrapper would work differently, I'm still curious why THIS didn't work. Is there something funky in my styling? Or something missing? And why do Sigil and Calibre render this differently?

[NOTE: attached images are with the height for "imgfull" set to 99%, not 100%]
Attached Thumbnails
Click image for larger version

Name:	fullpageimg1.jpg
Views:	13
Size:	224.8 KB
ID:	216223   Click image for larger version

Name:	fullpageimg2.jpg
Views:	15
Size:	150.5 KB
ID:	216224  
ElMiko is offline   Reply With Quote
Advert
Old 06-14-2025, 11:07 AM   #33
RbnJrg
Wizard
RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.
 
Posts: 1,711
Karma: 8700123
Join Date: Mar 2013
Location: Rosario - Santa Fe - Argentina
Device: Kindle 4 NT
Quote:
Originally Posted by ElMiko View Post
So... I used the the html/body 100% approach, and there were a couple idiosyncracies...
...
Now, bearing in mind that the perhaps an svg wrapper would work differently, I'm still curious why THIS didn't work.
If you had read what I posted, then you would know why you should use svg wrappers. And you also would know why your images look distorted; I am not going to write the same as before (more than that, I posted even screenshots and epubs).

Last edited by RbnJrg; 06-14-2025 at 11:41 AM.
RbnJrg is offline   Reply With Quote
Old 06-14-2025, 12:20 PM   #34
ElMiko
Evangelist
ElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileRead
 
ElMiko's Avatar
 
Posts: 427
Karma: 65460
Join Date: Jun 2011
Device: Kindle
@RbnJrg - I assume you're referring to this post?

If so, I had read it (and just reviewed the attached test files), but it's a bit different from what I'm talking about. Specifically, in your example you are setting image height and width to 100%, whereas I'm setting the width to "auto".

If you were referring to your first post, where you mentioned that using "width: auto" could make the width larger than 100%, I'm still confused as to why. Isn't auto supposed mean that it will use available space? Is it that the 100% height has priority over the "auto" width? If so, why? Does height always have priority over width, or is the value-defined setting always prioritize over a competing "auto" setting (regardless of which is defining height and which is definining width)?

Moreover, as I said in my previous post, part of what's confusing me is that it renders differently between Sigil/PageEdit and Calibre. The distortion you describe in your recent example (again, because the code is slightly different) isn't really what I'm referring to (or at least, I don't think it is...). In my example, Sigil/PageEdit doesn't distort the image at all, it just refuses to resize if the window gets too narrow (which i think may be what you were referring to in your first post). Whereas in Calibre it doesn't stretch or scroll, but it will compress when the window gets too narrow.

Separately, the issue of 100% height rendering as slightly more than 100% of the window height (resulting in a vertical scrollbar) is a little different than the commentary you've made regarding this setting (and its 99/97/95vh corollary). You seemed to be cautioning against these maximized height settings resulting in the insertion of blank space/pages. My issue is not with any blank space insertion (I didn't see any in either Sigil/PageEdit or Calibre), but rather that the 100% height renders as taller than 100% of the window/container height.

Last edited by ElMiko; 06-14-2025 at 12:23 PM.
ElMiko is offline   Reply With Quote
Old 06-14-2025, 01:35 PM   #35
RbnJrg
Wizard
RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.
 
Posts: 1,711
Karma: 8700123
Join Date: Mar 2013
Location: Rosario - Santa Fe - Argentina
Device: Kindle 4 NT
Quote:
Originally Posted by ElMiko View Post
@RbnJrg - I assume you're referring to this post?
Yes, I am.

Quote:
If so, I had read it (and just reviewed the attached test files), but it's a bit different from what I'm talking about. Specifically, in your example you are setting image height and width to 100%, whereas I'm setting the width to "auto".
No, in my examples, you need to pay attention where I said: "But by employing a svg wrapper all problems disappear:". The others examples show issues due to not using svg wrappers. Since you want a full page image, then you must use the code I employed in my Temporal3.epub attached to that post. There, I never use "width: 100%". Alternatively, instead of the code used in the stylesheet for that epub, you can use the following:

Code:
body {
  margin: 0;
}

.myFullHeight {
  height: 100%;
}

@supports(height:99vh) {
  .myFullHeight {
    height: 99vh;
  }
}
Both of those codes give the same output; the original one included in Temporal3.epub and the above alternative one. When you set a value to "height", "width" is "auto" by default. So to write:

Code:
.myDiv {
   height: 100%;
   width: auto;
}
is the same as to write:

Code:
.myDiv {
   height: 100%;
}
Quote:
Moreover, as I said in my previous post, part of what's confusing me is that it renders differently between Sigil/PageEdit and Calibre. The distortion you describe in your recent example (again, because the code is slightly different) isn't really what I'm referring to (or at least, I don't think it is...). In my example, Sigil/PageEdit doesn't distort the image at all, it just refuses to resize if the window gets too narrow (which i think may be what you were referring to in your first post). Whereas in Calibre it doesn't stretch or scroll, but it will compress when the window gets too narrow.
I understand you, you don't understand me. AGAIN, USE A SVG WRAPPER!!!!! And all your issues will disapear.

Quote:
Separately, the issue of 100% height rendering as slightly more than 100% of the window height.
Employ the code of my Temporal3.epub and you won't have more issues. But if you also want to have the image centered in the screen, not matter the ereader, employ the more elaborated code I posted at the end of this post:

https://www.mobileread.com/forums/sh...39&postcount=7

Of course, in all what I wrote above, I was assuming you're working for a full-page image, with no text before or after it on the same page (otherwise you wouldn't have used html, body {height: 100%}). If there is text before or after the image (on the same page) then you have to use the following code:

1. In your .css stylesheet:

Code:
.myFullHeight { /* This is for RMSDK rendering engines */
  height: 99%;
}

@supports(height:98vh) { /* This is for Readium/Webkit rendering engines */
  .myFullHeight {
    height: 98vh; /* Here you also could try with 95vh */
  }
}
2. In your .xhtml file:

Code:
<p>blah, blah, blah,...any extension of text</p>

<div class="myFullHeight">
     <svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 XXX YYY" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
      <image height="YYY" width="XXX" xlink:href="../Images/your_image.jpg"/>
    </svg>
</div>

<p>blah, blah, blah,...any extension of text</p>

Last edited by RbnJrg; 06-14-2025 at 01:40 PM.
RbnJrg is offline   Reply With Quote
Advert
Old 06-14-2025, 02:47 PM   #36
ElMiko
Evangelist
ElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileRead
 
ElMiko's Avatar
 
Posts: 427
Karma: 65460
Join Date: Jun 2011
Device: Kindle
Yeah, RbnJrg, I see we're kind of talking past each other, and I apologize for that. As I mentioned before, I have no doubt that the svg solutions you've proposed would pre-empt the problems of a non-svg approach. The nature of my question in post #33 wasn't really about HOW to get a full screen, proportional image (a problem for which you've already provided extremely thorough responses), but rather a questions about WHY the non-svg approach was behaving in the way that it did.

So, for example, while you have a solution to fitting the image on a single page (by reducing the height to 99%, which is what I had done and adding a contingent vh specification), I'm puzzled by why 100% height would produce greater than 100% height in the non-svg example, despite having set the html, body, and container to 100% as per the Josh Comeau article.

Likewise, I understand that an SVG wrapper would preempt the variously scrolling/squeezing issues, but don't understand why Sigil treats it one way and Calibre treats it another.

Last edited by ElMiko; 06-14-2025 at 02:53 PM.
ElMiko is offline   Reply With Quote
Old 06-14-2025, 05:49 PM   #37
RbnJrg
Wizard
RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.
 
Posts: 1,711
Karma: 8700123
Join Date: Mar 2013
Location: Rosario - Santa Fe - Argentina
Device: Kindle 4 NT
Quote:
Originally Posted by ElMiko View Post
So, for example, while you have a solution to fitting the image on a single page (by reducing the height to 99%, which is what I had done and adding a contingent vh specification), I'm puzzled by why 100% height would produce greater than 100% height in the non-svg example, despite having set the html, body, and container to 100% as per the Josh Comeau article.
One thing is the screen height, and another thing is the html/body height; many times are not the same. With your code, you set the body height to 100% (or whatever) but that 100% can be higher than the 100% of the screen height. When that happens, it appears a vertical scrollbar but it doesn't mean your code is wrong; you need to test it with one of the Sigil's plugin (Readium, Bibi Reader, JSReader) and not in the Sigil's Preview Pane. If you don't like that vertical scrollbar in Sigil (that means nothing), add to the html/body style the property "overflow: hidden".

Code:
   
html, body {
    height: 100%;
    margin: 0;
    padding: 0;
    overflow: hidden;
}
Open the epub I attach with Sigil/PageEdit/Calibre and now you won't see any scrollbar. You need to know what is the "viewport". Read the following article:

https://elementor.com/blog/vh/

Pay attention when the article says:

Quote:
Before we master the ‘vh’ unit, we need a solid grasp of the browser viewport. Think of the viewport as the visible area of your website within the browser window. It’s important to note that the viewport is sometimes the same size as your device’s physical screen. Factors like browser toolbars, scrollbars, and whether the browser is maximized or resized can all influence viewport dimensions.
Quote:
Likewise, I understand that an SVG wrapper would preempt the variously scrolling/squeezing issues, but don't understand why Sigil treats it one way and Calibre treats it another.
Open the epub I attach and you'll see all is showed of the same way in Sigil/PageEdit/Calibre.

PS: You are using "%" and not "vh". With "vh" you don't need to style the <html> tag; the problem here is that ereaders based on RMSDK don't support "vh" and you are forced to employ "%"
Attached Files
File Type: epub Temporal4.epub (107.5 KB, 8 views)

Last edited by RbnJrg; 06-14-2025 at 05:58 PM.
RbnJrg is offline   Reply With Quote
Old 06-14-2025, 07:15 PM   #38
ElMiko
Evangelist
ElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileRead
 
ElMiko's Avatar
 
Posts: 427
Karma: 65460
Join Date: Jun 2011
Device: Kindle
Interesting....

So, to be clear, I don't have a problem with the scrollbar per se. I mean, if it is necessary to see the whole image then I definitely want it! What I think I'm seeing now is that even at 100%, the vertical scroll bar is actually just showing a sliver of white space below the image, not actually revealing any more of the image (and i assume this is what you mean by "that means nothing"). So what's really happening (I think...???) is that the picture IS 100% of the window height... its just that the container is greater than 100% of the window height, hence the extra little sliver of whitespace that results in the scrollbar (unless you hide "overflow").

Regarding how the two programs render it, I'm seeing that Calibre proportionally resizes the image when you narrow or widen the window, but Sigil stretches the image if you widen the window (which you alluded to in your first post).

If you set the image width to "auto", again, Calibre proportionally resizes the image when you widen or narrow the window. Basically, it doesn't allow for overflow—hidden or not. In Sigil/Preview, widening the window preserves the aspect ratio just fine, BUT narrowing the window results in the left side of the image being cut off (presumably because the overflow has been hidden).

Now.... here's where things go completely off the rails. If I use the attached "Test1" file which seems to be the same as yours except that I've switched out your image for my image, setting width to "auto" results in a squishy image in Calibre!

If i change your image to "auto", it resizes perfectly in Calibre (but cuts off the image in Sigil); if i use the same code on MY image, it gets squished in Calibre.

I've attached both your file (modified to "auto") and mine...

P.S. one important thing I learned is that <p> has embedded margins, while <div> does not, so I've changed that container for the image itself, as per your example.

P.P.S. Does anyone here know how we can just instantly upload knowledge to our brains as in The Matrix? That would save me a lot of time. kthxbye.
Attached Files
File Type: epub Test1 - Unknown.epub (480.1 KB, 7 views)
File Type: epub Temporal 4 - Unknown.epub (107.5 KB, 6 views)

Last edited by ElMiko; 06-14-2025 at 07:23 PM.
ElMiko is offline   Reply With Quote
Old 06-14-2025, 09:26 PM   #39
RbnJrg
Wizard
RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.
 
Posts: 1,711
Karma: 8700123
Join Date: Mar 2013
Location: Rosario - Santa Fe - Argentina
Device: Kindle 4 NT
Quote:
Originally Posted by ElMiko View Post
Interesting....

So, to be clear, I don't have a problem with the scrollbar per se. I mean, if it is necessary to see the whole image then I definitely want it! What I think I'm seeing now is that even at 100%, the vertical scroll bar is actually just showing a sliver of white space below the image, not actually revealing any more of the image (and i assume this is what you mean by "that means nothing"). So what's really happening (I think...???) is that the picture IS 100% of the window height... its just that the container is greater than 100% of the window height, hence the extra little sliver of whitespace that results in the scrollbar (unless you hide "overflow").
Sigil shows a bit more than 100%, for that way you see the white space below the image. For that reason I said it means nothing.

Quote:
Regarding how the two programs render it, I'm seeing that Calibre proportionally resizes the image when you narrow or widen the window, but Sigil stretches the image if you widen the window (which you alluded to in your first post).
One moment! When you say Calibre, what do you mean? Calibre Viewer or Calibre eBook Editor? You can't compare Sigil/PageEdit with Calibre Viewer; you need to compare Sigil with Calibre eBook Editor. And both of them, display the same image when you resize the Preview Pane. Regarding Calibre Viewer, it doesn't honor the code inside the epub. Open my Temporal4.epub with the Sigil's plugin Readium and you'll see that the image has the same behaviour as in Sigil/Calibre eBook Editor.

Quote:
If you set the image width to "auto", again, Calibre proportionally resizes the image when you widen or narrow the window. Basically, it doesn't allow for overflow—hidden or not. In Sigil/Preview, widening the window preserves the aspect ratio just fine, BUT narrowing the window results in the left side of the image being cut off (presumably because the overflow has been hidden).
As I said, Calibre Viewer is not honoring the epub code (the image doesn't take the 100% of the viewport when you narrow the window). Sigil, OTOH, displays properly the image with a height of 100% and a width to maintain the proportion ("width: auto" means a width to maintain the proportion of the image; meanwhile "width: 100%" means a width of 100% of the viewport width). As the window is narrow than the image, and you are using "width: auto", then you can't see it fully.

Quote:
Now.... here's where things go completely off the rails. If I use the attached "Test1" file which seems to be the same as yours except that I've switched out your image for my image, setting width to "auto" results in a squishy image in Calibre!

If i change your image to "auto", it resizes perfectly in Calibre (but cuts off the image in Sigil); if i use the same code on MY image, it gets squished in Calibre.

I've attached both your file (modified to "auto") and mine...
It's all ok. Your image is already squished (is a narrow image), Calibre just maintains the proportion; with "width: auto" it won't stretch the image. My image resizes "perfectly" as you say because the width of my image is bigger than yours.
RbnJrg is offline   Reply With Quote
Old 06-15-2025, 06:06 AM   #40
ElMiko
Evangelist
ElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileReadElMiko has read every ebook posted at MobileRead
 
ElMiko's Avatar
 
Posts: 427
Karma: 65460
Join Date: Jun 2011
Device: Kindle
Quote:
Originally Posted by RbnJrg View Post
One moment! When you say Calibre, what do you mean? Calibre Viewer or Calibre eBook Editor? You can't compare Sigil/PageEdit with Calibre Viewer; you need to compare Sigil with Calibre eBook Editor. And both of them, display the same image when you resize the Preview Pane. Regarding Calibre Viewer, it doesn't honor the code inside the epub. Open my Temporal4.epub with the Sigil's plugin Readium and you'll see that the image has the same behaviour as in Sigil/Calibre eBook Editor.

As I said, Calibre Viewer is not honoring the epub code (the image doesn't take the 100% of the viewport when you narrow the window). Sigil, OTOH, displays properly the image with a height of 100% and a width to maintain the proportion ("width: auto" means a width to maintain the proportion of the image; meanwhile "width: 100%" means a width of 100% of the viewport width). As the window is narrow than the image, and you are using "width: auto", then you can't see it fully.
It appears we're getting to the crux of the issue; I was/am referring to Calibre Viewer. But I'm a little confused as to why I need to compare Sigil only with Calibre Editor? I mean, most people don't read in Calibre editor, no? Aren't Sigil Preview/PageEdit designed to show what the reading experience would look like? Does this mean that Calibre's Viewer is bugged? And if so, are there other ebookreaders that share this bug?

Quote:
It's all ok. Your image is already squished (is a narrow image), Calibre just maintains the proportion; with "width: auto" it won't stretch the image. My image resizes "perfectly" as you say because the width of my image is bigger than yours.
It's true that the image is narrow, but it also gets squished on top of that, whereas yours does not. I've attached three images: 1) Your file/image (set to auto width) with a narrow window (scaling correctly), 2) My file/image with narrow window (getting squished), and 3) My file image with normal window (correct aspect ratio).
Attached Thumbnails
Click image for larger version

Name:	TemporalNarrowWindow.jpg
Views:	8
Size:	109.2 KB
ID:	216243   Click image for larger version

Name:	TestNarrowWindow.jpg
Views:	8
Size:	155.0 KB
ID:	216244   Click image for larger version

Name:	TestNormalWindow.jpg
Views:	7
Size:	241.4 KB
ID:	216245  
ElMiko is offline   Reply With Quote
Old 06-15-2025, 08:01 AM   #41
Falkor
Connoisseur
Falkor began at the beginning.
 
Posts: 73
Karma: 10
Join Date: Dec 2024
Device: Tolino Shine 5
Quote:
Originally Posted by RbnJrg View Post
<html> tag; the problem here is that ereaders based on RMSDK don't support "vh" and you are forced to employ "%"
Is this generally not supported by RMSDK or is this only a problem for old versions that do not support EPUB3?
Falkor is offline   Reply With Quote
Old 06-15-2025, 08:45 AM   #42
JSWolf
Resident Curmudgeon
JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.
 
JSWolf's Avatar
 
Posts: 79,561
Karma: 145863177
Join Date: Nov 2006
Location: Roslindale, Massachusetts
Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3
Quote:
Originally Posted by Falkor View Post
Is this generally not supported by RMSDK or is this only a problem for old versions that do not support EPUB3?
If you are coding for ePub2 backward comparability and if you want your eBook to be read on a Kobo, then you have to use % and not vh or rem as Kobo is using a version 3 RMSDK which is old and not ePub3 compatible.

When you code for backwards comparability, you have to assume that ePub3 specific features may not work.
JSWolf is online now   Reply With Quote
Old 06-15-2025, 11:26 AM   #43
Turtle91
A Hairy Wizard
Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.Turtle91 ought to be getting tired of karma fortunes by now.
 
Turtle91's Avatar
 
Posts: 3,339
Karma: 20171571
Join Date: Dec 2012
Location: Charleston, SC today
Device: iPhone 15/11/X/6/iPad 1,2,Air & Air Pro/Surface Pro/Kindle PW & Fire
Quote:
Originally Posted by JSWolf View Post
When you code for backwards comparability, you have to assume that ePub3 specific features may not work.
That’s the point of having fallback coding for backwards compatibility …

The old coding works but isn’t very pretty, but if the device/app can use the new coding it automatically does and is all nice and pretty!
Turtle91 is online now   Reply With Quote
Old 06-15-2025, 12:14 PM   #44
Falkor
Connoisseur
Falkor began at the beginning.
 
Posts: 73
Karma: 10
Join Date: Dec 2024
Device: Tolino Shine 5
Quote:
Originally Posted by JSWolf View Post
If you are coding for ePub2 backward comparability and if you want your eBook to be read on a Kobo, then you have to use % and not vh or rem as Kobo is using a version 3 RMSDK which is old and not ePub3 compatible.

When you code for backwards comparability, you have to assume that ePub3 specific features may not work.
I was really just wondering if vh doesn't actually work in RMSDK…

Having a fallback solution is easy enough to implement.

It’s not as if ePub3s shoulnd't exist because Kobo won’t support that format and keeps using a decade old renderer. They can only get away with this because so many publishers keep their epubs backwards compatible. The pressure to fix this is way too low.

On the Tolino Shine 5, using vh is the only way I can make full page images work (at least without switching back to the ancient RMSDK). Setting html and body to 100% height won't do the trick. It will still display a line of text under a 100% height SVG, so it seems their renderer for some reason requires an ePub3-compatible solution.
Falkor is offline   Reply With Quote
Old 06-15-2025, 12:45 PM   #45
RbnJrg
Wizard
RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.RbnJrg ought to be getting tired of karma fortunes by now.
 
Posts: 1,711
Karma: 8700123
Join Date: Mar 2013
Location: Rosario - Santa Fe - Argentina
Device: Kindle 4 NT
Quote:
Originally Posted by ElMiko View Post
It appears we're getting to the crux of the issue; I was/am referring to Calibre Viewer. But I'm a little confused as to why I need to compare Sigil only with Calibre Editor? I mean, most people don't read in Calibre editor, no?
Exactly, people don't read in Calibre editor and not in Sigil, either. Because Sigil is an epub editor and Calibre Viewer is an epub reader. You can compare Calibre Viewer with any (or all of them) the Sigil's plugin: Readium, Bibi Reader, JSReader. While Sigil shows a xhtml page in scrolling mode, Calibre Viewer shows the same under the unique page mode.

Quote:
Aren't Sigil Preview/PageEdit designed to show what the reading experience would look like?
NO, they aren't. To get the reading experience of an epub shows you need to employ Readium, Bibi Reader or JSReader.

Quote:
Does this mean that Calibre's Viewer is bugged? And if so, are there other ebookreaders that share this bug?
I don't know whether to call it a bug or part of the design. Calibre Viewer has a lot of problems displaying colors, for example.

Quote:
It's true that the image is narrow, but it also [gets squished on top of that, whereas yours does not. I've attached three images: 1) Your file/image (set to auto width) with a narrow window (scaling correctly), 2) My file/image with narrow window (getting squished), and 3) My file image with normal window (correct aspect ratio).
Open the epub I attach (width: auto) with Calibre Viewer; I don't see what you see in your system.
Attached Files
File Type: epub Test1 - Unknown.epub (480.1 KB, 7 views)
RbnJrg is offline   Reply With Quote
Reply


Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
CSS Styling based on class/existing styling 1ily Calibre 8 03-17-2025 06:37 AM
Incorrect styling with specific CSS quiris Marvin 9 07-04-2016 01:04 PM
Missing CSS properties roger64 KOReader 0 06-01-2016 06:39 AM
inspect image properties /replace image cybmole Sigil 6 02-05-2013 12:46 PM
Unsetting properties in CSS Jellby ePub 2 06-03-2009 04:29 AM


All times are GMT -4. The time now is 05:02 AM.


MobileRead.com is a privately owned, operated and funded community.