Added explicit warning to bit version when scripting is attempted. Fixed crash during Dynamic port forwarding under heavy load Fixed application's failure to upload prior crash for analysis Changes made in version Included ED for host keys, which is now the minimum required on some servers Added support for three new Diffie-Hellman key exchange algorithms : diffie-hellman-groupsha diffie-hellman-groupsha diffie-hellman-groupsha Improved windows 10 DPI scaling using per-monitor DPI version 2.
In short, windows now scale properly when you move them between monitors with different resolutions primary monitor, external monitor, laptop monitor, etc Improved error handling using Windows Error Reporting, allowing a user to capture Changes made in version Thanks go out to John Page aka hyp3rlinx for reporting this.
However, only the last-opened tab session in a window can run the X app, the other tabs get errors. On those rightmore tabs, I also get errors when I run vi or vim "incorrect authentication" popup errors. Is that just a feature of the tabbed interface? Also, after making these changes, when I try to run SFTP, the file transfer window opens then closes immediately. It seems specific to the host it's connected to, not the window or tab. Lisa, Sorry it took me a while to get to this.
I began diagnosing the X problem you described and realized pretty quickly that there indeed was a problem. It's pretty much just as you said. Each new window was stomping on the X11 authentication data for existing sessions. The result was that only the last window opened could use X windows. I've got an update that takes care of that. You can grab it here: www. Normally, though, you would get a message stating that SFTP could not be established, then a graceful exit. I'm sure it's the same root cause.
Thanks, Lisa. Thanks Lisa. If you find out what the problem is, please let me know so I can reproduce here. Press this and you should see the text re-ordered and shaped. The 'Translation' setting you choose should match the character set of the host. If editing is not important, then skip this part. The editor will assume that the text is visually displayed in a LTR manner, but since it is not, the cursor position will become confused and you'll edit data you did not intend to edit Scenario two: Using AbsoluteTelnet RTL and an editor that IS arabic-aware The editor may reverse the text itself, assuming that the terminal will not.
This will allow the editor to set the text order, cursor position, etc Editing should work as expected In any case, I believe there is a workable scenario in there somewhere. Depending on what editor you use, you may have better or worse luck editing text. If you have issues, I'd love to work with you on trying to handle them in the most appropriate way. I don't know Arabic myself, so the capabilities that ARE there have come via requests from users such as yourself.
I look forward to your feedback on the current capabilities. Regards, Brian. I've gone back to test the RTL and shaping functions in 6. Stick with 6. Thx Brian. We tried this and yes, the 6. Does it otherwise fit your needs as an arabic-enabled terminal package? What will you be using it for? We are still testing. Have you considered adding support for Farsi?
Dave Sills. Dave, I've never tested with Farsi data, but AbsoluteTelnet is written to handle most unicode data and displays most things pretty well. Of course, some scripts present additional challenges such as ordering and shaping that require additional processing. There are no character set translations in Absolute that specifically handle legacy Farsi data, but if your data is in UTF8 format, it will at least try.
I'll do some testing and let you know what I find out. Dave, I've been doing some testing with Farsi data and things look pretty good. It's close enough to Arabic that it works pretty much the same, with additional characters as you said.
In my sample data, only one character didn't display, but that's mostly a font issue. I would assume that the PCs used by a Farsi-speaking user would have a selection of Farsi fonts that I don't have, including fixed-width ones required by the terminal client. Thx Brian, Actually, we are trying to avoid Unicode for various reasons. One being that our applications databases use fixed-length text fields, and storing unicode would require 2 data characters per printed character.
So far we're satisfied with the Arabic capabilities of Absolute, and are starting to look for Farsi fonts, e. You can avoid UTF8 if you wish. Win seems to cover both Arabic and Farsi characters. Just set Win in the AbsoluteTelnet options panel and you should be good. As for fonts, Unicode fonts would be preferred.
Internally, AbsoluteTelnet supports only unicode data. The font selection has no effect on the data received from or sent to the host. AbsoluteTelnet will make the proper conversions. The tricky part about fonts is finding one that is fixed-width that the terminal can use. I installed the Persian language interface pack to try to get some additional fonts Fixed-width persian fonts are not easily found. To my surprise, Windows rebooted and the entire interface was now in Persian!
It took me a minute to uninstall it, but I'm back to normal now. Still looking for fonts Dave, I found and fixed the problem in 6. I had incorrectly linked to Fribidi 1 which does not include shaping. Thanks Brian -- I've updated to 6. One other question -- is there a programmatic way within Absolute Telnet to select character sets -- e.
Dave, Sorting is not something that is handled within AbsoluteTelnet. AbsoluteTelnet is just the display. An application that handles Farsi your app written on the host would have to know the proper way to sort items, then tell AbsoluteTelnet what to display where.
Win is just the way to communicate to AbsoluteTelnet which characters to display.
0コメント