Subject: Re: Possible reduction of HXWZ bandwith

From: Undetermined origin c/o Postmaster <[email-masked]>
Date: Mon, 19 Oct 1992 15:45:03 EDT

This topic has already been discussed before, and there was some sort of
solution been suggested (I assume they were all archived somewhere).
For example, Ya-Gui Wei provided the zW format of HXWZ as an alternative:

>>	You may want to know that CND-CM (HXWZ) has been relayed by
>>	[email-masked] in zW format. (Send a dummy msg
>>	to [email-masked] for subscription).  The
>>	conversion is done on Ultrix and there are people reading it
>>	on PC and Mac. You are right that there has been no end of
>>	line problems reported.

As to whether the compressed format will make the procedure of reading
hanzi text more diffcult? Not really. For unix box, the following is jsut
what you need (kudo goes to Paul Rutter, author of atob).

-------------------------------> cut here <----------------------------
# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#	tarmail
#	untarmail
#
echo x - tarmail
sed 's/^X//' >tarmail << 'END-of-tarmail'
Xif test $# -lt 2; then
X  echo "Usage: tarmail mailpath directory-or-file(s)"
X  exit
Xelse
X  mailpath=$1
X  echo "mailpath = $mailpath"
X  shift
X  echo files = $*
X  tar cvf - $* | compress | btoa | mail $mailpath
Xfi
END-of-tarmail
echo x - untarmail
sed 's/^X//' >untarmail << 'END-of-untarmail'
Xif test $# -ge 1; then
X   atob < $1 | uncompress | tar xvpf -
X   mv $1 /tmp/$1.$$
X   echo tarmail file moved to: /usr/tmp/$1.$$
Xelse
X   atob | uncompress | tar xvpf -
Xfi
END-of-untarmail
exit
-------------------------------> cut here <----------------------------

Of course, if you are uuencoded addict, minor modification can be easily
applied. To further simplify the preprocessing of e-mailed hanzi text,
another shell script can be derived to perform this task automatically,
if your system allows doing so (say, your mailer is sendmail).

Hujie also observed that...
>
> I took cm9210c.gb for testing, and the relative sizes are,
>
> Method			Relative Size
> -----------		--------------------
> GB+zip+uuencode		0.932
> GB+lha+uuencode		0.862
>
> Yes, it saves bandwidth.  But it requires readers to own and operate a
> compressor every time.
>
> Here could be the another way to solve the previous problem, by converting
> the compressed files into self-extract format before uuencode.
>
> Method			Relative Size
> -----------		--------------------
> GB+zip+exe+uuencode	1.485
> GB+lha+exe+uuencode	0.937
>
> You can see that using lha is still a big save.  However, this also limits
> users to a specific machine, for instance, MS DOS or Unix.
>
> Then, to save the bandwidth, HXWZ editors need to distribute more than one
> version of package.  And users need to pick one that fit its plateform.  I
> think it is a pain. :-)!

Not necessarily true, these process can be made quite painless as long as our
honorable hanzi list moderators don't feel uncomfortable to make their list
maintaining scripts a little bit sophisticate (does bitnet's listserv allow
some degree of customization?), and all we subscribers required is just to
specify the desired format (atob/uuencode, tar/zip/lha/compress/binhex,
gb/big5/HZ/zW...whatever) in our subscription requests. By providing more
alternatives to subscribers, many would be benefited, and so does the net
environment (as far as bandwith concerned).

--- Simon
                                           inet: [email-masked]
      .&______~*@*~______&.       m        uucp: ...!bellcore!bcr!csf!syeh
    "w/%%%%%%%%%%%%%%%%%%%\w"    mmm***
      `Y""Y""Y"""""Y""Y""Y'      mm*****   "One day our civilization,
   p-p_|__|__|_____|__|__|_q-q   mm**Y**    sublimation or vanity,
_-[EEEEM==M==MM===MM==M==MEEEE]-_.|..|....  will be over."  -- Zhang Ailing