EPUB output

[starrigger]

Originally Posted by kovidgoyal

The cover inclusion bug will be fixed in 0.6. The hyphen problem is a problem in the HTML itself. If you open the HTML in an edior, you will see that the hyphen character is not correctly encoded. This probably happened either when you pasted it into Word or converted from rtf to html

Hm. I see that the hyphen is rendered in html as ‑ which means, I know not what.

But the conversion to LRF correctly renders it as a hyphen. Why does LRF do it but not EPUB?

EDIT: That's interesting. I put in "‑" but it showed up on the board as a hyphen.

EDIT OF EDIT: Dang. How do you display an HTML entity here? I'll spread it out: & # 8 2 0 9 ;

[kovidgoyal]

Ah my mistake, it is a hypen, but a special hypen, a "non-breaking hyphen" ADE evidently doesn't have the fonts to display this character correctly. If you view the EPUB in calibre it should be fine

[nrapallo]

Originally Posted by starrigger

EDIT OF EDIT: Dang. How do you display an HTML entity here? I'll spread it out: & # 8 2 0 9 ;

It's sufficient to use just once space, as: & #8209;

[starrigger]

Originally Posted by kovidgoyal

Ah my mistake, it is a hypen, but a special hypen, a "non-breaking hyphen" ADE evidently doesn't have the fonts to display this character correctly. If you view the EPUB in calibre it should be fine

Nope, in Calibre, it displays as a black vertical bar.

Actually, I use nonbreaking hyphens all the time in my manuscripts (to keep -- dashes from breaking), and need to remember to convert them back at the end.

Could the conversion to epub be made to convert these to regular hyphens? Either the LRF conversion does that already, or the viewer handles it. (I haven't tried in on the Reader yet.)

[starrigger]

Originally Posted by nrapallo

It's sufficient to use just once space, as: & #8209;

Ah--thanks.

[nrapallo]

Originally Posted by starrigger

Nope, in Calibre, it displays as a black vertical bar.

Actually, my text editor cannot handle that UTF-8 encoded character and also displays it as a "black vertical bar".

To be able to re-edit the .epub, it would be better to retain the HTML entities ( like & #8209; ) instead of their UTF-8 / Unicode counterpart.

When all else fails, I've used the 'recode' unix command to convert all such UTF-8 characters back into HTML entities; that my text editor does understand.

[kovidgoyal]

Originally Posted by starrigger

Nope, in Calibre, it displays as a black vertical bar.

Actually, I use nonbreaking hyphens all the time in my manuscripts (to keep -- dashes from breaking), and need to remember to convert them back at the end.

Could the conversion to epub be made to convert these to regular hyphens? Either the LRF conversion does that already, or the viewer handles it. (I haven't tried in on the Reader yet.)

Works for me in the calibre viewer. (But the fonts for the calibre viewer on windows are different, so probably that's why it doesn't work for you). The conversion of non breaking hyphens will be in the next release.

[kovidgoyal]

Originally Posted by nrapallo

Actually, my text editor cannot handle that UTF-8 encoded character and also displays it as a "black vertical bar".

To be able to re-edit the .epub, it would be better to retain the HTML entities ( like & #8209; ) instead of their UTF-8 / Unicode counterpart.

When all else fails, I've used the 'recode' unix command to convert all such UTF-8 characters back into HTML entities; that my text editor does understand.

The problem is many epub readers get confused by numerical entities, plus they increase file size.

[nrapallo]

Originally Posted by kovidgoyal

The problem is many epub readers get confused by numerical entities, plus they increase file size.

Thanks Kovid. That explains a lot to me!

I recently had to re-edit a .epub created by calibre and had difficulty editing some minor textual changes no matter what I tried, using my so-called unicode compliant text editor, TextPad. It just didn't know how to handle those UTF-8 encoded characters. That's when I used 'recode' to solve this re-editing problem I encountered.

Thanks again, and it's a much better answer than " It does that? "

[starrigger]

Originally Posted by kovidgoyal

The conversion of non breaking hyphens will be in the next release.

Excellent.

[thawk]

hi, kovidgoyal

I found a bug relatived to encoding.

I has a txt file with gbk encoding, so I use any2epub with --encoding gbk. Any2epub convert the txt from gbk txt to utf-8 html, it's ok. But, in the second step, any2epub pass the original encoding opts (gbk) to html2epub, so the final result is wrong.

I think changing the encoding opts to utf-8 before calling html2epub should fix it.

[kovidgoyal]

Will be fixed in next release.

[ilovejedd]

I tried searching but I couldn't find the relevant information. How do I use multi-byte UTF-8 characters via command-line?

I tried html2epub -t "u'title" but that didn't work.

[kovidgoyal]

it depends on the level of unicode support in terminals in your OS. Basically you have to encode them in the encoding supported by the terminal and hope calibre correctly decodes them to unicode

[ilovejedd]

In that case, it's probably none as I'm using Windows XP. Thanks for the help. Guess I'll just have to convert titles to ASCII.

By the way, I was just checking the online manual (*gasp* yes, I read the manual ) and I noticed the conversion options have changed. I looked at the changelog and didn't see any comments regarding the change. Has this been implemented yet? Currently, I'm still using older versions (0.4.143, 0.5.3, 0.5.8, basically whatever was out at the time I rebooted my computers) and I have a bunch of PHP scripts that rely heavily on the Calibre command-line utilities so I can't just upgrade arbitrarily.