You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Epub files containing unicode work beautifully when epub.py is called without command-line options. They also works perfectly well (at least in unicode locales) when the output is simply dumped to the screen. However, in most cases when dumping the contents of an entire ebook one would probably want to redirect the output, e.g., to a screen reader like less or to a file. The -d option fails in both these cases with the dreaded Python2 ascii codec error:
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-9: ordinal not in range(128)
As explained here, this is because python2 treats printing to the terminal differently than redirecting output.
Solution
I was able to fix this problem by using kitchen.text.converters.getwriter() as suggested in the document above. Normal functioning of the program does not seem to have been affected, and unicode files now work as expected in all cases (including -d).
The text was updated successfully, but these errors were encountered:
dohliam
added a commit
to dohliam/epub
that referenced
this issue
Mar 14, 2015
Epub files containing unicode work beautifully when
epub.py
is called without command-line options. They also works perfectly well (at least in unicode locales) when the output is simply dumped to the screen. However, in most cases when dumping the contents of an entire ebook one would probably want to redirect the output, e.g., to a screen reader likeless
or to a file. The-d
option fails in both these cases with the dreaded Python2 ascii codec error:UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-9: ordinal not in range(128)
As explained here, this is because python2 treats printing to the terminal differently than redirecting output.
Solution
I was able to fix this problem by using
kitchen.text.converters.getwriter()
as suggested in the document above. Normal functioning of the program does not seem to have been affected, and unicode files now work as expected in all cases (including-d
).The text was updated successfully, but these errors were encountered: