Best Typeface and Font Size for ePub Creation

[Lenora]

Hi all,

I'm creating a document in InDesign specifically for ePub conversion (destination Barnes&Noble). Because eBook devices offer their own font selection and the reader can resize the font, I was wondering if there is a preferred font and font size to use when creating a file for ePub conversion. Are there some fonts that work better than others? What is considered a good point size for body copy?

BTW, I do not plan on embedding fonts, but would like to use a font that is as glitch-free as possible.

Should the destination device (in this case, the nook) have any bearing on font selection?

[Jellby]

If you are not embedding the font, then the font you use for viewing the book while you create it has no effect on the book. At least as long as you don't use font-specific stuff (like very precise positioning of drop caps or things like that).

[JSWolf]

As long as it's not a fixed layout ePub for the nook, also test it in ADE (desktop version) and see if it looks good. There's no reason you cannot make ePub for the nook that works elsewhere.

[_savage]

In fact, the Nook is my first device for the EPUB files I build and when 'epubcheck' works and the Nook renders ok, chances are fairly good the books are ok elsewhere too...

As for the font, I never specify these properties because the reader ought to be free to define how he/she'd like to have the book rendered. I might set the justification, but font size is set through "small" or "larger" rather than pixel sizes.

[JSWolf]

Originally Posted by _savage

but font size is set through "small" or "larger" rather than pixel sizes.

Please don't tell us that you do what a lot of publishers do (wrongly) and use a font size of small? The best way to do it for most people is to not set a font size for the main body text and let the reading software use the default font size (most default to 1em).

The term larger is meaningless. It's x-small, small, large, x-large or xx-large.

[Jellby]

Originally Posted by JSWolf

The term larger is meaningless. It's x-small, small, large, x-large or xx-large.

No, it isn't:

A <relative-size> keyword is interpreted relative to the table of font sizes and the font size of the parent element. Possible values are: [ larger | smaller ]. For example, if the parent element has a font size of 'medium', a value of 'larger' will make the font size of the current element be 'large'. If the parent element's size is not close to a table entry, the UA is free to interpolate between table entries or round off to the closest one. The UA may have to extrapolate table values if the numerical value goes beyond the keywords.

But It's better to give an explicit relative size, in percent or em.

[_savage]

Originally Posted by JSWolf

Please don't tell us that you do what a lot of publishers do (wrongly) and use a font size of small? The best way to do it for most people is to not set a font size for the main body text and let the reading software use the default font size (most default to 1em).

The term larger is meaningless. It's x-small, small, large, x-large or xx-large.

No, I don't use the font-size attribute for general text. However, I do use "font-size:x-large;" (or some such) for <h2> tags, assuming that these are relative to the user-selected font size which should be "font-size:normal;".

Is that wrong? If so, how do I go properly about increasing and decreasing the sizes of fonts for headers etc relative to the user's font size?

Originally Posted by Jellby

A <relative-size> keyword is interpreted relative to the table of font sizes and the font size of the parent element. Possible values are: [ larger | smaller ]. {...}

But It's better to give an explicit relative size, in percent or em.

How do I use this? Don't think I've seen it before, and I can't find much info on it. Found this discussion though.

Thanks!

[Jellby]

Originally Posted by _savage

However, I do use "font-size:x-large;" (or some such) for <h2> tags, assuming that these are relative to the user-selected font size which should be "font-size:normal;".

Is that wrong? If so, how do I go properly about increasing and decreasing the sizes of fonts for headers etc relative to the user's font size?

It depends on the reader software, I guess. "normal", "x-large" and friends are supposed to be fixed sizes set by the reading software. I can imagine some software that sets "normal" to 12pt and "x-large" to 20pt... and let's you change the "normal" size, but has a different setting (or no setting at all) for the "x-large" size. That would break your usage. Or it could let you select the base size among the "normal", "x-large", etc. pre-defined sizes, but would leave your "x-large" text unchanged. That would break it too.

I think it's better so set "font-size: 150%;" (= "font-size: 1.5em;") or something like that (for <h2>), that should work unless the reader is broken already.

[JSWolf]

http://websemantics.co.uk/resources/...version_chart/

That page is very good for showing relative sizes. Also, if you prefer to use ems instead iof the keywords, it will show you what ems correspond to what keywords.


http://pxtoem.com/

This is a px > em or em > px converter. This is good for using when you have the size you want in px but know you should be using em instead.

[_savage]

Originally Posted by JSWolf

http://websemantics.co.uk/resources/...version_chart/

That page is very good for showing relative sizes. Also, if you prefer to use ems instead iof the keywords, it will show you what ems correspond to what keywords.

Thanks JSWolf! So here is what I have in my current stylesheet of one of the books now, and reading through related material it seems this is the right way to go.

body {
  font-size: 100%;
}
.big {
  font-size: 1.125em; /* large */
}
h1 {
  text-align: center;
  font-weight: bold;
  font-size: 2em; /* xx-large */
}
h2 {
  text-align: center;
  font-weight: bold; 
  font-size: 1.5em; /* x-large */
}        
h3 {      
  font-weight: bold;
  font-size: 1.125em; /* large */
}
p.hd { 
  font-style: italic;
  font-size: 0.8em; /* small */
  text-indent: 0;
  text-align: center;
}

No other "font-size" uses anywhere in the EPUB.

[JSWolf]

Just a quick note. You don't need the p in p.hd. What p.hd does is tie the class hd to p. but not having the p and just using .hd, you can use hd with p, span, div, etc. as you see fit.

[dgatwood]

Originally Posted by JSWolf

Just a quick note. You don't need the p in p.hd. What p.hd does is tie the class hd to p. but not having the p and just using .hd, you can use hd with p, span, div, etc. as you see fit.

With the caveat that this has lower specificity. That usually doesn't matter (a class by itself is supposed to have higher specificity than any number of leading elements even if some of them have a class). However, not all readers follow the specificity rules correctly, and I've actually seen situations where ADE violates that rule, so be sure to test your content in a wide range of readers before you do anything that would reduce specificity of a CSS selector.

[JSWolf]

Originally Posted by dgatwood

With the caveat that this has lower specificity. That usually doesn't matter (a class by itself is supposed to have higher specificity than any number of leading elements even if some of them have a class). However, not all readers follow the specificity rules correctly, and I've actually seen situations where ADE violates that rule, so be sure to test your content in a wide range of readers before you do anything that would reduce specificity of a CSS selector.

I prefer not to stick classes to anything. They are better free form. So p.hd would be just .hd. It works in all cases where CSS is respected. So no need to test .hd as the class in the CSS. Any reading software that breaks if it is just .hd is too buggy to even bother with. ADE does work with .hd so no problem there.

[Jellby]

Using p.hd or just .hd is just a matter of personal coding style. Some may want to have a single style for every class="hd" element, some may want to specify different styles for <p class="hd"> or <span class="hd"> or <img class="hd"> (even if only one of them is used at first).

I prefer to include the element name in the stylesheet, that way I know exactly what the class was originally intended for.

[dgatwood]

Originally Posted by JSWolf

I prefer not to stick classes to anything. They are better free form. So p.hd would be just .hd. It works in all cases where CSS is respected. So no need to test .hd as the class in the CSS. Any reading software that breaks if it is just .hd is too buggy to even bother with. ADE does work with .hd so no problem there.

For simple rules, ADE works consistently. Where ADE tends to screw up its specificity rules is when some of those have multiple elements and other rules have just a class.

For example, given <div class="foo"><p class="bar">...</p></div>, the CSS rule div.foo p { ... } should have lower precedence than .bar { ... }, but in ADE, IIRC, it doesn't. I'm not sure about p.bar { ... }, but that might be enough to make ADE give it precedence as it should. Not sure.

Honestly, it's likely that ADE won't ever break because of removing the p, but given the aforementioned bug, I wouldn't bet my life on it.

Originally Posted by Jellby

I prefer to include the element name in the stylesheet, that way I know exactly what the class was originally intended for.

Agreed. An uncluttered CSS namespace is less likely to cause surprises later. If I'm applying a style, it is rare that I don't know in advance what element it is intended to affect.