![[IUCr Home Page]](../iucr-top/logos/iucrhome.gif)
![[Crystallographer's Guide to Internet Tools and Resources]](intguide.gif)
Nearly all conferences nowadays, even local ones, have some Web presence. Roughly speaking, there are four levels of presence.
In the following, only level 3 will be considered. See: additional explanations, a short history and some words of caution about this type of W3 posting which is particularly suited to international crystallography meetings.
The instructions for abstract submission
have survived the beating of ACA'95 and IUCr XVII without creating major problems. For IUCr XVII an automatic acknowledgement of receipt presumably alleviated the problem of duplicate electronic submissions.
Viruses: Those submitting abstracts on diskettes may be
unaware that these can propagate electronic viruses. Abstracts received on diskettes should be
read on a machine different from the workhorse machine for the meeting and the abstract file
then emailed from there to the main machine.
Unrelated to later use on W3, an entry in a database has to be made for each abstract submitted. A commercial database program or a spreadsheet program can be used interchangeably because each can read the output of the other. Duplicate submissions are spotted through alphabetical ordering on the name of the first author and on the title. True duplicates (same name, same t itle, no explanations) are eliminated right away. Other suspicious cases (same name, different titles; same title, names in a different order; resubmissions etc...) are referred to the Program Chair for decision. These suspicious cases should not be eliminated from the database but just flagged as obsolete in a special field. In this way, questions can be answered at a later date.
Desktop publishing of the abstract book for a meeting with hundreds to thousands of abstracts is a major undertaking for a team. The work involves 'detaching' (in PC jargon, 'UUdecoding' in Unix jargon) the word-processor file, numbering the abstract and printing it right away. WordPerfect and Word files can be read and printed by virtually all commercial desktop publishing software. A trace of the abstract will therefore remain even if the electronic file gets lost. But the largest part of the work is in the retyping and proofreading of hardcopy submissions. This part of the work is humongous and should not be underestimated. Fortunately the fraction of hardcopies will decrease as time goes on and electronic submission becomes the preferred means. For ACA '97 in St-Louis the proportion of hardcopies should be around 20%.
For the purpose of electronic publishing, abstracts have to be streamlined first on some word-processor format, Word and WordPerfect being two widely known commercial ones. All commercial word-processors known to the author can produce Rich Text Format (RTF) code. The RTFtoHTML converter will transform this RTF code into fairly acceptable HTML code for the bulk of the abstract, including typography (bold, italics, underlined), simple mathematical formulas, sub/superscripts, figures and the most frequent special characters.
Global replacement macros are run on the generated HTML file to take care of additional RTF markup which was not translated, e.g. replacement of all RTF strings '{\alpha}' by the HTML equivalent '&greekalpha;' or whatever. After that, there is no way around hand-editing of the sources with an ASCII editor. Rare instances of residual RTF markup are easily spotted by searching for the '{' and '\' characters, and then taken care of. This is much less work than it sounds.
The HTML abstract is then stripped by hand from its HTML header down to the text of the title. The footer is also stripped, starting from the last line of the abstract. At close time, the abstract is given a customized name relating to the code for the corresponding entry in the general database for the meeting, e.g. "a127.txt" for entry with code #127.
A simple utility program is then written to generate integer numbers in sequence up to a maximum number, construct corresponding possible file names, open the file, and output an error message if the file is not found. A standard header is added by the program at the top of the file, and a standard footer at the bottom. The header/footer can contain fixed data like: <img src = logo.gif>, in order to introduce a logo or a fixed hyperlink, or data customized for the entry like <A HREF="index.html#a127">index</A> which will install a working button to a name index or a title index, and position this index file at the right place. Viewing of the abstract and very minimal additional hand-editing will then produce a uniform-looking result.
The indexes with working HTML anchors and hyperlinks are produced from the database with all the submission information by outputting the desired data in the standard TAB-delimited format, and then global replacement with a macro of the delimiting TAB characters with space characters. Alphabetical lists of properly printed names, including special HTML characters, are produced by maintaining two fields for each name, one with the HTML code for the name and the other with the name reduced to its 25-letter alphabetical equivalent. E.g. the two fields for "de Médoc, François" would be: "de Médoc, François", and "medoc francois". Alphabetization of the list (a standard function of spreadsheets) is performed on the second field while the first field is output, ensuring that "de Médoc" is properly spelled and alphabetized under "M" as it should.
A Web site cannot prompt potential viewers about its existence or about major updates. This is best achieved with email messages sent at crucial times.