VanDyke Software Forums

VanDyke Software Forums (
-   Secure Shell (
-   -   ASCII characters problem (

jimserio 07-21-2005 11:23 AM

ASCII characters problem
1 Attachment(s)
I'm trying to display ASCII characters through SCRT. TO my knowledge I have never been able to do this and I've tried every terminal type. I'm sure it's something simple but any help woudl be appreciated. Here's a screen shot of what I get with xterm with ANSI color as the terminal.

MrC 07-21-2005 08:03 PM

Its also a font property. Set the font to the "Terminal" font.

jimserio 07-22-2005 12:13 PM

Thanks for the reply. I have an older version of SCRT on my laptop at home and selecting xterm with ANSI color and Terminal as the font indeed wors as you described.

However, with SCRT5 b845 I still cannot get this to work. I've tried connecting to both a server running OPenSSH and one running VShelld. Any other ideas? I even created a blank (new) session and only changed the terminal type and font. Still the same garbage.

MrC 07-22-2005 12:48 PM

You're welcome.

First, update to the 5.01 !

The graphics characters require that 8 bits of data are being supplied. Be sure that you don't have Strip bit 8 enabled under Emulation->Advanced.

jimserio 07-22-2005 03:28 PM

2 Attachment(s)
OK. Upgraded to 5.0.1. This seems to fix it, or at least it appears like my old SCRT (4.x). But I still think it is missing some of the ASCII characters, such as the borders. Here are two exmaples. The first is xterm with Terminal as the font. The second is Linux with Terminal as the font. See the borders? Those ar emissing with the xterm type. I've tried every other terminal type and I get junk for the rest. Is this the best I am going to get?

MrC 07-22-2005 05:47 PM

1 Attachment(s)

Set your term type to xterm and *then* connect. Ensure that your TERM type is xterm on linux (echo $TERM).

Enclosed is a file. Transfer to your linux box and unzip. Then, cat the file:

cat sample.txt

You should have line art. Report back your findings.

jdev 08-03-2005 10:14 AM


Originally Posted by jimserio
I'm trying to display ASCII characters through SCRT. TO my knowledge I have never been able to do this and I've tried every terminal type. I'm sure it's something simple but any help woudl be appreciated. Here's a screen shot of what I get with xterm with ANSI color as the terminal.


I'm not sure if line drawing is still a problem for you or not, but the graphic you provided displays something that is indicative of line drawing problems that are caused by the Windows operating system treating a font as a Unicode font; notice how the corners of the boxes look right, but everything else seems to be off -- line drawing characters, yes. But not the right ones.

There are a couple of possible resolutions to this problem. One involves a configuration change in Windows, the other involves a configuration change in SecureCRT.

Disabling support for East Asian languages:
When you see line drawing as displayed in the screen shot you provided, it is typically caused by the "Install files for East Asian languages" option being enabled within the "Languages" tab of the "Regional and Language Options" window accessible from the control panel. When this option is enabled, the operating system seems to change how it addresses fonts. From what I can tell, it treats all fonts as Unicode fonts, and since Terminal and vt100 fonts aren't, it displays things wrong when it comes to 8-bit characters such as line drawing glyphs. Disabling the "Install files for East Asian languages" option (might require a machine reboot) should resolve the problem. Sometimes this option is enabled unbeknownst to a user as a result of choosing "Yes" to a prompt you might see browsing a web page that states something along the lines of "In order to view this page properly, fonts must be installed. Do you want to install these fonts now?".

Changing the configuration of SecureCRT:
If you depend on the ability to view East Asian languages and cannot disable this setting, there is a combination of SecureCRT configuration settings that should get line drawing to work properly even with this option enabled. In this case, open the Session Options dialog and in the Appearance category:
  • Ensure that the Use Unicode line drawing characters option is enabled.
  • Set the Font to a TrueType or OpenType font such as Courier New or Lucida Console.

In most cases, if the font is a TrueType or OpenType font (in the Font dialog, this is indicated by an O or a TT icon to the left of the font name) and the Use Unicode line drawing characters option is enabled, line drawing should work well.

Do either of these configuration changes get you to the point where line drawing is working properly?

bprager 01-05-2006 12:48 PM

still not happy
2 Attachment(s)
I followed the discussion because I want to solve that issue for me as well.
I also have been trying for quite a while now. And I am still not happy with the current solution.

It seems that I have to settle with the ugly and hard to read Terminal pixel font to use curses like interfaces (and development is really not fun with that) or I use nice TTF fonts (like LuxiMono) but then I cant have the functionality. (See my attachments.)

Does anybody knows an acceptable (!) font that supports box drawings and that works with SecureCRT and doesn't kill my eyes? And if it even supports UTF-8 ... that would be splendit!

Thanks a lot!

jimserio 01-05-2006 02:24 PM

Still not working
I haven't had much time to look into the problem, even though I still use SCRT daily. If they have come up with a solution I would appreciate it.

Likewise, we are using VShelld server and I get extremly poor sftp x-fer rates with any client except SecureFX. What's that all about?

tnygren 01-06-2006 09:00 AM

Hi Bprager,

There may be a couple of font/line drawing settings that
could work for you.

In the font that you are currently using, have you tried any
other 'Character encoding' options in the 'Appearance'
sub-category under 'Terminal' in the 'Session Options'?

This font does not seem to support UTF-8 as the character

If that does not work, try setting the font to 'Lucida
Console' and the 'Character encoding' to 'OEM'. This does
work on many systems.

If none of these options work, could you send me a raw log
of the connection so that I can see what the remote is
requiring for line drawing?

To create a raw log:

1. Before connecting with the session, select Raw
Log Session from CRT's File menu.

2. In the Select Log File dialog, choose a folder
and filename in which you would like the log
text to be stored and click the Save button.
At this point, if you open the File menu, you
will notice that Raw Log Session now has a
check-mark next to it; this indicates that raw
logging is activated.

3. Now connect to the remote machine and perform the
actions which cause the reported problem to occur.

4. Disconnect the session and select Raw Log Session
from the File menu to turn off the raw log feature.

5. Browse to the location of the raw log file, attach it to
an email sent to with a subject of
ATTN: Teresa Forum Thread 921

tnygren 01-06-2006 10:29 AM

Hi Jimserio,

Getting consistent sftp performance has been a problem since
the beginning of sftp. Things have improved, but there are a
number of variables:

- SSH2 Window size
- SFTP packet size
- number of parallel sftp requests

The best performance is achieved when the client and the
server have made similar assumptions. Thus far, we've been
unable to tweak our clients to perform consistently across a
range of various vendors servers. This same obstacle holds
true for our efforts to tweak our VShell server to perform
consistently across a range of various vendor clients.

Our client and server products are using the same basic
assumptions for SSH2 Window size, SFTP packet size, and the
number of parallel SFTP requests.

Some client will allow for changes to these variables to
help improve the performance.

For example, using OpenSSH, it is possible to adjust the
buffer size (-B) and the the outstanding requests (-R) with
the SFTP command to increase file transfer performance.

However, if the network does not have a high latecy, then
increasing the outstanding requests will not have a
significant impact on performance.

Does this help explain why SecureFX has a better transfer
rate then other clients?

As for the line drawing, do any of the suggestions in my
previous post help?

If not, could you also send me a raw log of the connection?

bprager 01-06-2006 12:12 PM

yes, but this is not UTF-8 encoding

I know what you mean, and yes switching to a different character encoding does the trick. But it's a temporary workaround, since then I have to give up UTF-8 encoding.

You can download a UTF-8 file with box-encoding for yourself:

Go to the very end of the text where the "Box drawing" test is and you see what I mean. I can either make the boxes working or I can see the characters correctly. I can't do it both.

How do I get boxes with UTF-8. Your checkbox in "Appearance"-> "Use Unicode line drawing characters" suggest that it works. I just can't make it. ;-)

-- Bernd

jdev 01-06-2006 02:26 PM


It looks like you are in need of a combination of OEM encoding (for line drawing characters) and UTF-8 encoding (for everything else).

Although this combination isn't currently available in SecureCRT, it has been requested before, and is currently under consideration for being added as a feature to a future version of SecureCRT.

If you would like to be notified via e-mail should this combination be added as a feature to SecureCRT, please send e-mail requesting notification to with a subject of "VanDyke Forum: Thread #921".


bprager 01-06-2006 03:21 PM

i am confused

I'm sorry. I'm not sure what you mean.
I don't really want OEM encoding. I want standard UTF-8 encoding with box-drawing support.

If you open the UTF-8 test document that I posted in a web browser, you can see the UTF-8 characters including the box drawings. That's what I want. UTF has line-drawing characters defined. I would like to use them.
I have not been able to do that with SCRT.

Maybe I need to create a custom termcap to return different characters?
-- Bernd

jdev 01-10-2006 05:15 PM


Thanks for the clarification. I've created an incident in our database for SecureCRT (DEV# 11496) and assigned it to the product director for prioritization.

How many others in your organization are affected by this problem?


All times are GMT -6. The time now is 02:35 PM.