INSTRUCTIONS FOR THE REQUEST "archive paper" >> how to submit a paper to mp_arc by e-mail A paper may be mailed in N parts, with N equal to one or larger (if there are restrictions on the length of E-mail messages on your machine). The request for archiving the first part will only be recognized if it is of the following form: -------------- REQUEST: archive paper PART: 1 of N PASSWORD: justLETTERS FORMAT: LATeX 2e KEYWORDS: comma, separated, list of, keywords AUTHORS: Comm A., Separat E.-D. , l'Ist O.F., Author S. TITLE: Anything found here, on the lines between the two lines "TITLE:" and "ABSTRACT:", is considered the title of your paper. ABSTRACT: Similarly, this should be the first line of your abstract, and this the second line, etc. The following line "PAPER:" marks the end of the abstract. PAPER: Whatever text is found here, between the two lines "PAPER:" and "ENDPAPER:", will be sent out if your paper is requested. This part may begin with instructions on how to convert everything into readable form (see the recommendations below), and it should contain (part 1 of) the body of your paper ... ENDPAPER: This line, and everything below it, will be deleted. The remaining parts should be sent in the following form: ------------------ REQUEST: archive paper PART: M of N PASSWORD: justLETTERS PAPER: The M-th part of your paper goes here. ENDPAPER: The password (which is again required for the request "remove paper") has to be the same for all N parts. All the parts will eventually be combined into one file, as if they had been sent in one piece. **************************** W A R N I N G **************************** * Note that in the above it is important that * * certain input be ON the line describing it, as for "AUTHORS", and * * certain input FOLLOW the line describing it, as for "TITLE". * *********************************************************************** Concerning the syntax ===================== The title, abstract, and paper, are recognized by their position between the lines "TITLE:", ... , "ENDPAPER:". All other lines have to begin with one of the headers "REQUEST: ", ... , "AUTHORS: ", in order to be recognized; and all of these headers should be present (actually, "PART: 1 of 1" may be omitted). To avoid long lines, the (comma separated) list of keywords may be split into several lines, each starting with "KEYWORDS:". Similarly for the list of authors. For example, the following three lines are considered equivalent to the single authors line given above: AUTHORS: Comm A., Separat E.-D. AUTHORS: l'Ist O.F. AUTHORS: Author S. A Note ====== After a paper has been archived successfully, the paper and its abstract and the updated index are available immediately for downloading by others. However, in order to give the author(s) some time to check whether the paper arrived at mp_arc as intended (e.g. by requesting a copy using "send paper" and comparing it to the original) before bringing it to the attention of a large number of people, it will not be listed immediately in our weekly list of new abstracts that is sent automatically to everybody on the mailing list. More precisely, the abstracts of papers that have been archived on Thursday(n-1) ... Wednesday(n) will be sent at the earliest on Sunday(n) around 00:00 a.m. central time. A Recommended Format for Including Instructions =============================================== To assist the reader in viewing or printing your paper, and/or to restore a (systematically) garbled file into its original state, we recommend the following extension to the format given above: whatever goes here ... PAPER: instructions and/or other information BODY the actual paper ENDBODY ENDPAPER: The space (lines) between "PAPER:" and "BODY", which we will refer to as the instruction field, could include instructions on how to prepare the paper for viewing or printing, or information that could help with some of the problems mentioned below. Note: If you submit a paper in N parts, the "instructions ...", the "information ...", and the line "BODY", should be in part 1; and the line "ENDBODY" should be in part N. Otherwise these lines will appear somewhere in the middle of the paper, as the parts get joined after they arrive at mp_arc. If your paper is written in some flavor of TeX, instructions on how to process the file etc. could be embedded directly at the beginning of the "actual paper" in the form of lines starting with a percent sign %. Such lines are ignored by the tex. Some Known Problems and Guidelines for Avoiding them ==================================================== When submitting a paper to the archive, you should keep in mind that the potential readership spans several continents and uses very different machines. Even if you do not have problems submitting a paper, some readers may have trouble receiving or reading it. With most of these difficulties, the best we can do is to mention their existence and suggest ways of avoiding or minimizing them. In addition, we will make available some programs or macros that we have found useful in fixing common problems. For the time being, these "utilities" are stored (and can be requested) like regular papers; their numbers are 90-1, 90-2, etc. Here are some specific problems: 1) There are systems that impose limitations on the size of files that can be transmitted as mail. (The smallest limit we have found so far is 100K.) An obvious cure is to send the paper in several parts. 2) Some old mainframes insist that all lines be 80 characters long and they truncate longer lines or add blank spaces at the end of shorter ones. We suggest that you use your editor to make sure that no line is longer than 80 characters. If blank spaces at the end of a line are meaningful for the formatting program you are using, we suggest that you use special precautions, such as searching with the editor in your machine to determine which lines end up with a blank line and reporting this in the instruction field. 3) For most machines, "carriage return" and "newline" are different characters but some insist on one particular type. For example, MS-DOS insists on having both at the end of a line. If you take the binary pattern of an MS-DOS file and put it into UNIX without any special precautions, it will print with alternating blank lines. This is usually not difficult to correct, but if you are preparing your contribution on an MS-DOS machine we suggest that you pay attention to this problem. 4) Many mailers modify files or get confused by special characters. - Lines starting with a tilde can be a problem. - Lines containing only a period can be a problem. - Lines that start with "From " get modified by many mailers, by adding a special character at the beginning of the line. We recommend that you avoid lines of this type. Any decent editor can search for such lines, and if necessary, you can modify them and report this in the instruction field. When files get garbled by mailers, they tend to get garbled in a systematic way, and it is often possible to restore a file into its original state if the sender included some additional information. If you submit a paper to mp_arc, you can include things like - The number of characters of "the actual paper". - A checksum for the part "the actual paper". - A list of ASCII codes with corresponding ASCII characters, e.g., ASCII character 33! ASCII character 34" ASCII character 35# ... in the instruction field, to assist the reader in identifying and correcting errors that may have occurred enroute. (The c code for a program "charcount" that generates this type of information can be found among the utilities mp_arc 90-?) If you get many reports that your file has been altered enroute, chances are that this is a problem of your machine, or of an intermediate machine that forwards your mail to mp_arc. In that case we recommend that you use an editor to substitute problem characters by "sentences" such as HEREGOESATILDE that will survive without change and that the reader can convert to the appropriate symbols by using an editor. 5) Many languages include special letters or punctuations which are not included in the ASCII or EBCDIC standards. If your computer (or software) enables you to type and display such characters, the code which it uses to represent such a character may be interpreted and displayed as something different on another computer. If you suspect that your paper contains special codes, we suggest that you include a test pattern such as THIS IS A LEFT PARENTHESIS ( THIS IS A RIGHT PARENTHESIS ) etc. in the instruction field. In case a reader sees different symbols, he/she can use an editor to make the appropriate substitution. 6) TeX and other programs change in time, features become obsolete, and installations differ from one place to another. Generally, changes between different versions of plain TeX have been minor from the point of view of most users. However, old versions of AMSTeX are rather incompatible with newer versions, both in the macros and the styles. If your paper is written in some flavor of TeX, please mention in the "FORMAT:" field exactly which flavor and version was used, e.g. LATeX 2e, AMSTeX 2.1, ... If your TeX file contains \input instructions for reading in macros that may not be installed on most other systems, we recommend that you replace each such "\input filename" instruction by the content of the corresponding file "filename". For fonts that cannot be included this way, and that the reader may not find at a standard TeX distribution site, it would be useful to mention in the instruction field where the necessary files can be obtained (e.g. the e-mail address of the author). Readers that encounter problems with missing macros, styles, or fonts, are encouraged to contact the author. 7) The number of different formats for graphics is much larger than what the average computer user is prepared to deal with. But most users seem to be able to view and print graphics in PostScript format, which has become the de-facto standard. It is possible to include PostScript figures in the the middle of TeX by using psfig or epsfig (which are recognized e.g. by dvips). These macros have semi-official status and come with the standard public domain distribution of TeX for UNIX systems. They instruct tex, or latex, or amstex, to read in the specified PostScript files (containing the figures), and to include them in the resulting .dvi file in a way that is recognized by programs like dvips that can convert .dvi files to .ps (PostScript) files for printing. But before you send such a paper to mp_arc (see below for ways of combining everything into a single file), we recommend that you test out the steps that a potential reader will have to go through in order to view or print your paper. One potential problem is that the PostScript code for the figures can interfere with the one generated from the TeX code. This should not happen if your site has installed all the necessary public domain utilities in the distribution of TeX. But if it does, we recommend that you include the .ps figures as independent files (see below) to be printed separately by the reader. Combining TeX and PostScript Files ================================== For simplicity, let us assume that your paper and figures are contained in 3 files: paper.tex, fig1.ps, and fig2.ps. Before your contribution (paper and figures) can be sent to mp_arc by e-mail, it has to be converted into a single ASCII file (This file may be sent in several parts; but these parts will be recombined into a single file at mp_arc.) In what follows, we describe several possible ways of doing this. They are listed in *** INCREASING ORDER OF DESIRABILITY *** from the point of view of the reader (user of mp_arc). 1) You could (use an editor to) concatenate the various files into a single file, preferably starting with the .tex file (so that the resulting file can still be run through tex, if desired, to obtain the paper.dvi without the figures), and insert an easily visible comment like %%%%% here begins the file fig1.ps %%%%% between the end of one file and the beginning of the next. (It is necessary to mention filenames like "fig1.ps", if the .tex file contains macros for including these .ps files.) Normally, the resulting file can be put "as is" in the field designated for "the actual paper". If you choose this approach, we strongly recommend that you include instructions (in the way described earlier) on how to prepare your paper for printing. 2) An alternative way of combining the .tex paper and the .ps figures into a single file is to use one of the standard archiving programs like tar or zip. If you use tar, we recommend that you compress the resulting .tar file with a program like gzip (which is in the public domain and available for almost any system). The resulting .zip or .tar.gz file has to be converted to ASCII format before it can be sent by e-mail. A standard utility for doing this is uuencode. This approach has the advantage (over the one described before) that it is easier to reconstruct the original .tex and .ps files (especially if there are many), for those readers that are familiar with the necessary utilities. Also, the process of extracting the .tex and .ps files can easily be automated. But the disadvantage of this method is that the resulting file is not suitable for indexing, i.e., a paper encoded this way will not be retrieved when somebody searches for keywords in the mp_arc papers. 3) If you use macros like \psfig or \epsfig (mentioned earlier), the program tex (or latex, or amstex) itself is able to combine .tex and .ps files into a single file. This .dvi file has to be converted to ASCII before it can be sent by e-mail. But instead of using a program like uuencode (which is a possibility), you could use dvips to convert the .dvi file to PostScript. The advantage of submitting a single PostScript file is that most readers will be able to print it without any further processing. But PostScript code (unlike TeX code) is virtually unreadable "as is", and thus it is not well suited for keyword searches. 4) It is possible to include PostScript (or other ASCII) code directly into a .tex file, in such a way that when the reader processes this file with tex (or latex, or amstex), the embedded PostScript code is written out to .ps files. And if the .tex file also uses macros like \psfig or \epsfig (mentioned earlier), the PostScript figures will be directly embedded in the .dvi file. A macro called \psdump for writing PostScript files from within TeX, and a Unix shell script "texpsinclude" that automates the task of combining your original .tex file and .ps figures into a single .tex file (using psdump), can be found among the mp_arc utilities (papers 90-?). The advantage of this approach is that the reader only needs to know how to process a .tex file, and that this .tex file is also suitable for keyword searches. A Final Note: mp_arc uses a program that tries to convert incoming ------------ papers automatically to (gzip-ed) PostScript files, which are made available to mp_arc users (via www and ftp), in addition to the original file submitted by the author(s). This program is prepared to deal with papers that include figures in any of the formats mentioned under 2),3), and 4) above. If the program encounters problems, the paper may get converted only incompletely (e.g. without the figures), or not at all.