In my limited LaTeX experience, I've always found that I can accomplish what I want by just using the relevant set of packages, even for more complex formatting. If I were to try and create a configuration for someone else I would be hard-pressed to justify creating a class file; instead, I would just create a config.tex file that includes the relevant packages and commands and then tell them to just \input it in their main file. However, I'm sure that there is some additional flexibility afforded by creating a class, so my question is: When is it actually worth writing class files?

EDIT Some further clarification of what exactly I'm asking. My question was more meant to address the case where a more specialized class is called for, such as the one in Alan's answer. In the case of, say, maintaining a thesis template for a university, what is the advantage of creating a custom class instead of just using packages? The beamer example is a good instance where the entire layout is different, but in that case what we're doing is creating an entirely different template. In the thesis case, though, I would guess that the base class does a LoadClass of article (or something similar) since we're generically constructing something pretty similar. To that end, I'm trying to understand why that approach would be preferable to the package-based configuration approach I stated above.

  • The thing is: you can load 1000 packages in a config file, a package or a class. If nobody ever uses the packages loaded, there is no gain in either.
    – Johannes_B
    Commented Aug 12, 2015 at 17:25
  • 1
    By the way, this is known as template confusion. You can visit our nice little chat for some further thoughts.
    – Johannes_B
    Commented Aug 12, 2015 at 17:26
  • @Johannes_B What chat are you referring? Also, I don't disagree with your first point but it doesn't answer the question of why a class file might be preferable; obviously you could make a useless class just as easily as a useless config file, but the question is what problems a class can solve more easily than a collection of packages
    – Vyas
    Commented Aug 12, 2015 at 18:19
  • chat.stackexchange.com or more precisely chat.stackexchange.com/rooms/41/tex-latex-and-friends :-)
    – Johannes_B
    Commented Aug 12, 2015 at 18:38
  • Though i really agre with all answers so far, i think at the current state, the question is kind of broad. Can you specify a bit?
    – Johannes_B
    Commented Aug 12, 2015 at 23:00

4 Answers 4


I think there are two very different kind of class files: general purpose class files like memoir and KOMA, which strive to create a uniform interface to most aspects of document formatting, and specialized class files for particular document types. Peter Wilson has already addressed the first type in his answer.

But there is another kind of class which is designed to provide predefined formatting for a particular document type. I maintain a thesis class for my university. Being an American institution, it sets out very particular and stupid formatting guidelines which all theses must follow, (in addition to specifying particular wordings in title pages etc.)

For this kind of use, a class file is quite useful. I provide a document class which people can simply "pour" their content into, knowing that the university guidelines will be met without their having to think of them. Crucially, the class does only this: it doesn't load other packages such as font packages or bibliography packages etc., or try to guess what people will need. This is where most naive class files go wrong.

Another class of this sort is beamer, which provides methods for formatting a presentation rather than a printed document. Doing this with just regular packages is really not practical.

The choice between creating a class and using a package is partially conceptual, and partially practical. Conceptually, a thesis is a different document type, and so it makes sense from the user's point of view to define it in the \documentclass command rather than in a package. As a document class it provides the all the specific boiler plate language that my university requires for the title page etc., and this is what is to be expected of a document class. The class defines various components of the document that are logically part of the document class such tables of contents formatting, special pages before appendices, formatting for landscape pages, etc.

On a practical matter, from my point of view as the author, it reduces the complexity of maintenance and documentation: I don't have to worry about people trying to use my package with some other class with which it may be incompatible, or have to maintain extra code for different document classes that are around, and I therefore don't have to document things like "must only be used with class X" etc., which I know from experience people don't tend to read.

Of course some dedicated classes are less useful. I've never been a fan of the letter class, for example, since it has various odd restrictions on the kinds of environments it allows, preferring to use article plus my own letterhead package.

So there are definitely use cases in which a dedicated class is very helpful. For most of my documents I still use the basic classes + packages, but for large documents I prefer the all-in-one classes like memoir.

  • 1
    your second and third paragraphs are the closest to answering my intended question. You mention that the class only does the minimum necessary, which makes sense. But to give a specific example, I imagine that your thesis class was primarily concerned with things like setting up margins and things like that. Why would you prefer to do that with a class rather than just use commands from the geometry package? Or are there other modifications you made, perhaps to the title page, that were only possible by editing the class directly.
    – Vyas
    Commented Aug 14, 2015 at 17:07
  • @Vyas I've added some comments about how/why I made the choice between class and package.
    – Alan Munn
    Commented Aug 14, 2015 at 17:47
  • +1, though I learned LaTeX by writing my dissertation, albeit with memoir: had I relied on my university's class, I would not have learned nearly as much. And I suppose: writing a class file is yet another way for the class-writer to learn (more) LaTeX. So I suppose there's a difference between those who want to learn how to use LaTeX and those who'd rather "merely" use LaTeX (which I don't mean to sound as an insult: just a different goal).
    – jon
    Commented Aug 14, 2015 at 20:08
  • @jon Agreed. In my case I got tired of my students asking me how to do stuff to meet the requirements. And in reality, LaTeX should be a tool, and I'm happy to provide a reliable class to students around the university. phdcomics.com/comics/archive.php?comicid=1115
    – Alan Munn
    Commented Aug 14, 2015 at 20:25

I guess I have to plead guilty to creating the memoir class.

Before doing that I had been involved in creating class files for ISO (the International Standards Organisation) and they kept on changing their requirements. In the end, for them, I tried to create a flexible class file that wouldn't need revamping every few months.

I had written a number of packages that helped me in my general creation of technical articles, reports, and books, but were not necessarily consistent in their interfaces. With the ISO experience in mind I thought that if I effectively reproduced their coding in a class file I could provide a consistent user interface (also creating some internal efficiences in terms of code sharing). Further, the differences between the standard book and report classes were small, and at that time quite a lot of people were asking how to simply convert an article document to a report or vice-versa. I therefor enabled a memoir user to easily switch the output to look like it was produced by any one of the three main standard classes. Effectively it is a superset of the three main standard classes and natively provides the capabilities of some 31 commonly used packages.

The downside of writing a new class is that some pre-existing, or new, package might not be compatible with it. This was the case with memoir in it's early days but I think that with time (14 years since the first release) and the generosity of package writers it is now a minor problem, if one at all.

EDIT: This is in response to Vyas' edit. Reverting to my ISO work I created a 'general ISO' class file that dealt with the overall ISO requirements and terminology. For instance they used terms Like Clause, Sub-Clause, Sub-Sub-Clause, etc., down to, I think, Sub-Sub-Sub-Sub-Sub-Clause, for what in LaTeX is normally denoted by \chapter, \section etc., so I created heading macros like \clause, \sclause, \ssclause which were more akin to the language of the requirements. Another generic item was a cover page containg administration details about the document. This consisted of a series of rectangular boxes enclosing the appropriate texts. The generic macros were just for the texts with the class putting them in the correct boxes. The class also dealt with the tricky issue that ISO required the documentation on A4 paper but many participants would be based in the USA which uses letterpaper and they required the documentation in a format that they could read and not run off the edge of the paper.

I was heavily involved in the ISO 10303 Industrial Systems and Automation --- Product data representation and exchange standard which runs to many parts and thousands of pages. For these I wrote a package that dealt with all the 10303 boilerplate text, the cover page texts, and so on. 10303 was a very formal standard and used the EXPRESS information modeling language (defined in 10303-11) for which some compilers were developed to check and implement the models. The package contained provisions to either typeset the whole document, including all text and EXPRESS code, or to output only the EXPRESS code which could then be processed by other mechanisms.

This is probably not much help to Vyas but I think that the anser to his question is `It all depends ...'

  • +1 for providing a great use-case. I've added some clarification to my question, so perhaps it'll be clearer what exactly I was asking.
    – Vyas
    Commented Aug 14, 2015 at 17:02

I think the answer depends what you are using LaTeX for. Creating "generic-format" documents using some common user-defined macros is one thing. Creating a set of documents all with the same fully-defined, customized, "print-ready" format is another.

For one-time use, I don't think there is much practical difference. The functionality is the same either way, though you don't need \makeatletter and \makeatother in a class file.

But consider the situation when you have accumulated many different config.tex files, some of which only work correctly with particular document classes, or only if you use particular options of the document class (e.g. your config.tex only works properly for a particular paper size, or only for two-column documents).

Since you can base a new document class on an existing class by using \LoadClass, you can easily make a document class file that creates exactly the document format you want, with a single parameterless \documentclass command, rather than having to remember to specify options foo and bar of document class baz and then include the correct config.tex file from your collection.

  • 1
    third option: config.sty instead of config.tex and then load it as package (would also get rid of \makeatletter…)
    – cgnieder
    Commented Aug 14, 2015 at 17:08
  • @clemens Depends, some template authors tend to put a config file where user packages are put to keep the preamble short (see classicthesis-template). As changing package files is highly discouraged ... OTOH the most succesful (as it seems) thesis template requires the user to change the class file. Which is really, really bad.
    – Johannes_B
    Commented Aug 14, 2015 at 18:18
  • 1
    @Johannes_B I don't see a reason why one should not use sty for a personal config file and input it with \usepackage instead of tex and \input. I don't mean manipulating packages...
    – cgnieder
    Commented Aug 14, 2015 at 18:20
  • @clemens But you know what you are doing. I have a personal package myself where i deal with my stuff. Licence, version and date; though i never gave it away. But i know, if users are required to change stuff in package, that meta content will be ignored and the same file flies around the net multiple times. That is what i wanted to warn of.
    – Johannes_B
    Commented Aug 14, 2015 at 18:23

A class is pretty useful to setup environments where certain functionality is essential. This is also meant in a conservative fashion that you don't want external tools affecting the result. From the beamer example mentioned earlier, certain packages don't work with beamer because their assumptions about itemization etc. environments is altered. Or in the memoir case, the page setup doesn't like the ubiquitous geometry package that much because it wants to work with the same targets.

This might look like a problem but in many cases it is a blessing in disguise as package conflicts are much harder to spot, let alone to resolve. Instead the class can be a pretty tight sandbox redefining all the relevant stuff and leaving the rest completely open. This includes for example redefining all the common macros such as \author, \maketitle etc. with which the user should be able to create the result the class is meant for. You surely don't want a user trying to replicate a title page if the specifications are defined in a strict fashion. Instead the user provides the content and the class takes care of all the fine-tuning.

A final advantage of a class is again like memoir of koma, you can regularize the frontend such that all the settings and namings are unified instead of trying to remember all different macro names for each package. That kind of unification would be pretty useless to load as a package because you might not want to load some of those packages.

Moreover, a class is pretty useless if it is just a compilation of package declarations. Then you can copy paste the package list and you would be done. In a pretty pedantic way, if a class is not doing nontirivial declarations inherent to that particular result then it is not practical in a meaningful sense.

And if those nontrivial declarations don't clash with the typical TeX/LaTeX macros then it is again conceptually a package in disguise rendering a class useless.

A package on the other hand goes towards the flexibility and tries to leave virtually no footprint. In the ideal world, it works regardless the class it is operating in. Hence it is the defensive approach in the orthogonal way such that a package tries to get out of the way as much as possible creating its own macro names, defining dangerous macros in local groups and restoring the originals when exiting the group and so on. You should be able to use it in a table or a caption without any need to \protect or handle expansion depth etc.

That way, it can be combined with as many classes as possible without sacrificing the functionality.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .