Image styling css... what do all these properties do?

[ElMiko]

Originally Posted by RbnJrg

In Calibre Viewer, within the Preferences, under page structure, you may have the option to maintain cover aspect ratio enabled. And under Miscellaneous, you may have enabled the option to remember the window position and size (while I don't).

THAT was it. Calibre was interpreting your Scaramouche image as the cover, and then preserving the aspect ratio. Whereas my Bosch image was not considered the cover image and therefore not having its aspect ratio perserved.

If I duplicate the page with your Scaramouche image (making it a two-file epub instead of a one-file epub), the second image gets squished when the viewing window is narrowed.

What a relief... I was starting to feel like a crazy person.

[PeterT]

Originally Posted by RbnJrg

Really? Please, open the sample I attach (an epub3) in Kobo for Android and see what it looks like; then open the same file on one of your Kobo devices and tell me if you find any differences in what you see. It would be a really nice surprise if your Kobo device didn't add any extra blank space because of the pictures, and also avoided page breaks where they weren't needed.

I've got this epub now on my Libra Colour as both an ePub 2 and ePub 3. What screen shots would you like to see? (The ePub 3 was NOT converted by Sigil or calibre; just renamed to a .kepub.epub file). (The .epub opens in the RMSDK based engine; the .kepub.epub in the other engine).

[RbnJrg]

Originally Posted by PeterT

I've got this epub now on my Libra Colour as both an ePub 2 and ePub 3. What screen shots would you like to see? (The ePub 3 was NOT converted by Sigil or calibre; just renamed to a .kepub.epub file). (The .epub opens in the RMSDK based engine; the .kepub.epub in the other engine).

In principle, you should not see any white space generated by the images but open the sample in Calibre Viewer or in any of the Sigil's plugin (Readium, Bibi Reader, JSReader) or in Thorium and you'll see how the epub must display images and text. The sample is an epub3 (it has everything from animations to jagged outline images) with no fallback code to epub2, so epub2 ereaders can't show properly the sample contain. The sample is intended to test the epub3 capabilities of Kobo devices (as I said in my previous post, in Kobo for Android the sample looks great).

PS: Please, tell me if there are differences between what Kobo device shows and what you see in Calibre, Sigil's plugins or Thorium (or Kobo for Android if you want to install the app in your smartphone). No matter the font size you set, the layout mustn't break.

[PeterT]

Attached find screen shots

Changing font size causes no issues with image placement (apart from the issue with the text with imnage wrapped around it).

[RbnJrg]

Originally Posted by PeterT

Attached find screen shots

Changing font size causes no issues with image placement (apart from the issue with the text with imnage wrapped around it).

Thank you very much! As I suspected, fragmentation occurs when the ePub is read on a Kobo device. Here's how it looks on an e-reader that honors CSS3 properties:





As you can see, no blank space is created by images, even by that one with L-form. Increasing or decreasing the text size by the user does not affect the design; for example, the first three pages with a font-size of 150%:

[PeterT]

One final data point for which I'll try for images tomorrow. Adding the book to the Kobo Android app does result in the text being wrapped correctly in the L shaped image.

It would be fascinating to see this test done on a Tolino device.

[JSWolf]

Originally Posted by RbnJrg

Thank you very much! As I suspected, fragmentation occurs when the ePub is read on a Kobo device. Here's how it looks on an e-reader that honors CSS3 properties:

Attachment 216293 Attachment 216294 Attachment 216295 Attachment 216296

Attachment 216297 Attachment 216298 Attachment 216299 Attachment 216300

As you can see, no blank space is created by images, even by that one with L-form. Increasing or decreasing the text size by the user does not affect the design; for example, the first three pages with a font-size of 150%:

Attachment 216301 Attachment 216302 Attachment 216303

The problem is that the Alice sample uses webkit code. Not every program that respects ePub3 uses webkit. Also, webkit is not part of the ePub3 specification. Can you do it without having anything to do with webkit and just ePub3 code?

[RbnJrg]

Originally Posted by JSWolf

The problem is that the Alice sample uses webkit code. Not every program that respects ePub3 uses webkit. Can you do it without having anything to do with webkit and just ePub3 code?

Except for ADE 4.x, all ereaders I know are based on Readium/Webkit rendering engine. Of course, physical devices are a different matter. But it wouldn't be difficult for the latter to incorporate one of the latest versions of WebKit as their rendering engine. Take Kobo for example; on Android and iOS, they have a version of WebKit that supports everything (one of the best I've seen); why don't they include it on their physical devices?

[DiapDealer]

Also note that webkit css is not limited to only being supported by webkit rendering engines. WebEngine, for instance, likes it just fine. I'd be surprised if most modern browsers and rendering engines didn't as well.

[JSWolf]

Originally Posted by RbnJrg

Except for ADE 4.x, all ereaders I know are based on Readium/Webkit rendering engine. Of course, physical devices are a different matter. But it wouldn't be difficult for the latter to incorporate one of the latest versions of WebKit as their rendering engine. Take Kobo for example; on Android and iOS, they have a version of WebKit that supports everything (one of the best I've seen); why don't they include it on their physical devices?

No idea why Kobo is not using the latest version of webkit. But since webkit is not part of the ePub3 spec, it should not actually be used to be ePub3 compliant.

[KevinH]

FWIW, On iOS they are required to use Apple's built-in Webkit so any iOS ereaders can access it without maintenance costs or software size increase. I assume for Android it would be a similar situation with a Chrome/blink based engine built-in.

[RbnJrg]

Originally Posted by JSWolf

But since webkit is not part of the ePub3 spec, it should not actually be used to be ePub3 compliant.

I didn't understand that last statement of yours. As you know, Readium is an open source initiative whose primary goal is to facilitate the implementation of the EPUB 3 specification. Well, originally, the Readium Project (launched by the IDPF, now part of the W3C) was conceived with the idea of ​​building its EPUB 3 reference implementation on top of WebKit. Although the direct reliance on "WebKit" as a single entity has diversified over time, the idea of ​​using a web rendering engine to display EPUB content (which is essentially HTML and CSS) remains fundamental to Readium's functionality. So:

Readium Web: Uses the capabilities of the web browser it's running in. If your browser uses WebKit (like Safari), then Readium Web will take advantage of that.

Readium Mobile and Desktop: These native app toolkits can still use webview components, which in turn can be based on WebKit (especially on iOS/macOS) or on its derivatives/alternatives (such as WebView on Android using Blink/Chromium, or Electron on desktop using Chromium/Blink).

AFAIK, all ereaders based on Readium support webkit properties. More than that, if you want to view text in color within Calibre Viewer then you need employ the property "-webkit-text-fill-color"; without that property, no colors in Calibre Viewer. So see if the webkit properties are not important.

[JSWolf]

Originally Posted by RbnJrg

I didn't understand that last statement of yours. As you know, Readium is an open source initiative whose primary goal is to facilitate the implementation of the EPUB 3 specification. Well, originally, the Readium Project (launched by the IDPF, now part of the W3C) was conceived with the idea of ​​building its EPUB 3 reference implementation on top of WebKit. Although the direct reliance on "WebKit" as a single entity has diversified over time, the idea of ​​using a web rendering engine to display EPUB content (which is essentially HTML and CSS) remains fundamental to Readium's functionality. So:

Readium Web: Uses the capabilities of the web browser it's running in. If your browser uses WebKit (like Safari), then Readium Web will take advantage of that.

Readium Mobile and Desktop: These native app toolkits can still use webview components, which in turn can be based on WebKit (especially on iOS/macOS) or on its derivatives/alternatives (such as WebView on Android using Blink/Chromium, or Electron on desktop using Chromium/Blink).

AFAIK, all ereaders based on Readium support webkit properties. More than that, if you want to view text in color within Calibre Viewer then you need employ the property "-webkit-text-fill-color"; without that property, no colors in Calibre Viewer. So see if the webkit properties are not important.

It doesn't actually matter what Readium does with Webkit. Webkit is not part of the ePub3 standard. So using anything Webkit is non-ePub3 compliant.

Can you make that Alice sample without using any Webkit and just ePub3 code?

[JSWolf]

Originally Posted by RbnJrg

I didn't understand that last statement of yours. As you know, Readium is an open source initiative whose primary goal is to facilitate the implementation of the EPUB 3 specification. Well, originally, the Readium Project (launched by the IDPF, now part of the W3C) was conceived with the idea of ​​building its EPUB 3 reference implementation on top of WebKit. Although the direct reliance on "WebKit" as a single entity has diversified over time, the idea of ​​using a web rendering engine to display EPUB content (which is essentially HTML and CSS) remains fundamental to Readium's functionality. So:

Readium Web: Uses the capabilities of the web browser it's running in. If your browser uses WebKit (like Safari), then Readium Web will take advantage of that.

Readium Mobile and Desktop: These native app toolkits can still use webview components, which in turn can be based on WebKit (especially on iOS/macOS) or on its derivatives/alternatives (such as WebView on Android using Blink/Chromium, or Electron on desktop using Chromium/Blink).

AFAIK, all ereaders based on Readium support webkit properties. More than that, if you want to view text in color within Calibre Viewer then you need employ the property "-webkit-text-fill-color"; without that property, no colors in Calibre Viewer. So see if the webkit properties are not important.

p {
  color: blue;
  margin-top: 0;
  margin-bottom: 0;
  widows: 1;
  orphans: 1;
  text-indent: 1.2em;
}

That works in calibre's viewer and preview to show blue text.

[Falkor]

Originally Posted by RbnJrg

I didn't understand that last statement of yours. As you know, Readium is an open source initiative whose primary goal is to facilitate the implementation of the EPUB 3 specification. Well, originally, the Readium Project (launched by the IDPF, now part of the W3C) was conceived with the idea of ​​building its EPUB 3 reference implementation on top of WebKit. Although the direct reliance on "WebKit" as a single entity has diversified over time, the idea of ​​using a web rendering engine to display EPUB content (which is essentially HTML and CSS) remains fundamental to Readium's functionality. So:

Readium Web: Uses the capabilities of the web browser it's running in. If your browser uses WebKit (like Safari), then Readium Web will take advantage of that.

Readium Mobile and Desktop: These native app toolkits can still use webview components, which in turn can be based on WebKit (especially on iOS/macOS) or on its derivatives/alternatives (such as WebView on Android using Blink/Chromium, or Electron on desktop using Chromium/Blink).

AFAIK, all ereaders based on Readium support webkit properties. More than that, if you want to view text in color within Calibre Viewer then you need employ the property "-webkit-text-fill-color"; without that property, no colors in Calibre Viewer. So see if the webkit properties are not important.

also, unsupported CSS properties must be ignored, so using a prefixed property shouldn't do any damage.

Problems may occur if different renderers interpret the same settings differently or if more than one property has to be used to do the same thing in different renderers. Some renderers may support more more than one of the properties and they may interfer with each other.