Re: compression/conversion

[jefbla@bconnex.net (Jeff Blakeney)]

On 22 Jan 1997 00:18:13 GMT, rubywand@aol.com wrote:

>     As explained in FAQ 2.4 and the BINSCII docs, the main purpose of
>binscii-encoding is to protect files, usually .SHK file archives, from
>being messed around when transmitted via email or to sites which may not
>handle plain binary files correctly.
>
>     The up-side is that the technique usually works. The down-side is
>that binscii-encoding (1) increases file size,  (2) necessitates using a
>binscii decoder on the file when it is downloaded, and (3) makes it harder
>to verify correct uploads using simple original vs. uploaded file-size
>comparisons. 

BINscii is very convenient for posting to comp.binaries.apple2 and for
e-mailing to other Apple II users.

Yes, it increases the file size but at least the file gets through
without losing one out of every eight bits.

Yes, you must use BINscii to decode the file but then again, you have
to use ShrinkIt to uncompress .SHK files as well.  No big difference
there.

And your third point is irrelevant if BINscii is used for what it was
intended.  Transmission of 8 bit data over a 7 bit connection.  When
you post a BINscii file to comp.binaries.apple2 or send it via e-mail,
there is no way to check the size of those messages so you can't check
it against the original file anyways.

>     Today, most .SHK uploads go to ftp sites which, typically, have no
>problem  handling binary files. Binscii-encoding is not necessary. Users
>just need to remember to set "binary" mode when uploading an .SHK file and
>"ascii" mode when uploading text files they wish to be viewable on-line.

Agreed.  The exception here is ftp sites that archives the BINscii
posts that are made to comp.binaries.apple2.

It would be nice if the operators of those sites would unBINscii them
before putting them on their ftp sites but I'm sure they probably have
other things to do so I don't really blame them.  Besides, the person
posting the BINscii file should also be uploading a non-BINscii
version to the ftp sites anyways.

>     Another, generally, unnecessary practice is the use of Binary II
>"wrappers". ShrinkIt preserves all file type information in .SHK file
>archives and the .SHK file itself does not need to have its file type
>preserved.

I disagree here.  I want all the files on my machine to have the
correct file type.

When I tell the Finder to display files by type, I like to have all my
NuFx archives listed together.  I don't want some as ASCII text files,
some as Binary files and some as Unknown.

>     Unlike binscii, Binary II does not change the entire file and the
>size increase is small. Spectrum, ProTerm 3.1, and other telecom wares
>have no problem checking incoming files for Binary II and doing the
>unwrapping automatically.

This is what Binary II was originally intended to do.  Allow Apple II
users to exchange files without losing information such as the file
name, file type, aux type, creation and modification dates and times.
Basically, all the ProDOS directory information about a file is
preserved and when using telecommunications programs that support
Binary II on the fly, the use of it is totally transparent to the
user.

>     Binary II is not a great bother. On the other hand, it does not,
>usually, do anything useful; and, since file size of an .SHK file which is
>"Binary II Up" loaded to an ftp site is changed, it is more difficult to
>get a quick size check.

All that is required to double check the file size is to add 128 bytes
to the original file and compare that to the upload file size because
that is all that Binary II adds to a file.

Another thing to keep in mind about adding Binary II wrappers it will
cause no problems with ShrinkIt, GSHK or Balloon.  You can unshrink a
Binary II wrapped file as easily as an unwrapped one because they will
automatically skip the Binary II header if one exists.

Gee, I think you struck a nerve.  I have written a message this long
in ages.  :)