Many document classes seem to have their own way of defining document title and author information, often with only subtle differences. (\title seems to be pretty much standard everywhere, in contrast to \author.) Have there been efforts to create a consistent interface for this kind of metadata? This could be the union of all metadata supported by any of the many document classes out there, with adapters to existing document classes and perhaps warnings if a setting is not supported. Something along the lines of:

\title{Document title}
\subtitle{Document subtitle}
\author{First Author, email=first@author.com, affiliation=..., }

The benefits of such an interface would be:

  • Users need to learn only one way to define document metadata
  • Two document classes that support this interface can be used interchangeably
  • For document classes that do not support this interface, wrappers could be provided via packages

At our site, we have a home-grown solution with a nonstandard syntax. I wonder if and how others have tackled this problem.

  • 2
    Sorry, this is impossible. Because for instance AMS journals prefer to have at most 2 addresses for a person, one "permanent" and one "current", whereas the journal I typeset has abritrary number of institutions, and the address is printed only once for each institution. They prefer having e-mails of all authors, we prefer having only one corresponding e-mail, but it needn't be of the first author. Do I need to continue? And btw, I hate people who "know better than the typesetter" what they do. Better read the journal instructions instead of looking for such a non-sense interface. – yo' Oct 11 '13 at 11:07
  • @tohecz: The whole idea is that the document class should be able to grab the information it needs/want to display, which the user provides through a standard interface. I don't see how this contradicts your (very emotional) comment. In your case AMS would look for a person's current address (\author{..., address=..., current.address=...}), and your journal would collect and sort the addresses of all institutions. Your journal would print only the e-mail address of the corresponding author (\author{..., corresponding}), while AMS would print all e-mail addresses. Do I need to continue? ;-) – krlmlr Oct 11 '13 at 11:28
  • I've done this for every journal class file that I've encountered. I define a new set of commands, such as \mytitle, and then behind the scenes each journal class gets fed the information that it needs in its own preferred way. My class for doing this is at math.ntnu.no/~stacey/HowDidIDoThat/LaTeX/MyClass.html Some journals have been more difficult than others to integrate (and I've been told off by journals for doing this, but if they accept the article then I'm happy to do any modifications they ask for). – Andrew Stacey Oct 11 '13 at 12:51
  • 2
    No, sorry, that's too much work with too little gain, both for the authors and for the class maintainers. It takes hundreds of hours to make an article, and 10 minutes to open the instructions and write the credits as the journal wants. And in the end, there'll be cases that you don't cover by the general approach (or you would have to make it too complicated whence useless). – yo' Oct 11 '13 at 14:21
  • @tohecz: If you multiply 10 minutes by the number of submissions (which might or might not be accepted), the maths look a bit different. These 10 minutes are wasted time. -- I agree that the interface has to be very versatile and extensive. – krlmlr Oct 11 '13 at 16:50

There are really two questions here: how to define the interface and how to implement it. I'll only tackle the former, because the implementation would require several hours' work.

First you have to decide whether using non standard commands, say \Title and \Author instead of \title and \author. There are many classes around and different realizations. For instance, the standard classes (article, report and book) allow for only one \author command, others want that different authors go in distinct \author commands (amsart does this).

I'll assume you go with \title and multiple \author commands for maximum flexibility. The best approach is, in my opinion, using a key-value syntax.

A document always has a title, and sometimes a short title for the header or a subtitle. I would do it like

  subtitle=A subtitle,
  short-title=A short title
]{The very long title of this document}

rather than providing a bunch of commands such as \subtitle and \shorttitle: in this way all the data are in one place. Similarly for author information:

  affiliation=University of Someplace,
  affiliation-secondary=Institute of Silly Investigations,
  address=42, Hidden Road, Someplace,
  abbreviated-name=A. Uthor,
  thanks=Research grant 1234567890,
]{Abigail Uthor}

  affiliation=University of Nowhere,
  long-name=Winfried Riter,
]{W. Riter}

]{B. C. Dull}

Note that I used several keys that can be used or not by your class. For instance, key=writer could make it possible to share affiliation information between two or more authors. The more detailed and classified is the information, the easier will be to implement a set of commands that process it.

Talking of user interface, something like \AtBeginDocument{\maketitleandabstract} is surely not something document authors should be supposed to type. This will be done by the class; the classical approach with \maketitle can be used too.

I'm also keen towards placing this information after \begin{document}. If you do it in this way, you can free yourself from the burden of adding the \maketitle command: just define a articledata environment, whose end automatically issues \maketitle. So





  this is the abstract

  a list of keywords

<paper starts here>


With a simple switch you can warn that commands such as \author, \title, \abstract and so on must go in the articledata environment (or issue an error message). It will be also easy to provide a package with a compatibility option that redefines the commands and the environment so that the document becomes compatible with article.

  • 1
    Thanks a lot for the valuable suggestions. They definitely will be useful when attempting such an implementation -- the user interface should be done once and done right. Actually, it should be possible to allow the articledata environment both within document (the way you describe it) and outside document (having it issue an \AtBeginDocument{...} command to typeset the "front matter"). Ideally, the metadata should be used for hyperref's PDF comments, too -- is this possible within the document environment? – krlmlr Oct 11 '13 at 20:15
  • @krlmlr \hypersetup{pdftitle=Title, pdfauthor=Someone} works also after \begin{document} (just checked). My preference is towards having the data after \begin{document} so they won't be hidden in the preamble; anyway, just check in the articledata environment where it's placed and in case issue \AtBeginDocument{\myclass@maketitle} where the command does all the related work. – egreg Oct 11 '13 at 20:21
  • One more thing: Is there a particular keyval package from the big list that you can recommend for this task? – krlmlr Oct 11 '13 at 20:37
  • @krlmlr That's a tough decision. I'd go with the LaTeX3 functions. – egreg Oct 11 '13 at 20:41

I have a class that does this. It is imaginatively called myclass. I wrote it out of frustration with journal classes all having different ways of wanting the same information. The reasons why are:

  1. I rarely know which journal I am going to submit to when I set out writing my article. So customising it to fit the journal is something done at the end.

  2. Sadly, I often end up submitting an article to several journals. It's always a bit ambiguous as to whether or not they should be submitted in the "house style" and in my early days I'd put it in the house style just in case. But changing journal style can involve large changes to the document so having a more "plug and play" method makes sense.

  3. It's not uncommon to have several versions of the article on the go: one for submission, one for the arXiv, one for some other repository; and each will have its own idiosyncrasies. So being able to change one option makes life that much easier.

  4. Unfortunately, journals don't just supply a class. They also tend to supply a load of "helpful" macros. These often conflict with my own macros - but since I didn't know which journal I was going to submit to at time of writing, I don't want to think about these conflicts at time of writing. Ideally, I don't want to think about them at all.

The underlying ethos is this: when writing my article, I want to be able to make use of all the things in LaTeX that make it easy to write an article. Thinking about which journal I'm going to submit to conflicts with this. But once I've written the article then I don't want to waste a lot of time (and it really can be a lot, due to point 4 above) changing everything.

My class is not very elegant or sophisticated. It was written long before I happened on this site and I've learnt a lot since then. So I'd probably do it all differently now. Nevertheless, it stands as an example.

(Incidentally, some journals have really weird ways of accepting input. Getting them right was ... difficult.)

As for why a class and not a package, it makes the interface easier. All I need to do is change one option to my class. If I made it a package then I'd have to change the class and probably some options to the package. Too much work!

  • Thanks a lot for the writeup, I couldn't have explained the motivation better :-) Also, the idea of a "meta document class" is interesting. Point 4 is alarming, though... – krlmlr Oct 11 '13 at 20:08

This question did come to my mind several times. But, I would never even dreamed to attempt a general solution. Thinking about it led to similar concerns as expressed by @tohecz. But, looking at @egregs solution inspired me to extend it.

The problem which remains is that an interface with with a finite set of commands to gather meta data won't be able to cover all cases. Hence, an ideal interface must be able to provide a command that allows users to create custom metadata-commands, such as '\newmetacmd', one that can redefine the existing ones, and one to rudimentarily restyle the appearance. With this approach the problem arises of how to include the information of the custom commands to the title. (If they are custom they can't be coded into \maketitle beforehand. Well, there would be a possibility, but it is very limiting...) My idea to solve this consitst in considering every collection of information coming from one macro, e.g. \title[...]{...} as one block. So, the \title macro will produce something like \block1 behind the scenes. All these blocks/chunks will be gathred at the end of a articledata (or maybe documentdata) environment using a loop. The ordering will be determined by the emergence of the \newmetacmds (or better \newttlblocks) in the preamble, and it will be influencable somehow - also regarding the predefined commands \title, \author and \date. In detail it would look like


(where the integer parameter gives the ordinal position of the block; if empty, it will be the next one after the last block) which than would be used as


As addressed further up, there would be something like

\ttlblocksetup{newinfo}{<space below>}{<alignment>}{<font>}

and also


Funtionality could of course include the usage of multiple authors (pointing to AMS classes) too.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.