The LaTeX environment for the EVU conference proceedings: Unterschied zwischen den Versionen

Aus Colliseum
Zur Navigation springen Zur Suche springen
Zeile 84: Zeile 84:
==Proofreading and translations==
==Proofreading and translations==
Before initiating any translation, you should have achieved a stable version of the LaTeX document in one language. As far as possible, proofreaders and translators should apply their changes directly to the LaTeX file. This will spare the layouter from a lot of work and exclude a lot of possible error sources. Any translation should be proofread by a native speaker at last. To enable those who don't posess a LaTeX compiler to perform their revisional work, the layouter should supply them with the LaTeX file as well as with the compiled PDF of the paper. This PDF may have a reduced resolution to speed up the transfer by e-mail.
Before initiating any translation, you should have achieved a stable version of the LaTeX document in one language. As far as possible, proofreaders and translators should apply their changes directly to the LaTeX file. This will spare the layouter from a lot of work and exclude a lot of possible error sources. Any translation should be proofread by a native speaker at last. To enable those who don't posess a LaTeX compiler to perform their revisional work, the layouter should supply them with the LaTeX file as well as with the compiled PDF of the paper. This PDF may have a reduced resolution to speed up the transfer by e-mail.
==Keeping track of the changes applied to the LaTeX documents==
As LaTeX is pure ASCII, there is no built-in version control. With several people working with the files – the author, the layouter, the translator –, all of them possibly several times, you should however keep track of the changes applied.
Each LaTeX document should therefore start with a header of comment lines explaining the changes applied to the document, with the most recent change at the top. This is what the header of the 2009 papers looked like:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% T. Hugh Woo
% Application of Video-Aided Mapping
% in Verifying Signal Violation - A Case in Taiwan
%
% Version 1.3, 2009-09-03 16:00
%  capitalisation of headings corrected
%
% Version 1.21, 2009-08-28 15:40
%  "Proofread by Richard Lambourn"
%  [normalheadings]
%
% Version 1.2, 2009-08-24
%  Figure 2 (signalling table) exchanged
%
% Version 1.1, 2009-06-30
%  Proofread by Richard Lambourn
%
% Version 1.0
% 2009-06-22
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
In order to avoid misunderstandings caused by different date formats, the dates are given as YYYY-MM-DD.
==Approvement by the authors==
It should be obvious that the final version of a paper (in all languages) should be approved by the author. As there might be deviations between a paper compiled on its own and a paper compiled in the context of the binder document (i.e. the entire proceedings), the authors should finally be given the opportunity to have a look at the entire proceedings.
It is recommended to upload the final version (in all languages) to an Internet server and providing the authors with the download links to the paper via e-mail. This version of the proceedings should have a reduced resolution, i.e. about 5 MB in total, intended for screen display.

Version vom 11. Oktober 2009, 20:10 Uhr

Why LaTeX?

LaTeX offers the possibility to create a single PDF file for the conference proceedings in a very stable environment. It offers direct support for PDF files which can be binded in as fgures. LaTeX files are pure ASCII files, which means that they can be edited by any program, which simplifies the translation and review process: proofreaders and translators can directly edit the TeX files.

Furthermore, LaTeX is free software, which means that the conference proceedings can be layouted and compiled by any country group without having to buy expensive layout software. One shortcoming of LaTeX is however that it doesn't offer WYSIWYG; if you want to see what LaTeX's PDF output looks like, you have to initiate a compilation, very much like compiling source code into a computer program, with all that comes along with that, like error and warning messages. For the conference proceedings, we use the pdfTeX compiler which directly produces PDF output.

To answer the most often objection directly: Microsoft Word is not suited for this purpose. It is no layout program and not stable enough to support large documents with lots of figures.

What programs do you need?

In order to layout papers and compile them to a PDF, you need a TeX distribution and an editor. The best choices under Windows are probably MikTeX (http://www.miktex.org) for TeX and TeXnicCenter (http://www.texniccenter.org) for the TeX editor. You should first download and install MikTeX and then TeXnicCenter, this will guarantee that all path variables are set correctly.

When installing MikTex, you have to decide whether you would like to install a complete system or a basic system – both of them will do. TeX has a modular concept based on so-called packages. each of them offering a certain specific functionality. If you chosse a full installation, this will take rather long and will install a lot of packages that you will never need.

If you opt for a basic installation, additional packages will be downloaded from the Internet on the fly when used by your document. This will cause the first compilation of a EVU conference paper to take rather long, as all the additional packages will be downloaded and installed from the Internet. All subsequent compilation processes will then be performed in normal time.

In order to view the PDF output, you need a PDF viewer such as the Adobe Reader. For layout purposes you should however posess Adobe Acrobat Professional such that you can really edit PDF files, e.g. cut graphics from a largers page. Adobe Acrobat will also allow to produce higher compressed versions of PDFs which speed up the transfer process when sent by e-mail: The PDFs compiled from LaTeX code can become quite large as they take any graphics as-is, e.g. leave high-res JPEGs images as they are. In contrast to this Adobe Acrobat will recalculate any raster image to a pre-set resolution.

All others who just want to edit the TeX files (without compiling them to PDFs), i.e. proofreaders, translators and the like, just need a text editor. We would recommend Notepad++ (http://notepad-plus.sourceforge.net) for this purpose as it will highlight the syntax of the TeX files, i.e. prevent users from altering control codes. TeX files can, however, also edited with Microsoft Word, such that proofreaders and translators do not really have to install specific software.

Additional program tools

For the layouter, we would also recommend some additional tools:

Basic Concept

All papers of the proceedings reside in a directory tree with one directory for each paper. This directory is named after the first author of the paper (without special chracters and umlauts) and contains all files which are related to this paper, especially the TeX files and all figures. Figures must have one of the formats JPEG, PNG or PDF. The paper itself has the same name as the directory with the language indicator attached, e.g. hugemann_eng.tex or hugemann_ger.tex.

The root directory of the tree contains the header files with the basic definitions, i.e. the generic header.tex and the language-specific header files header_eng.tex, header_ger.tex and the like. These header files are referred to (via include) at the beginning of the LaTeX document of each paper. Every paper has more or less the same intro (header) of TeX commands and the same footer of TeX commands. These basically guarantee that each paper can be compiled on its own (i.e. stand-alone) as well as in the context of the binder document that resides in the root directory of the tree. The compilation of the binder document will create the entire conference proceeding as one single PDF file at th eend of the layout process.

During the layout process, each paper is compiled on its own for most of the time, producing a stand-alone PDF for each paper. The compilation of the entire conference proceedings is the very last step, when everything else has been done. In the final proceedings, each paper will automatically start on a right side (with an odd page number). This is to guarantee that the layouts of the papers will look exactly the same when compiled on their own or when compiled in the context of the entire proceedings.

The references and the authors' addresses reside in one file references.tex for all language versions of a paper. This file is referred to at the footer of each paper.

So in the root directory you have the following files:

  • header.tex – generic header file with all the packages
  • header_eng.tex – language-specific header files
  • 2009_eng.tex – binder document for the entire proceedings
  • start_eng – intro with the welcome message, etc.
  • participants.tex – participants list

Besides these files there are only a few figures, such as the EVU logo, the photographs of the editors and their signatures. The LaTeX code for the participants list is generated automatically in the Excel file participants.xls.

In the paper directores you have:

  • hugemann_eng.tex – English version of the paper
  • hugemann_ger.tex – German version of the paper
  • references.tex – references an addresses for all language versions
  • all figures as JPEGs, PNGs or PDFs

Some of the packages used

You'll find all the packages used in the generic header file, accompanied by some comments. We will refrain from naming them all over here. The proceedings use the following larger packages:

  • Koma-Script – defines "European" document classes
  • Babel – language support
  • AMS math – math extensions defined by the American Mathematical Society
  • Siunitx – SI units for quantities, reformats numbers automatically
  • chapterbib – allows the use of a bibliography after each paper in the proceedings
  • quotation – quotations
  • dblfloatfix – fixes a some bugs connected with page-wide (two-column-wide) floats (i.e. figures)
  • abstract – defines the environment for the single column abstracts
  • url – hyphenation of URLs

Basic formatting in LaTeX

The papers will mostly come along as Word documents. You can transfer these into LaTeX code in TeXnicCenter via the Windows Clipboard. Before doing so, you have to switch of the automatic hyphenation in Word, otherwise the code would be peppered with a lot of superfluous hyphens.

It is however recommended to store the word files in pure text format and treat these with SED first, in order to perform a lot of autiomatic replacements.

Figures should be grouped such that several graphics that make a common statement are grouped to one figure with subfigures. This is disregarded by most authors, but the proceedings of Nice (2008) and Hinckley (2009) give a lot of examples of logical grouping. The authors should provide each figure as a single file, i.e.

  • JPEG – for photographs
  • PNG, GIF or TIFF – for sketches, i.e. screenshots, scans of police sketches, etc.
  • PDF or original format (e.g. XLS) – for vector drawings

It turns out that a lot of authors don't seem to understand or disregard these rules, such that the layouter has to extract the figures from a Word document or a PDF:

  • You can extract raster images from a Word document by storing it in HTML format. This works best with old versions of Word (i.e. Word 97).
  • In order to extract raster images from PDFs, use the PDF Image Extraction Wizard.
  • Vector images can be cut from PDFs by extracting the according page, deleting everything but the vector graphic and cropping the page to the size of the graphic. This can be performed with Adobe Acrobat.

When sending the first layout back to the author, you should ask for the original files of the graphics you extracted in the first run. This is very important if the resolution of the graphics does not suffice the needs of high resolution printing.

PDFs supplied by the authors should immediately be tested in regard to conformity. A lot of PDF conversion is performed by crude printer drivers which may produce non-confom PDF output. This testing in regard to PDF conformity can also by performed by use of Adobe Acrobat Professional. Please keep in mind that the pdftex compiler can only deal with older versions of PDF up to 1.3, corresponding to Acrobat Version 4. Newer PDF can however be binded in as long as they do not make use of features that only exist in higher PDF versions.

Proofreading and translations

Before initiating any translation, you should have achieved a stable version of the LaTeX document in one language. As far as possible, proofreaders and translators should apply their changes directly to the LaTeX file. This will spare the layouter from a lot of work and exclude a lot of possible error sources. Any translation should be proofread by a native speaker at last. To enable those who don't posess a LaTeX compiler to perform their revisional work, the layouter should supply them with the LaTeX file as well as with the compiled PDF of the paper. This PDF may have a reduced resolution to speed up the transfer by e-mail.

Keeping track of the changes applied to the LaTeX documents

As LaTeX is pure ASCII, there is no built-in version control. With several people working with the files – the author, the layouter, the translator –, all of them possibly several times, you should however keep track of the changes applied.

Each LaTeX document should therefore start with a header of comment lines explaining the changes applied to the document, with the most recent change at the top. This is what the header of the 2009 papers looked like:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% T. Hugh Woo
% Application of Video-Aided Mapping 
% in Verifying Signal Violation - A Case in Taiwan
%
% Version 1.3, 2009-09-03 16:00
%   capitalisation of headings corrected
%
% Version 1.21, 2009-08-28 15:40
%   "Proofread by Richard Lambourn"
%   [normalheadings]
%
% Version 1.2, 2009-08-24
%   Figure 2 (signalling table) exchanged
%
% Version 1.1, 2009-06-30
%   Proofread by Richard Lambourn
%
% Version 1.0
% 2009-06-22
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

In order to avoid misunderstandings caused by different date formats, the dates are given as YYYY-MM-DD.


Approvement by the authors

It should be obvious that the final version of a paper (in all languages) should be approved by the author. As there might be deviations between a paper compiled on its own and a paper compiled in the context of the binder document (i.e. the entire proceedings), the authors should finally be given the opportunity to have a look at the entire proceedings.

It is recommended to upload the final version (in all languages) to an Internet server and providing the authors with the download links to the paper via e-mail. This version of the proceedings should have a reduced resolution, i.e. about 5 MB in total, intended for screen display.