The "best" body?

[radius]

I like to set line-height in my personal books. This is because of reading on devices which don't allow you to adjust (Sony) or have very limited range of adjustability (Kindle PW2)

[Jellby]

Originally Posted by roger64

- Or you probably consider that the user will always be able to modify the line-height setting. I bring you back then to the DiapDealer argument expressed above: even the owners of old machines?

I consider that one of these apply:

- The reader does not offer a way to change font or line-height, and the user is just satisfied with the defaults. Nothing to be done.

- The reader does not offer a way to change font or line-height, but the user cares and can tweak the CSS to his/her liking. The simpler and cleaner the CSS, the easier it will be for the user to tweak.

- The reader does offer font and/or line-height settings. Any setting you add in the CSS could prevent this to work (just like a hard-coded font

We make different choices but it seems that the questions arisen are not that different...

and I don't mean that your choice is wrong, but you asked for feedback

Originally Posted by roger64

I had heard about it. I can't help ( and I think Jellby has a Nook).

I currently have an Orizon, as you can see in my profile.

[bfollowell]

I've attached a body definition and a page global that I typically use for all of my personal ebooks. I do not develop anything professionally so these are just personal choices but these provide a very nice, clean look for me.

I, for one, despise the fact that most commercial ebook designers are now using pixels as a unit of measure for setting margins, indents and the like. It's such an arbitrary, subjective unit of measure. A measurement that looks great on a Kindle 3 or a first or second generation Nook eink reader, will almost certainly look horrible, and quite possibly even non-existant on my ultra high-resolution Nook HD+ tablet reader. I don't care for % either but it is much, much better than using pixels. Personally, I use ems and feel this is a much better unit of measure but I realize everyone has their own opinions. I've had to result to developing my own little formula to convert pixels to ems and the first thing I do when I purchase a new ebook is clean up the css and convert any and all pixel measurements to em.

That's what works for me.

- Byron

@page { margin-top: 2em; margin-bottom: 1.333em; margin-left: 2em; margin-right: 2em; }


body
{
    display: block;
    font-size: 1em;
    line-height: 1.2em;
    margin-bottom: 0;
    margin-left: 0;
    margin-right: 0;
    margin-top: 0;
    padding-left: 0;
    padding-right: 0;
    page-break-before: always;
    text-align: justify;
    font-family: "Charis";  (or whatever font I wish to use)
}

[DiapDealer]

The "page-break-before" is unnecessary. There's always a page-break with each new html file (and each html file can have only one body).

"display: block" really serves no purpose in that context either.

[roger64]

@Jellby

My opinion is that setting up font-family, lateral margins, line-height only once in the body let them be easily modifiable either by current ebook-readers like KoboGlo or by opening the CSS.

Sorry for the Nook, I was joking.

@bfollowell

Thanks for sharing.

About relative units

Yes em is certainly a unit I will consider for margins, paddings and font-size.

I've found that % -which looks externally very handy- may yield inconsistent results (some readers or apps fail to take them precisely into account) for margins and paddings. It's perfect for font-size.

Other attributes

I personnaly do not setup text-align and font-size in the body but it's your choice.

Could you comment further on why you use these following attributes. I may have missed something (and I certainly missed the DiapDealer comment above).
- display:block;
- page-break-before:always;

[bfollowell]

Originally Posted by roger64

@Jellby

Could you comment further on why you use these following attributes. I may have missed something (and I certainly missed the DiapDealer comment above).
- display:block;
- page-break-before:always;

You know, that's a very good question. I wish I had a good answer for you. I guess, really, I don't though, other than copy/paste. I believe these are just hold-overs from old S&S Microsoft Reader css files that I originally stared modifying and working with years ago. Over the years I've changed preferences and techniques, but those attributes have always stayed in there, even though I never was certain that they made much difference one way or the other. I guess I just need to abandon them altogether if they really serve no purpose.

- Byron

[Hitch]

Originally Posted by bfollowell

Only if you have publisher defaults turned off, unless you're talking about Nook eink readers and there's a difference between the Nook eink and tablet readers. My Nook Tablet and Nook HD+ have no problems picking up and using font-family as defined in the body.

No. He's talking about, particularly, the Nook HD Color, which routinely and very annoyingly ignores perfectly solid CSS and embedded fonts, and simply does NOT display them, publisher-fonts or no publisher fonts. There was a very lengthy thread, when was it, Jellby, Tox, do you remember?--last year, sometime, and I thought the OP was crazy, too, until we had the same thing happen. A file with an embedded font could NOT display the font on the client's Nook HD Color. Subsequent experiments seem to indicate an override of some type. And, yes, we directly side-loaded the file to the devices, with no joy. And the fonts worked perfectly on a Nook Color, Nook readers and other Nook devices.

And it didn't matter how we embedded the fonts; by individual style; by class, by body. One of the fonts just would NOT display.

FWIW.
Hitch

[bfollowell]

Originally Posted by Hitch

No. He's talking about, particularly, the Nook HD Color, which routinely and very annoyingly ignores perfectly solid CSS and embedded fonts, and simply does NOT display them, publisher-fonts or no publisher fonts. There was a very lengthy thread, when was it, Jellby, Tox, do you remember?--last year, sometime, and I thought the OP was crazy, too, until we had the same thing happen. A file with an embedded font could NOT display the font on the client's Nook HD Color. Subsequent experiments seem to indicate an override of some type. And, yes, we directly side-loaded the file to the devices, with no joy. And the fonts worked perfectly on a Nook Color, Nook readers and other Nook devices.

And it didn't matter how we embedded the fonts; by individual style; by class, by body. One of the fonts just would NOT display.

FWIW.
Hitch

That is really strange. I've never experienced anything like that with my Nook Tablet or Nook HD+. Neither have ever failed to display an embedded font, assuming it was setup correctly. I guess I've just been lucky.

- Byron

[Hitch]

Originally Posted by bfollowell

That is really strange. I've never experienced anything like that with my Nook Tablet or Nook HD+. Neither have ever failed to display an embedded font, assuming it was setup correctly. I guess I've just been lucky.

- Byron

Yup, the "that's really strange" thing was how we all viewed it, too, but I now do not assume that if something works in ADE and my NookColor that it will work on a NookHD tablet, because I've got screenshots to prove it doesn't. It's a poser, and it's not a one-time thing. There are definitely some overrides in the HD firmware or ? that cause some issues in following the CSS as written, vis-a-vis fonts.

(P.S.: this is also VERY true if the client/publisher uploads an ePUB at NookPress and does NOT explicitly tell it to use the "original file." NookPress has CSS, etc., that it will use INSTEAD OF the CSS provided, so that the entire file gets overwritten in a completely different fashion. If you produce books commercially, make sure your clients are aware.)

Hitch