Technical requirements for Judgment and Decision Making (JDM)

This information applies to articles that are accepted for publication. Articles submitted for review do not need to follow these guidelines, although it is helpful if they are in a format that anyone can read, and if they have the footnotes, figures and tables in the text rather than at the end.

However if you ar preparing an article with the idea that you might submit it to JDM, then you can save time later by anticipating some of the technical requirements (explained in more detail below), in particular:

So far we have no charges for authors. This is because I (Jon Baron) do the production, with the help of lots of open-source software (listed below). If you follow these guidelines, I can produce an article while reading it through to make sure it makes sense, something I would do anyway, with little extra time. I can tolerate some deviations from these guidelines, but, if the deviations are major, I will ask you to fix them. You are free to hire someone to help you do this (and this may still cost you less than what other open-access journals charge).

Timing: Regular issues of the journal appear every two months starting February. Final versions of articles are due the 15th of the month in which the issue appears. In most cases, when an ariticle is accepted pending revision, the revision (with a letter explaining what was done) is the final version, even if some further editing is required.

Style notes

Graphics

Please submit all graphics as separate files, as well as leaving them in the document.

When you make graphs, think about how they will fit in a two-column layout. Are they one column or two? Then adjust the font size so that it looks right given the width of the figure (roughly 3 inches for one column, 6 inches for two).

Put legends (e.g., identifications of line types) inside of the box of the graph.

For graphs, use vector formats such as eps (Encapulsated PostScript, which is what I use), PostScript (ps), xfig, or svg (scalable vector graphics). These can be re-sized easily. Unfortunately, these formats can include raster (bitmap, non-vector) data, and many proprietary program tend to include these raster images even when they are saved in a vector format.

If you have a choice of fonts, please use Helvetica (or, if you have it, Nimbus Sans). Other fonts (aside from Times Roman, Courier, and probably Arial) should be embedded (defined in the file you send).

One program that does everything correctly "out of the box" is R, which is what I use when I need to re-draw something. If you use R, send the R code. Stata, Matlab and SigmaPlot produce good eps output. With SPSS use "ps output". Whatever you use, choose options for "no preview" and "convert to postscript fonts" if these are available.

For diagrams, a useful and easy-to-use tool is Mayura Draw. It makes nice EPS output.

For other images, such as photos, a bitmap (raster) format is necessary (e.g., bmp, png, gif, tiff, jpg). The bigger the better. It is easy to shrink. Hard to expand.

Note that we are not bound by the need to call every graphic a "figure". You are free, for example, to use Sparklines, so long as other graphic requirements are met.

Text formats

I accept most word-processor formats: Open Document Format; OpenOffice Writer; Word Perfect; Microsoft Word (doc, but not docx); and rtf. I prefer text files formatted in LaTeX, especially for articles with a lot of math. See below for special notes about LaTeX or for word processors. This section applies to both methods.

Special notes for LaTeX

Use LaTeX for formatting if possible. Please use a minumum of additional packages and do not attempt to control positioning, spacing, or width (unless you use the template). Specifically:

A template is here.

See the instructions for the title page for word processors, below, to make sure you include all relevant information.

Every published article has a .tex version. To find it, look at the URL of the html version, replace "htm" or "html" with "tex". Later articles are better examples to imitate (because I'm using Hevea rather than Tth to make the html version).

Special notes for word processors

The general principle is that I convert these to LaTeX using many wonderful open-source programs (OpenOffice, writer2latex, sed, and hevea for the html). What is easy for these programs and what is easy to read on a printed page are two different things.


Some technical details

Authors do not need to read this section, but it seems to be a good place to document some of the methods used in production. The basic idea is to produce a .tex file, with settings in the header for two columns and other things like foreign characters, math, and nice tables. To get this from a word-processor document I use OpenOffice to produce .sxw, then writer2latex to produce .tex. After I fix this up, when everything is final and the proof is approved, I use hevea to produce the html version. When the whole issue is done, I produce files for RePEc, DOAJ, the various indexing organizations, and the rss feed. The table of contents is a by-product of these operations, as is the listing by author.

For converting word-processor formats to LaTeX, and LaTeX to html.
My notes on LaTeX
Batch file to convert .sxw (made by OpenOffice) to .tex, using writer2latex
configuration file for writer2latex
configuration file for HEVEA (for making html)
CSS file for html version

For RePEc (Research Papers in Economics), table of contents, citations, and notifications. (Perl scripts by Adam Kramer and Alan Schwartz.)
notes on usage
Template for 'dat' format
Make table of contents
Convert 'dat' to APA format
Make RePEc 'rdf' format
Make 'ris' format
Extract abstract from .tex files
R script for making rss feed from RePEc rdf
R script for DOAJ (and archives)

When I need to re-draw figures, I use R. Here are some examples. The numbers are related to the articles. For example, "8221/figs.R" has results in "8221/jdm8221.pdf".


Jonathan Baron