Frequently Asked Questions and Their Answers#

There are always users who believe that the default settings do not meet user expectations or, for other reasons, were not chosen optimally. Some of these comments are indeed well-founded.

As mentioned in the introduction to the manual, KOMA-Script was developed in the early 1990s from the LaTeX 2.09 package Script 2.0. Although I had already contributed a few minor features to Script 2.0, overall it was a package created by Frank Neukam, who also made all the design and implementation decisions. In 1993, I decided to design KOMA-Script to be as compatible as possible with Script 2.0. This applied in particular to the default settings.

At the same time, KOMA-Script still had to grow in terms of its range of functions. In 1994, KOMA-Script offered only a fraction of the capabilities it provides today. So some features only became possible over time. The default settings were then based on what had previously been set as fixed values—that is, on the state prior to the introduction of the new feature. For features that hadn’t even existed as fixed settings before, I based my decisions on user requests from support, on the overall appearance of the default settings, and, in exceptional cases, on third-party packages.

Compatibility has always been important to me. As far as possible, a document should still look exactly the same years later when opened with the latest version of KOMA-Script as it did when opened with the version in which it was originally created. Up through version 3.00, the only restriction here was that compatibility should not hinder bug fixes and improvements.

While the results of my compatibility survey tend to argue against moving away from the compatibility rule, I noticed during the transition from KOMA-Script 2.9 to the source code base of KOMA-Script 3.00 that other package authors themselves attach little importance to compatibility. Several of my older documents were reformatted—in some cases quite significantly—even though I experimentally used not only the compatibility setting version=first but even an older version of KOMA-Script. So in reality, it’s of little use if KOMA-Script itself could reformat documents in a highly compatible way. To achieve this, you have to archive all the packages used anyway. In this case, KOMA-Script can of course be included as well.

However, this experience does not mean that all default settings will now be reviewed and changed across the board. Some default settings have already been changed (for example, the default page style for white pages). For others, we are considering changes in this direction.

Incidentally, I already ran into trouble back in the 1990s while attempting to change a default setting: Because italic fonts—in LaTeX \slshape—are generally frowned upon in typography, I wanted to change the header preset to italic—in LaTeX \itshape. The protests after the release were so intense that I reversed the change by the very next release—and back then, releases were much more frequent than they are today. After that experience, I think twice before implementing even well-founded change requests.

Nevertheless, anyone with a well-reasoned suggestion for a change can submit it as a feature request in the Issue Tracker. However, whenever possible, you should also consider potential side effects. This includes the question of whether the user can easily revert to the old default setting. For example, I would rarely change the size or font of a single heading level.

There is an entire page dedicated to the topic of minimal working examples. The relevant LaTeX forums also often provide detailed information on how to create a minimal example. For example, on TeX.SX, there is a detailed explanation of what even a beginner should keep in mind when creating a minimal working example. Despite the effort required of the user, it’s important to remember that this not only significantly improves the chances of receiving effective help, but minimal examples also prevent unnecessary discussions and frustration.

A minimal working example for a LaTeX LaTeX problem is the smallest possible LaTeX document in which the problem occurs or that can be used to illustrate the problem. The attribute working is important here. A document preamble is not a working example. A main file that includes various other files or graphics is not working without those other files and graphics. It is best to embed subfiles directly into the main file. For \includegraphics commands, it is recommended to use one of the example images from the mwe package. A file that requires modifications before the problem becomes apparent is also not a working example of the problem. To avoid long placeholder texts, feel free to use packages such as

blindtext or lipsum. These are available from all LaTeX distributions via their package managers. In some cases, you can also replace text with \vspace commands.

Although the name “minimal working example” actually implies that it is the smallest LaTeX document for this purpose, I am deliberately putting this into perspective. The smallest document is not necessarily the best one. Furthermore, a less experienced beginner might not necessarily find the smallest possible document that demonstrates this problem, even with the best of efforts. Nevertheless, they should strive for the smallest possible LaTeX document.

It’s important to me that I can work with the minimal example without having to worry about dozens of irrelevant definitions and packages. I also appreciate it when someone provides a minimal example in response to a question that seemingly cannot be demonstrated with one. I can then conduct my own tests using that exact example and use it to illustrate my proposed solutions. A minimal example often also helps me gauge how advanced the user is—and thus how detailed my answers should be. Beginners, in particular, often have underlying issues where the question only reveals a symptom. With a minimal example, I can potentially identify this and provide much better assistance. For me, the absence of a minimal example means the user only needs a minimal answer.

Ultimately, a minimal example signals to me that a question is important, while at the same time allowing me to provide my best possible answer. Without a minimal example, my best possible answer might simply be, “I don’t understand; I can’t answer it this way.” This also applies when the person asking the question has clearly spent little effort on the minimal example, or when multiple problems have been confusingly mixed together in a single example in a way that makes them difficult to distinguish. Whenever possible, each individual problem should be isolated in a separate minimal example (and, if possible, in its own post). A single minimal example makes sense only if it becomes clear that the problems are inextricably linked—that is, if they are sub-aspects of a larger problem. In that case, however, the sub-problems and their interdependencies should also be clearly stated.

This makes a difference in two respects. First, size<size>.clo files are loaded only when used in \documentclass, since KOMA-Script has no control over the exact contents of these files from external sources, and they often cannot be loaded without errors at a later time. When using \KOMAoptions or \KOMAoption, a calculation of the font size settings is therefore also used in some cases where a configuration file is used to set the base font size via the optional argument of \documentclass.

Furthermore, changing the base font size after the class has been loaded does not adjust all lengths used by the class—or even by previously loaded packages—to the new base font size. This is also technically nearly impossible. The information regarding whether a length depends on the base font size or not is not even unambiguous when the length is set. Once the length is set, this information is no longer available at all. Therefore, even with KOMA-Script, the document’s actual base font size should always be specified when loading the class. Any subsequent changes should really be limited to exceptional cases. For example, the documentation mentions the case of a (rather short) appendix in a different font size.