This initial analysis is not entirely accurate. For the correct analysis, follow the discussion in this pull request.
I've looked into this a bit more, and this mojibake is caused by passing UTF-8 line-drawing chars. to ncurses functions which take old-fashioned ASCII text.
For example, take the print_hline and print_vline functions in cursive, which are used to draw horiz. and vert. lines for boxes. These functions pass a UTF-8 char for the bar char. The print_hline and print_vline functions call print_at or print_at_rep which in turn call the backend's mvaddstr(). Which, is wrong.
The curses mvaddstr() or addstr() only accepts ASCII or VT100 line-drawing chars. For writing UTF-8, curses provides different functions: add_wchstr() and mvadd_wchstr(). But, here's the rub: the backends don't implement these functions.
What's to be done, then?
1. The correct solution is to fix both the backend (ncurses, pancurses, ...) and cursive to call the UTF-8 aware functions.
2. As a hack, patch cursive to send ASCII chars. for the glyphs down to the backends instead of UTF-8 ones. This should be trivial to do. I'll do it--if nobody else does it.
