EPUB output

[JeffElkins]

Originally Posted by thawk

OK.
Embedded fonts is not so useful for CJK, because CJK font set is too large.
Anyway, thanks.

To JeffElkins:
You can try substituting <br> to <p> before using html2epub. I may helps.

I'm doing a s/r for <br/><br/> and replacing with <p>

Unfortunately, unzipping/edit rezipping isn't working. After the rezip the epub is reported as invalid. I seem to remember that the files have to be zipped in a particular order? Recombining the component html files and hitting them with html2epub works though.

[thawk]

Originally Posted by JeffElkins

I'm doing a s/r for <br/><br/> and replacing with <p>

Unfortunately, unzipping/edit rezipping isn't working. After the rezip the epub is reported as invalid. I seem to remember that the files have to be zipped in a particular order? Recombining the component html files and hitting them with html2epub works though.

You should do the s/r before using html2epub.

[JeffElkins]

Originally Posted by thawk

You should do the s/r before using html2epub.

Um, I did

The first thing I tried was unzipping the epub doing the s/r on the html files then rezipping. When that didn't work I unzipped the file(s) did my s/r then ran any2epub against the recombined html, re-creating the book. All is well.

[thawk]

There should be a '<?xml version="1.0" encoding="UTF-8"?>' in metadata.opf.
Without this line, reader and epub-meta will parse the book title with wrong encoding some time.

[kovidgoyal]

Originally Posted by thawk

There should be a '<?xml version="1.0" encoding="UTF-8"?>' in metadata.opf.
Without this line, reader and epub-meta will parse the book title with wrong encoding some time.

I dont see why, utf-8 is the default encoding for XML files and calibre always creates them in that encoding.

[thawk]

Originally Posted by kovidgoyal

I dont see why, utf-8 is the default encoding for XML files and calibre always creates them in that encoding.

Yes, I know that. But, I met the charset problem sereval times.
Most book I had converted are good, but there're 2 or 3 books which book title is incorrect displayed by 505 and the epub-meta. The titles have utf-8 encoding, but it seems that epub-meta treat the title as a sequence of ascii bytes, and re-encode each byte into utf-8.

e.g.
I have a book title '中文版', which utf-8 encoding is e4 b8 ad e6 96 87 e7 89 88,
but the result is epub-meta is 'ä¸*ćç', which is c3 a4 c2 b8 c2 ad c4 87 c3 a7.
I have check the metadata.opf, it's correctly encoded with utf-8. After adding the UTF-8 declaration line to metadata.opf, both 505 and epub-meta display the title correctly.

btw, without the UTF-8 line, 'epub-meta test.epub' display the wrong title to the console. 'epub-meta test.epub > file' reports a error:

Traceback (most recent call last):
File "/usr/bin/epub-meta", line 8, in <module>
load_entry_point('calibre==0.4.104', 'console_scripts', 'epub-meta')()
File "/usr/lib/python2.6/site-packages/calibre/ebooks/metadata/epub.py", line 238, in main
print unicode(get_metadata(stream, extract_cover=False))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 11-19: ordinal not in range(128)

[kovidgoyal]

OK I've added the encoding declaration

Originally Posted by thawk

Yes, I know that. But, I met the charset problem sereval times.
Most book I had converted are good, but there're 2 or 3 books which book title is incorrect displayed by 505 and the epub-meta. The titles have utf-8 encoding, but it seems that epub-meta treat the title as a sequence of ascii bytes, and re-encode each byte into utf-8.

e.g.
I have a book title '中文版', which utf-8 encoding is e4 b8 ad e6 96 87 e7 89 88,
but the result is epub-meta is 'ä¸*ćç', which is c3 a4 c2 b8 c2 ad c4 87 c3 a7.
I have check the metadata.opf, it's correctly encoded with utf-8. After adding the UTF-8 declaration line to metadata.opf, both 505 and epub-meta display the title correctly.

btw, without the UTF-8 line, 'epub-meta test.epub' display the wrong title to the console. 'epub-meta test.epub > file' reports a error:

Traceback (most recent call last):
File "/usr/bin/epub-meta", line 8, in <module>
load_entry_point('calibre==0.4.104', 'console_scripts', 'epub-meta')()
File "/usr/lib/python2.6/site-packages/calibre/ebooks/metadata/epub.py", line 238, in main
print unicode(get_metadata(stream, extract_cover=False))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 11-19: ordinal not in range(128)

[=X=]

Hi kovidgoyal,
I just summitted a Ticket #1287 with the generation of ePUB. It seems any style sheet that has a number as part of the name is not ported over to the final CSS in the ePUB file.

I've attached the original HTML (crated from BookCreator) the final ePUB product and a sample LRF(which does handle the style sheets correctly)

=X=

[ewiplayer]

I don't know where to start on this problem so I'm just going to bring it up and go from there.

I've got a book in CHM format that I obtained to replace the pulp version I've got. I decompress it on my Mac 10.5 box and then give the table of contents to html2epub and it converts it for me. However, loading the file into Adobe Digital Editions or the PRS 700 causes a crash.

Can someone give me a pointer on how to retrieve some better debugging information for this problem?

[kovidgoyal]

Unfortunately, there isn't one. DE doesn't seem to have a "debug" mode. In these situations what I usually do is test the epub file part by part (i.e. remove all the parts and add them back one by one) to try to localize what is causing the problem. Another useful tool is epubcheck.

[ewiplayer]

Too bad Thanks for the info, though... it forced me to dig into the HTML and read it through. The problem came down to horrid HTML with unmatched table tags, and td tags. I assume this was probably blowing the HTML parser's stack to hell.

I fixed one file, though... I don't relish running around fixing a ton of them, as I think there are a lot that have bad HTML in them. I'll have to find a magic program to fix this stuff up - I also don't relish writing one of those... one must exist somewhere.

Thanks again

[kovidgoyal]

htmltidy might do the trick

[ewiplayer]

I'll take a look at that.

Now that the device doesn't crash, however, I see something new. There are 3 pages in that are generated but they all get shown together (page 1-3 of 3). The problem is that what's actually shown is only the top part of what I would see in Safari. The bottom part is cut off (say the last half to two thirds of the text) and scrolling forward and backward takes me to blank pages.

I read through this thread, but I may have missed this issue and/or its workaround.

Is this a known issue with an easy answer already?

[kovidgoyal]

Never seen that issue. Does it act that way in calibre's epub viewer as well?

[ewiplayer]

The doc in the PRS700 does the issue that I already described (page is cut off at the bottom).

The ebook-viewer has some drawing problems with repeating artifacts all over the place but if I force it to redraw it gets the page properly rendered.

Digital Editions chokes on this just like the PRS 700, however. First, it's wicked slow with it, and second pages render the same way... One page with text cut off at the bottom and an attempt to scroll down switches to the next page, which is blank.

I've noticed that most of the pages' entire content is in a table, like this:

<table>
<tr>
<td>
... whole bunch of HTML text ...
</td>
</tr>
</table>

I figure that's probably causing the problem... does that sound reasonable?