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