The "best" body?

[roger64]

Hi

I tend to use the same body for each style-sheet of my EPUB2 books. The idea is to include in the body informations that can later be easily modified, if need be, by modern ebook-readers in order to provide more freedom to the reader.

This is the one and I would be happy to discuss every point.

@page {
  margin-top: 0.4cm;
  margin-bottom: 0.2cm;
}

body {
  margin: 0 0.5cm;
  font-family: "Linux Libertine O";
  line-height: 1.25;
}

Comments

1. - Of course, we can use relative units (em or %). Are there any drawbacks?
2. - font-family is named only once
3. - line-height is named only once
4. - lateral margins are set-up only once
5. - I use padding for vertical margins because of some ADE quirks. (replaced with @page following advices)
6. - I use a transparent background-color ... for no particular reason. (suppressed following advices)
7. - font-size is supposed to be 100%, so it's not named here.
8. - Exceptions can still apply for everything: then, new attributes and values have to be added to the relevant styles.

Any idea about improving this?

[DiapDealer]

I honestly don't see the point in dictating most of those properties in the body. Having to adjust a reader's various overrides (if the reader CAN override all of those settings) each time they open a different ebook from a creator (who each has their own preferences for many of these settings) can get a bit annoying.

I know you embed a font to get around certain characters missing from many readers' system fonts--and I can sympathize with that (although I wish there was a better solution)--but the rest seem really unnecessary to me.

The CSS for the body of all my ebooks looks like this:

body {
  margin-top: 0;
  margin-right: 3px;
  margin-bottom: 0;
  margin-left: 3px;
  padding: 0;
}

I got in the habit of using the long-form css margin-notation simply because I've seen mention of some devices that choke on the short-hand notation.

I add an @page to add a bit of top/bottom margin in my personal ebooks just to keep text from getting hidden by the controls on my preferred epub reading software:

@page { margin-top: 5pt; margin-bottom: 5pt; }

I see no point in dictating the base line-height at all.

[roger64]

Thanks for your comments and your body.

Thanks for your your warning about long-form notation. I did not know there could be some laggards...

I don't use @page (I know calibre does it) because later it conflicts with my PDF-producing software. Were it not for this, its use is very handy.

You call "dictate" the fact that I name some atributes. Well, these things (line-height, margins) have to be set-up somewhere anyway, so why not name them sparingly only in the body?

I should have said that I also use these values to control my PDF-producing software.

Any idea about background-color?

[DiapDealer]

Originally Posted by roger64

Well, these things (line-height, margins) have to be set-up somewhere anyway, so why not name them sparingly only in the body?[I]

Why do they HAVE to be set-up somewhere? Devices/apps will use defaults. I tweak a few of those things for personal use, but I don't think I'd define any of them if I were creating an ebook for distribution (I'm exempting your embedded font-family definition for reasons previously discussed, of course).

Any idea about background-color?

I wouldn't think "transparent" would cause problems. But then again ... I wouldn't want to guarantee that it wouldn't break somebody's personal color themes (Nightmode, etc...). And since you admit you have no real reason for including it, why do so?

[roger64]

Originally Posted by DiapDealer

.../...Devices/apps will use defaults.../...

Take line-height. Usually calibre make use of 1.2, sometimes you find it in many many places... Line-height is quite an important parameter for readability. I use an embedded font with a rather small x-height (like TNR) and so it makes sense to provide the text with a "good" enough (or say matching) line-height. Why should I trust variable "defaults" values on this?

Furthermore, if you set it up once in the body, any decent software will be able to change it easily. Or am I wrong?

When I'm happy or confident with the default, like for the "universal" default font-size (100%), I mark nothing.

Originally Posted by DiapDealer

I wouldn't think "transparent" would cause problems. But then again ... I wouldn't want to guarantee that it wouldn't break somebody's personal color themes (Nightmode, etc...). And since you admit you have no real reason for including it, why do so?

Ah, nightmode... In fact I trust the author of my converter. But you have a point.

Coming back to the choice of the word "dictate". This is a political statement. I would call it "gently recommending" (the same...).

[DiapDealer]

Sorry. I don't mean "dictate" in the political sense at all. But for devices/apps that can't override such settings ... it is the correct term.

[roger64]

Sure if they can't.

And if they can, it's a gentle recommendation.

I would dream of a service where one could test the display of his EPUB to sort this out. For me, I have only Calibre, ADE (1.73...), some common Android readers, Azardi and my Kobo Glo (v. 2.8.1. and patched)

Also, as I supply PDF with both formats (9x12cm and IPAD), it can sweeten the pill if need be, which really I don't know.

[mrmikel]

Having an old Sony PRS-300, I can't override anything, so setting text sizes and so on can make for too big or too small on my small screen. Of course if you have to embed a font that is too stubby then you have to fix it.

I almost never embed a font, but then my work is all in English. My current one has romaji words in it, so I needed the long o which Charis provides.

[Jellby]

My "body" is much simpler:

body { margin: 0; }
@page { margin: 2mm; }

(or the equivalent with long-style properties)

If I want to override @page settings when converting to pdf, I can easily do that using "!important". Line-height is extremely dependent on the font, I never set it (except to prevent increase line separation in superscripts or drop caps).

[roger64]

@Jellby

I know you like the minimalist approach.

Line-height or no line-height?

It's a yes or no question. You let the user rely on its system fonts. And, since you do not embed a font and do not know which font the user will select, it seems better for you not to setup a line-height. This is a fairly logical no-no answer. But the opposite seems logical too. Since I embed a font, I also setup a matching line-height. It's just a yes-yes answer.

It seems that each choice entails the same questions.

For my choice (yes to line-height), the main question is to know if these settings which are setup once in the body have to be considered as hard-coded ("dictated") or can be easily modified ("gently recommended"). If I judge from my -modern- e-reader, I can still change easily the font, modify the line-height and the margins though they are set-up in the body. Nothing has been "dictated". But, I have been told that maybe this is a controversial point of view (owners of old machines can really setup nothing).

For your choice (no to line-height), at least not in the body, let's consider what can be the consequences:
- You probably would not setup the line-height for each style in the CSS. It would be the worst choice because now no e-reader would be able to modify anything. And the user would have to dig in the CSS...
So what's left?
- Either you let the e-reader/app settings choose for the user. I am not aware that these machines or apps are smart enough so as to adapt the line-height according to the x-height of the selected font. Is it a better choice? Furthermore, machine or apps default settings can differ since there is no standard on this field. I know Calibre defaults frequently to 1.2 which seems to go well with Georgia kind of fonts. Which one will be the right one? Do you leave it to luck?
- 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?

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

The use of @page

@page is a very handy way to control vertical margins. So, thank you for your information. I will try to modify your scripts with important! and maybe contact you if I fail...

[roger64]

Originally Posted by Jellby

.../...
If I want to override @page settings when converting to pdf, I can easily do that using "!important".../...

It works very well.
So, I edited the first post and replaced the padding attributes with @page. I also suppressed the background-color attribute.

[Toxaris]

Be aware that font family in the body will be ignored by a Nook. I do not know if also font-family like serif will be ignored though.

[bfollowell]

Originally Posted by Toxaris

Be aware that font family in the body will be ignored by a Nook. I do not know if also font-family like serif will be ignored though.

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.

[roger64]

Originally Posted by Toxaris

Be aware that font family in the body will be ignored by a Nook. I do not know if also font-family like serif will be ignored though.

I had heard about it. I can't help ( and I think Jellby has a Nook).
But maybe there is some hope or recent change in this field following bfollowell informations?

I try to follow ADE which has already lots of limitations (for example the first element would not work). Other players have others. Kobo is very touchy about some font-naming conventions for embedded fonts. Hopefully they'll go mainstream... one day.

[DiapDealer]

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.

One or the other (tablet vs eink) comes with Publisher Defaults turned off--out of the box, so to speak. So embedded fonts aren't seen unless the user knows enough to turn Publisher Defaults on.