Xref: bloom-picayune.mit.edu alt.binaries.pictures:4723 alt.binaries.pictures.tasteless:421 alt.binaries.pictures.erotica:9165 alt.binaries.pictures.erotica.d:4984 alt.sex.pictures:11770 alt.sex.pictures.d:8959 Newsgroups: alt.binaries.pictures,alt.binaries.pictures.tasteless,alt.binaries.pictures.erotica,alt.binaries.pictures.erotica.d,alt.sex.pictures,alt.sex.pictures.d Path: bloom-picayune.mit.edu!bloom-beacon!micro-heart-of-gold.mit.edu!wupost!uunet!Cadence.COM!deej From: deej@cadence.com (Jim Howard) Subject: alt.binaries.pictures FAQ - General info Supercedes: <1992Jun19.050103@U2.Cadence.COM> Message-ID: <1992Jul03.050543@U2.Cadence.COM> Followup-To: alt.binaries.pictures.d Sender: usenet@Cadence.COM (Usenet News) Nntp-Posting-Host: cds8613.cadence.com Organization: Cadence Design Systems, Inc. Date: Fri, 3 Jul 1992 11:56:12 GMT Approved: news-answers-request@MIT.Edu Expires: Fri, 31 Jul 1992 00:00:00 GMT Lines: 728 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 mail-server@pit-manager.mit.edu 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 mail-server@cs.ruu.nl 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 deej@cadence.com 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 " (where "" is a three-character numeric string, and "" 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!): begin 666 bogus.file MLEHHWHURHUH %$^4653%#$#&^%$$46^%#^%)LKDUHEWFHIUG^$^#DJIUTE&F^R M&#H:FNP(ENER(*HNFUHDG(&#&B#HY@#(*@YNUF(&$HU$HF(YSAUHIRY(&YHHEU M(*NUFE(YHDH end 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 ftp@piggy.ucsb.edu' or 'finger ftp@ferkel.ucsb.edu' 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 >>ftpmail@decwrl.dec.com. For those of you on BITNET, send an e-mail >>containing the text "help" to bitftp@pucc.princeton.edu. 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 (odin@pilot.njin.net) "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 (readdm@ccwf.cc.utexas.edu). 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 (steveq@umbc5.umbc.edu). 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 (deej@cadence.com) 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 -- deej@cadence.com | (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