EPUB output - Page 22

Coolmicro · 01-31-2009, 12:14 PM

Hello,
I say HTML, and not XHTML.
It's not possible to produce good XHTML with ODT or DOC files. And the HTML produced by OpenOffice or Word is not good for Epub.
Also, we chose format ODT to convert towards the format epub, for the reasons explained above.

(PS: I am French, I cannot describe the problems of conversion into XHTML, with OpenOffice for example, they is too complicated for me in English)

llasram · 01-31-2009, 02:46 PM

Quote:

Originally Posted by Coolmicro

It's not possible to produce good XHTML with ODT or DOC files.

Ah, I see our confusion, perhaps? EPUB content is XHTML, so to produce EPUB from ODT, calibre first converts it to XHTML. Any EPUB validity errors are either in the generated XHTML or are errors which would happen no matter what the input format is.

Vintage Season · 01-31-2009, 04:24 PM

Quote:

Originally Posted by Xenophon

Does the current ePub conversion capability support embedded fonts? If not, could it be added easily? Alternatively, could someone with a Mac and a PRS700 figure out how to get the change-of-font-via-css-file trick to work properly? I've struck-out on my efforts in that direction.

Xenophon

Quote:

Originally Posted by kovidgoyal

it doesn't and no its not easy, which is why it hasn't been done yet. It is on my TODO list though, so it will get done eventually

Xenophon (or kovidgoyal, or anyone else who already owns a Sony PRS-505 or PRS-700), would you be willing to try an experiment for me? Here are the steps I took to get TrueType fonts accessibly embedded into .epub files using Calibre, and I have verified that they work using the Calibre reader on several different computers and operating systems that have never had these particular fonts installed, but I do not yet own any electronic-ink devices on which to test compatibility.

If anyone wants to donate a PRS-505 or PRS-700 to me, I'd be happy to test further on this end!

In the book I authored this morning, I used three separate TrueType fonts: David Rakowski's "UpperWestSide" for titles, chapter headings and drop-caps, Monotype Typography, Ltd's "Garamond" and the italicized version of same.

When I originally tried a direct conversion, Calibre would only add the first noted font. In order to convince Calibre to import all the three .ttf files into the .epub, I placed each within its own style element in the XHTML - and I also gave "UpperWestSide" an oblique style, since there were certain places I had artificially italicized the font within the text, although I linked it to the same font file - as follows:

Code:

<style type="text/css">
                @font-face { font-family: UpperWestSide; font-style: oblique; font-weight: normal; src: url(UpperWestSide.ttf); }
</style>

<style type="text/css">
                @font-face { font-family: UpperWestSide; font-style: normal; font-weight: normal; src: url(UpperWestSide.ttf); }
</style>

<style type="text/css">
                @font-face { font-family: Garamond; font-style: normal; font-weight: normal; src: url(gara.ttf); }
</style>

<style type="text/css">
                @font-face { font-family: Garamond; font-style: oblique; font-weight: normal; src: url(garait.ttf); }
</style>

I then placed UpperWestSide.ttf, gara.ttf and garait.ttf in the same directory as the XHTML file, and loaded it into Calibre and converted to .epub.

Next I opened the .epub file as if it were a .zip (no need to rename, just open it in whatever utility you would use to view the contents of any other .zip). Browsing the directory structure I saw that all three .ttf fonts were located in "content\resources," but when I checked the relative path structure in (name)_0.css I discovered that the font links were erroneously pointing to a recursive "resources" directory, as follows:

Code:

@font-face {
    font-family: UpperWestSide;
    font-style: oblique;
    font-weight: normal;
    src: url(resources/UpperWestSide_0_0.ttf)
    }
@font-face {
    font-family: UpperWestSide;
    font-style: normal;
    font-weight: normal;
    src: url(resources/UpperWestSide_0_0.ttf)
    }
@font-face {
    font-family: Garamond;
    font-style: normal;
    font-weight: normal;
    src: url(resources/gara_1_1.ttf)
    }
@font-face {
    font-family: Garamond;
    font-style: oblique;
    font-weight: normal;
    src: url(resources/garait_2_2.ttf)
    }

So I stripped out the "resources/" notation and saved it back into the .epub, such that the .css content now appeared like this:

Code:

@font-face {
    font-family: UpperWestSide;
    font-style: oblique;
    font-weight: normal;
    src: url(UpperWestSide_0_0.ttf)
    }
@font-face {
    font-family: UpperWestSide;
    font-style: normal;
    font-weight: normal;
    src: url(UpperWestSide_0_0.ttf)
    }
@font-face {
    font-family: Garamond;
    font-style: normal;
    font-weight: normal;
    src: url(gara_1_1.ttf)
    }
@font-face {
    font-family: Garamond;
    font-style: oblique;
    font-weight: normal;
    src: url(garait_2_2.ttf)
    }

... all of which is technically violating the .epub spec, but appears to work.

- M.

Coolmicro · 01-31-2009, 04:32 PM

I explain the things badly, in English

The XHTML produced by format ODT, in OpenOffice, is valid. But, when one uses the XHTML produced by a file ODT in OpenOffice (Export) with Calibre, the result is not the same one as when one uses directly format ODT for th same file, with Calibre.

To understand, here 2 pictures, the same text, with ODT, and with XHTML produced with OpenOffice:
Epub Calibre with ODT:
https://www.mobileread.com/forums/att...1&d=1233436953
Epub Calibre with xhtml:
https://www.mobileread.com/forums/att...1&d=1233436953
Appearance is not the same one, the margins in particular (not to take account of space between paragraphs, it is an error which I did)

kovidgoyal · 01-31-2009, 04:50 PM

Quote:

Originally Posted by Coolmicro

I explain the things badly, in English

The XHTML produced by format ODT, in OpenOffice, is valid. But, when one uses the XHTML produced by a file ODT in OpenOffice (Export) with Calibre, the result is not the same one as when one uses directly format ODT for th same file, with Calibre.

To understand, here 2 pictures, the same text, with ODT, and with XHTML produced with OpenOffice:
Epub Calibre with ODT:
https://www.mobileread.com/forums/att...1&d=1233436953
Epub Calibre with xhtml:
https://www.mobileread.com/forums/att...1&d=1233436953
Appearance is not the same one, the margins in particular (not to take account of space between paragraphs, it is an error which I did)

That's because the library used by OpenOffice to convert ODT to HTML is different from that used by calibre to convert ODT to HTML. Genrally speaking (though I haven't tested this) you should get better results converting from ODT to EPUB rather than from the exported HTML to EPUB.

Coolmicro · 01-31-2009, 05:31 PM

Yes, thanks for the explanations.

Have you see ? :
https://www.mobileread.com/forums/showpost.php?p=340175
and
https://www.mobileread.com/forums/showpost.php?p=340250

kovidgoyal · 01-31-2009, 07:11 PM

I'll fix the navpoint problem when I get some time. As for the footnotes, ebook readers typically have a back button to get back from an end note. EPUB is a reflowable format, and there's no real analogue to footnotes ina reflowable format.

tompe · 01-31-2009, 08:38 PM

Quote:

Originally Posted by kovidgoyal

I'll fix the navpoint problem when I get some time. As for the footnotes, ebook readers typically have a back button to get back from an end note. EPUB is a reflowable format, and there's no real analogue to footnotes ina reflowable format.

Not being able to easily find the place in a text that corresponds to a particular footnote is irritating for paperbooks. For electronic books I would assume that this limitation does not exists...

Vintage Season · 02-03-2009, 04:14 PM

Quote:

Originally Posted by Vintage Season

Xenophon (or kovidgoyal, or anyone else who already owns a Sony PRS-505 or PRS-700), would you be willing to try an experiment for me...

... all of which is technically violating the .epub spec, but appears to work.

- M.

Responding to my own suggestion from a few days ago, I finally realized I could simply copy an .epub file to and SD card and test for myself in-store. Much to my disappointment I learned that, although the PRS-505 I tested did successfully recognize and read the .epub, it did not recognize the fonts (probably because they were not extracted from the archive), nor did it honor the full justification I'd specified. Drop-caps worked fine, but that's a small consolation.

- M.

Coolmicro · 02-03-2009, 05:55 PM

For kovidgoyal

Thank you very much to have corrected the bug that I had announced.

kiklop74 · 02-03-2009, 09:20 PM

I just found out how to setup epub file to use standard LRF fonts.

This is the line you need to add to your recipe:

Code:

extra_css = '@font-face {font-family: "serif1";src:url(res:///opt/sony/ebook/FONT/tt0011m_.ttf)} @font-face {font-family: "monospace1";src:url(res:///opt/sony/ebook/FONT/tt0419m_.ttf)} @font-face {font-family: "sans1";src:url(res:///opt/sony/ebook/FONT/tt0003m_.ttf)} body{text-align: left; font-family: "serif1"} .article_date{font-family: "monospace1"} .article_description{font-family: "sans1"} .navbar{font-family: "monospace1"}'

mtravellerh · 02-04-2009, 04:38 PM

Quote:

Originally Posted by kiklop74

I just found out how to setup epub file to use standard LRF fonts.

This is the line you need to add to your recipe:

Code:

extra_css = '@font-face {font-family: "serif1";src:url(res:///opt/sony/ebook/FONT/tt0011m_.ttf)} @font-face {font-family: "monospace1";src:url(res:///opt/sony/ebook/FONT/tt0419m_.ttf)} @font-face {font-family: "sans1";src:url(res:///opt/sony/ebook/FONT/tt0003m_.ttf)} body{text-align: left; font-family: "serif1"} .article_date{font-family: "monospace1"} .article_description{font-family: "sans1"} .navbar{font-family: "monospace1"}'

Errm ... why?

kiklop74 · 02-04-2009, 05:13 PM

Quote:

Originally Posted by mtravellerh

Errm ... why?

Fonts used in rendering epub on sony reader are not the same as fonts used in rendering lrf files. epub fonts support only latin1 characters while lrf fonts contain broader range suitable for most eastern-european languages.
In short this is intended for the people reading texts in non-latin1 languages.

Valloric · 02-05-2009, 03:07 PM

Quote:

Originally Posted by kiklop74

Fonts used in rendering epub on sony reader are not the same as fonts used in rendering lrf files. epub fonts support only latin1 characters while lrf fonts contain broader range suitable for most eastern-european languages.
In short this is intended for the people reading texts in non-latin1 languages.

Can't you simply embed the fonts with Unicode support directly in the epub file?

kiklop74 · 02-05-2009, 05:48 PM

Quote:

Originally Posted by Valloric

Can't you simply embed the fonts with Unicode support directly in the epub file?

Why is embedding font easier than just pointing reader which one to use?

BTW I was not aware that feature is supported by calibre. How do you embed fonts in epub?

01-31-2009, 12:14 PM	#316
Coolmicro Groupie Posts: 195 Karma: 542 Join Date: Jul 2008 Device: Tablette android SmartQ T7 - Nook Touch - Pocketbook 602	Hello, I say HTML, and not XHTML. It's not possible to produce good XHTML with ODT or DOC files. And the HTML produced by OpenOffice or Word is not good for Epub. Also, we chose format ODT to convert towards the format epub, for the reasons explained above. (PS: I am French, I cannot describe the problems of conversion into XHTML, with OpenOffice for example, they is too complicated for me in English) Last edited by Coolmicro; 01-31-2009 at 12:18 PM.

01-31-2009, 04:32 PM	#319
Coolmicro Groupie Posts: 195 Karma: 542 Join Date: Jul 2008 Device: Tablette android SmartQ T7 - Nook Touch - Pocketbook 602	I explain the things badly, in English The XHTML produced by format ODT, in OpenOffice, is valid. But, when one uses the XHTML produced by a file ODT in OpenOffice (Export) with Calibre, the result is not the same one as when one uses directly format ODT for th same file, with Calibre. To understand, here 2 pictures, the same text, with ODT, and with XHTML produced with OpenOffice: Epub Calibre with ODT: https://www.mobileread.com/forums/att...1&d=1233436953 Epub Calibre with xhtml: https://www.mobileread.com/forums/att...1&d=1233436953 Appearance is not the same one, the margins in particular (not to take account of space between paragraphs, it is an error which I did) Attached Thumbnails

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[Old Thread] Epub Output: Line Height	greenapple	Conversion	20	01-27-2013 09:27 AM
EPUB output justification	toki08	Calibre	10	01-08-2011 04:14 PM
Calibre epub output details and Nook	squidward	Calibre	6	11-24-2010 03:21 PM
epub output metadata	troymc	Calibre	5	05-22-2010 12:23 AM
Problem with epub output in Cybook Gen3	fjf	Calibre	3	02-03-2010 02:23 AM

01-31-2009, 05:31 PM	#321
Coolmicro Groupie Posts: 195 Karma: 542 Join Date: Jul 2008 Device: Tablette android SmartQ T7 - Nook Touch - Pocketbook 602	Yes, thanks for the explanations. Have you see ? : https://www.mobileread.com/forums/showpost.php?p=340175 and https://www.mobileread.com/forums/showpost.php?p=340250

01-31-2009, 07:11 PM	#322
kovidgoyal creator of calibre Posts: 45,604 Karma: 28548974 Join Date: Oct 2006 Location: Mumbai, India Device: Various	I'll fix the navpoint problem when I get some time. As for the footnotes, ebook readers typically have a back button to get back from an end note. EPUB is a reflowable format, and there's no real analogue to footnotes ina reflowable format.

02-03-2009, 05:55 PM	#325
Coolmicro Groupie Posts: 195 Karma: 542 Join Date: Jul 2008 Device: Tablette android SmartQ T7 - Nook Touch - Pocketbook 602	For kovidgoyal Thank you very much to have corrected the bug that I had announced.