I had an idea for the epub standard, and want to know your thoughts.

[RbnJrg]

Originally Posted by JSWolf

The line-height of 1.2em might not work on a Kindle in KFX.

The line-height: 1.2em is for .kf8 not for KFX.

Also, you don't want to force a line height as one of the reasons for using ChareInk6SP is to have a smaller line height and if your line-height works, then it spoils the line height of the font.

Ok. What happens with the drop cap under .kf8 without setting a line height when the user change the font-size or the font-family? If you're going to force the .kf8 format, to avoid all these inconveniences, it's best to use an SVG image as a drop cap, so you don't have to worry about the font family and font-size.

So can you do a dropcap in KFX without the line-height and not knowing what the default line-height will be?

Yes, under KFX you don't need to set a line height; Kindle will handle all the calculations and fine-tuning to get that drop cap just right.

[JSWolf]

Originally Posted by RbnJrg

The line-height: 1.2em is for .kf8 not for KFX.

I thought that KF8 ignores line-height if it's not large enough. I'm not sure though.

Ok. What happens with the drop cap under .kf8 without setting a line height when the user change the font-size or the font-family? If you're going to force the .kf8 format, to avoid all these inconveniences, it's best to use an SVG image as a drop cap, so you don't have to worry about the font family and font-size.

That might work.

Yes, under KFX you don't need to set a line height; Kindle will handle all the calculations and fine-tuning to get that drop cap just right.

I know for sure that KFX forces the line height. So that's not an issue. So with ChareInk6SP the line height in the metadata is overridden.

[RbnJrg]

Originally Posted by JSWolf

I thought that KF8 ignores line-height if it's not large enough. I'm not sure though.

No, in Kindle you can't set a line-height lower than 1.2em. But you can set for example a line-height of 1.5em or 1.8em, any value higher than 1.2. If you set a line-height of 1em, then is ignored.

I know for sure that KFX forces the line height. So that's not an issue. So with ChareInk6SP the line height in the metadata is overridden.

The same is valid for KFX; if you set a line-height higher (or equal) than 1.2em, then that is honored. However, in part you are right because KDP specifically advises against setting line-height in CSS or HTML for reflowable ebooks, as it's handled automatically (by default employs 1.2em).

[JSWolf]

Originally Posted by RbnJrg

No, in Kindle you can't set a line-height lower than 1.2em. But you can set for example a line-height of 1.5em or 1.8em, any value higher than 1.2. If you set a line-height of 1em, then is ignored.



The same is valid for KFX; if you set a line-height higher (or equal) than 1.2em, then that is honored. However, in part you are right because KDP specifically advises against setting line-height in CSS or HTML for reflowable ebooks, as it's handled automatically (by default employs 1.2em).

That's part of the reason I made ChareInk. I did it so the line height would be smaller on a Kindle. I didn't know if it would work and I didn't know I could make one version with line height metrics for Kindle and other such as Kobo and Windows.

Personally, I don't like 1.2em line height on a Reader. KFX forcing the line height to be at least 1.2em is the reason I dislike it. It spoils ChareInk6SP (my font of choice).

[Falkor]

Originally Posted by RbnJrg

You opened my epub in ADE, and I said that you should open it in Thorium and Calibre Viewer (because you had said that the code wouldn't look fine in those ereaders). Open my epub in those ereaders please (there it should look fine, as you could see in the screenshoot I posted). ADE 4.x DOESN'T HONOR the property "calc()", so it's neccesary to write special code to deal with ADE 4.x and captions (ADE 4.x is an issue, because it also lacks support for @supports and makes it a little harder to write alternative code).

@supports seems to work in ADE 4.5 when using epub3.

'Calc()' seems to work as well.

The problem here is 'float'. It makes all the difference. Removing it will make your file work fine in ADE and Books.
Maybe it takes some additional settings to make 'float' work as intended?

[RbnJrg]

Originally Posted by Falkor

@supports seems to work in ADE 4.5 when using epub3.

Do the try and write:

@supports(display: flex) {
   p {
      background: yellow;
   }
}

ADE 4.x supports "display: flex" so if @supports is honored, then paragraphs should have a yellow background color. Once you check the property is supported, erase the code to do the try.

'Calc()' seems to work as well.

Do the try for example by setting a width of an element of "width: calc(100% - 10em);" and watch if the element's width was reduced.

The problem here is 'float'. It makes all the difference. Removing it will make your file work fine in ADE and Books.

Maybe it takes some additional settings to make 'float' work as intended?

If you don't set "float" then you will have fragmentation in your epub. But you didn't say if you tested it or not in Thorium and Calibre. You said that my sample didn't work there and in the screenshoot I posted you can see that the epub looks fine those ereaders. My code is not for ADE 4.x; as I said in my previous post, ADE needs additional statements in order the things work there.

EDIT: "calc()" works under ADE 4.5; @supports it doesn't.

[RbnJrg]

Originally Posted by Falkor

The problem here is 'float'.

In my tests, even this version that is not for ADE, works fine in ADE 4.5. Watch the following screenshots:



With a bigger font-size:



And with a biggest font-size:



As you can see, the image floats perfectly (no blank spaces; I added a green background so the block can be watched easier). If you have issues to get the same output, then you have something wrong.

[Falkor]

Originally Posted by RbnJrg

Do the try and write:

@supports(display: flex) {
   p {
      background: yellow;
   }
}

ADE 4.x supports "display: flex" so if @supports is honored, then paragraphs should have a yellow background color. Once you check the property is supported, erase the code to do the try.



Do the try for example by setting a width of an element of "width: calc(100% - 10em);" and watch if the element's width was reduced.

Done that. Works fine.

@supports (display: flex) {
  hr {width: calc(100% - 14em)}
  }

Originally Posted by RbnJrg

If you don't set "float" then you will have fragmentation in your epub. But you didn't say if you tested it or not in Thorium and Calibre. You said that my sample didn't work there and in the screenshoot I posted you can see that the epub looks fine those ereaders. My code is not for ADE 4.x; as I said in my previous post, ADE needs additional statements in order the things work there.

I found the error in my epub that caused the issues with Thorium and Calibre and I wrote about it in #47.

For ADE and Books I just found a way to make your epub work with float: Don't set the margin to 0. It needs to be bigger (or not set at all). The left and right margins should be set to auto to keep things centered. Works fine in ADE, Books, Thorium and Calibre viewer

[Falkor]

Originally Posted by RbnJrg

In my tests, even this version that is not for ADE, works fine in ADE 4.5. Watch the following screenshots:

Attachment 216549 Attachment 216550

With a bigger font-size:

Attachment 216551 Attachment 216552

And with a biggest font-size:

Attachment 216553 Attachment 216554

As you can see, the image floats perfectly (no blank spaces; I added a green background so the block can be watched easier). If you have issues to get the same output, then you have something wrong.

I was using the exact same file you shared.
And ADE has hardly any settings to change, just the text size and the size of the window. There's nothing I have done that could have caused this. Maybe ADE for MacOS is different from ADE for Windows?

I've attached screenshots of the unchanged file and the file with modified margin. It behaves much better, but apparently it's not a perfect fix. Sometimes the layout will still be messed up... but never as badly as with zero margin.