[comp.text] Producing Conference Proceedings

harv@cis.ksu.edu (Harvard Townsend) (03/07/91)

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. 
Ideally, we would like an attractive, uniform end product in both hardcopy
and on-line form with minimal time and expense since it is a volunteer
project (what a dreamer, you say! Actually, my boss is the dreamer). :-)
So, what are your experiences? We use Framemaker, troff, and LaTeX locally,
and have access to Interleaf. For figures in troff and LaTeX papers, we 
generate the figures with Fig and include them with psfig. It would
therefore be helpful to use one of these tools for the final product, but
we can certainly learn something new if there are better solutions.

As it stands now, I anticipate having authors submit one hard copy and one
electronic copy of their final paper. The electronic copy would be a simple
ASCII file for the text part, and then have figures separate in whatever
format they want. We would suggest preferred formats (pic, fig, postscript)
but take anything. If we cannot incorporate their electronic format into
our final proceedings, then we would scan it in from the hardcopy.
So what have other people done? Here are some other questions that come to
mind:

- What formats are professional journals requiring these days? How many are
    accepting electronic submissions, and in what formats? How do they handle
    figures?
- Anyone ever try OCR from hardcopy? How reliable is this? Does it take more
    time to check for errors than it is worth? Any pointers to OCR vendors
    or publications where I can read about it?
- How about getting a vendor to donate their wp software, then providing a
    disk to the authors with that software on it. The authors then generate
    the final paper on the disk with that software and return the disk to us.
- How about display systems for on-line copies so that viewers can see the
    figures as well as the text in the published format? Hypertext would be
    fun and useful in such an application.
- How about copyrights and electronic distribution of the papers?
- How about volunteers who want to do this for me? :-)
--
Harvard Townsend, Systems Manager, Dept. of Computing & Information Sciences 
Kansas State University, Manhattan, KS 66506   (913)532-6350
Internet: harv@cis.ksu.edu    UUCP: rutgers!ksuvax1!harv

clewis@ferret.ocunix.on.ca (Chris Lewis) (03/09/91)

In article <1991Mar6.210709.28109@maverick.ksu.ksu.edu> harv@cis.ksu.edu (Harvard Townsend) writes:
>- How about display systems for on-line copies so that viewers can see the
>    figures as well as the text in the published format? Hypertext would be
>    fun and useful in such an application.

I haven't done all of this myself, but: if your figures are in postscript,
use of psfig/ditroff, a ditroff-to-postscript backend (psdit, tpscript, and
shortly my psroff) and a postscript previewer such as Pageview (Sun) or Display
Postscript (NeXT and IBM RS/6000 and there's also a DEC product) should work well.

(I'll be testing psfig with ditroff, RS/6000 and DPS shortly - contact me if you
want to know the results)
-- 
Chris Lewis,
clewis@ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis
Psroff support: psroff-request@eci386.uucp, or call 613-832-0541 (Canada)

jeffrey@cs.chalmers.se (Alan Jeffrey) (03/09/91)

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

spqr@ecs.soton.ac.uk (Sebastian Rahtz) (03/11/91)

I have to agree with most of Alan Jeffrey's points. I have edited a
conference proceedings each year for the last five years, and it has
ruined months of my life. I think it depends on the interaction
between two things: the subject matter, and the authors. If, for
instance, all the authors use mathematics, BUT a large proportion use
something like Macwrite, the effort putting into producing a book with
LaTeX might be worthwhile. Unless you can guarentee that over 50% of
the authors will produce *logical markup*, be prepared for hours of
madness. Get used to writing zillions of one-off programmettes to sort
out author A's idiosyncracies. The golden rule is

  Authors Ignore Instructions

My topical tips:

 - go for PostScript pictures, even if it means scanning originals and
   using the image. the usefulness of arbitrary scaling to fit the
   right space is invaluable. dont even consider cut and paste unless
   you have an assistant to do it
 - if you do it, go the whole hog. I use LaTeX, and convert all the
   references to BibTeX format. its time-consuming, but when its done,
   I get guarenteed consistency of layout, and guarenteed
   correspondence between references in the text and the bibliography.
   saves a lot of checking. similarly, symbolic cross-referencing is
   slow, but is wonderful when a last minute paper arrives and all the
   chapter numbers change
 
Sebastian
--
Sebastian Rahtz                        S.Rahtz@uk.ac.soton.ecs (JANET)
Computer Science                       S.Rahtz@ecs.soton.ac.uk (Bitnet)
Southampton S09 5NH, UK                S.Rahtz@sot-ecs.uucp    (uucp)

jeffrey@cs.chalmers.se (Alan Jeffrey) (03/12/91)

In article <SPQR.91Mar10171353@manutius.ecs.soton.ac.uk> spqr@ecs.soton.ac.uk (Sebastian Rahtz) writes:

> - go for PostScript pictures, even if it means scanning originals and
>   using the image. the usefulness of arbitrary scaling to fit the
>   right space is invaluable. dont even consider cut and paste unless
>   you have an assistant to do it

Yes, I should have been clearer about that---if you can get the
publishing house to do it, use cut&paste, you should try to get your
money's worth out of them...  But if you're having to do it yourself,
use some technical means.  Try to avoid scanning, as it usually
produces horribly digitized images which look like they've been faxed.
I notice the New Statesman (which should know better) has taken to
scanning images, and all the B&W linework has suffered dreadfully.
You can also spot the vectorization of the fonts, but that's another
matter.

If you do end up having to cut&paste, like all optical markup, leave
it to the last moment.  There's nothing more disheartening than than
pasting up a book only to discover some last-minute corrections which
mean you have to screw the whole thing up and stick it in the bin.

Agreeing with your agreements,

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