ScreenWriter doesn't handle wide characters nicely

[GoogleCodeExporter]

In particular I was trying to use 옷 to represent a users position but it gets 
cut off.

Original issue reported on code.google.com by medwa...@walledcity.ca on 29 Jul 2013 at 9:27

[GoogleCodeExporter]

Yes, this is a known issue, notably affecting CJK characters as well. I'm 
trying to come up with a proper way to handle them but it's a bit ticket to get 
it right.

Original comment by mab...@gmail.com on 30 Jul 2013 at 6:53

• Changed state: Accepted

[GoogleCodeExporter]

By the way, are you using the SwingTerminal or a 'proper' terminal emulator?

Original comment by mab...@gmail.com on 3 Aug 2013 at 5:44

[GoogleCodeExporter]

Sorry, about the delayed response:
To your first comment - oops I forgot to check the ticket backlog. My bad, lets 
just mark this as a dup then? I'd also point out that this isn't limited to CJK 
characters, there are lots of cool unicode characters that are doublewidth 
(most of these I believe: http://en.wikipedia.org/wiki/Miscellaneous_Symbols )

As for my Terminal, I just use TerminalFacade.getScreen() since I didn't 
completely grasp the difference between different Terminal subclasses.

From the Investigate CJK characters it sounds like if I switch to SwingTerminal 
I will get better behaviour? 

Original comment by medwa...@walledcity.ca on 3 Aug 2013 at 8:14

[GoogleCodeExporter]

Nah, what I mean is, when you run your application, do you use the 
SwingTerminal that is supplied with lanterna or do you run your application in 
a 'proper' terminal emulator like Putty, gnome-terminal, Terminal.app or 
something like that?

Original comment by mab...@gmail.com on 21 Aug 2013 at 12:50

[GoogleCodeExporter]

Just looked at the Wikipedia page, that's quite a set of odd characters! We 
should definitely make the code treat them as double-wide, but as I pointed out 
before, the whole system is not completely tuned to deal with such yet. Since I 
didn't realize double-width characters existed until much later, most of the 
codebase assumes that one char = one column. Hopefully I can get it right in 
the 3.x version.

Original comment by mab...@gmail.com on 21 Aug 2013 at 12:54