25

I publish a lot for science journals and some of them are very strict on the number of pages your manuscript will be, as usual the final version of the articles is double column but for review and stuff like that it is always ez to compile as single column.

My question is this, Is there a way to compile just one .tex file and get a Single column pdf and a double column one?

I read that this could be achieve by use of \write18 but I don't understand at all how

I guess must be something like this:

\documentclass[layout=onecolumn]{SomeJournalStyle}
all the preamble

\write18{pdflatex "2Columnversion" Master.tex some script/modifier to change column layout at preamble }

\begin{document}
.
.
.
.
.
\end{document}    
Peter Grill
  • 223,288
Jared Lo
  • 652

4 Answers4

20

I would recommend you use a command line option to specify the column type. So the MWE below with either of these two:

pdflatex doc.tex

or

pdflatex "\def\ColumnType{onecolumn}\input{doc.tex}"

will produce a single column layout, but with

pdflatex "\def\ColumnType{twocolumn}\input{doc.tex}"

will produce a two column output.

Code:

\ifdefined\ColumnType
\else
    \def\ColumnType{onecolumn}
\fi
\documentclass[\ColumnType]{article}
\usepackage{lipsum}
\begin{document}
\lipsum[1-5]
\end{document}
Peter Grill
  • 223,288
11

The arara automation tool can help to automate the idea given by Peter Grill in his answer.

You simply save the following arara rule, onetwocolumns.yaml, into a directory where arara knows to find it, and then you can run

arara myfile

on the following file, and you'll receive two pdfs:

myfileONECOLUMN.pdf
myfileTWOCOLUMN.pdf

The arara directives are detailed in the rule file but, just for clarity, you can use them in any of the following ways:

% arara: onetwocolumns
% arara: onetwocolumns: {columns: onecolumn}

The default value of columns is twocolumn but you can change that as you see fit.

myfile.tex

% arara: onetwocolumns
% arara: onetwocolumns: {columns: onecolumn}
\ifdefined\ColumnType
\else
    \def\ColumnType{onecolumn}
\fi
\documentclass[\ColumnType]{article}
\usepackage{lipsum}
\begin{document}
\lipsum[1-5]
\end{document}

onetwocolumns.yaml

!config
# Make one and two column document 
# author: Chris Hughes
# last edited by: cmh, April 26th, 2014
# https://tex.stackexchange.com/questions/173532/two-pdf-versions-from-one-single-tex-file
# requires arara 3.0+
#
# Sample usage
#
# % arara: onetwocolumns
# % arara: onetwocolumns: {columns: onecolumn}
# % arara: onetwocolumns: {columns: twocolumn}
#
identifier: onetwocolumns
name: OneTwoColumns
commands: 
- <arara> pdflatex "\def\ColumnType{@{columns}}\input{@{file}}" 
- <arara> @{ isWindows( "cmd /c move", "mv" ) } @{getBasename(file)}.pdf @{getBasename(file)}@{columns.toUpperCase()}.pdf
arguments: 
- identifier: columns
  flag: <arara> @{parameters.columns}
  default: twocolumn
cmhughes
  • 100,947
2

I have often used a solution like Peter Grill's for things like this, but sometimes I do it this way: a 'content' file and then two 'shell' files. I find this more convenient when there are going to be many differences in how things need to be formatted in the two files. (This can be achieved quite easily with conditionals, but sometimes I just end up going this route...)

The 'content' file is pretty simple

% content.tex
This is the file that has all the actual content

and the shell files contain all the formatting directives

% shell-1col.tex
\documentclass{article}
\usepackage{...}
% other specific stuff for the one-column layout
\begin{document}
\input{content}
\end{document}

(if the two shell files will have a lot of overlap, it is probably wise to wrap that all up in a .sty file that both include)

% shell-2col.tex
\documentclass[twocolumn]{article}
\usepackage{...}
% other specific stuff for the two-column layout
\begin{document}
\input{content}
\end{document}

And compilation is easy:

for f in shell-1col.tex shell-2col.tex ; do latex $f ; done

As for which is better, the conditional route or the two separate files route, I suspect it depends on a number of factors. My advice is try both.

jon
  • 22,325
1

To achieve what has been suggested in other comments - namely, using \input to read in the meat of your document into various "shell" documents that may use different styles, I ended up doing a few additional things. I have one common file that contains helpful commands used in many of my LaTeX projects. For instance, you may want to define commands that can insert an abstract.

For conditional formatting, you may also want to use something like ifthenelse. Finally, I suggest putting the common files in a subdirectory and each "shell file" project (e.g. the file with the \documentclass) in their own directories. For more on this structure, see Path to External Files in Nested \input and How to include files from a directory specified by a concatenation of text and a macro?.

bbarker
  • 1,177