Manuscript Instructions

ManuscriptInstructions

ADASSManuscriptInstructions

User Manual:

Open the PDF directly: View PDF .
Page Count: 21

Download
Open PDF In Browser	View PDF

Manuscript instructions
October 19, 2018.
No matter how experienced an ADASS author you are, you should at least read this
introduction and the checklist that follows it. Requirements have changed in recent
years, particularly in the way references have to be handled. For ADASS 2018 we
are now asking authors to include author index entries in their papers, and this
document describes how to do this.

Introduction
If you give a talk, present a poster, or organise a BoF, at ADASS you are expected
to submit a paper for the proceedings.1 The Proceedings are published by the
Astronomical Society of the Pacific (ASP) as part of their conference series. The
ASP has a house style for these Proceedings and this imposes a number of
constraints on the way papers are written and formatted.
You must submit your paper in LaTeX with references using BibTeX, and must
follow the proper ASP style files. For ADASS XXVIII, the main LaTeX style file is
asp2014.sty and the BibTeX bibliographic style file is asp2014.bst. On the ADASS
site there is a .tar file2 that contains these .sty files and a template LaTeX file that
can be used as the basis for your paper. It also provides a copy of the ASP’s
document called ‘Instructions for Authors and Editors’, the first part of which
provides detailed directions for authors.
You should read these ASP-provided directions, but should note that they are
now some years old, and that requirements for new volumes have changed
slightly. In particular, all papers must now provide a .bib file with details of their
references in BibTeX format. Papers must no longer use \bibitem LaTeX
directives. You may have used \bibitem references for ADASS papers in the past,
but these are no longer acceptable. (The template LaTeX file included in the
ADASS-supplied .tar file is a modified version of the standard ASP file, which –
amongst other things – has had the old \bibitem examples removed. Please use
this file rather than any older copies you might have.)
The following check list is intended to serve as a basic summary of what is
required. Even if you are an experienced author of ADASS papers, please do read
through it, because some things have changed over time. And in any case
experience shows that even the most experienced and careful authors can get
some of these things wrong. The ADASS editors for this conference will check
your paper, and may be able to correct minor problems, but will ask you to

Invited speakers and financial aid recipients are required to submit a paper. Everyone else is
strongly encouraged to do so.
2 http://www.adass.org/instructions/ADASS2018.tar
1

modify it if necessary. Editing and checking papers can be a very time-consuming
process, but it goes much, much faster if authors follow the guidelines!
Each item in the checklist ends with a reference to one of the following sections,
which covers the point in more detail. For even more detail, see part one of the
ASP’s ‘Instructions for Authors and Editors’ document.

Check list
•

Papers should be submitted as compressed tar archives named
_.tar.gz. For example: O4-3_v1.tar.gz for the first
version submitted, O4-3_v2.tar.gz for the second, etc. (See File names and
Paper IDs, p6.)

•

References must all use BibTeX entries in a .bib file. No use of \bibitem!
(Even though some older ASP templates have them.) (See References, p4.)

•

All references must be cited in the text, usually using \citet or \citep. Do
not use \cite. (See References, p4.)

•

No LaTeX warnings. Particularly, no overfull hboxes or unresolved
references. (See LaTeX warnings and errors, p9.)

•

No use of \usepackage except for \usepackage{asp2014}. (See LaTeX
packages and commands, p13.)

•

No use of \renewcommand or \renewenvironment. (See LaTeX packages
and commands, p13.)

•

Arguments to \citep etc., should use ADS type references where possible,
fall back on or something suitably unique if not. (See
References, p4.)

•

References in the text are all generated automatically (using \citep etc),
not put in explicitly as ordinary text that just looks like a generated
reference. (See References, p4.)

•

Definitely no LaTeX errors. (See LaTeX warnings and errors, p9.)

•

Paper is the right length. References don't spill over into one more page.
(See Length of Paper, p12.)

•

Paper has an abstract. (See Length of Paper, p12.)

•

References are to things that actually exist and can be expected to
continue to exist. Not papers "in preparation" or URLs for blog items. (See
References, p4.)
2

•

Graphics files have to be .eps encapsulated Postscript format. Yes they do!
Sorry, but they do. (See Figures – format, p9.)

•

Name all the files properly - figures are _f.eps, eg O1-3_f1.eps.
Paper names use dashes not periods, O1-3.tex not O1.3.tex. Posters now
use the same naming convention as oral papers, e.g. P3-21. All files should
be in the same directory – don’t use a separate sub-directory for graphics
files. (See File names and Paper IDs, p6.)

•

Figure captions should make sense if the figure is printed in monochrome
- because it will be! (See Figures – content, p8.)

•

Figures are legible at the size ADASS Proceedings volumes are printed,
which is quite small. (See Figures – content., p8)

•

Avoid ending lines with ‘\\’ – this leads to underfull \hbox warnings. (See
LaTeX warnings and errors, p9.)

•

Author lists follow the correct format: comma separated, with an 'and' for
the final author. (See Authors and Affiliations, p10.)

•

The first author of the paper must be the person who presented the paper
at the conference. (See Authors and Affiliations, p10.)

•

No repetition of affiliations - list each organisation once, with multiple email addresses if you really must. (See Authors and Affiliations, p10.)

•

Running heads should fit in the same horizontal space as the text does,
not pushing the page numbers over to the right. (See LaTeX warnings and
errors, p9.)

•

Run through a spelling checker. (I know that can be tricky with LaTeX.)
(See Content and Typesetting, p14.)

•

Proofread, or have the text proofread, to check for proper English usage.
In particular, note that "allows to" is not conventional English, and English
uses articles ('a','an','the') in places where other languages, particularly
Eastern European languages, don't have them. (See Content and
Typesetting, p14.)

•

It will help the editors if you add subject and author index entries to
your .tex file. (See Authors and Affiliations, p10 and Appendix: The
Index.py script, p18.)

References
Unless your paper has no references at all, it needs a .bib file. An example file is
included in the .tar file available from ADASS.3
Most of the entries in the example file come from the ADS abstract service.4 If
you can find the paper you want to reference on ADS, you can click on the “Bibtex
entry for this abstract” link that ADS provides following the abstract. Copy and
paste this into your .bib file. If you cannot find the reference on ADS, you will
probably need to create the entry yourself. A useful guide to BibTeX entries can
be found in the OpenOffice pages.5 If absolutely nothing else fits, fall back on an
@misc entry.
The point of including references is so that readers can actually locate the
reference in question. Remember this when considering references to papers “in
press” or “in preparation”. ASP frowns on such references to things that don’t
actually exist yet, because they’re going to be hard for readers to find. Try to
avoid these. If you really must use them, try to include enough detail for a future
reader to locate the paper when it does appear.
Papers in arXiv that have not yet been published can be referenced. Indeed, ADS
will generate BibTeX refences for such papers. This fictional example shows the
main fields:
@ARTICLE{20yyarXivnnnn.mmmmm,
author =
{{Author}, A.~N. and others},
title =
"{A really important paper}",
journal =
{ArXiv e-prints},
archivePrefix ="arXiv",
eprint =
{arXiv:nnnn.mmmmm},
year =
20yy,
}

In general, most things on the Web are transient, and should not be included as
formal references. The preferred way to reference a URL is to supply the URL as
a footnote. If it doesn’t clutter up the text, it might be included as part of the main
text, usually in parentheses. If you are struggling to fit in your 4 pages, note that
footnotes take up more space than in-text references. If you use a URL, embed it
in \url{}, e.g. use \url{http://cxc.cfa.harvard.edu/} rather than {\tt
http://cxc.cfa.harvard.edu/}.
You will find that references generated by BibTeX from ADS-generated entries
can be very verbose, and eat into your allotted number of pages. You can reduce
this fairly easily. ADS generates the full author list, but the ADASS convention is
that papers with 8 or more authors should be abbreviated to just “A. N. Author et
al.”, for which the BibTeX entry should be “{Author}, A.~N. and others”. Note
that this applies to lists of editors as well, although having more than eight
http://www.adass.org/instructions/ADASS2018.tar
http://adsabs.harvard.edu/abstract_service.html
5 http://www.openoffice.org/bibliographic/bibtex-defs.html
3
4

editors is unusual. Also, ADS makes ADASS references particularly verbose,
calling the series “Astronomical Society of the Pacific Conference Series” which
you can replace with “ASP Conf. Ser.”, and the ADASS book titles “Astronomical
Data Analysis Software and Systems XXI” etc., which you can replace with
“ADASS XXI”.
The editing process for the ADASS proceedings involves combining all the
individual .bib files into one master .bib file for the whole volume. For this to
work properly, the names used to cite references should be as standard as
possible. Please do not use “ref1”, “ref2”, etc. – if everyone does that it will be
chaotic. The standard ADS reference names, 2015MNRAS.454.1012A,
2015arXiv151100011O, etc. are cumbersome, but are a standard. If you have to
make up your own, a convention like is reasonable.
References to the current ADASS volume should be based on the following
template:
@inproceedings{_adassxxviii,
author
= "",
booktitle
= "ADASS XXVIII",
year
= 2019,
editor
= "TBD",
volume
= "TBD",
series
= "ASP Conf. Ser.",
pages
= "TBD",
publisher
= "ASP",
address
="San Francisco",
}
(This is for ADASS XXVIII in College Park, 2018. For later meetings change the
roman numerals – in both places – and the year. Note that the proceedings will
be published the year after the conference.) The ADASS editors will fill in the
various TBDs as part of the process of completing the volume. For the
element, please use the oral, poster etc. ID (e.g., O2-1, P2-17, etc.)
given in the programme. The element should list the authors of the
paper being referenced.
It is never correct to list more than one author followed by et al. You should
never have an entry like author = {{Author}, A.~N. and {Coauthor}, B.~M. and
others} in the BibTeX file.
The .bib file you supply should only include references actually cited in the .tex
file. Please don’t send your master .bib file with every reference you’ve ever used.
This complicates things for the editors.
Don’t put ‘fake’ references in your actual text: “This is described by Bloggs et al.
(1999)”. Use “This is described by \citet{Bloggs1999}”.
LaTeX supports a number of ‘\cite’-type commands, but most of what you need
can be accommodated by \citet and \citep. You should not use the simple (and
5

traditional) \cite, which is an older-style of command and can cause problems.
There are other ‘\cite’-type commands that can be used in unusual
circumstances,6 and only \cite must be avoided, but try to stick to \citet and
\citep. The ASP Instructions provide a very good explanation of how to use these.
You will need to supply your .bib file, which you should call .bib, eg
P9-99.bib, and you will need to include the line:
\bibliography{P9-99}
in your .tex file, with P9-99 replaced by your paper identifier.
Note that using BibTeX with LaTeX is something of a circular process. First you
run LaTeX to pick up all the ‘\cite’-type references (written into the .aux file).
latex P9-99.tex
At this point, you will see LaTeX warnings about undefined citations.
Then you run BibTeX:
bibtex P9-99
And then you run LaTeX again. It always takes two runs to get all the citations
resolved:
latex P9-99.tex
latex P9-99.tex

File names and paper IDs
Following a standard convention makes it easier to handle submitted files
automatically. Please name all your files as follows.
All presentations have a type and a number, and an ID constructed from these.
The type is abbreviated to a single letter, as follows:
Invited presentation: I
Oral presentation: O
BoF: B
Focus demo: F
Poster: P
Demo booth: D
Tutorial: T

See http://texdoc.net/texmf-dist/doc/latex/natbib/natbib.pdf

The number for an oral presentation is formed from the session number and the
number within that session, separated by a dash, e.g. “I2-1”, or “O10-3”. Posters
follow the same convention, using a combination of the key theme number and
number within that theme, e.g. “P3-21”. (Note that for conferences before 2016,
posters were just given a three-digit number, e.g. “P045”, but that has now
changed so that posters can be associated with conference themes.) All other
presentations are just given a number from 1 up.
The ID for each presentation is then just the type letter followed by the number.
In most of these notes this is shown as .
The main LaTeX file for a presentation must be .tex. The BibTeX file
must be .bib and the graphics files for any figures must be
_f.eps, where is the figure number, starting at 1.
For example:
Oral presentation O4.3
Invited presentation I3.1
BoF 2
Focus Demo 5
Poster P1.23
Demo Booth 4
Tutorial 2

O4-3.tex, O4-3.bib, O4-3_f1.eps
I3-1.tex, I3-1.bib, I3-1_f1.eps
B2.tex, B2.bib, B2_f1.eps
F5.tex, F5.bib, F5_f1.eps
P1-23.tex, P1-23.bib, P1-23_f1.eps
D4.tex, D4.bib, D4_f1.eps
T2.tex, T2.bib, T2_f1.eps

When you submit your paper, you should include the .tex file, the .bib file (unless
your paper has no references) and any .eps files it uses. You should also include a
copy of the .pdf file that was generated when you typeset the paper yourself.
Please have all the files in the same directory, rather than using a subdirectory
for associated files like figures.
You must submit a single archive file – preferably a .tar file, compressed to form
a .tar.gz file, but .zip files are acceptable – named as follows:
_.tar.gz
where is v1 for the first version, v2 for the second, etc. For example,
the first version of the O4-3 paper should be called
O4-3_v1.tar.gz
and subsequent versions should be called O4-3_v2.tat.gz, O4-3_v3.tar.gz etc.
Following this convention makes it much easier for the ADASS editors to keep
track of the numerous submissions. If you use .zip files, they should follow the
same convention: O4-3_v1.zip etc. Note that each .tar or .zip file should contain
all the files needed for the paper – don’t expect the editors to go back into your
earlier versions to find missing graphics files, for example.

Figures - content
The most important point about figures is that they’re there for the reader to
look at. That means they have to be clear and legible. It’s important to realise
that the reader may read the paper in two rather different ways: in the printed
volume, and on-line. This complicates things, but ideally a figure should be clear
and informative in both circumstances.
The printed book produced for all ASP Conference proceedings has quite small
pages – the books are closer to A5 than to A4. Most authors will make test prints
of their papers, if at all, on A4 or the roughly equivalent US quarto. Try printing
your paper two pages to a sheet instead, and in black and white. Most people will
be surprised at how hard it is to make out the figures, and will be thoroughly
confused by captions such as “the red line shows … while the green line shows
…”. See if you can say what you need without mentioning colour.
If you possibly can, make your figures easy to read in the printed volume. The
ASP has quite strict guidelines about this, and they review the volume when it is
submitted to them for publication. However, being realistic, most people are
going to view an on-line version of the paper, and that version will be in colour
and can be blown up on a screen as much as needed. ADASS papers are available
without restrictions such as paywalls, and the preface to the volume will
describe how to access them.
The ASP ‘Instructions for Authors and Editors’ document devotes quite a lot of
space to the question of figures, and you should read what it has to say.
(Summary: \articlefigure and \articlefiguretwo, or \plotone and \plottwo will do
most of what you need, and if you need more you can use \includegraphics.) Do
crop any unnecessary white space from around your figure, because that is
wasted space on the page. Ideally, ensure that any included line art or text (such
as annotations) is legible when the figure is shrunk to 90% of the intended print
size. Lines should not be defined as hairline width; the recommended minimum
line width at the intended print size is 0.25pt.
Figures need to have a minimum resolution of 240 pixels per inch (95 pix/cm) to
reproduce satisfactorily. Authors should print out their figures at actual size and
evaluate the readability of any embedded text. If the embedded text appears
smaller than about 8 pt, then it is not going to be readable in the final printed
figure. Text also needs to appear in a contrasting colour to be easily legible.
Equally, for the benefit of those reading on-line, make sure that your figure has
enough resolution to be magnified to show the required detail without becoming
pixelated.

Figures – format
Figures must be submitted as .eps (encapsulated postscript files). Unfortunately,
this is an ASP requirement. We realise the originals for most figures will not be in
this format, and you will have to convert them. Sorry.
There are some very capable graphic conversion programs that can convert
almost anything into a .eps file. One example for MacOS is GraphicConverter.7
There are a number of Web-based converters of varying quality available. We
have seen some rather strange .eps files submitted with ADASS papers in the
past. It also seems that some versions of LaTeX handle strange .eps files better
than others do, so the ADASS editors may not always get the same results as you
do from some of the stranger files – bounding box problems in particular can
make a figure look a different size on different machines.
If you have problems with conversion to .eps, contact the ADASS editors. If you
think your .eps files may give problems, it can help to submit the original files as
well (but don’t expect the editors to fix all your conversion problems for you!).
This is a case where submitting your version of the final .pdf file can help – the
editors can at least see what you expect the figures to look like.

LaTeX warnings and errors
Your paper should run through LaTeX without any errors. Obviously!
It should also run through LaTeX without any warnings. Most warnings should
be treated as errors.
ADASS papers often generate warnings about an overfull \hbox. These need to
be fixed, as otherwise the text can run off the printed page in the final volume.
Some overflow errors will be annoyingly small, but they still need to be fixed.
A common cause of an overfull \hbox is an included figure that’s been forced to
too large a scale. Another is verbatim text where the lines are too long. LaTeX
will not attempt to hyphenate verbatim text, and all it can do is let it overflow the
page. Yet another, especially given the variety of terminology and the use of URLs
etc. in ADASS papers, is the simple case where LaTeX would like to hyphenate a
word, but doesn’t know how to, and ends up leaving it poking into the right
margin.
Figure scales can be reduced until the figure fits properly. You may then have to
see how legible it is, of course. Verbatim text is something you will have to
reformat yourself – if it is program text, you may need to split the lines up. You
7

https://www.lemkesoft.de/en/products/graphicconverter/

can change the text size of verbatim text, perhaps with \small, and this may help.
You can use the \- directive to show LaTeX where a word can be hyphen\-ated, if
you have a word it doesn’t know, but in some cases you may have to modify the
sentence to fix the problem; a very small change, like changing “such as” to “like”
or vice-versa, may be enough.
If you want to combine two separate images into a single figure, the usual way is
to use \minipage. But this has a subtle way of generating an overfull hbox:
\begin{minipage}{0.3\textwidth}
\includegraphics{P999_f1.eps}
\end{minipage}
\begin{minipage}{0.7\textwidth}
\includegraphics{P999_f2a.eps}
\end{minipage}
Here, the two minipages together take up exactly 1.0 of the textwidth (0.7 + 0.3).
However, you get an overfull hbox. The problem is that each minipage is treated
as a word by LaTeX, and it inserts an interword space between them. The
(unintuitive) fix is to put a single ‘%’ after the first \end{minipage}, so it
becomes:
\end{minipage}%
The opposite warning, an under full \hbox, can be tolerated in some cases. You
need to look carefully at the result to see how it looks. If a line has been spaced
out by a ridiculous amount, some rewording may be needed. In general, you
should avoid ending a line with ‘\\’ – this is a common cause of under full
\hboxes. The ASP convention is that there is not normally a blank line between
paragraphs; you can use ‘\\’ to get this effect, and may feel it looks better, but it
should be avoided.
One genuine problem that, strangely, doesn’t always generate a warning is when
the running heads (specified using \markboth at the start of the .tex file)
overflow the space allowed. Usually the problem is the string used for the paper
title; if this is too long it will push the page number on the right hand page over
past the page margin. Oddly, LaTeX just lets this happen. If you have a long paper
title, check that this isn’t happening.

Authors and affiliations
The ASP ‘Instructions for Authors and Editors’ goes into great detail about the
format of the list of authors and their affiliations that make up the arguments of
the \author LaTeX command. It may seem quite petty at times, but it helps give
the complete volume a coherent feel, and it also means that things like an author
index can be added semi-automatically by parsing the \author command, if
necessary.

Read the ASP instructions for the details. A few points are worth emphasising:
If all authors are from the same institution, there is no need to give them
superscript numbers, and no need to number the single affiliation.
Generally, only the main author’s e-mail address needs to be given. If you really
want to publicise every author’s address, don’t do so by giving multiple versions
of the same affiliation with the same institute but different e-mail addresses.
Provide just one \affil entry for each institute, but supply multiple e-mail
addresses at the end, separated by commas.
The presenting author must be the first author of the paper. (It is a requirement
of the ADASS conferences that a paper must be presented by its first author.) In
the case of an invited talk, the first author must be the person who was invited.
Some authors seem to prefer to spell out forenames; others prefer to just use
initials. Either is acceptable, but be consistent. Put the surname last for each
author, separate the authors with commas, and if there are more than two
authors the last author’s name should be preceded by ‘and’.
If there are multiple affiliations, the ASP convention is that the commas
separating the authors should go after each author’s name and before the
corresponding affiliation number, as in “Ralph Alpher,1 Hans Bethe,2 and George
Gamow3”. Note that this “superscripts follow punctuation” rule is the same as
that used for footnotes.
If your name is Mario Vargas Llosa, or any name where someone from a different
culture (or, more the point, an automatic parser) might be confused as to
whether you are Vargas Llosa, M. or Llosa, M. V., it would help to note this in a
comment somewhere, or you may end up misrepresented in the author index.
Because of problems such as this with automatic parsing of the author list,
starting with ADASS 2018 we are now asking authors to add their own author
index entries. The \author command still needs to be formatted correctly, as
described above, but we have realised it is much easier for authors – who, after
all, know their own names! – to add the required entries.
There needs to be a separate author index entry for each author, each on a
separate line. These \aindex commands should come just before the abstract.
The \aindex command has a very simple format, with Surname followed by a
comma, followed by initials, for example:
%\aindex{Smith,~J.}
%\aindex{Vargas Llosa,~M.}
%\aindex{Kennedy,~J.~F.}

Note that these entries need to be commented out, as they will only be
recognised when the final volume is constructed – at which point they will
automatically be uncommented. Each initial must have a period after it, and a ~
before it to get the spacing correct.
Here are a few more examples, showing some of the less usual cases, such as
hyphenated surnames and first names, and juniors and seniors:
%\aindex{Picard,~J.-L.}
%\aindex{Downey,~R.~J.,~Jr.}
%\aindex{Fairbanks,~D.,~Sr.}
%\aindex{Lloyd-Webber,~A.}
%\aindex(Van der Waals,~J.~D.)
Please try to make sure that you and your co-authors are named consistently in
the author index. If you drop your middle initial in one paper and include it in
another, you will generate two author index entries. The same will happen if you
sometimes hyphenate a double-barrelled surname and sometimes don’t.8 The
editors will try to spot these cases, but it’s much easier if they don’t have to.

Length of Paper
Except in very exceptional circumstances (an extra page awarded to the winner
of the best poster competition, for example), page limits are as follows:
Invited Oral:
Contributed Oral:
Poster:
Demo:
Focus Demo:
BoF:
Tutorial:

10 pages
4 pages
4 pages
4 pages
4 pages
4 pages
4 pages

Editors will enforce these very strictly. Four pages are not very many, and it can
take some effort to keep a paper to that limit. There are some things that can
help. And there are some things that might help, but are not allowed.
•

Abstracts. You must have an abstract. But it does not have to be exactly
the same as the one submitted with your original proposal. Many people
tend to submit quite long abstracts with their initial proposal, using the
abstract to argue for having the paper accepted, or to be given as a talk.
Such abstracts may even include most of the content of the paper. The
abstract needed for the published paper, however, is simply a brief
summary of the contents of the paper.

The British are often inconsistent here. You see both David Lloyd-George and David Lloyd
George. Sacha Baron Cohen does not use the hyphen, but his brother, Simon Baron-Cohen does.
8

•

Footnotes. Although particularly appropriate for things like URLs, these
use up a lot of vertical space. You could always consider putting the text
in-line.

•

References. Note what is said in the section on References about the
verbose nature of some ADS-generated BibTeX entries. You can save some
space, as described in that section, by trimming these down. However,
remember that all references will be combined into a master .bib file,
which will be edited for duplicates, and as a result the final versions may
change slightly in format. If you trim your references too enthusiastically,
they may grow again in the final editing, so don’t rely too much on that.

•

Excessive \section and \subsection commands can constrain where page
breaks can occur, and can use up space.

•

Don’t try to gain extra space by using packages that modify the normal
spacing of the ASP layout. Such things exist, but they will interfere with
the construction of the overall volume, and would in any case make your
paper look different to all the others. The editors will remove such
packages and return the paper to you.

•

Don’t try to save space by making figures so small they are unreadable.

In the end, if you find yourself hitting the page limit, you probably need to get rid
of some text.

LaTeX packages and commands
The whole set of ADASS papers is processed as one big LaTeX job to produce the
final Proceedings volume. This means that your paper has to play nicely with all
the other papers, and in general this means sticking as far as possible to standard
constructions and not getting too clever with LaTeX. In particular, it means not
using non-standard packages, and not modifying the way commands work.
Your paper needs to have \usepackage{asp2014} at the start of the .tex file, but
that should be the only \usepackage command in the file.
Authors should not use \usepackage except in the most exceptional
circumstances. Many packages will interfere with the construction of the volume
(in particular, the subfig package performs global redefinitions of some key
formatting quantities and must not be used). The asp2014 package itself includes
all the packages that are usually needed. There is a list of these packages in the
ASP ‘Instructions for Authors and Editors’ (appendix E). If you believe you really
do need to make use of a specific additional LaTeX package, contact the ADASS
editors.
You should avoid changing the font size used for normal text in your paper.
However, it is OK to save space by setting verbatim text, or tables, in a smaller
13

font using \small or even \footnotesize. However, if you do this, make sure your
paper does not end with a small font still enabled. If it does, this will affect the
layout of subsequent papers in the final volume and you will not be popular with
the editors. Use braces, or \begin and \end, to restrict the range affected by
changes to font size.
Authors should never use \renewcommand or \renewenvironment in their
submissions! If it is absolutely necessary to redefine a command, authors should
create their own version that embeds a label that is unique to their article (e.g.,
\_itemize and NOT \myitemize).

Content and typesetting
There are some conventions in typesetting that should be followed by all authors,
so that the volume has a uniform appearance.
Footnotes are added in general after the corresponding punctuation "... like
this,\footnote{see here} ..." rather than "... like this\footnote{see here}, ...". The
difference is that the comma should go before the footnote, rather than after.
Different languages seem to have different conventions, but this is what the
Chicago Manual of Style recommends.9
“Interesting astronomical objects (AGNs, … )” where the ellipsis (“…”) indicates
that AGNs are only the start of a list of possible objects, is not standard English
usage. You can use “(e.g. AGNs)” or “(AGNs, etc.)”. The ellipsis is very rarely used
in formal written English.
Does English put a space in front of a question mark or an exclamation mark? No
it doesn’t! That space is the convention in other languages, like French, but it
looks odd in English, doesn’t it ? (As I typed that last sentence, my grammar
checker complained about the space, so that proves it.)
The ASP guidelines suggest that a volume should be consistent throughout in its
use of either British or American spelling. Given the range of ADASS authors, this
seems difficult to enforce. However, you should be consistent within your own
paper, and not say “color” on one line and “colour” on the next. Given how many
ADASS papers are about visualization, and how things are organized, it’s worth
pointing out that most verbs that the British now spell with “…ise” were
originally spelled with “...ize” even in Britain, so there isn’t much point in being
pedantic about that particular spelling difference.
Papers ought to be run through a spelling checker (set to your choice of British
or US English). This can be tricky with LaTeX text, where there are so many
“words” like “\usepackage” that most spelling checkers will complain about.
However, there are LaTeX-aware checkers available – Emacs has one, for
It’s easy to get wrong; the original 2016 version of this document managed to have two
footnotes that didn’t follow this rule.
9

example. Failing that, just read your .tex file into a standard word processor like
Textedit on the Mac, try to ignore the extraneous warnings, and concentrate on
the actual spelling errors.
Regrettably, there don’t seem to be any good LaTeX-aware grammar checkers.
Do proofread your paper for correct use of English. If necessary, get someone
else to do this for you. The standard of English in most ADASS papers by nonnative speakers is usually very good, but occasionally there are problems that
make it hard to understand the meaning of a piece of text, or that make it
awkward to read. Some that seem to crop up quite often are:
•

“Allows to do something” doesn’t work in English, although it does in
other languages. You have to “allow someone to do something”. You can
use “allows one to…” but that sounds excessively formal; “allows the user
to…” or even “allows us to…” usually sounds OK.

•

“Proposer” in French very rarely translates to “propose” in English – it’s a
‘false friend’, a word that sounds the same but has a subtly different
meaning. “Offer”, “suggest”, “recommend” are usually what is really meant.

•

English uses articles ('a','an','the') in places where other languages,
particularly Eastern European languages, don't have them. Remember not
to miss them out.

•

People seem prone to write long sentences, with lots of clauses in commas,
with the subject so far from the verb that they lose track of whether that
subject was singular or plural. Make sure your subjects and their verbs
agree.

•

Apostrophes often cause problems. The possessive for “it” is “its” without
an apostrophe. (Remember that “his” and “hers” don’t have one either.)
“It’s” is short for “it is”. Otherwise, singular possessives use apostrophe-s:
“the car’s route”, “the bus’s route”; plurals just use an apostrophe: “the
buses’ routes”.

•

“A software” isn’t English usage. We don’t talk about “softwares” and you
can’t count them or have just one of them. Usually you have to say “a
program”, or possibly “a piece of software” or “a library” or “an
application”, or something similar.

Most ADASS editors are not going to be pedantic about English usage, but they
will want the papers to be clear and easy to read; what matters is the work being
described, after all.

Miscellany
A common problem with \markboth is forgetting to change the values from the
defaults supplied by the template. Another, strangely, is using the author’s name
for both the author and the title fields.
The copyright forms are important. ASP will not publish your paper without a
completed copyright form, either an actual signed form or a scan in PDF format
of such a form.
Please do fill in the copyright form! We see a surprising number where the top of
the form has been filled in, but the form has not been signed and dated. And on
occasion we see one that has been signed, but nothing else has been filled in.
And, although it may seem old-fashioned, signing forms electronically – for
example using Acrobat to insert an electronic signature – is not acceptable. If the
form doesn’t look as if a human has signed it, it won’t do. Sorry about that. Such
forms will be sent back to the authors.

Appendix: The PaperCheck.py script
The ADASS2018.tar file containing the template .tex file, style files, and these
instructions, also contains a Python script (PaperCheck.py) that can be used to
check your paper for a number of possible problems. It is recommended that you
run it before submitting your paper, and try to fix any problems that it may find.
PaperCheck.py should run under either Python 2 or Python 3. It has been
developed under OS X, but should run equally well under Linux. It has not been
tested under Windows.
The simplest way to run it is to have it, together with the other Python scripts it
uses (AdassChecks.py and TexScanner.py), in the same directory as the .tex file
for your paper. You can then run it using:
python PaperCheck.py
where is the ID for your paper, ie O10-1 or P5-3 etc, and is
the surname of the first author of the paper.
You can always set the executable flag for the script, eg “chmod +x
PaperCheck.py” and run it directly, using:
./PaperCheck.py
The program produces relatively verbose output describing the tests it is
performing, followed by a summary of what it found.

Ideally, you will see the following in the summary:
---------------- Summary ---------------------------------------The paper has passed the very basic checks run by this program.
You need to make sure you have followed the ADASS manuscript
instructions, and you need to make sure that your paper
typesets without any LaTeX errors or warnings, and is within
the page limits.

Note that PaperCheck does not run LaTeX or BibTeX – it assumes that you have
done this and fixed any errors or warnings that these generate. Nor does it check
the length of the paper, or check spelling or grammar. What it does check for are
a number of common problems that the ADASS editors have found in the past.
For example, it checks that references use a .bib file and not \bibitem entries,
that all references are supplied, and that no additional references are included in
the .bib file. It checks that graphics files are .eps files, as required, and that they
are in the top-level directory. It checks that all the graphics files supplied are in
fact used by the .tex file. It checks that the running headers set up by the
\markboth entry are not just the default values, and it checks that the author list
can be parsed properly. It checks for the use of any non-standard LaTeX
packages. It checks for any unprintable characters in the .tex file, and checks for
the use of \cite instead of \citep or \citet.
Most papers will not pass PaperCheck the very first time. You will usually see a
message like:
---------------- Summary ---------------------------------------Some problems were found with this paper, as follows:
Problems were found with the use of LaTeX packages
For more details, see the earlier diagnostics from the various stages

In this case, you should look back at the more detailed output. In this example,
the detailed output contained:
Step 2

- Check for use of unsupported LaTeX packages -------

** .tex includes the following non-standard package(s):
hyperref
this may be a problem **

Some of the problems spotted by PaperCheck are less important than others: a
missing graphics file is clearly much more important than the presence of one
that isn’t used, for example.
Many papers have problems with the \author list. This is partly because the ASP
rules for the format of the list of authors are very precise and it is very easy to
get a comma in the wrong place or to forget that authors should be listed with
the surname last (unlike the standard way of listing authors for references).
Problems such as this should be fixed, but there are cases where the parser will
flag a possible problem with a perfectly correct author list. For example, if an
17

author has a multi-word surname like “di Marco”, the parser will get this right,
but will ask for this to be checked. It is a good idea to check the parsing of the
author list in the detailed PaperCheck output, because the same parsing is used
to generate the author index for the final volume, and we really want to avoid
getting authors’ names wrong.
If you are using an editor that generates characters that are not in the basic
standard ASCII set – for example, LATIN-1 accented characters, or UTF-8
encoded Unicode characters – PaperCheck will recommend that these be
replaced by standard LaTeX sequences. Not all LaTeX installations support these
extended character sets. Additionally, we have seen papers that use OS X roman
characters, which overlap ambiguously with the LATIN-1 extended character set.
PaperCheck will flag any such use. It’s annoying to have to replace, for example, a
perfectly good é with \’{e}, but this does guarantee that your paper will be
typeset properly in the final volume.

Appendix: The Index.py script
The Index.py script is included in the ADASS2018.tar file, and is intended to be
used to help generate entries for the subject index found at the end of the
Proceedings volume. Traditionally, these entries have been inserted as part of
the editing process by the ADASS editors, but it makes their job much easier if
authors insert these entries themselves.
Index.py should run under either Python 2 or Python 3. It has been developed
under OS X, but should run equally well under Linux. It has not been tested under
Windows.
The simplest way to run it is to have it, together with the other Python scripts it
uses (AdassChecks.py and AdassConfig.py), in the same directory as the .tex file
for your paper. You can then run it using:
python Index.py
where the term that you want to generate an index entry for.
You can always set the executable flag for the script, eg “chmod +x Index.py” and
run it directly, using:
./Index.py
An index entry has the form:
\ssindex{topic!sub-topic!sub-sub-topic}

where the sub-topics are optional. ADASS volumes only support up to three
levels in the subject index, but they do generally make a lot of use of all three
levels. The VLT, for example, is indexed as:
\ssindex{observatories!ground-based!VLT}
When the \ssindex entries are added at first, they need to be commented out, as
\ssindex is not defined. When the full volume of the proceedings is typeset, the
entries will automatically be un-commented. So, if, for example, your abstract
makes a significant mention of the VLT, you should have a line:
%\ssindex{observatories!ground-based!VLT}
Note that because this is commented out, it needs to be on a separate line,
otherwise it will affect any text that follows it.
Ideally, of course, such an \ssindex entry should be as close as possible to the
VLT reference in the text. However, in practice, it merely needs to appear on the
same page. So, for example, it is common to collect all the %\ssindex lines for
terms that appear in the abstract in a block just after the abstract. (If your
abstract runs into the second page, you need to allow for this, but very few
abstracts are that long.)
You do not need to put in a huge number of index entries. ASP guidelines suggest
that three or four per page is sufficient. You do not need to index the same term
more than once for any paper; someone looking for the term in question will be
led to your paper, and that’s what really matters.
The most important thing about index entries is to try to keep them consistent.
The VLT could be indexed as shown above, but could also be indexed as
\ssindex{VLT}, \ssindex{telescopes!Very Large Telescope} etc., etc. However,
having all of these used, more or less randomly, would lead to a very confusing
and less useful index.
The Index.py script tries to do two things:
•

It makes it easy to generate the %\ssindex strings, formatted properly,
that need to be inserted into the text.

•

It uses the cumulative index entries for the most recent ADASS
proceedings (held in the file subjectKeywords.txt) to generate consistent
entries.

For example:
./Index.py VLT
will print out

Looking for index entries matching 'VLT'
%\ssindex{instruments!individual!VLT/UT2}
%\ssindex{instruments!individual!VLT/UT4}
%\ssindex{observatories!ground-based!VLT}
3 entries in master index

and of these, the entry you want is almost certainly:
%\ssindex{observatories!ground-based!VLT}
which you can easily copy and paste from the terminal into your .tex file. You
may find you don’t care for the existing hierarchical entries, but please do try to
use them if possible rather than adding a new, different, entry for something that
already exists.
What if an entry doesn’t already exist? For example if your paper describes a
new, proposed, Ludicrously Large Telescope, (LLT), and you try
./Index.py LLT
you will get
%\ssindex{applications!Q-FULLTREE}

(Note that all the program is doing is a case-insignificant search on all the
existing entries.) This may include ‘LLT’, but it clearly isn’t the entry you want, so
you have to introduce a new one. You should try to be as consistent with the
existing entries as possible, so you might think of something similar – perhaps
the VLT – and see how that would be indexed. On that basis, you should probably
modify the result you get from a search for VLT and use:
%\ssindex{observatories!ground-based!LLT}
assuming your LLT is ground-based, but that seems quite likely.
By the time the next ADASS conference comes around, your new entry will have
been extracted from the proceedings and added to the new version of the
cumulative index file, ready for someone else to use.

History
This document was originally prepared for ADASS XXVI in Trieste.
Modified July 2017 for ADASS XXVII in Santiago.
Modified September 2017 to add the appendices on the PaperCheck and Index
scripts, and to emphasise the importance of naming the submitted .tar or .zip
archives correctly.
Modified May 2018 for ADASS XVIII in College Park. References to the Santiago
conference and the conference number have been modified. A couple of minor
grammatical changes were made.
Modified October2018 to add a description of how to add author index entries.

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.3
Linearized                      : No
Page Count                      : 21
Title                           : ManuscriptInstructions
Author                          : Keith Shortridge
Subject                         : 
Producer                        : Mac OS X 10.13.6 Quartz PDFContext
Creator                         : Word
Create Date                     : 2018:10:18 23:05:01Z
Modify Date                     : 2018:10:18 23:05:01Z

EXIF Metadata provided by EXIF.tools

Manuscript Instructions

ManuscriptInstructions

ADASSManuscriptInstructions

Navigation menu

Versions of this User Manual:

Views

Navigation