ebook.com preview is mangled.

[phillipgessert]

I’d add that unsetting justification is not the same as setting it rag right. It’s just surrendering control of it to the reading system, generally considered a positive. Folks pick their app based on what it does for them, and they like that more than whatever we do to circumvent or improve that.

Re:your font declaration, it is harmless enough but won’t do much. Most people won’t have that font installed on their device, but it will fall back on a sensible default.

For ebook, good design usually means “behaves as expected.” It is a cooperative approach (with the reader) that usually manifests as meticulous markup coupled with very minimal css. Whatever is the least you can bear.

[Hitch]

Originally Posted by roland1

I can already see one conflict, which is the margin-top: one is in em, the other in rem.

My problem is wearing too many hats —*I might make a quick change on the fly and get distracted elsewhere, leaving such discrepancies in place.

Oh well, one step forward at a time...

(Not sure why I put the "display:block" in there. I may have swiped the css from one of my websites during early testing. At least I didn't put a "box-sizing" declaration in there...)

Is anybody else going to comment on using rem inside ebooks?

If I had to guess, I'd say that the root element em is causing all the rendering problems in the LookInsides/previews. BUT, I freely admit, I'm guessing.

Hitch

[roland1]

Originally Posted by Hitch

Is anybody else going to comment on using rem inside ebooks?

If I had to guess, I'd say that the root element em is causing all the rendering problems in the LookInsides/previews. BUT, I freely admit, I'm guessing.

Hitch

Yes please. Coming from the web world and its ever-increasing code options, I just dove into this as though it was a website — and previews looked fine, so I just though —*meh, don't worry about it. Not so apparently.

So yeah, the more you guys can throw my way in terms of do's and don't's, the better it'll be for my ebooks, but also anyone searching for this kind of specific info (circa 2022).

[Hitch]

Originally Posted by roland1

Yes please. Coming from the web world and its ever-increasing code options, I just dove into this as though it was a website — and previews looked fine, so I just though —*meh, don't worry about it. Not so apparently.

So yeah, the more you guys can throw my way in terms of do's and don't's, the better it'll be for my ebooks, but also anyone searching for this kind of specific info (circa 2022).

I think the problem with REM is that it's relative, right? Based on the root font size--but this, this specific thing, rendering in the browser, means it's getting conflicting information--should it use the base font size of the browser's font settings, or the book?

The reason I think this is simple--I've seen Amazon's LITB affected by HTML coding that the author put into the DESCRIPTION field. The authors would put in italics, for example and NOT close the coding--so an opening italic tag and not a closing tag. The LookInside (LITB) rendered, sequentially, after the description--so the entire LookInside rendered in italics, until it encountered a closing tag.

For all we know, this environment is having the same issue and the rem tags are screwing with it. I don't use REM inside ebooks, anyway--and if you're going to ask me why, now, of course, I can't really remember. I seem to recall screwing with them years ago, when the Kindle Universe first came off of HTML 3.2 (in large part) and moved "up" to HTML 4.0, but I also vaguely recall that something went horribly wrong. I don't think it was the LITB, but damned if I can remember. Too many years.

Guys, Phillip, Dion, anybody, remember why we're not all using REM? Or, hell, maybe I'm wrong?

Hitch

[phillipgessert]

Ha, that stood out to me too, but since I don't use them, I wasn't very confident that was the issue. Seems likely.

I also don't remember why I don't. It does kind of seem like a needless abstraction to use a multiple of the font-size of the html element rather than that of the element you're actually working with. If I had to guess, rems would be mainly useful for highly precise, grid- and baseline-oriented layouts, and those won't work for ebook where user controls would throw it all out of whack anyway.

[Hitch]

Originally Posted by phillipgessert

Ha, that stood out to me too, but since I don't use them, I wasn't very confident that was the issue. Seems likely.

I also don't remember why I don't. It does kind of seem like a needless abstraction to use a multiple of the font-size of the html element rather than that of the element you're actually working with. If I had to guess, rems would be mainly useful for highly precise, grid- and baseline-oriented layouts, and those won't work for ebook where user controls would throw it all out of whack anyway.

I could swear that somewhere in time, we all kicked this around, but hell, it could be (gosh) 10 years ago here. I know they didn't work, but damned if I remember why. I feel like Capidamonte was the one that did all the grunty research work and that means, a loooong while ago. Coulda been Tex or...hmmm...someone. But I think someone did that work and we all said "nope, ain't gonna work" and then we shrugged and that was that.

I damn sure can't see it working on Kindles. I mean..with line-heights? OMG, the end is near, the 4th Horseman of the Rendering cometh and he rides a White Horse made of Crashing Pixels.

Hitch

[roland1]

Well, one thing's for sure, I have to find an ebook creation formula that works. I don't want people looking at previews of my book online and cringing or being afraid to buy it because of how bad it looks.

[DNSB]

Originally Posted by phillipgessert

Ha, that stood out to me too, but since I don't use them, I wasn't very confident that was the issue. Seems likely.

I also don't remember why I don't. It does kind of seem like a needless abstraction to use a multiple of the font-size of the html element rather than that of the element you're actually working with. If I had to guess, rems would be mainly useful for highly precise, grid- and baseline-oriented layouts, and those won't work for ebook where user controls would throw it all out of whack anyway.

As far as I recall, using rem was supposed to help prevent some issues with inheritance where you were nesting elements. If I set a header to font-size: 2em; and then set a font-size: 1.5em on something inside that header, that text would display at 3 em whereas using 1.5rem would display the text at 1.5em (assuming I set root size to 1em).

[Hitch]

Originally Posted by DNSB

As far as I recall, using rem was supposed to help prevent some issues with inheritance where you were nesting elements. If I set a header to font-size: 2em; and then set a font-size: 1.5em on something inside that header, that text would display at 3 em whereas using 1.5rem would display the text at 1.5em (assuming I set root size to 1em).

I think that's right, but I also think that in our test ebooks, they didn't work worth a shoot.

Hitch

[roland1]

I think I'll stay away from the em/rem thing and maybe go points, or pixels. I'll have to dig deeper into this. I may have been a bit cavalier the first time around.

Q. Which measurement unit are you guys most consistently using for ePub reflowable ebooks? And do you leave out line height altogether — to allow users that choice, as was earlier mentioned? (which makes total sense).

[phillipgessert]

You shouldn't use fixed units like points or pixels for that, or really anything text-related. It needs to be something that will scale up or down with user-selected font size changes, and those won't.

I think you'll find that the most common unit for text-related stuff is ems, and for most everything else it will be % (width). You'll mainly see fixed units like px for borders and the like.

[JSWolf]

Originally Posted by Hitch

Guys, Phillip, Dion, anybody, remember why we're not all using REM? Or, hell, maybe I'm wrong?

Hitch

Because in a lot of situations it does not work.

[JSWolf]

@roland1, This is the code I use. Code for a blockquote is for the offset text. .blockquote is for when the blockquote end at the end of the chapter and is used as a class <blockquote class="blockquote">. Body is to setup the layout with no widows and orphans and justified text. No need to justify the text any other place. Hr is for section break markers. It gives a 20% line to separate sections. Img is to make sure images do not go off the screen. And finally P is to setup a proper margin for paragraphs. You only need <p> in most cases. Noindent is to class P to give a paragraph or line with no indent.

blockquote {
  margin-top: 1em;
  margin-right: 1.5em;
  margin-bottom: 1em;
  margin-left: 1.5em;
}
.blockquote {
  margin-top: 1em;
  margin-right: 1.5em;
  margin-bottom: 0;
  margin-left: 1.5em;
}
body {
  widows: 1;
  orphans: 1;
  margin-top: 0;
  margin-right: 0;
  margin-bottom: 0;
  margin-left: 0;
  text-align: justify;
}
hr {
  margin-top: 1em;
  margin-right: 40%;
  margin-bottom: 0.9em;
  margin-left: 40%;
  border-top: 2px solid;
}
img {
  max-height: 100%;
  max-width: 100%;
}
p {
  margin-top: 0;
  margin-bottom: 0;
  text-indent: 1.2em;
}
.noindent {
  text-indent: 0;
}

This is what I call some good code. And not a single REM in site.

By the way, What you really should do is install ADE 2.0.1 and use that to check out how your ePub looks.

You can get ADE 2.0.1 for Windows or MAC (32-bit) here. Adobe took down the page, but The Wayback Machine still has it.
https://web.archive.org/web/20200619...downloads.html

[DNSB]

Originally Posted by JSWolf

By the way, What you really should do is install ADE 2.0.1 and use that to check out how your ePub looks.

You can get ADE 2.0.1 for Windows or MAC (32-bit) here. Adobe took down the page, but The Wayback Machine still has it.
https://web.archive.org/web/20200619...downloads.html

ADE 2.0.1 is somewhat useful but then having a selection of ereaders and renderers to test your ebooks is even more useful. When I am working on an ebook that is going to be published, I like to test on both epub and Kindle ereaders and renderers with the objective of producing something that may not be the prettiest but it will be readable on multiple platforms saving the author from drowning in complaints and without needing me to produce an edition for every platform. The addition to Sigil of multiple renderers (BibiReader, EpubJSReader and ReadiumReader) in addition to it's builtin preview has been very helpful.

[roland1]

Thanks, JSWolf —*this is the kind of input I was hoping for; that we could find some consensus and have some examples of what "seems" to work in most combat situations.

I installed Java 1.8 yesterday, so I'm going to install a few more readers into Sigil (one's I had trouble with earlier for some reason.)

But it looks like I might at least get some solid footing in the ebook creation world with what you guys have posted.

Thank you, I do appreciate it.