Welcome to the VanDyke Software Forums

Join the discussion today!


Go Back   VanDyke Software Forums > Secure Shell

Reply
 
Thread Tools Display Modes
  #1  
Old 07-21-2005, 11:23 AM
jimserio jimserio is offline
Registered User
 
Join Date: May 2004
Posts: 4
ASCII characters problem

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.
Attached Images
File Type: png scrt500b845.png (36.5 KB, 1145 views)
Reply With Quote
  #2  
Old 07-21-2005, 08:03 PM
MrC MrC is offline
Registered User
 
Join Date: Mar 2004
Posts: 216
Its also a font property. Set the font to the "Terminal" font.
Reply With Quote
  #3  
Old 07-22-2005, 12:13 PM
jimserio jimserio is offline
Registered User
 
Join Date: May 2004
Posts: 4
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.
Reply With Quote
  #4  
Old 07-22-2005, 12:48 PM
MrC MrC is offline
Registered User
 
Join Date: Mar 2004
Posts: 216
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.
Reply With Quote
  #5  
Old 07-22-2005, 03:28 PM
jimserio jimserio is offline
Registered User
 
Join Date: May 2004
Posts: 4
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?
Attached Images
File Type: png scrt51-linux+terminal.png (36.0 KB, 739 views)
File Type: png scrt51-xterm+terminal.png (36.1 KB, 589 views)
Reply With Quote
  #6  
Old 07-22-2005, 05:47 PM
MrC MrC is offline
Registered User
 
Join Date: Mar 2004
Posts: 216
Jimserio,

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

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

cat sample.txt

You should have line art. Report back your findings.
Attached Files
File Type: zip sample.zip (1.9 KB, 390 views)
Reply With Quote
  #7  
Old 08-03-2005, 10:14 AM
jdev's Avatar
jdev jdev is offline
VanDyke Technical Support
 
Join Date: Nov 2003
Location: Albuquerque, NM
Posts: 930
Quote:
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.
screenshot
jimserio,

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?
__________________
Jake Devenport
VanDyke Software
Technical Support
YouTube Channel: https://www.youtube.com/vandykesoftware
Email: support@vandyke.com
Web: https://www.vandyke.com/support
Reply With Quote
  #8  
Old 01-05-2006, 12:48 PM
bprager's Avatar
bprager bprager is offline
Registered User
 
Join Date: Oct 2005
Posts: 3
still not happy

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!
Attached Images
File Type: png terminal.png (54.1 KB, 614 views)
File Type: png LuxiMono.png (80.3 KB, 528 views)
Reply With Quote
  #9  
Old 01-05-2006, 02:24 PM
jimserio jimserio is offline
Registered User
 
Join Date: May 2004
Posts: 4
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?
Reply With Quote
  #10  
Old 01-06-2006, 09:00 AM
tnygren's Avatar
tnygren tnygren is offline
Registered User
 
Join Date: May 2005
Posts: 1,408
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
encoding.

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 support@vandyke.com with a subject of
ATTN: Teresa Forum Thread 921
__________________
Thanks,

Teresa

Teresa Nygren
Reply With Quote
  #11  
Old 01-06-2006, 10:29 AM
tnygren's Avatar
tnygren tnygren is offline
Registered User
 
Join Date: May 2005
Posts: 1,408
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?
__________________
Thanks,

Teresa

Teresa Nygren
Reply With Quote
  #12  
Old 01-06-2006, 12:12 PM
bprager's Avatar
bprager bprager is offline
Registered User
 
Join Date: Oct 2005
Posts: 3
yes, but this is not UTF-8 encoding

Tnygren,

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:
http://www.cl.cam.ac.uk/~mgk25/ucs/e...UTF-8-demo.txt

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. ;-)

Thanks,
-- Bernd
Reply With Quote
  #13  
Old 01-06-2006, 02:26 PM
jdev's Avatar
jdev jdev is offline
VanDyke Technical Support
 
Join Date: Nov 2003
Location: Albuquerque, NM
Posts: 930
bprager,

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 support@vandyke.com with a subject of "VanDyke Forum: Thread #921".

--Jake
__________________
Jake Devenport
VanDyke Software
Technical Support
YouTube Channel: https://www.youtube.com/vandykesoftware
Email: support@vandyke.com
Web: https://www.vandyke.com/support
Reply With Quote
  #14  
Old 01-06-2006, 03:21 PM
bprager's Avatar
bprager bprager is offline
Registered User
 
Join Date: Oct 2005
Posts: 3
i am confused

Jack,

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
Reply With Quote
  #15  
Old 01-10-2006, 05:15 PM
jdev's Avatar
jdev jdev is offline
VanDyke Technical Support
 
Join Date: Nov 2003
Location: Albuquerque, NM
Posts: 930
bprager,

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?

--Jake
__________________
Jake Devenport
VanDyke Software
Technical Support
YouTube Channel: https://www.youtube.com/vandykesoftware
Email: support@vandyke.com
Web: https://www.vandyke.com/support
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 05:53 PM.