Width of Blank Character

[scaret]

Hi I'm using GateOne for a command-line BBS in chinese ( http://nykz.net:8889 )

GateOne is great. In recent years I've tried to create something like GateOne for the command-line bbs, including parsing the CT100 format charachers, socket-to-webosocket agent etc. GateOne has done more than my expectation.

As a Chinese user my questions are:

1. Chinese input is NOT actually effective in GateOne. I notice that while I'm trying to type something in Chinese, GateOne offers an input handler. But while I'm finished typing Chinese and press enter, only the original keyboard characters (a-z) are input.
2. The width of the blank( " " ) is not equal to one of a character, which influence some drawing in characters called ANSIART. They look a little bit strange. I think it may be some CSS problem.
3. Generally Gateone seems to redirect a os command's io into websocket. But actually I use a python file to offer a telnet-command-like. so I use "python XXX.py" in a python-based GateOne, Can GateOne offer an interface to other python module? Or one already exist?
4. Can GateOne run behind an Apache server?
5. Does GateOne offer a pure CT100-to-tags ( \033[m -> <span...>) JavaScript file?

[liftoff]

1. I think this is caused by your IME. In testing with Anthy on Japanese (double-width) characters it is indeed sending the Japanese and not the ascii characters. Can you give me your OS/browser/IME along with what you're typing? I'll see if I can reproduce it. It could very well be a problem with Gate One but I really do think the IME since Gate One will just send what the IME gives it.
2. This is the same problem as Midnight Commander doesn't work #1. The IME isn't sending the double-width space. I get double-width spaces with Japanese using Anthy.
3. Yes you can do this... Just make a plugin that imports/uses your module. There's an Example plugin that demonstrates how to write a plugin. You may need to include some client-side JavaScript to go along with it (i.e. to handle WebSocket actions sent by your server-side Python module). Just take a look and email me directly with any questions--I can help you out.
4. Not with Apache's mod_proxy but it should work with the apache-websocket module (https://github.com/disconnect/apache-websocket). For reference, most of the success I've seen in proxying Gate One has beein with Nginx.
5. I have no idea what CT100 is but your example escape sequence (\033[m) is just an ANSI standard CSI/SGR (aka text renditions) mode setting (originating from vt100). Gate One's terminal.py module can dump to HTML if that's what you're asking. You can grab/process terminal output from a plugin if you so desire. Not sure what you're trying to accomplish though.

[scaret]

1. I'll try to record screen typing something with explanation and upload it somewhere to you later.
2. Sorry, I found it my mistake. The problem is, while a character is bold, it will be a little bit fatter than a normal character, which is not welcomed in monospace-based ASCIIart. I think I can update the css file myself. Thank you.
3. To my surprise that the \033[m-to-tag translation is accomplished in python on the server. I had expected that the \033[m stream is transmitted directly through websocket and parsed by JavaScript, because in my opinion it is all front-end thing.
   What I'm trying to accomplish is that, a user can copy & paste a piece of \033[m stream into an input/textarea, then JavaScript will translate it into tags and render it in another area. Then the user can see & copy the rendered text for his use. I wrote a simple one in JavaScript with \033[XXXm but without \033[A/B/C/D/H/etc. Python version is OK, but server side will be included.

[liftoff]

1. Please do post a recording of what is going on so I can fix whatever is wrong.
2. Let me know if something in the CSS needs fixing... I'll make sure everyone gets the fix.
3. I tried the "parse the terminal output in JavaScript" thing in the past... It didn't work out so well. It has a few problems (in order of importance):

A) Performance; It isn't as fast as doing it on the server. Especially if you have more than one terminal open. This problem gets worse and worse as you increase browser (terminal screen) size.

B) Keeping the terminal in sync with the server (e.g. mode settings) becomes very complicated. Especially if you have a client disconnect and reconnect from a different browser. In order for that to work you basically need to have two terminal emulators: One on the server (to keep track of state) and one at the client. Why write two terminal emulators when you really only need one?

C) It limits what you can do to the terminal output (on the server) before sending it to the client. For example, if you want to capture an image/PDF and display it in the terminal you now have send the whole thing to the client before it can be processed (resized-to-fit).

D) You can't act upon terminal output at the server if the client is disconnected. For example, to page someone when a disconnected terminal has output (this has been in my "Plugin TODO" list for some time).

Having said all that, I have on many occasions experimented with offloading various aspects of terminal processing to the client. Everything from converting the screen/text renditions to HTML (which you are proposing) to full-blown terminal emulation.

If I were going to re-write Gate One from scratch today I'd definitely stick with server-side terminal emulation. JavaScript is really a terrible language for text/stream processing. Also, you run into all sorts of wacky limitations on a regular basis (like not being able to easily convert binary data into something usable in any straightforward way).

[scaret]

I've recorded 2 pieces of videos which you may get from:

http://scaret.in/u/f/scaret/IME.avi
http://scaret.in/u/f/scaret/IME.mp3

http://scaret.in/u/f/scaret/bold.avi
http://scaret.in/u/f/scaret/bold.mp3

I fail to combine the video and audio so you may open them at the same time.

&. thank you for your third comment. For ASCIIart we often copy the article/graph in \033[m from here to there. So maybe it's important that we can copy what we see in a terminal in \033[m format, even a simple one. I tried in the past JavaScript parser too which you can see in:
http://scaret.in/dsw/14/WTerm_0.0.1/
in which you can see the source code the \033[m texts. and another in canvas with a little interaction with a textbox hidden behind ( but maybe not suitable for gateone ):
http://bbs.sjtu.edu.cn/webterm/

[liftoff]

Video #1: I believe this is a bug with Pinyin related to Google Chrome. Someone mentioned this in issue #188 (this, specifically: #188 (comment)). If you use Firefox it should work fine. I have no idea what causes it but I'll see what I can do (I highly suspect it is a bug in Chrome itself).

Also, that crashing thing happens in your program (nykz.py) not Gate One. I took a screenshot of that specific moment when it crashed:

Looks like you're trying to use a variable named 'ss' which doesn't exist.

Video #2: This looks like a font rendering or encoding issue but I can't tell for sure. If you post a .golog (Gate One log capture) of a session where display a bunch of ASCII art like that I can figure it out. Please also post screenshots of what the ASCII art is supposed to look like. It may be a bug in the Ubuntu font itself.

If you can't post such a .golog publicly you can send it (or a link to it) to support@liftoffsoftware.com and I'll be able to get it (but not the general public).

[scaret]

I'm so sorry for mis-reporting the bug, which is all my mistake.
I write nykz.py file to change encoding in vt100 from GBK to utf-8 because the gateone's setting "encoding" act not so well in both input and output of GBK,Chinese. ( forgive me that the blame is lack of testing where the exact problem is, and it seems that I did not do so well either ╮(╯_╰)╭ )

After your suggestion, I downloaded the latest version of FireFox and had a try. IME work very well in FireFox.

about font rendering, in my commonly used terminal, instead of BOLD, a \033[1;31mA represents a red A with rgb #F00 and a \033[0;31mA another dark red A with #F00. If we use a dark red A in a (dark) red background, it should not been. So maybe it's some difference about the theme of terminal.

Recently I'm hunting for a job so I'm a little busy. I think I can read manually vt100 format well to find the difference, but I need some time. I'll send the report to you some time later.

[liftoff]

Since I haven't heard back on this issue I'm going to close it out. Hopefully everything is rendering OK.