info-mac@uw-beaver (info-mac) (12/03/84)
From: <OTHB@SRI-KL.ARPA> There appears to be a problem with the MacTerminal 1.D and BinHex 2.0 talking to eachother when compressed hex files are involved because when SAVING LINES OFF TOP, MacTerminal likes to trim lines of all trailing spaces (except blank lines which it always leaves with one space). BinHex's new compressed format uses blanks in its encoding scheme, and it often produces trailing blanks, all of which are significant. Suggested solutions (in order of preferance): 1. In the next release of BinHex, don't treat trailing blanks as significant. If a compressed line has too few or too many trailing blanks, treat it as though it had the proper number of blanks. (Perhaps even trim all lines when they are created by BinHex thus saving a little space.) 2. In the next release of MacTerminal, treat trailing blanks as significant. (Most hosts are smart enough not to send extraneous blanks.) 3. Warn people that they must us a protocol file transfer (like XMODEM or KERMIT) with compressed BinHex files. While this virtually eliminates errors, it is not supported by all hosts, and can greatly increase transmission times, especially when going through a network. (Other than this minor complaint, BinHex 2.0 works great!, and yes, I do have a release copy of MacTerminal on order.) -Jon Spear -------