#1
|
|||
|
|||
Minor Font Issues
I've just recently begun to evaluate SecureCRT as I realize I am outgrowing PuTTY. So far I am quite impressed. However, I have come across a couple (albeit minor) complaints.
1) When using Courier New font (sorry, I couldn't get used to the vt100 font, I'm just too comfortable with Courier New) and with the "Use ClearType to smooth edges of screen fonts" option enabled, I find that some characters (specifically the 'D' and 'm' get slightly chopped off on their right edges. I actually first thought this was a video driver issue since forcing the SecureCRT to re-paint its window (dragging another window over it) actually fixes the problem for the characters that are currently on the screen. However, after updating to the latest video drivers the issue persists. I've noticed this problem in other applications as well (http://www.ultraedit.com/index.php?n...ewtopic&p=2638) so its probably a Windows thing. However, PuTTY does not exhibit this behavior with ClearType enabled and Courier New font, so it must be fixable. ![]() 2) Again when using Courier New and running an application via SSH that uses Unicode line-drawing characters, SecureCRT renders the line-drawing characters with Courier New's ugly non-line-drawing characters. This of course could be expected as Courier New does not have Unicode characters to properly render what is being asked. However, it would be nice if you could (either automatically or manually) select a separate font to use for rendering line-drawing characters when using a font that doesn't have them itself. This has already been mentioned here in this post: http://forums.vandyke.com/showthread.php?t=384 (#7 in the poster's list). Again, PuTTY handles this somewhat automagically so a solution should be feasible. Please let me know if either of these issues have been addressed in 5.0 beta and I may have to give it a try. Thanks for your time. |
#2
|
||||
|
||||
DaCypher,
Very good points. Both of these issues are still problems in the current 5.0 beta. The second issue that you brought up, has been discussed previously in another forum and Maureen said that she would add it to the development database. In regards to the first issue, I seen/heard that before so I gave it a try and I am seeing the exact same results as you. The alternative is to turn off cleartype, however with the way that cleartype text looks, I don't plan to turn it off anytime soon. (It's way too nice!!!)
__________________
Drew J. Como Highland Visuals & Graphic Design |
#3
|
|||
|
|||
Thanks for your reply. I look forward to any progress on these issues...
|
#4
|
|||
|
|||
Cleartype issue
I just downloaded and tried latest 5.0.3 binary and the problem with ClearType is still there. Are there any plans to address this issue in future?
Thanks, alex |
#5
|
||||
|
||||
Interesting.... I actually had forgotten about this issue.
I'd like to know if this is going to be reviewed as well... :-)
__________________
Drew J. Como Highland Visuals & Graphic Design |
#6
|
||||
|
||||
Quote:
Maureen Last edited by Maureen; 11-02-2005 at 05:49 PM. |
#7
|
||||
|
||||
Maureen,
Yes, this is exactly what I am seeing. If I type the character 'm', it looks correct until I type another character next to it.
__________________
Drew J. Como Highland Visuals & Graphic Design |
#8
|
|||
|
|||
Maureen,
Yes, that is exactly how this happens. |
#9
|
||||
|
||||
Drew and kai,
Thanks for the replies. I have updated the development issue to include this information. Maureen |
#10
|
||||
|
||||
Is there an update on this issue?
I have recently discovered the wonders of ClearType, and as a result I have also discovered this interesting slight-font-glitch problem (SecureCRT 5.0.5). It seems to be a problem with the block cursor slightly overwriting the anti-aliased edge of the preceding character. ClearType probably violates some of SecureCRT's expectations about characters not writing outside their designated glyph size. |
#11
|
||||
|
||||
Font Glitch
There is no update on this just yet, however we are all hoping that this will make it into the latest 5.2 release!
__________________
Drew J. Como Highland Visuals & Graphic Design |
#12
|
||||
|
||||
Quote:
Thanks for following up on this. I'll post a note here as soon as a version with this change is available. Maureen |
#13
|
|||
|
|||
Maureen, did this font rendering issue make the cut for 5.2?
|
#14
|
||||
|
||||
Thanks for following up on this. Unfortunately, it didn't make it into 5.2. After looking into it a little more, it was an even harder problem than initially thought. It's still being considered for a future version and I will definitely post a note here when we have something for you to try.
Maureen |
#15
|
||||
|
||||
However, remember that the hard part is actually over. The most hardest part should be trying to reproduce the issue, which appears that the great folks over at VanDyke were able to do.
The fix.... The fix is the second most hardest part! :-) (Or the third... The second being the fact that Maureen had to tell us that it didn't make the cut for 5.2) Looking forward to the future! I'm sure the fix will be released when it is ready!
__________________
Drew J. Como Highland Visuals & Graphic Design |
![]() |
Thread Tools | |
Display Modes | |
|
|