Just as the ADASS Conference Series has established itself as an important resource for astronomical software developers, so has the proceedings volume that is produced after each annual meeting. The value of the proceedings has increased in recent years with rise of the on-line version: not only does the Web provide participants easy access to the articles presented, it affords authors opportunities for more sophisticated and in-depth presentations via hypertext links. It is expected that such technological developments will become increasingly important as the Series evolves to better serve a community that must work at the bleeding edge of its field. However, producing even a basic conference proceedings is a time-consuming, detail-oriented process; thus, the process must become easier if we want the proceedings to do more in the future.
As editors of the ADASS VIII conference proceedings, we set out to continue the development of the production process started by previous ADASS editors; in particular, we attempted to package that process into a form that can be passed onto future editors and evolved to accommodate new features. Among our specific goals were:
The result of our development has be distilled into an editors' kit which can be downloaded via our ADASS editors' web page.
Editing duties were divided equally among the three editors. In the first stage, we each took responsibility for a third of the contributions from authors, proofreading them, making traditional types of edits, and correcting layout problems. Some papers required working with the original author to fix problems with length or style. We allowed ourselves some latitude in working with authors; in particular, a fair amount of worthwhile effort was spent helping authors who were not native-English speakers. After the first pass, we organized contributions into parts, and began the iterative cycle of producing the compiled printed version. During this stage, we each took on different, major problem areas uncovered in the first stage--such as, references, tables, and figures--and worked to correct problems for all papers that made up the book. Some of that effort was spent to ``standardize'' some aspect to give the book a consistent presentation. We also put in a fair amount of effort into the author and subject indices: similar entries were resolved and additional terms were added where we thought appropriate. While we intended to work on the printed and web-based versions simultaneously, time constraints caused us to concentrate on the paper version first before solving problems with the web version.
Our primary software tools were LATEX (for typesetting), LATEX 2HTML (for creating the web version), and GNU make (for driving the iterative processing). RCS, a revision control system familiar to code developers, proved invaluable for controlling the editing of individual source files, particularly during the second stage when we worked on problems common to many papers throughout the book.
Our Makefile has three primary jobs, the first of which is to produce previews of the contributions: that is, it LATEX s each document separately for proofreading and early editing.
The second job is to produce the full book in PostScript format for submission to the printer. This is accomplished through a master LATEX document that loads in each of the contributed papers, along with material for the front and back matter. Since the individual contributions were set up to be processed independently, they must first be filtered to remove opening and closing markup. It is convenient then to include other filtering functions in this step; this includes adding markup that would put the author list into the table of contents and converting keywords from an ``author-friendly'' format to one needed by LATEX . This preprocessing is carried out with a new script called papfilter. This is followed by a first pass by LATEX , index processing with the LATEX program makeindex, and a second LATEX pass. Because LATEX produces a table of contents on-the-fly, it is difficult to correct an imperfect layout. A second filtering script, finalfilter, applies customizable edits to the table of contents (or any other part created on-the-fly); this avoids having to make the changes by hand every time a ``final'' copy of the book is needed. This step is followed by another LATEX pass before conversion to PostScript with dvips.
The third job of our Makefile is to produce the Web-based version using LATEX 2HTML. In this process, the indexes are first filtered (with a script called indfilter) for easier processing with LATEX 2HTML. Then, LATEX 2HTML is applied to the master document, producing HTML versions of the front and back matter only; contributed papers are converted individually as separate documents at the end of the process. To link all the parts together, we use two scripts (mkaux2db and mkaux2) to pass information from the master document to the individual contributed papers. PostScript reprints are produced as a by product of this intermediate linking stage; we create PDF versions from them using ps2pdf.
As the previous section demonstrates, we had to develop a number of software customizations to meet our goals. These fell into three categories: special LATEX style files, LATEX 2HTML customizations, and various Perl scripts that help guide the processing. A detailed description of each script and configuration file is available via our ADASS editors' Web page.
The downloadable kit contains all the scripts and configuration files we developed to produce the proceedings volume. The kit also contains source documents for creating an abbreviated version of the proceedings. The kit requires that LATEX , LATEX 2HTML, GNU Make, and RCS already be installed.
As an aid to applying the kit to future ADASS proceedings, we describe via our ADASS editors' Web page an idealized recipe for creating an ADASS proceedings volume. In reality, we hope that the process will be further improved as future editors adapt to new constraints and needs.
We were largely successful in meeting our goal to deliver the final printed book to the publisher electronically: only the conference photo had to be sent by mail. The advantages of electronic transfer included the ease of delivering updated versions to the editor. Furthermore, we didn't have to worry about the quality of our local printers. A disadvantage was that we had to pay closer attention to what fonts were used in the PostScript file; this was particularly tricky for the many figures included in the final document.
We were largely successful in automating the production of the
PostScript version. An important technique for improving the
automation is adding LATEX macros to the author's template for
marking up important information. In our case, we added several macros,
including 
paperID and paperref, used to enable
cross-paper referencing, as well as paindex and
aindex, which sets the names that will appear in the author
index. The more one can encourage authors to markup such information,
the easier it is to render the information in an automated way.
We were less successful automating the production of the Web version. Considerable effort was put exploiting the hooks into LATEX 2HTML for customizing its behavior; nevertheless, substantial editing was necessary to complete the presentation and correct various rendering problems.
Our process leaves plenty of room for improvement. One important area is better support for PDF reprints. The converter we used is fairly crude: the fonts are bit-mapped, resulting in a document that is not only larger than its compressed PostScript counterpart but is also unable to take advantage of the advanced text selection capabilities of PDF. The Web version required the most amount of hand editing, much of which could have been alleviated through improvements to the LATEX 2HTML customizations. The most difficult problems were ensuring that tables and images were rendered with sufficient quality; some flexible macros to automate this would ease those problems.
The most interesting opportunities for improvement involve providing ways to include sophisticated or expanded presentations that might only appear in electronic form. These might be supported through new latex markup macros that allow for the inclusion of code snippets, applets, or animations. Some careful thought should be given to the framework in which authors would take advantage of such hooks so that the printed version remains sufficiently coherent and useful to the reader.