🚀 go-pugleaf

In article <1991Mar6.210709.28109@maverick.ksu.ksu.edu> harv@cis.ksu.edu (Harvard Townsend) writes:
>I have been assigned to help put together the conference proceedings for a
>major ACM conference next year (the call for papers has already gone out).
>I am interested in other people's experience with such an endeavor. 

Apologies in advance for this posting, it's going to be very long, and
probably not a little contentious.  Last year I spent far far too much
of my time producing a conference proceedings under very similar
circumstances, and I've been meaning to write a TUGboat article about
it for a while.  So consider this version 1.0\beta.

My initial reccomendation, spoken from the bottom of my heart, with
complete sincerity is DO NOT DO THIS.  Producing an attractive,
consistent, readable conference proceedings is a long, thankless,
tedious task.  It is much much much harder than producing a
single-author book, and usually the effort just isn't worth it.
Conference proceedings on the whole are a medium for getting material
printed quickly, and are expected to be out of date within five years.
So my initial reaction would be don't bother---just print the CRC your
authors provide for you, in whatever grotty horrible format you can,
just get it done *quickly*.  Producing an attractive end result will
add on at least a few months to the production time, and possibly as
much as a year.  And your authors would much rather see a shoddy
volume now than a beautiful volume in a year's time.

Right, polemic over, onto more practical matters.  The main thing you
need to do is plan in advance.  And the first thing you need to decide
is how and where the finished result is going to materialize.  Which
publisher will you be using?  What formats will they accept?  What
will the finances of getting the thing printed be?  Will you be
running CRC off laser-printed copy (yuk! but all too common nowadays)
or will it be phototypeset?  If so, who's paying?  How many free
copies of the book do you get?  Who keeps copyright?  These things
need decided *now*, before you even think about things like which
typesetting system to use.  Many publishers will have their own likes
and dislikes about which systems they'll accept.  

WARNING: Most publishers (no names, no packdrills) regard
author-produced copy (such as your average book produced with TeX) as
a means of getting books set cheaply.  So don't expect the publisher
to treat your CRC with the care they would a textbook---they'll be
expecting a textbook to sit around for a while and gradually sell a
decent number of copies.  Conference proceedings have an incredibly
short shelf-life, and don't sell.  So a) they're expensive, and b)
they don't look as nice as `real' books.  (There are honourable
exceptions to this rule, but not many.)

So, after you've got a publisher, you need to decide how much work
you're going to do yourself.  Who is responsible for:

* Book design?  Who is going to design the page layout, decide on
fonts, choose a referencing style, decide how footnotes, chapter
headings, A headings and B headings will look, and all the other
work you'll have to do?  If you're getting it professionally
published, chances are the publisher will have standard designs for
this sort of thing.  But you may well have to implement these in your
(or their) favourite markup language.  Do that NOW, so that you can
send the authors a .sty file (or the equivalent) for them to produce
their final copy with.

* Logical markup?  That is, if the author provides you with a
god-awful mess of a document, will you be prepared to go in and change
the logical markup to fit the document style you chose?  The worst
case of this is what to do about authors who produce copy in a
different typesetting system, or who provide such awful non-logical
markup as to be worse than useless.  For example, authors who type
(using LaTeX as an example)

\vskip1in\par\noindent{\bf 1.5 Foo-bar spaces}\par\medskip\noindent

rather than \subsection{Foo-bar spaces}.  In my experience it takes
about the same amount of time to {\em completely re-keyboard the
entire paper\/} as to edit a lousy manuscript.  The worst example I
had was a document that had been written in some DTP system, and then
converted automatically to TeX.  Plain text it managed, but {\em every
single piece of mathematics in the entire paper\/} was wrongly set,
and had to be edited by hand (this was a paper on topology, folks).
Afterwords I realized it would have been faster to re-keyboard the
damn thing.

* Grammatical or style changes?  Are you going to let the author's
copy stand as is?  Are you going to make everyone's citation styles
the same?  Everyone's figure referencing (Figure~37, or Fig.~37, or
figure~37)?  Correcting punctuation (its, it's)?  Correcting
italicization of foreign phrases (`{\em et al.}~foo', `et al.~foo',
`et al., foo'...), misuse of `e.g.' and `i.e.', misspelled words,
grammatical errors, the list goes on.  And although all of these
things are small in isolation, the combination of a lot of little
inconsistancies and inaccuracies adds up to produce an unattractive
whole.

* Optical markup?  Are you prepared to correct widow words, widow
lines, bad figure positioning, bad line-breaks, bad page-breaks,
change displays to in-line formulae and back again, rivers, chapters
ending on recto pages, bad hyphenation?  If so, don't do it until the
very last run of the document, as you will discover that both the
authors and the publishing house will keep changing their mind about
the MS or the book design, both of which will completely screw up your
carefully thought-out optical markup.

* Figures?  Every single author will use a different method of
producing figures, and probably the only thing to do is to cut and
paste them by hand (or rather let the publishing house do this for
you).  Some authors will provide you with figures in a format that the
publisher can cope with, but make sure their printer can manage!  For
most figures, forget about trying to integrate them with the text
(unless you're prepared to redraw them from scratch) and insist on
getting hard copy off the authors, in duplicate at least, numbered
consistently with the text.

* Badgering the authors?  Everything always takes ten times longer
than you expect, and you'll end up in huge arguments with authors over
trivialities such as `is ``r\^ole'' a foreign word' and why Author A's
axioms for sub-functor spaces can't possibly be fitted into your book
design.  To quote P. R. Halmos, from his excellent `How to write
mathematics', 

   Smooth, consistent, effective communication has enemies;
   they are called editorial assistants or copyreaders...
   If you want to be an author you must be prepared to defend
   your style; go forearmed into the battle.

In this case, the `enemy' is you and me.  You have to learn to live
with authors screaming and cursing your name, fighting for every last
full stop.  Some are a joy to work with, considerate, reasonable, but
others (fortunately a minority) are as confrontational as anything.
And (unlike a copy editor, who can afford to say `what the hell')
these people are your peers, or (worse) senior members of your field,
who you can't really afford to offend willy-nilly.

So, in conclusion (at last), ask yourself very carefully whether it's
all worth it.  It's a lot of work, you won't get any research done for
a looooong time, you'll generate tension within the field, nobody will
appreciate your work, but you will have produced a beautiful book.

Sorry to be so negative about the whole thing, but I've seen too many
people start out with the idea that computerized typesetting makes
typesetting easy, so running a book off would take no time at all.
True, it is now a lot easier to get something sort-of-OKish, but an
attractive book is still a hell of a lot of work for all concerned.

Is it worth it?  I'd say yes, a beautiful object is worth the time it
takes to get it right, and has to be its own reward, but you need to
know what you're getting into...

I hope it all works out in the end,

Alan.

Alan Jeffrey         Tel: +46 31 72 10 98         jeffrey@cs.chalmers.se
Department of Computer Sciences, Chalmers University, Gothenburg, Sweden