To Embed Fonts or Not to Embed Fonts

[keress]

I've seen articles cautioning against embedding fonts -- articles eight years old. I'm trying to get a feel for what the current wisdom is. I was excited to learn that epub simply uses HTML and CSS. I've been writing both pretty much on a daily basis since 1999. I have a novel written in ms word. I used Kindle to make an ebook, but now I want to use epub. It seems to be offering much better creative control of my material.

I converted the .docx to HTML and then spent FAR too much time taking out all that crappy ms word code. I'll look at a better converter in the future. Any suggestions? I want everything gone except all italics, bolding, links, etc. All those things I'd have to read the whole thing word-for-word to rebuild.

The print version of the book is using two fonts I really like. They're both from Google fonts (TTF fonts). I did all the embedding. It looks great in Sigil and Chrome epub reader. I even got some drop caps to display perfectly with just a minimum of CSS styling.

Then I tried viewing it in Adobe Digital Editions. I'm very disappointed. It's rendering fonts in funky ways. I have a slight variant for the first paragraph in a chapter. It just has no initial indent. And there's a span styling a Drop Cap. In Adobe, that whole paragraph is rendered as bold. No drop cap is displayed. I thought maybe it was getting the 'bold' idea from the drop cap, but that doesn't use a bold, so it makes no sense. It seems Adobe can't handle a simple 'span.'

I don't get it. I'm using very basic, solid CSS tags. All weird MS Word stuff is gone. Why can't Adobe read basic CSS?

[KevinH]

I am assuming you have permission to post that novel, it is in the public domain, or you are the author. If not, please remove it as posting copyrighted material is against the rules.

[hobnail]

One generic problem that jumped out to me is that you're using physical dimensions; inches (in), points (pt), and pixels (px). That's a bad smell. Stick to em and percentages since different ereaders have different screen dimensions, and the user can change the font size.

[BetterRed]

The Workshop forum has threads that discuss getting from DOCX to ePub.

The simplest way is to convert the DOCX with calibre, or use Toxaris' addin for Word which can be found in the Workshop forum to create the ePub, or use Sigil's DOCX Input plugin.

BR

[DiapDealer]

Based on an Amazon search, I'm assuming the OP is the author of this attached work. But I'm also moving it since it's not really a Sigil issue/topic/question.

[DNSB]

I took a quick look at the epub styling. Blecchh... Not the worst I've seen but not good.

One issue with the font-face portion of the stylesheet is the use of curly quotes. Check the Gentium Book Basic normal compared to the Gentium Book Basic bold. This may be the source of your font display issue.

@font-face {
font-family: "Gentium Book Basic";
font-weight: normal;
font-style: normal;
src: url(“../Fonts/GenBkBasR.ttf”); <==
}

@font-face {
font-family: "Gentium Book Basic";
font-weight: bold;
font-style: normal;
src: url("../Fonts/GenBkBasB.ttf"); <==
}

I also swapped the weight and style for Cormorant Infant Bold -- weight: normal and style: bold doesn't quite work.

Then there is the use of naked text -- the line below is not valid code, it needs to be wrapped.

____________________________________

Then we have the naked img tags. I'd suggest wrapping them in a <p> tag with appropriate class.

And this one where some colons were left out or replaced by other characters (I'm assuming the -12px was intended to be 12px):

<img alt="image013" src="../Images/image013.jpg" style="margin-right;12px;margin-left-12px;margin-top:12px;margin-bottom:12px;width:100%;"/>

<img alt="image013" src="../Images/image013.jpg" style="margin-right:12px; margin-left:12px; margin-top:12px; margin-bottom:12px; width:100%;"/>

Then we have the odd mix of measurements. Please use relative (em, rem,%, etc.) not absolute (px, pt, in, etc.). It makes it much easier to read on devices with varying resolutions.

And ';!important;' which is used after four maxwidth:s is incorrect. You need to use ' !important;'. Though, IMNSHO, your epub with a single stylesheet should not need to use any !important.

I did a quick clean up on the file to clean up epubcheck's errors and prettified it to remove those unneeded EOLs in the paragraphs. I also deleted several of the Comorant font files that were not being used to reduce the file size.

[Tex2002ans]

Originally Posted by keress

Then I tried viewing it in Adobe Digital Editions. I'm very disappointed. It's rendering fonts in funky ways. I have a slight variant for the first paragraph in a chapter. It just has no initial indent. And there's a span styling a Drop Cap. In Adobe, that whole paragraph is rendered as bold. No drop cap is displayed. I thought maybe it was getting the 'bold' idea from the drop cap, but that doesn't use a bold, so it makes no sense. It seems Adobe can't handle a simple 'span.'

Your CSS is wrong, and ADE doesn't like CSS that's broken. One error and ADE will potentially throw the entire thing out.

There are serious issues with semicolons in the wrong place, causing the entire CSS file to not be parsed properly.

If you run your CSS through W3C's CSS Validator, you can see all the issues:

https://jigsaw.w3.org/css-validator/validator

You could also run it through Calibre Editor's Tools > Check Book.

* * *

One example,

@font-face {
font-family: "Cormorant Infant";
font-weight: normal;
font-style: bold; <---- This line invalid
src: url("../Fonts/CormorantInfant-Bold.ttf");
}

font-style: bold isn't valid (normal/italic is). And based on the filename, you meant to put:

font-weight: bold;
font-style: normal;

Originally Posted by keress

I don't get it. I'm using very basic, solid CSS tags. All weird MS Word stuff is gone. Why can't Adobe read basic CSS?

There's many other potential issues with your CSS too.

1. For font-size, best to not use rem. Change it to em.

rem isn't well supported across devices.

It's also a poor idea to use px/pt in ebooks (because of DPI issues). Best to change those to em too.

2. You have many forced color (black + gray fonts). This will lead to:

• black-on-black text
• and/or won't allow users to override with their own colors
• the potential to break Night Mode

Remove the forced color.

3. Why are you using max-width on paragraphs?

p.Ghosts, li.Ghosts, div.Ghosts
	{
	margin:0 auto 12px;
	max-width: 700px; <--- This line

Just get rid of this. Readers will set their own margins in their devices.

4. Paragraphs with margins above/below AND indentation is extremely poor typography. Go with either:

A. Text-indent + no margins (what I recommend).

B. No indentation + margin above (this is called "Block Paragraphs"). (Websites usually use this type of spacing, but books aren't typeset this way.)

It's best just to leave this stuff up to user preferences.

Question: ... you said you already "created a Kindle version". I'm assuming you did DOCX->Kindle Previewer?

The reading experience of that ebook is going to be extremely subpar.

* * *

Other Errors I Noticed

1. You still have many apostrophe as dumb quotes. Turn those into RIGHT SINGLE QUOTES.

' -> ’

You may want to run your book through another Smarten Punctuation pass...

2. There are quite a few stray non-breaking spaces:

<p class="Ghosts">&nbsp;“<i>Srće moje</i>,” Jovanka continued. [...]</p>

[...]

<p class="Ghosts">&nbsp;“Yes, my girl!” said Srđa with great excitement suddenly appearing before her. [...]</p>

Replace with a normal space, then run Sigil's Tools > Reformat HTML > Mend and Prettify All HTML Files.

3. There's also a few stray leftovers from Word's HTML:

<i><span style='font-size:9.5pt;line-height:115%;
font-family:"Arimo",sans-serif;letter-spacing:.4pt'> </span></i>

[...]

<span style='font-size:9.5pt;line-height:115%;font-family:
"Arimo",sans-serif'>.</span>

Unsure what else slipped through. Do a search for span style= and you'll probably find them all.

4. You accidentally have a ─ (U+2500 BOX DRAWINGS LIGHT HORIZONTAL) instead of an EM DASH — (U+2014).

You can use Sigil's Tools > Reports > Characters in HTML to find all the characters used in your book. Investigate/Remove any of the funky ones.

Also, your book is plagued with soft hyphens. These are a very poor idea in ebooks, plus they break things like Search + Sigil's spellchecking. Eliminate these.

Originally Posted by DNSB

Then we have the naked img tags. I'd suggest wrapping them in a <p> tag with appropriate class.

Better to use <div>s. Typically no margins or anything is inherited.

Also, with images, it's best to use helpful alt attributes.

<img alt="image003" src="../Images/image003.jpg" class="full-image"/>

alt is read by Text-to-Speech, so it is important to give these meaningful descriptions:

alt="A man down by the river."

If you can't think of a description, then it's best to leave alt="" blank instead of full of gibberish like alt="image003".

[DNSB]

This is a snippet from the Kindle edition sample which shows the effect of the inconsistent paragraph styling.

[Tex2002ans]

Originally Posted by keress

I've seen articles cautioning against embedding fonts -- articles eight years old. I'm trying to get a feel for what the current wisdom is.

Still holds true to this day.

Embedded Fonts, if used, should be used very sparingly (I always mention Maths + Accented Greek as examples). Maybe for chapter headings and decorative things (scene breaks)... But embedding them as the body font? Bad idea.

What typically happens is "Print Fonts" are used (because "the ebook has to look exactly like the print book!"). These fonts may look okay on paper, but come out very poorly on the various types of devices + font sizes + DPIs.

For example, the fonts are usually too thin on e-ink (JSWolf always comments about this).

The font may have also been designed for ideal reading at "12pt" in mind... but on cellphones, with small font size, the font may be too hard to read.

On many ereaders, embedded fonts will forcefully override the user's chosen fonts... (this leads to pissed off readers!).

Also, Amazon's workflow just makes certain fonts completely disappear... or break in the Look Inside.

That's just a few pain points with embedded fonts. The rest has been discussed thoroughly on MobileRead throughout the years. Just do a search for:

embedded fonts site:mobileread.com

and you'll probably run across all of them.

[najgori]

Go to tipometar download page and get Areal RNIDS font. It is made for internet/web and it's free to use.
Gentium is OK, but IMHO it's not for ebooks.
If you are new epub designer better download some epub template and modify it for your book. Word or Indesign exported css and html are not very good.

[JSWolf]

Originally Posted by hobnail

One generic problem that jumped out to me is that you're using physical dimensions; inches (in), points (pt), and pixels (px). That's a bad smell. Stick to em and percentages since different ereaders have different screen dimensions, and the user can change the font size.

Don't forget different resolutions so px and pt will be a different size.

[JSWolf]

Originally Posted by najgori

Go to tipometar download page and get Areal RNIDS font. It is made for internet/web and it's free to use.
Gentium is OK, but IMHO it's not for ebooks.
If you are new epub designer better download some epub template and modify it for your book. Word or Indesign exported css and html are not very good.

Templates? No thanks. It's best to learn CSS/HTML and do it by hand as needed for the styling in the ePub. But leave out the embedded fonts if they are not actually needed.

[najgori]

Yeah, right, reinvent that css wheel.

[JSWolf]

Originally Posted by najgori

Yeah, right, reinvent that css wheel.

You have it all wrong. A template like you are suggesting is not going to help. You need to create the CSS based on what you need it to be, not what some template has for CSS. Sigil and Calibre are very good programs that can help you create your ePub and they are free.

If you are going to be creating eBooks, it's bets to know how to code them yourself. Programs that do the coding for you come out with really poor code. The idea is to keep it clean and simple and that requires doing ithe coding by hand. Also, clean and simple means better compatibility across a range of devices and programs.

[najgori]

We could badminton our opinions all day.
I think it is better to start somewhere (blitz or paul salvette css framework) and learn by editing existing code.
You think it is better to start with empty sheet of paper and stumble upon every device glitches and nuances. Well, good luck with that.
I will here rest my case.