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.
Last edited by roger64; 03-17-2013 at 09:04 PM.
|