Subject: alt.binaries.pictures FAQ - General info
From: [email-masked] (Jim Howard)
Date: Fri, 3 Jul 1992 11:56:12 GMT
Newsgroups: alt.binaries.pictures,alt.binaries.pictures.tasteless,alt.binaries.pictures.erotica,alt.binaries.pictures.erotica.d,alt.sex.pictures,alt.sex.pictures.d

Archive-name: pictures-faq/part1
Last-modified: 9 June 1992

	This is part 1 of the FAQ for the alt.binaries.pictures* hierarchy.  
    This part of the alt.binaries.pictures FAQ contains "general", or
    operating-system independent information.  It answers (hopefully) all 
    the questions you may have about the pictures newsgroups, decoding and 
    encoding techniques, and picture formats.

      For information on your particular system and on specific utilities, 
    consult part 2 of this posting.

    Before posting to these groups for the first time, please check the FAQ
    list (this posting - including part 2), and also read the newsgroup 
    news.announce.newusers, which contains many answers to questions about 
    UseNet in general.

    If you've read previous versions of this FAQ, you'll still probably want
    to read anything that has changed since the last distribution - this is
    a "live" document, and is always getting important information added or
    updated.  Anything that's changed is easy to find, since it's always 
    marked with the notation ">>".

GENERAL RULES OF ABP* ETIQUETTE:
Alt.binaries.pictures.erotica is for erotic pictures ONLY.
Alt.binaries.pictures.erotica.d is for the Discussion of pix in ABPE, etc.
Alt.binaries.pictures.tasteless is for "tasteless", "bizarre", or 
  "grotesque" pictures ONLY.
Alt.binaries.pictures.fractals is for fractal pictures ONLY.
Alt.binaries.pictures.misc is for the remaining types of pictures ONLY.
Alt.binaries.pictures.d is for the Discussion of pix in ABPT, ABPF, ABPM, etc.
>>Alt.binaries.pictures.utilities is for the posting of source or binary
>>  executables of pictures-related software.
Comp.sources.misc is a good place for image-viewing source code.
Comp.graphics is a good place for discussion of image formats.
Alt.graphics.pixutils is for discussion of image format translation.

Throughout the remainder of this document, any newsgroup in the 
alt.binaries.pictures.* hierarchy WITHOUT the '.d' extension (including, but
not limited to alt.binaries.pictures.erotica, alt.binaries.pictures.tasteless,
and alt.binaries.pictures.misc) will be referred to as "the pictures 
newsgroups", and those WITH the '.d' extension (including, but not limited to
alt.binaries.pictures.d and alt.binaries.pictures.erotica.d) will be referred 
to as "the discussion newsgroups".

BY FAR THE MOST IMPORTANT ASPECT OF ABP* ETIQUETTE IS:
The pictures newsgroups are for pictures ONLY (if it's not a picture,
don't post it in any of these newsgroups)!!!!  It has been pointed out
that some sites carry the pictures newsgroups without also carrying the
discussion newsgroups.  This is very unfortunate, as there is often
valuable information contained in the discussion newsgroups that anyone
who frequents the pictures newsgroups would find of interest.  If your
site doesn't carry the discussion newsgroups, complain to your news
administrator!
Note that even this posting is in violation of this etiquette, but does 
so to assure that everyone has the benefit of the information contained 
herein.

Thank you for honoring this age-old UseNet netiquette guideline.

HOW TO GET THIS FAQ:
You're reading it, so you already have it, of course!  But just in case
this is an old version, and you want the latest and greatest, you can
get it by anonymous FTP, or through e-mail by using the services 
available from a couple of mail servers.  For anonymous FTP access, 
you can look on either pit-manager.mit.edu [18.72.1.58] in the directory 
/pub/usenet/news.answers, on archive.cs.ruu.nl [131.211.80.5] in directory 
NEWS.ANSWERS, on cnam.cnam.fr [192.33.159.6] in directory /pub/FAQ, or on 
ftp.uu.net [137.39.1.2 or 192.48.96.2] in directory /pub/usenet.  In all 
cases, you'll want to get one or both of the FAQ parts named as files
"pictures-faq/part1" and "pictures-faq/part2".  Both parts are also 
available on bongo.cc.utexas.edu [128.83.186.13], in the gifstuff directory 
as FAQ.abp.1 for part 1 and FAQ.abp.2 for part 2.
    For e-mail access, send a message to [email-masked] with 
the mail body "send usenet/news.answers/pictures-faq/part1" to get the first 
part, and "send usenet/news.answers/pictures-faq/part2" for the second, or 
e-mail to [email-masked] with "send NEWS.ANSWERS/pictures-faq/part1"
and/or "send NEWS.ANSWERS/pictures-faq/part2" in the body of the message.
***********************************************************************
>>Throughout this file, the "I"s are from the original author 
(Dave Read) unless otherwise expressly noted.
Comments from Steve Quinn are denoted by "S-NOTE:".
Comments from Jim Howard are denoted by "J-NOTE:".

This file is intended to be a general introduction to the pictures
newsgroups, answering some common questions concerning pictures posted 
in those newsgroups, namely how to decode and view them.  It is not, of 
course, possible to cover everything, but I will try to to get as much 
as I can into this file.  If you feel something important has been 
omitted and you know the subject well, please write me so I can 
include the info for future releases.
[J-NOTE:  E-mail should be sent to [email-masked] for these purposes.]

Before you miss an important detail contained in this file, let me
"pre-repeat" that I have tried to make many of the programs mentioned 
in this document available for anonymous ftp at bongo.cc.utexas.edu
(128.83.186.13), in the gifstuff directory.  If you think I've omitted
something important in the viewers-only archive, feel free to let me
know.  Also: there are NO GIF files of any kind at this site!  Save
your time and don't bother looking for them!

[J-NOTE: Articles contained in the news groups in the alt.binaries.pictures* 
hierarchy are available ONLY by subscribing to those groups through UseNet; 
there are no FTP archive sites (with the exception of a.b.p.fractals - see
the "ftpsites" list on bongo), mailing list, or mail servers that allow
access to these articles.  If you want access to the pictures hierarchy, your 
site must subscribe to it;  talk to your news administrator!]

OK... on to the real reason you're reading this document...

TABLE OF CONTENTS
   I.	DOWNLOADING AND DECODING FILES
  II.   COMMON PICTURE TYPES
 III.   ENCODING AND UPLOADING FILES
  IV.   ALTERNATE SOURCES FOR PICTURES/HOW-TO'S OF FTP
   V.   THE "PICTURES NEWSGROUPS" AND THE "DISCUSSION NEWSGROUPS"
  VI.	COMMON PROBLEMS

I. DOWNLOADING AND DECODING FILES

By far the most common method of posting files to the pictures 
newsgroups is the UUENCODE standard.  This program, shipped standard 
with most implementations of UNIX, converts binary files into plain-text 
ASCII files which can be handled by the mail system.  You will need a 
version of UUDECODE before anything else in order to view anything 
downloaded from the net.  If your system does not have a version of 
UUDECODE available, you can get one via anonymous ftp from
bongo.cc.utexas.edu, in the gifstuff/uutools directory.

The format of a uuencoded file consists of an optional "table specification",
which consists of the word "table" alone on a line, followed by one or more
lines containing the characters that will be used in the remaining encoded
data.  Following this, the standard requires the line containing only the text 
"begin <permissions> <filename>" (where "<permissions>" is a three-character 
numeric string, and "<filename>" notes the name of the decoded file - for 
example "begin 640 myfile.gif").  This "begin" line is then followed by 
several lines of approximately 63 characters, all beginning with a capital 
"M", and containing any non-lower-case printing character (and very rarely 
resembles anything but absolute gibberish).  Optionally, one to two lines 
may be blank or contain less than the normal number of characters if those 
lines are immediately before the line containing the "end" notation.  The 
"end" text alone on a line marks the conclusion of the uuencoded data.  Any 
information that does not fit into the above classifications are termed as 
either "headers" or "trailers", and are not intended to be included in the 
information to be decoded.  For example, the following represents a valid 
uuencoded file (although it contains no useful information - don't bother 
decoding it!):

Most decoders are smart enough to ignore anything before the "begin" line 
and after the "end" line.
 
The first step is to save the file you want to view... in most versions
of the newsreader, this is done by pressing 's' followed immediately (no
spaces) [S-NOTE: my rn will allow spaces, though] by a file name.
You will usually be asked if you want to save it in mailbox format;
you should answer 'n'.  [S-NOTE: This is important because files will
get messed up or not saved properly if you choose a mailbox format.  I
don't claim to understand the workings of it.  I think it has something 
to do with the mailbox file getting full and dumping older stuff out.]

In the case of a single-part file, you can now uudecode the file, 
which will create whatever output file is encoded.  You can usually 
tell if it's a single-part file by looking on the subject line; 
standard netiquette is to make something like [03/06] part of the 
subject line, which indicates you're on part 3 of a 6-part file.  If no
numbers are there, you can usually assume it is a 1-part file.  If 
not, feel free to write the poster (directly... please don't waste 
bandwidth by posting) and request that he/she put this info in the 
subject line.  Be nice about it!  Another way to determine if a file 
is a single-parter is if both the uuencode "begin" and "end" lines 
(as outlined above in the description of the uuencode format) are 
included in the file.

For multi-part files, life is a little more difficult.  If all you 
have is a standard UUDECODE program (as opposed to a "smart decoder"), 
you will need to trim the headers and trailers out from the rest of the 
information.  You can either do this by saving each part in its own file 
and editting them separately, then concatenate the editted files together 
to make one big file (this might be your only choice if your editor can't 
handle large files!), or you can save each part in order into one big 
file and then edit all the headers and trailers out from that file.  
Either way, you'll need to run the result through UUDECODE.  You can use 
your favorite text editor to strip out header and trailer information.

There are several "smart decoders" out there that will handle all of
the header/trailer stripping and decoding for you (some will even make
sure that the pieces are in order!) - see part 2 of this posting for 
specifics.

Some articles are actually posted with easy decoding in mind, and contain
UNIX shell script headers/trailers that facilitate easier decoding.  This
is often very helpful, as it saves you a lot of work, and can also provide
error checking not available in a "normal" uuencoded posting.  These
postings nearly always contain instructions on their use, so I won't
attempt to explain all the details here (there's no set "standard" for
this type of posting anyway).

Some news readers have an "extract" capability that greatly simplifies
life by automatically decoding articles - this means you don't have to
go to the hassle of saving to a file and then decoding.  I know that
newer versions of rn, nn, and trn can handle this - check the "man"
page or ask your news administrator to find out if you can let your
news reader do the work for you!

If you're going to download the picture file to a home machine, or move 
it around a network, remember that most outputs are going to be BINARY 
files, so set your transfer protocol accordingly.  [S-NOTE: Please be 
aware that it is the decoded file that needs to be moved around in binary, 
not the encoded one (though I suppose it would work).  Also be aware that 
if you transfer, say, a GIF file in ascii, you won't notice a problem
until you try to view it.  Then you'll be sorry.]

II.  COMMON PICTURE TYPES

OK.  Now you've got this great picture file from downloading it and 
running it through UUDECODE.  What is it, and what do you do with it?

The most common type of picture is the GIF format (which usually has
a .GIF or .gif file suffix).  GIF stands for Graphic Interchange Format, 
and is a standard format for images that was developed by CompuServe to 
be a device-independent method of storing pictures.  It includes 
Lempel-Ziv-Welch (LZW) compression, which makes the files fairly small.

JPEG is another standardized image compression mechanism, which stands 
for Joint Photographic Experts Group (the original name of the committee 
that wrote the standard).  It seems more and more common that JPEG-type 
pictures (.JPG or .jpg file suffix, usually) are getting posted to the 
net.  Some claim that JPEG is destined to overtake GIF format in popularity, 
because it is the most compact method to store 24-bit data, but mostly due 
to the fact that it uses much less space to store the same picture (this is, 
in fact, true - I have seen many examples of this phenomenon).  This may be 
an accurate assessment, but this will probably take a while to happen, as 
most people HAVE GIF software/viewers, but lack JPEG equivalents.  
Undoubtedly, however, this too shall change, but at this point, JPEG is 
recognized as still being in its infancy.  But, if you prefer to be on the 
leading (bleeding?) edge, it is possible to get software both to view JPEG
pictures, and to convert JPEG to and from other formats, as detailed in 
part 2.

The latest and greatest info about JPEG is included in the Tom Lane's
"JPEG image compression: Frequently Asked Questions" (archive name is
"jpeg-faq"), posted on a regular basis to the alt.binaries.pictures.d, 
alt.graphics.pixutils, alt.binaries.pictures.erotica.d, alt.sex.pictures.d,
and news.answers newsgroups.  Some details on JPEG are also included in
part 2 of this posting.

Of course, to view a picture of a particular type, you will need a viewer 
that supports that type (again, for specifics on viewers for your 
particular configuration, see part 2 of this posting).

There are other types of single-picture files posted to the net, 
although they are not as common as GIF or JPEG files.  Other than the 
difference in the viewing software, the downloading/decoding and 
encoding/uploading procedures are identical as for other types of pictures.
Platform-dependent picture types and conversion programs are discussed
in part 2 of this posting.

Occasionally people get into an argument about which standard is best. 
I think the answer is:  WHO CARES?!?  The only thing I have to say 
about this matter is that almost every machine under the sun already 
has a program written for it to view GIF files, and if yours doesn't, 
shareware or PD source code is available almost everywhere.

Commonly people post files to the net with a .GL extension.  These 
files are actually animated picture-shows that can be viewed on a small
number of system types.

Usually, GL files are huge, so people often compress them with one of
several popular compression/archiving packages.  Perhaps the most
common is the PC family's PKZIP package.  If a GL file is posted with
a .ZIP extension, you know it's been ZIP'ed.  Similarly, if it has a
.Z extension, it's been compressed with the UNIX `compress' utility. 
"Uncompression" tools of either type are available for various types of
systems - part 2 has the necessary details.

Files of a .DL extension are also sometimes posted.  These are very
similar to GL files, except in format and in the fact that DL files allow
color "movie" viewing, so of course it takes different software to view 
them (this software is also discussed in part 2).

III. ENCODING AND UPLOADING FILES

A common question that is asked is this one:  what should I post to the 
net?  The basic answer is: anything you'd like to see here yourself!

Before I get into the nitty-gritty of how to post, I should say a few 
things about the loose etiquette of posting.

The first thing is this:  it's probably best to restrict yourself to 
one or at most two images per day.  I know you've got over 600 MB of 
absolutely stunning images that you're dying to distribute all over 
the world.  However, the net gets severely loaded down by these images, 
since they are typically 100 - 300 KB each.  When you post ten of 
them at once, you're transmitting megabytes of data all over the net,
which shows up in the weekly Arbitron ratings when pictures newsgroups
account for something like 50% of the entire net traffic, and 75% of 
the alt.* traffic.  We need to be self-policing if the pictures 
newsgroups are going to avoid being axed by nervous sysadmins.

Second, be sure to give subject lines that are informative, like:
   CRSH+BRN.GIF [02/08]: Plane crash at an air show, 800x600x256
Notice that it includes everything: the file name, what part of how 
many this one is, a short description, and the resolution.  If you 
insist on leaving everything *else* out, at least say the name of
the file and which part it is!
In the "erotica" newsgroups, it's also popular (and often demanded!)
to include the picture subject's gender (i.e. "{male}", "{female}", 
"{both}", etc.).  The gender should be considered as part of the 
minimal set of information in the "erotica" newsgroups, as the addition
of this information to the subject line makes it possible for people to
avoid spending time downloading stuff they don't care about.

Third, in the actual message you're posting, be sure to give at least 
a brief description of what's in it, like:

   CRSH+BRN.GIF   800x600x256 (in 8 parts)

   This is 15th in the series of this plane crash at the Beirut Air Show
   taken at every single conceivable angle.  This one was taken from a 
   photograph by a guy who happened to be standing directly under the
   plane as it came down.  Pulitzer Prize material.  At least the camera 
   was saved.

Also, checksums are nice, for people with access to sum programs.  It 
helps people identify erroneous transmissions.  Usually people say 
things like 

   Checksums: (obtained with 4.2 BSD 'sum' or SysV 'sum -r')
   between 'CUT HERE lines':
      part 1: 76663 9082
      part 2: 78973 1234
   etc...

Finally, if you got the file from some FTP site that was announced 
over the net, don't bother posting it.  5-to-1 odds say that everyone 
and his dog already have it, and we *really* need to be careful about 
wasting bandwidth!  If you're unsure of whether there's any interest 
in it, just post a short message saying: "I have this file.  Mail me 
if you want a copy."  If 500 people say they want one, post it... if 
only one bozo from outer mongolia wants it, it's a sure bet that the 
picture has already made the rounds!  [J-NOTE:  You might consider 
*e-mailing* it to the bozo from outer mongolia instead!]

[J-NOTE:  the same goes if you see a request!  If that same bozo posts 
a request for T2.gif and you've got it and are thinking about posting it,
*MAIL* it to him/her instead!  This will eliminate the problem of the same 
picture getting posted to the net on a weekly basis (and pissing a lot of 
people off in the process)!!!]

OK... on to the how-to's of posting.

First things first:  if you have a GIF file, don't bother trying to
run some compression routine on it... it *won't* work.  LZW compression
(the kind used in GIF files) is a very efficient compression scheme,
and happens to be the one used in many common compression routines
(including the standard UNIX `compress' utility!).  If you try to 
compress a GIF file, it will usually just end up getting bigger. 

OK.  You need to UUENCODE the file.  Find an encoder and encode it!  
If the output file is particularly large (i.e. more than 60 KB), it 
would be wise to split up the encoded file into smaller parts (< 60 KB) 
and then post those.  You can split the file with a text editor if you 
like, or check part 2 for more specifics on splitting utilities.

If you do post a multi-part file, be sure to add lines before and 
after the data that say 'CUT HERE' so that people trimming the headers 
and trailers by hand know where to cut.  A recent addition to the 
etiquette also has you make the lines say 'BEGIN-----Cut Here' and
'END-----Cut Here' at the obvious locations, so that simple AWK and 
PERL scripts can handle multi-part files.  Another nice thing to do is 
to put the part (02/06) numbers in each file.  Again, the afore-
mentioned 'super' uuencode programs will do most of this for you.  It
is important to make the "Cut Here" parts in mixed-case or lower-case
letters; some decoders detect data based on the presence of characters
which belong in the normal uuencoding character set, and they will
choke on lines which are all upper-case, since these lines contain
only characters which belong in the set.  If you mix the cases, these
decoders will do fine...  Remember (if you add "BEGIN" and "END"
keywords) to make "BEGIN" and "END" all caps so existing scripts won't
miss them, and so uudecoders won't choke on them.

Now post the files... and remember to include the neat info mentioned 
earlier, like subject lines that mean something, descriptions, 
checksums, etc...  One thing that has been pointed out to me recently
is that certain newsreaders (NN, for example) sort the articles
alphabetically by title, so subject lines with part numbers get 
displayed and saved in order.  There is an obvious (and common) way to 
torpedo this process: make subject lines which do not follow sequentially.  

An example:
        first article's subject: "plane crash GIF: CRSH+BRN (part 1 / 4)"
  subsequent articles' subjects: "CRSH+BRN (part N / 4)"
These subject lines will not be displayed and sorted correctly by NN.

However, if you change the arrangement a little, like this:
        first article's subject: "CRSH+BRN (part 1/4) plane crash GIF"
  subsequent articles' subjects: "CRSH+BRN (part N/4)"
you will please NN-users the world over.

That's about it for posting!

IV. ALTERNATE SOURCES FOR PICTURES/HOW-TO'S OF FTP

The pictures newsgroups are certainly not the only source for pictures, 
nor are GIF files the only types available (see section II).  The most 
likely place you are to find other pictures is in an archive that is 
reachable via FTP.  FTP stands for File Transfer Protocol, and is a 
program for transmitting files over the network.  To use FTP, you will 
need access to a computer with the FTP program, and a network connection.
[S-NOTE:  Be aware that files on FTP sites will probably NOT be UUENCODED,
so remember to transfer in binary when getting non-text files.]
[J-NOTE:  For the greatest level of detail on FTP, you should refer to
the posting "How to find sources (READ THIS BEFORE POSTING)", which is
periodically posted to comp.sources.wanted, alt.sources.wanted, and 
news.answers.  OR you can execute either 'finger [email-masked]' or
'finger [email-masked]' to get a quick tutorial.  Additionally, it
is possible to get files from anonymous FTP sites via e-mail.  For details
on this wonderful facility, send an e-mail containing the text "help" to
>>[email-masked].  For those of you on BITNET, send an e-mail 
>>containing the text "help" to [email-masked].  Now you too can 
get all sorts of great utilities from anonymous FTP sites using an e-mail 
proxy!]

[J-NOTE:  Due to popular demand, an anonymous FTP site list of pictures-
related "stuff" has now been compiled and is available from bongo in 
/gifstuff/ftpsites.  This list is by no means guaranteed to be accurate
or comprehensive, but hopefully most of the information is valid.  BTW,
this list is a condensed and supplemented version of the Jan. 20, 1990 
revision of Jon Granrose's ([email-masked]) "List of Hosts that 
Accept Anonymous FTP Requests", which is posted regularly to comp.misc, 
comp.sources.wanted, and alt.sources.wanted, and also available via 
anonymous FTP from pilot.njin.net (128.6.7.38).  Any additions or 
corrections would be most welcome and appreciated!]

Most ftp programs will allow you to enter something like 
  ftp wsmr-simtel20.army.mil
which will connect you with the mighty SIMTEL-20 archives at the White 
Sands Missile Range.  Occasionally, you will encounter an ftp program 
that is old enough or slothful enough that it does not recognize 
internet-style addresses like the one above.  In that case, you'll 
need to know the computer's numeric address; for SIMTEL-20
you would enter
  ftp 192.88.110.20 

Once you're connected, you'll have to tell the computer at the other 
end that you want to log in, by entering USER (some machines save you 
this step by *assuming* you want to log in.  What else would you want 
to do?)  When you are prompted for an account name, enter
  anonymous
When it asks you for a password, enter *your* internet address.

Often the machine to which you are trying to connect will be busy 
(i.e. too many anonymous users), in which case the machine will inform 
you of this and throw you off.  Try again later.

Now you're in.  What do you do?  Well, you need to know where the 
files are stored that you want.  If you know this, just 
  cd directory-name
to the directory in question.  Then you can do a DIR to find out
what is in it.  

So you see a file called CRSH+BRN.GIF and you want it for yourself.  
What do you do?  Well, the first thing is to tell the computer on the 
other end that you want it to transmit a binary file.  On most FTP 
servers, entering the magic word TENEX will do this.  If the machine 
doesn't recognize TENEX, try BINARY, or if all else fails, you can 
enter  
  TYPE L 8
Be sure to do this for GIF files or you'll get garbage when you try 
to view them!
[J-NOTE: The difference between TENEX and BINARY is in translation of data
type sizes - if your machine type has different data type sizes than the one
you're downloading from, use TENEX, otherwise use BINARY.  If you're not
sure, try TENEX first (if the command isn't recognized, you're probably OK).]

Now you're ready to grab the files you want.  You have two options: 
you can type 
  get filename
or
  mget wildcard
where wildcard is any UNIX-style wildcard.  MGET will get all files 
that satisfy the specification.

When you're done grabbing files, type QUIT or BYE to log off the remote 
>>machine and return to yours.  Now you're ready to view the picture -
>>no decoding step necessary (neat, eh?)!

A word about anonymous FTP and GIF files.  When you log onto a remote 
machine via anonymous FTP, please try to restrict yourself to no more 
then ten minutes of transmission time, or about five to ten files.  As 
you can imagine, when people discover a new archive of GIF files, 
they are all hot to download every one they can, and often they jam up 
the site for *days*.  You'll notice this effect the first time some 
bozo announces the name of a new GIF archive.  You won't be able to 
get through without persistent efforts over several hours or even a 
day or two.  Then the system administrators of that site notice that 
they have had about $5,000 worth of anonymous FTP over the last two 
days, and revoke the anonymous FTP privilege.  Now every one is 
screwed.

Be considerate; grab only a few files and then let someone else have a 
chance.  This probably won't solve the problem in the long term (still 
everyone and his dog will be ftp'ing into that machine), but at least 
it will spread the wealth a bit.

[J-NOTE:  Most of the non-erotica pictures that appear in postings to the 
alt.binaries.pictures* hierarchy are available from anonymous FTP sites 
(again, see bongo's "ftpsites" list), but this is of course not guaranteed.  

As for anonymous FTP sites for erotica pictures, THEY DO NOT EXIST.  Even if
you find an anonymous FTP site that *appears* to have erotica pictures, it is
merely an illusion.  As the sage once said, "Revel in your illusions, don't 
share them."  The effects of sharing your illusion in this case *ALWAYS*
results in your illusion being rendered non-existent (in one way or another).
For this very same reason, it is considered very poor form to ask someone
else to share their illusions with you.  If you were considering asking for
a list of anonymous FTP sites with erotica pictures -- don't.]

The other most common method for obtaining files is from an archival 
file server.  Most of these work in the following way: you send mail 
to the server's address, with one-line commands in your message, like
   help
   directory \pictures\gif\family-oriented
   send \pictures\gif\family-oriented\CRSH+BRN.GIF
and the requested info is sent back to you at some later time, when 
the server has time to get around to it.

The first step when you discover a server system is to send a HELP
command so you can learn what the commands are for that server.  
However, most servers operate with commands basically similar to those 
listed above.

V. THE "PICTURES NEWSGROUPS" AND THE "DISCUSSION NEWSGROUPS"

These two types of newsgroups work basically the same way as the 
comp.binaries.ibm.pc and c.b.i.p.d groups; one is for posting new 
material, and one is for discussing posts and other issues.

The basic idea is this:  if it is a picture, post it to the appropriate
pictures newsgroup.  If it is *ANYTHING ELSE* ANYTHING ANYTHING ANYTHING 
ELSE (INCLUDING UTILITIES!!), post it to the associated discussion newsgroup
>>or to an appropriate utilities newsgroup (like a.b.p.utilities, for example)! 
The truth is that I feel bad about posting *THIS FILE* to the pictures 
newsgroups, because it is not a picture.  However, the benefits of restricting 
the requests for info far outweigh the detriment of breaking the 
until-recently-unwritten rule.

PLEASE DO NOT POST ANYTHING TO THE PICTURES NEWSGROUPS THAT IS NOT A 
PICTURE OF SOME SORT!!!!

[J-NOTE: How should you react if you notice someone violating this sacred
rule?  Probably the *worst* thing you can possibly do is follow-up to the
offending posting and yourself violate the same rule!  After all, what good
are you doing by bitching about someone violating a rule you ignore yourself?
If you really *must* follow-up, make sure and edit the Newsgroups: line so
that your post is re-directed to the discussion newsgroup.  Another technique
you might try is just ignoring the post - if enough people did this, it's
entirely likely that there would soon be no discussion at all in the pictures
newsgroups, except for the occasional newbie or someone not wise enough to
read this FAQ - and they'd learn eventually.  I suggest the following course
of action, in order of preference:
	1) Respond via e-mail.  Gently suggest that they take discussion to
	   the discussion newsgroup.  Answer the question/request if you can.
	   Suggest that they read this FAQ to get more information and to
	   better understand pictures newsgroup etiquette.
	2) Follow-up only if you can answer the question/request, re-directing 
	   your posting to the appropriate discussion newsgroup (edit the
	   Newsgroups: line).  Suggest that they read this FAQ to get more 
	   information and to better understand pictures newsgroup etiquette.
	3) Ignore the posting.  They'll most likely get the hint eventually.
	4) Follow-up only if you can answer the question/request, re-directing 
	   the follow-ups of your posting to the appropriate discussion 
	   newsgroup (edit the Followup-to: line -- your posting will go to 
	   the pictures newsgroup, but anyone following up to your posting 
	   will go to the discussion newsgroup).  Gently suggest that this 
	   type of posting belongs in the discussion newsgroup, and that 
	   that's where follow-ups have been re-directed.  Maybe even throw 
	   in a small uuencoded picture at the end of your posting, just to 
	   make it "legal".  Suggest that they read this FAQ to get more 
	   information and to better understand pictures newsgroup etiquette.
The more people that respond in a positive way, the fewer the flame wars, and
the more pictures vs. discussion will end up in the pictures newsgroups!]

VI. COMMON PROBLEMS

Well, you've downloaded the file, tried to view it, and got garbage.  
What went wrong?

The two most likely places for something to go wrong are both in the 
transmission of the file.  The first is this:  when you downloaded the 
file to your home computer, did you remember to tell the modem- 
transfer software that you're sending a binary file?

The second-most likely is that you forgot to say TENEX before you 
grabbed the file via FTP.

Either of these will result in mangled files that are unviewable by 
anything known to man.

Also: did you remember to trim off the header and trailer information if
you are/were using a "simple" uudecoder?  The symptom of forgetting to
do this is usually a message something like "short file" from your GIF
viewer.
[S-NOTE: I have also seen a problem where blank lines are left between
parts (or anywhere for that matter) within the 'begin' and 'end' lines
of the uuencoded file.  Uudecode will get through them fine, but some
GIF viewers will choke on the results.  The only blank line I've seen
get by is the one just before the 'end' statement.  Beware of taking
too much or not enough off of the headers and trailers.]

>>Another common problem is this one:  IBM mainframes often use an 
>>EBCDIC character set (yes, there's more than one EBCDIC set!) instead 
of the ASCII set used by everyone else.  This wouldn't be a problem except 
that most ASCII-EBCDIC converters have a bug which mungs the translation 
of several characters, including ^ { } and a few others.  Even this 
wouldn't be a problem except that the particular munging it does is to 
map several of these characters onto the *same* wrong character.  Ooops.

The way around this is not to use uuencode to transfer these files,
but to use xx-encode, which produces files which look almost exactly
like uu-encoded files, but they use a character set which is
IBM-proof.  If you are using an IBM mainframe as your host computer
and you're having trouble decoding files, this is most likely your
problem.  Solution: 1) find a kind soul who is willing to uudecode the
files, xxencode them and send them to you, 2) get the files via FTP,
which should be EBCDIC-proof, or 3) get a better computer that uses
everybody else's character set. :-) 

Almost all of the problems described above can be checked by using
GIFTEST to check the GIF file's integrity on your host machine before
you download it.  I have recently added the source code for GIFTEST to
the archive at bongo.  I highly recommend that you get a copy of this,
even if you only occasionally have problems with your GIF files; it
runs in only a few seconds, and has the potential to save you hours of
download time!

The last and least likely problem is that some mailer somewhere 
actually munged the file.  It happens.  Fortunately, it doesn't happen 
all that often.  When it does (and please check all of the other 
problems *FIRST*), post to the discussion newsgroup and request someone 
to send you their (working) copy.  If enough people post requests of 
this sort, eventually the original poster will usually re-post it.  
If you're the only person with a problem, someone is bound to send you 
the file, and you'll save the net 'hundreds if not thousands of dollars.'
[J-NOTE:  Also, just because you've already read an article doesn't mean
it has vanished off the face of the earth.  It is a fairly simple matter
to get back to articles you've already read (unless your site administrator
has removed them or they've expired).  There are essentially four methods
to accomplish this (examples assume you're using rn):
	1.  Assuming you know the article number(s) of the postings, just
	    enter the article number from within that newsgroup.  Voila!
	2.  Since you probably DON'T know the article number, once you are
	    in the appropriate newsgroup, you can step backwards or forwards
	    through the articles by using "P" (previous) and "N" (next).
	3.  So you don't know the article number, and you don't want to step
	    backwards through 50+ articles - what now?  As long as you
	    remember something from the subject line of the article, you can
	    use regular expressions to search backwards, using the command
	    "?pattern?r", where pattern is the part you remember.  For
	    example, you read an article with the word "howdy" in the subject,
	    then decide later you want to get back to that article.  Just get
	    into the right newsgroup, then enter "?howdy?r" and rn will search
	    back through all the articles you've read to find the last one
	    with "howdy" somewhere in the title.  Not the right one?  Enter
	    "?", and rn will retrieve the next-to-last article with "howdy"
	    in the title.
	4.  You can modify your .newsrc file so that articles are no longer
	    marked as being read (this file usually resides in your home 
	    directory).  This is especially valuable if you forgot the name 
	    of a particular posting, but you know it was in the last ?x?
	    number articles.  For example, if your .newsrc file reads:
		alt.binaries.pictures.misc: 1-2380
	    ...and you know that the article you're looking for was in the
	    last 30 or so postings, you could edit this line to read:
		alt.binaries.pictures.misc: 1-2350
	    ...so that your news reader would think that you hadn't yet seen
	    these articles (of course you'll have to re-sort through many
	    other articles you've already seen, but hopefully you'll at least
	    be able to find the "lost" article!).  IMPORTANT NOTE!!:  If you 
	    edit your .newsrc file, make *absolutely sure* that you aren't 
	    currently running a news reader session - this may munge the 
	    .newsrc file, or cause other undefined or undesirable side-effects.

By using these techniques, you won't have to ask for someone to e-mail you a
copy or to re-post the article, since you already have it and know how to
get back to it!]

-------------------------------------------------------------------------------

HISTORY OF THIS FAQ:  
This file originally began life as the FAQ for alt.sex.pictures, and 
was first created and maintained by Dave Read ([email-masked]).  
Minor changes and a few S-NOTEs to clean it up a bit and make it a little 
more relevant to the alt.binaries.pictures group were made by Steven M. 
Quinn ([email-masked]).  A hierarchy of pictures groups (all under 
alt.binaries.pictures) was put into place in the fall of 1991, and since 
that time, Jim Howard ([email-masked]) has come forward to assist in 
the maintenance of the "new" FAQ.  The maintenance of this FAQ is now the
shared responsibility of Jim Howard, Dave Read, and Steve Quinn.

-------------------------------------------------------------------------------

That's about it for the "general" information.  System-specific 
information is continued in part 2 of this FAQ.  If you have any 
suggestions for things to include in future versions, don't hesitate 
to let me know...

         ~ deej ~              | (If I were expressing Cadence's opinions, )
Jim Howard -- [email-masked] | (they'd probably make me wear a tie...    )
        (^:=             Flames cheerfully ignored.             =:^)
"Did you ever wish kill files were like little electronic voodoo dolls,
 and really did what they said?" -- Perry Ross in rec.scuba