View Full Version : Specs to format an epub for kobo


verydeepwater
03-12-2013, 05:03 PM
Are there any specific specs to format an epub so that it is suitable for kobo? Or can you just use the same epub file for both?

JSWolf
03-12-2013, 06:01 PM
Are there any specific specs to format an epub so that it is suitable for kobo? Or can you just use the same epub file for both?

For both what? The same ePub file that works on a Sony or B&N or Bookeen or others should work on a Kobo except maybe the embedded fonts because Kobo refuses to fix the embedded font bug.

davidfor
03-14-2013, 03:09 AM
I have no problem using epubs obtained from other sites on either of my Kobo devices. Kobo do have their own format which is an epub with some extra tags. But I am fairly sure they just run a conversion of the standard epub to achieve that.

@JSWolf: You have mentioned the embedded font bug before, but I can't think of a discussion of it here. Can you point to one?

JSWolf
03-14-2013, 10:19 AM
All Kobo's ignore font-family when they are included in the body CSS style. Some ePub that have embedded fonts turn them on via font-family in the body CSS style.

To me, this is a major bug. The only way to fix things so they work is to put the font-family in other CSS styles. I'm wondering though if a styled div could work like so...

<div class="font">
the chapter goes here
</div>

.font {
font-family: charis
}

davidfor
03-14-2013, 11:38 PM
Ok, I can see what you are saying. If the book has the font family set for the body, it is ignored. As I have seen other fonts used in books on the device, styles for other tags probably work. It almost sounds like a deliberate decision to ignore the font on the body. Kobo does let the user choose the font to use and has a "Document Default" option. I would expect that this respected the document styling but choosing could let the user override this. I might have a play.

jackie_w
03-16-2013, 08:40 PM
@JSWolf,

I have seen you refer to this Kobo 'bug' in various threads, but I have to confess that I don't know what you mean.

If I load a typical retail epub, containing an embedded serif font for the main body text, then I can see the publisher's font if I select 'Document Default' in the Kobo's select-a-font menu. This works even if the publisher has put the font-family declaration in body {...}.

Alternatively, if I prefer to use a Kobo internal font, or my own sideloaded font, for main body text then, again, I just select the one I want from the font menu.

Whichever of the above I choose, any extra special fonts embedded by the publisher to highlight selected passages of text also display correctly.

In what practical way is there a bug? :blink:

In real life, I've no idea why any Kobo owner would ever need to embed a main body text font as it's a lot less effort and disk space (not to mention more flexible), to just use the font menu.

roger64
03-17-2013, 12:00 AM
.../...

In real life, I've no idea why any Kobo owner would ever need to embed a main body text font as it's a lot less effort and disk space (not to mention more flexible), to just use the font menu.

Real life is pretty large. You may wish to embed fonts for many reasons: contents or aesthetics among them. For example, to display Greek quotes, true smallcaps, dropcaps using special Swash fonts for laser effects :) , etc.

For the time being Kobo ignore these special needs. You'll find here an example with any of these books:
http://www.mobileread.com/forums/showthread.php?p=2446592#post2446592
- the EPUBs are not displayed correctly because Kobo ignores the Linux Libertine Display font (used for some titles and dropcaps) and the smallcaps font.

On the other hand, the six inch PDF with exactly the same display is perfectly displayed with the Kobo Glo.

And you may as well forget the endnotes, because the KoboGlo does not seem to know how to deal with them. After some tries, I've stopped playing hit and miss...

jackie_w
03-17-2013, 10:41 AM
Real life is pretty large. You may wish to embed fonts for many reasons: contents or aesthetics among them. For example, to display Greek quotes, true smallcaps, dropcaps using special Swash fonts for laser effects :) , etc.
Please don't misquote me. What I actually said was
In real life, I've no idea why any Kobo owner would ever need to embed a main body text font In case the emphasised part is ambiguous, by main body text font I mean the font which will be used to display the epub's standard, plain paragraphs. I certainly didn't intend to imply that no Kobo owner would ever want to embed fonts to enhance certain portions of an epub, e.g. SmallCaps and DropCaps.


For the time being Kobo ignore these special needs. You'll find here an example with any of these books:
http://www.mobileread.com/forums/showthread.php?p=2446592#post2446592
- the EPUBs are not displayed correctly because Kobo ignores the Linux Libertine Display font (used for some titles and dropcaps) and the smallcaps font.
I will look at your linked post later (my schoolgirl French is somewhat rusty so I'll have to rely on Google translate :)), but in the meantime all I can say is that I can and do display special dropcap and SmallCaps fonts on my Kobo Glo. See attached pics.

The only Kobo-specific problem with fonts that I have encountered so far is the fact that there is no built-in monospace font. But this can be solved in the same way as SmallCaps/DropCaps, i.e. either by embedding one or by css-referencing a sideloaded one in the Kobo /fonts directory.

roger64
03-17-2013, 11:06 AM
Sorry if you feel I misquoted you, it was not intentional. I may be wrong because my KoboGlo is only two days old, but I read on the support forum that any Kobo font you wish to add should include a regular, italic, bold and bolditalic font. This leaves aside stand alone fonts like Linux Libertine Display or smallcaps (semibolds somewhere?).

Nevertheless, I added Linux Libertine to my Kobo and the Linux Libertine Display as well (I named it Linux Libertine Display-Regular ???)

You sent a nice dropcap screenshot. Up to now, I did not manage to display properly the dropcaps for my books (except with the six inch PDF version of my book) with the Kobo Glo. If you find a solution to get a normal display of them, I'll be happy to try it.

There is not need to speak French for this. The CSS file is quite standard, and who cares about the story? :)

jackie_w
03-17-2013, 12:41 PM
I tried the first book on your list on my Kobo Glo.

Good news: Your embedded fonts are not being ignored, so the css is fine.

Bad news: Unfortunately they don't all look good. The smallcaps and dropcaps are OK but a bit too lightweight (IMO only). However the main body text and headings look terrible, with long vertical streaks. I can only assume this is something to do with the particular webfont .ttf files you've embedded. I happen to have a version of Linux Libertine as one of my sideloaded fonts. If I select it from the font menu the main body text looks fine again, which just leaves the headings as problematic. The Kobo obviously doesn't like some of your ttf files. I tried the same epub on my Sony PRS350 which displays fine - no vertical streaks at all - it's still a bit lightweight IMO.

I have to conclude that the Kobo is more picky about fonts than some other readers but the standard @font-face methods for embedded fonts do work as expected.

When publishing epubs which may be read on many different devices, font-embedding is a tricky business, so the fewer the better. IMO it's better to let each user pick their preferred font for main body text. If you're only preparing them for yourself (as I am) you just have to do a bit of trial and error about which ones look good on your own readers.

FYI - If you're only creating epubs for yourself then this recent post (http://www.mobileread.com/forums/showpost.php?p=2443591&postcount=12) of mine shows how to css-reference a sideloaded font in the Kobo /fonts directory without needing to embed it. It works for fw 2.1.5 but I'm not able to test it on any later versions. Feel free to PM me with any questions.

roger64
03-17-2013, 09:42 PM
Hi jackie

Kobo "weakness" with embedded fonts

Thanks for trying and for providing a useful link. Your observations recoup exactly what I noted. Contrary to ADE or Sony (yours and my former PRS-505)the way Kobo display the embedded fonts of my EPUBs is not satisfactory.

You pointed the fact that my CSS code is fine. Using strictly (not one letter change) this same CSS code and the same embedded fonts, Prince produces a PDF which is displayed fine everywhere, including on the KoboGlo.

I must conclude from this, that the implementation of embedded fonts display for EPUBs on the KoboGlo is whimsy. Call it a bug, a weakness, whatever, I don't know, but there is something wrong. Like for the endnotes display, if this is an hit and miss thing (yes for this font, no for the other one), it's not acceptable and this behaviour should be corrected.

I already wrote two days ago to the Kobo support about this.

Using dropcaps on EPUBs

Using dropcaps is a tricky business indeed, at least as long as you wish to use a special font to display your dropcap (as I did).

As the dropcap must be finely adjusted to the body font, you have to take also into account the metrics of these two fonts in your CSS values because they form a couple. For a safe display, it means that it's advisable to embed both fonts. As the regular font of Linux Libertine is already 800k, of course, it's better to embed a subset, if not your EPUB will be bloated.

I cannot see any other way out of this except renouncing to display dropcaps.

meeera
03-17-2013, 11:09 PM
However the main body text and headings look terrible, with long vertical streaks. I can only assume this is something to do with the particular webfont .ttf files you've embedded.

I haven't examined the source, but just as a possible clue, I think this has happened with some mis-named fonts. Perhaps fixing the name might help?

roger64
03-18-2013, 01:08 AM
I haven't examined the source, but just as a possible clue, I think this has happened with some mis-named fonts. Perhaps fixing the name might help?

You may be on to something. I will build again the webfonts and make a new try.

If somebody knows how Kobo checks a font-family name... I know already that for sideloaded fonts, they apply a strict naming-convention, maybe they follow some special rules for embedded fonts too?

Could FontForge be of some service for this? I mean renaming cleanly the font-family name or at least checking its proper name.

Jellby
03-18-2013, 12:15 PM
I cannot see any other way out of this except renouncing to display dropcaps.

Well... you could renounce to have perfect typesetting, which you already have to do for a number of other reasons. I think basic dropcaps can work pretty well in most situations.

jackie_w
03-18-2013, 07:18 PM
For a safe display, it means that it's advisable to embed both fonts.
...whereas the conclusion I would draw is that, if you're preparing epubs for others, it's advisable to embed neither :D If you're preparing them for yourself it's not difficult to find an acceptable solution. I don't think I'd want to give up the advantages of epub to get a fixed font selection in PDF, especially on a Kobo which doesn't seem like a great PDF reading experience (but that's obviously all just personal opinion :))

I cannot see any other way out of this except renouncing to display dropcaps.
If you let the dropcap display in the same font as the main body text, by removing the font-family setting from the dropcap class, then you'll have a fighting chance of success. This is what I do for most modern fiction books I read. I only add the fancy initials for a few book series (such as the Wheel of Time fantasy in my original pic).

roger64
03-18-2013, 11:10 PM
Hi
I can't really argue on your points. If I was trying to sell my books, I would indeed have chosen another path and tried to meet the needs of the largest reading audience. No question about that. :)

Feeling no pressure...

It happens that I publish non-commercial EPUBs, so I feel no pressure for two reasons:

1 - As far as I can see, the situation is not too bad: for the time being, I already provide a fallout solution. The Kobo displays the six inch PDF exactly the way I intended - Too bad for the unlucky Kobo Mini users...

2 - These books will be here for a long time because they are classical books. They will not be out of fashion next year, they are already out of fashion. And dropcaps have been around for centuries. They will survive this period.

Meanwhile, the current technical limitations of the Kobo will very probably not be eternal.

As an example, remember some years ago, people said:" if you publish for the IPAD, you cannot embed fonts." Well, Apple changed its mind. Currently it seems IPADs (or better said iBooks) does not seem to display nnbsp. Should we stop using them for this reason? This situation can change overnight.

Look for fonts: not long ago, people argued that, for ebook readers, we should discard the old print fonts and switch to web optimized fonts (like Georgia), for hard fact reasons. Now, people begin to realize that old fonts can also be used because the screen resolution on nearly all devices has been vastly increased. I also enjoy using Garamond on my - 213 ppi - Kobo screen.

These considerations apply also for dropcaps. This is a philosophical question, not a technical one...

... but looking for a solution

If I feel no pressure, it does not mean that I do not care about how easily the reader can read them now. It happens that I have just been aware of this Kobo dropcap problem for some days (I bought a Kobo Glo) and I am looking for a solution.

I already have to discard one solution proposed above: I will not use only one single font for body and dropcaps for a plain reason: I tried it already, and the resulting display is not nice nor elegant. The Linux Libertine Display font has been optimized for the display of big size characters but it's much too light-weight to be used for regular display. It would be a pity not to use it for what it has been intended for.

Up to now, I try to understand how Kobo deals with embedded fonts. Are there any quirks regarding font-family names? If I have to change some names, I would gladly do it, as far as it does not trigger any collateral damage.

If you found a solution to display fancy dropcaps, I would be keen to learn it (hoping these dropcaps are not just images).

Finally, it seems there is also one thing that makes a correct display of EPUB dropcaps more difficult. You need to recreate the exact original balance for the three cursors (size, line-spacing and margin) if not the dropcap will not display as planned as it seems that these Kobo settings take precedence over the EPUB CSS values (but for EPUBs only, not for PDF)...

jackie_w
03-19-2013, 12:50 PM
If you found a solution to display fancy dropcaps, I would be keen to learn it (hoping these dropcaps are not just images).
Now you're confusing me :blink: If you're embedding the fancy font, the solution is the one you're already using. Namely:

Find the fancy initial font file you want - often only available in Regular.
Embed in your usual way, with something like the following (substitute your own values, of course)
HTML: <p class="noindent"><span="dropcap">T</span>his is a fancy initial font.</p>
CSS:@font-face {font-family: "Fancy font"; src: url('../Fonts/Fancy font.ttf')}

.dropcap{
float:left;
font-family: "Fancy font", serif;
font-size:3em;
font-weight:bold;
line-height:0.8em;
margin-left:0.1em;
margin-right:0.1em;
margin-top:-0.1em
}

dgatwood
03-19-2013, 01:22 PM
IIRC, if you don't set display to block (I'm assuming you're using a span, because you really shouldn't be using a div inside a paragraph), most renderers will ignore the top margin. Depending on the font, you may also need to set the line-height to at least 1.2, and you may want to set the box's height property to avoid wasting too much space below the drop cap on whitespace.

There are lots of other fun surprises if you aren't careful. Take a look at the CSS section of the EPUB article on the wiki site. Most of those quirks are reader-specific bugs that I discovered while doing drop caps. :)

roger64
03-19-2013, 01:31 PM
I haven't examined the source, but just as a possible clue, I think this has happened with some mis-named fonts. Perhaps fixing the name might help?

You were right! I noticed a dramatic improvement when I added the Kobo suffixes to all the embedded fonts: ie -Regular, -Italic. All the streaks on the screen disappeared. Even the display of dropcaps is now nearly good (just a little too high; with for some letters like D, I still have some display quirks.

I took care to bring back the right balance for the three Kobo cursors but as Kobo does not provide numerical values, you never can be 100% sure about it.

I have good hope, with some more trials, to achieve a nice result. So, the good and plain answer seems to be: "Do not forget to add the Kobo font suffixes to your embedded fonts"

Thanks for the tip!! :thanks:

Nota: I selected the option: "Default document" for the font choice.

@jackie

Thanks also for your implementation of dropcaps. I will look at it.

meeera
03-19-2013, 10:43 PM
You're welcome! As well as adding the right suffix, the name itself needs to match the proper font name - so if you have any further trouble, you might want to check that as well.

roger64
03-20-2013, 07:17 AM
IIRC, if you don't set display to block (I'm assuming you're using a span, because you really shouldn't be using a div inside a paragraph), most renderers will ignore the top margin. Depending on the font, you may also need to set the line-height to at least 1.2, and you may want to set the box's height property to avoid wasting too much space below the drop cap on whitespace.

There are lots of other fun surprises if you aren't careful. Take a look at the CSS section of the EPUB article on the wiki site. Most of those quirks are reader-specific bugs that I discovered while doing drop caps. :)

I am afraid I did not find the CSS section of the EPUB article. Could you link to it?

The extreme sensitivity of Kobo to font-family names does not help. It seems they do request.
- the full font-family name (no abbreviation, single quotes) - not the postscript name -.
- a suffix at least for Regular, Italic, Bold and BoldItalic.

I have four embedded fonts: three display perfectly ('Linux Libertine-Regular', 'Linux Libertine-Italic','Linux Libertine OC') the third one being for small-caps. The fourth one: 'Linux Libertine Display-Regular' still has some quirks which defeat the purpose of the dropcaps.

This is my way for dropcaps. I do use a block (first span) in which I insert the letter (second span).


.let1{
display : block;
float : left;
margin-top : -0.2em;
margin-left : 1.30em;
margin-right : 0.20em;
height : 2.0em;
}

.let2{
font-family:'Linux Libertine Display-Regular';
font-size : 3.2em;
line-height : 0.9em;
}

/*Réglage Lettrine J et Q (let 2 vers let4) */

.let4{
font-family:'Linux Libertine Display-Regular';
font-size : 2.9em;
line-height : 0.9em;
}

body {
line-height: 1.30;
}

<p class="let"><span class="let1"><span class="let2">S</span></span>


For the time being I do not yet get a perfect display of the dropcaps on EPUBs with the Kobo Glo and this precise embedded font. Some letters are nearly OK (S, E, I), some others are badly displayed (L, D..)...

Arios
03-20-2013, 03:05 PM
1. Go to the wiki page (http://wiki.mobileread.com/wiki/EPUB#CSS_Tips);
2. If you look carefully you'll see (nearly at the end of the file): CSS Tips;
3. You win!

PS To verydeepwater: sorry for hijacking your post.

dgatwood
03-21-2013, 02:46 AM
Ooh. I see somebody reorganized it so that it isn't a giant wall of bullets. :D

Thanks.

roger64
03-21-2013, 07:30 AM
Thanks. I tried to find this item using the "main page" tree but one needs to be more clever. :)

For dropcaps, I use a 1.3em line-height for the body. But the one for the box needs to be adjusted. A 1.2 (or 1.3 value) would not fit, I think.

DaleDe
03-21-2013, 02:57 PM
Ooh. I see somebody reorganized it so that it isn't a giant wall of bullets. :D

Thanks.

You're welcome. I did it due to roger64's inability to find the data he was looking for.

Dale

roger64
03-23-2013, 09:19 AM
Kobo

Before giving up with dropcaps and embedded fonts, I had a last try which finally worked. I dumped my embedded fonts (which were a subset created using Font Squirrel) and installed the heavy full ttf regular and italic fonts.

This time everything was OK. The display of the dropcaps was perfect.

So Kobo is very sensitive to both the name and nature of your embedded fonts. Much more so than ADE and most of other readers. Can we say: "If your embedded fonts works on the Kobo, they should work everywhere..." ?

Wiki

@DaleDe

I am sorry if I gave you so much trouble for an offhand and dumb remark. There is indeed a link in the wiki from an introductory EPUB article toward the EPUB main article. My mistake was that I took this introductory EPUB article as the main one... Many times using Internet, the links are pointing elsewhere, for example to Wikipedia or W3Schools and so I did not bother to use this one. I forgot that a wiki structure is not an hierarchical one. All this comes from a poor judgment from my part.

Could I suggest to differentiate the wiki internal links from the external ones? If the internal link points to an exhaustive article like the one on the EPUB, maybe this link would deserve to be written in big bold letters, to distinguish it from the common rabble and catch the attention of not too bright users like me...

DaleDe
03-23-2013, 12:39 PM
Kobo

Wiki

@DaleDe

I am sorry if I gave you so much trouble for an offhand and dumb remark. There is indeed a link in the wiki from an introductory EPUB article toward the EPUB main article. My mistake was that I took this introductory EPUB article as the main one... Many times using Internet, the links are pointing elsewhere, for example to Wikipedia or W3Schools and so I did not bother to use this one. I forgot that a wiki structure is not an hierarchical one. All this comes from a poor judgment from my part.

Could I suggest to differentiate the wiki internal links from the external ones? If the internal link points to an exhaustive article like the one on the EPUB, maybe this link would deserve to be written in big bold letters, to distinguish it from the common rabble and catch the attention of not too bright users like me...

Actually wiki internal links are quite different from external ones. The external links have a square with a diagonal arrow at the end icon to show that you are going off site. Occasionally a new wiki user will create internal links what look like external ones and I fix those when I notice them but you can be assured that if there is no icon at the end of the link it is an internal link. Making them big would disrupt the reading I am afraid and also mess up the line spacing. We want the article to be as readable as a book. I think that once you familiarize yourself with the wiki structure you will have no problem distinguishing internal and external links.

Dale

dgatwood
03-25-2013, 02:25 AM
Before giving up with dropcaps and embedded fonts, I had a last try which finally worked. I dumped my embedded fonts (which were a subset created using Font Squirrel) and installed the heavy full ttf regular and italic fonts.

This time everything was OK. The display of the dropcaps was perfect.

So Kobo is very sensitive to both the name and nature of your embedded fonts. Much more so than ADE and most of other readers. Can we say: "If your embedded fonts works on the Kobo, they should work everywhere..." ?


Not necessarily. Sony Reader has an interesting font-related quirk that probably doesn't reproduce on Kobo.

Regarding your problem, I suspect something went subtly wrong in your subsetting process, like glyphs being removed from the file without removing matching lines from the calt table or some other alternate glyph table or kerning table or....

JSWolf
03-28-2013, 12:45 PM
In real life, I've no idea why any Kobo owner would ever need to embed a main body text font as it's a lot less effort and disk space (not to mention more flexible), to just use the font menu.

It's not the Kobo owner doing the embedding. It's the publisher doing it. And in most cases, it is done via the body CSS style.

For example, the book 11/22/63 uses embedded fonts and very well too. But the main font used is selected in the body style. The book uses a number of different fonts and the eBook follows this to give a similar look and it works very well. This is a case of yes, you do want the embedded fonts as overriding the fonts will not work as well.

I do sometimes embed when the eBook has enough smallcaps and I want them displayed correctly and not simulated. I also have been using Calibre's font subsetting to make the size of the embedded fonts much smaller and it works very well.

jackie_w
03-28-2013, 06:43 PM
It's not the Kobo owner doing the embedding. It's the publisher doing it. And in most cases, it is done via the body CSS style.

For example, the book 11/22/63 uses embedded fonts and very well too. But the main font used is selected in the body style. The book uses a number of different fonts and the eBook follows this to give a similar look and it works very well. This is a case of yes, you do want the embedded fonts as overriding the fonts will not work as well.

I'm surprised you are using this book to make your point. I have a copy of it and, as I'm sure you know, the embedded font for main body text is 'Garamond 3 LT Std' which, in my personal opinion, is way too light on an eink device.

Nevertheless if I want to read it in this spindly font all I have to do is select 'Document Default' from the font list -- as I believe I already said above. In what way is this a 'bug'?

In real life I will select one of my own sideloaded darker fonts from the font list. I can even choose one which is similar to Garamond if I wish.

Whichever of these 2 methods I choose, all the other (30 or so) special fonts embedded in this epub display exactly as the publisher intended.

I do sometimes embed when the eBook has enough smallcaps and I want them displayed correctly and not simulated.

Me too. I currently have no problem embedding a small-caps font, or preferably, css-referencing a sideloaded one on my Kobo Glo.

The Kobo has several quirks/faults but in my experience to date, custom fonts is one of its greatest strengths not weaknesses. To repeat myself, I do not experience the 'bug', which I have seen you quote in multiple threads, on the epub you yourself quote as a prime example of the bug. Do you actually have access to a Kobo to test these bug theories or is it guesswork?

FunkeXMix
05-16-2013, 04:28 PM
I can add that Kobo does not support relative size values for images like width:80% or height:80%. All images will be shown at full size if smaller then the screen resolution or shrink to fit if the image is larger.

It's terrible!

I only tested with the Kobo app. Can anyone confirm this is true for actual Kobo e-reader devices?

TheArtfulDodger
04-15-2014, 12:46 PM
Hello:

I am trying to come to grips with keeping HTML tables all on the same page in a Kobo ePub. That means I need a solution to the problem of conditional page-breaks.

I have tried to use 'page-break-before: avoid' with <div>, <span>, <object>, as well as several other things but everything seems to be ignored by the Kobo firmware.

I am hoping that someone knows the secret to the conditional page-break problem.

Thanks in advance,

Sparky