View Single Post
Old 07-15-2015, 09:32 AM   #1181
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 8,950
Karma: 6361444
Join Date: Nov 2009
Device: many
Hi jemc,

To be honest, I am not sure how to best work around it. Your cp437 encoding just has no character that represents the copyright character and therefore any attempt to convert to your encoding from full unicode will fail. I have to look to see if the codec automatic output encoding setting allows for fallback replacement of some sort. I know if I convert each string manually in python, it does allow for fallback replacement but that kind of defeats the whole purpose of using the output codecs for sys.stdout

A better long term solution for you may be to get a shell/terminal program that supports the utf-8 encoding. This is standard on all Linux, and Mac OS X systems. There is code in Kindleunpack that enables the Windows cp equivalent to utf-8 but users must enable that encoding for it to work. I have heard that using the windows cp equivalent to utf-8 causes issues on some older Windows systems. I have no idea how well it works on newer Windows 8.1 or later systems.

Alternatively,you could always use the gui as it provides a full utf-8 terminal scroll pane window.

You mentioned a workaround of your own? What is it?

Thanks,

KevinH
KevinH is online now   Reply With Quote