# Best Practice: Match different Journal specifications

In most cases one does not write papers for one journal exclusively. Changing your code to match all specifications takes a lot of afford and time. There is a wide variety of question referring to this topic

Going through the comments it looks pretty hopeless to find »One Package To Rule Them All«. Licences and changing templates make it nearly impossible to maintain all of those templates in one class or package.

Point is, are there some sort best practices to save time writing articles for different journals?

• +0.25 For One Package To Rule them all and 0.75 for the question itself ;-) – user31729 Dec 26 '15 at 15:18
• Use a standard class e.g. article.cls with as few packages, as few custom macros and as little non-default configuration as possible. – cfr Dec 26 '15 at 15:19
• There is not more than what is said in comments to tex.stackexchange.com/questions/276793/… so I don't think this question is really useful. Journals wouldn't accept anything else than their standard stuff, so unless some newly developed system converts your input file to their standard, it is useless. – yo' Dec 26 '15 at 15:33
• I just answered a question related to svjour3, which requires new theorem-like environments to be defined with \spnewtheorem rather than \newtheorem. Just a small example. – egreg Dec 26 '15 at 15:40
• @IgorKotelnikov Doing so in parallel may be against such policies, but doing so in series is most assuredly not. Some articles go through the 'submit-wait-reject' cycle many times before finding their natural home so it's not unnatural to submit an article to several journals in its lifetime. Moreover, some archival repositories have strange requirements and it's common to upload the manuscript to several repositories as well as submitting to a journal. So it is a perfectly reasonable thing to have several simultaneous versions of an article, and therefore this is a sensible question. – Loop Space Dec 30 '15 at 19:21

(A journal copy editor speaking.)

Basically, no, there is not much you can do. There have been ideas (nothing got to the final stage AFAIK) of providing a uniform way to input all metadata, so that the headers (everything until first \section of the article) looks the same for all journals. However, I doubt journal publishers would accept this sort of input; for one, I would not.

So, the provided system had to convert the input file into a new LaTeX file which looks as needed by the journal. This itself is not that much a problem (basically, it's just a data manipulator). However, developing such system and making people learn it is probably more work than simply modifying the file according to an example file provided by the publisher.

We also need not forget that some journal classes use different than standard macros for various necessary stuff, such as theorem environments in Springer classes. This makes any such efforts far from complete and useful.

To conclude, as of December 2015, no such system exists, to the best of my knowledge.

• Why would you object to a unified metadata interface? – Federico Poloni Dec 26 '15 at 19:05
• The problem is: I'm not willing to lose a single minute on a stuff that the author messed in 3rd party packages. Springer's theorem definitions are not strange, just named differently. – yo' Dec 26 '15 at 19:39
• @FedericoPoloni (things have gotten off-topic here really) the priority is below low for this thing, from the point of view of moreorless everybody involved. – yo' Dec 26 '15 at 21:23
• @FedericoPoloni -- latex is, sadly, far from a high priority except for relatively few publishers in very tightly delineated fields, and even they tend to take (la)tex for granted. very little development (or even maintenance) effort is going on there; they are under too much pressure to make their publications available in e-book format, able to be read on portable devices, to the neglect of paper (which, at the moment, "just works"). there is also considerable downward pressure on costs. without "public" encouragement, this isn't likely to change any time soon. – barbara beeton Dec 26 '15 at 22:25
• None of this really explains the principled refusal to even consider accepting metadata in a standard format, were such a format to come into existence. That seems like a determination to make authors waste time reformatting metadata into a journal or publisher specific format even if it turned out that a standard format emerged which would serve your current needs perfectly. I could understand rejecting any particular proposal or not wanting to put effort into developing one. But why a prior rejection of something which would standardise things a tiny bit, regardless of how well it fitted? – cfr Dec 27 '15 at 3:41

Yes, there are best practices. On this side of the pond, I would say that the secret is:

Macros, macros, macros.

On 't other, I would say:

It's macros, stupid.

As the comments on the (at time of writing) other answer, no-one is going to do it for you but there are things you can do to make life easier for yourself. Many years ago, I developed a system to make my life easier with journals. It was predicated on the following concepts:

1. When actually writing an article, it's highly unlikely that I'll know which journal I'll submit it to.

2. When actually writing an article, it's important that the writing not get in the way of the ideas so I want to use my own macros which make my life easiest.

3. Once the article is at the stage at which I want to submit it, I may need to put it in the journal's style at time of submission but I don't want to spend too much time doing that because experience says that the submit-wait-wait-wait-reject cycle will be repeated several times per article. Also, the arXiv is included in this as it generally has old versions of packages.

4. I'm quite likely to submit to the same journal more than once, so devising a system that works for specific journals is worthwhile.

5. Once an article is accepted, I'd be happy to do whatever modifications are needed to make it fit but only then.

So I wrote my own class which was a wrapper for all the journal classes that I've ever submitted to. There's only a certain amount of information that the journals need in the preamble although they are infinitely inventive in how they ask for it (some of them seem to go out of their way to make it complicated - the one that used \obeylines was my personal ... favourite). So storing it all in macros and then doling it out as required is a solvable problem.

Similarly, there generally are only a limited number of things that journal style files define. Some mathematical operators, some theorem environments, and not much more. So again, a few macros to provide wrappers between how I want to write my articles and how journals want them is a solvable problem.

So a typical article starts:

\documentclass[%
a4paper,%
%lms,% <-- this class has options for the various journals I've submitted to
%draft,%
defaults,%
]{myclass}

\usepackage[%
bb,%
geom,%
%track,%
]%
{mymacros}

\theoremstyle{\myrmkstyle} % <-- the remark style is set by my macro package
\providetheorem{examples}[theorem]{Examples}

\mytitle{%
% <- Title will go in here
}

\myshorttitle{%
% <- Short title here
}

\mydate{\today}

\mysubjclass{% <- AMS Subject classes
}

\myauthor{%
% <- Me!
}

}

\myemail{%
% <- Bet you can't guess this one
}
\myurl{%
% <- Or this one
}

\myabstract{%
% Abstracts get handled variously so we store it here first
}

\mybibliographystyle % <- The actual style will generally be set in the class file

\begin{document}

\mymaketitle % <- Puts all that junk in the right place in the document


Multiple authors are specified simply by adding more details. Each \myauthor triggers a new author and all following information pertains to the last named author.

Anyway, the point of it all is that I don't have to think about the journal when writing the article. I can just cut-and-paste from one article to another and change what needs changing.

Inside the myclass.cls file is a lot of hackery (and pretty awful hackery at that - I wrote it before this site existed) which puts the information in the right place (the complementary mymacros.sty tends to handle stuff like defining operators). It also handles loading packages according to the class - some journals' class files load things like amsmath and some don't so the class has a system for automatically loading packages. It can take a bit of time to figure out all that needs to go in this middle layer when I add a new journal, but generally at that stage of writing an article I'm quite happy to have a task like that to do. And as I said, it's rare that I'd submit to a journal only once so it's a time saver in the long run.

• Fascinating. I don't suppose your system can cater for journals which require DOC or DOCX format by any chance? Maybe more relevant to your situation (as opposed to mine): are you typically submitting source? If so, how do you generate the .tex to submit? – cfr Dec 27 '15 at 3:47
• This looks like it is exactly what was asked in the two questions linked by OP, tex.stackexchange.com/questions/227424/… and tex.stackexchange.com/questions/276793/…. You should consider releasing it. – Federico Poloni Dec 27 '15 at 11:09
• @cfr The journals I used to submit to all required LaTeX source code in the end (some were fine with PDF at submission, but wanted the LaTeX if accepted). I've no idea what I would do for DOC/DOCX. On initial submission, I would just send the LaTeX file with the class & style files attached (and I'd include a PDF) and wait to see if I got any complaints. If the article was accepted, then I would take the time to remove all my customisations but I wouldn't mind that because the article was accepted. It's doing it prior to acceptance that I objected to. – Loop Space Dec 30 '15 at 19:14
• @FedericoPoloni The best you'll get is me putting it on github. It's not pretty code, and each additional journal needs to be added by hand. I could make it modular, I suppose, but even then it's a pain to work out what a new journal needs (the one that used \obeylines was a particular favourite of mine!). Moreover, I no longer need such a class so have no interest in maintaining it. – Loop Space Dec 30 '15 at 19:16

Authorea lets you write your entire article in a non-specific format.

Once you are finished (or whenever you want) you can select among lots of different journals to generate your .tex or even the final pdf.

You can also upload your own .tex template file or load it from a number of other services (Overleaf, Sharelatex).

You can use the service for free (one private article and unlimited public articles).

• So how does this cope with the variable markup for content required by different journals e.g. different ways of specifying metadata, different macros for formatting tables, abstracts, keywords etc. etc.? – cfr Dec 27 '15 at 3:49
• Can the system import .tex code? – cfr Dec 27 '15 at 3:49
• Not really sure @cfr, but you can try it and see for yourself since it's free :) – Gabriel Dec 27 '15 at 14:29
• @Gabriel Given your last comment, this looks like a pure advertisement, if you don't even know whether the system can input LaTeX... – yo' Dec 27 '15 at 21:04
• @Gabriel Thanks, upvoted. I think it's important to show how much the proposed software is relevant, especially if there's a premium version which costs money. – yo' Dec 27 '15 at 21:15