The ADASS VIII Proceedings: a Case Study in Editing for the Electronic Age

The ADASS VIII conference proceedings volume was the first in its series to be delivered to the publisher electronically. Apart from one hardcopy figure, it was compiled entirely from digital sources. In this presentation, we review the process we used to assemble the proceedings book and its electronic companion for the Web. Among the goals we set for ourselves as editors was to maintain a single source of electronic manuscripts from which either the printed or electronic version could be generated automatically with minimum of manual editing. Furthermore, we tried to develop the process, including any new software we had to write, in such a way that it could be reused (at least in part) by future ADASS editors. This process has been distilled into a downloadable editors' kit built primarily on top of four existing software tools: GNU Make (for driving the process), L^ATEX (for typesetting), L^ATEX 2HTML (for creating the Web version), and RCS (for version control). We evaluate how successful we were in meeting our goals and make recommendations to future editors.

1. Challenges and Goals

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.

2. Process Overview

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 L^ATEX (for typesetting), L^ATEX 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 L^ATEX 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 L^ATEX 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 L^ATEX . This preprocessing is carried out with a new script called papfilter. This is followed by a first pass by L^ATEX , index processing with the L^ATEX program makeindex, and a second L^ATEX pass. Because L^ATEX 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 L^ATEX pass before conversion to PostScript with dvips.

The third job of our Makefile is to produce the Web-based version using L^ATEX 2HTML. In this process, the indexes are first filtered (with a script called indfilter) for easier processing with L^ATEX 2HTML. Then, L^ATEX 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.

3. Software Customizations

As the previous section demonstrates, we had to develop a number of software customizations to meet our goals. These fell into three categories: special L^ATEX style files, L^ATEX 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 L^ATEX , L^ATEX 2HTML, GNU Make, and RCS already be installed.

4. Successes and Shortcomings

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 L^ATEX 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 L^ATEX 2HTML for customizing its behavior; nevertheless, substantial editing was necessary to complete the presentation and correct various rendering problems.

5. Suggestions for Improvements

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 L^ATEX 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.