15

I don't know whether this question has a clear answer, but I was unable to find anything about this on Google, so here goes.

Despite the emergence of "rich" document classes like KOMA-Script or memoir, it is my impression that a substantial amount of LaTeX users still uses the standard document classes (correct me if I am wrong). This is indicated, for instance, by this answer to a TeX.SE question. For researchers looking to submit their work to a journal or publisher, there are actually (somewhat) objective reasons for sticking to the standard classes, since many journals have their own classes and the conversion process is typically the simplest when starting from a standard class. To summarize:

Many people still use the standard classes, and there are sometimes good reasons to do so.

At the same time, the standard classes have not been changed for what feels like decades (again, correct me if I am wrong). My gripe with this is that many of the common issues with the standard classes actually have solutions which would only require "micro-updates" to the classes themselves. For instance, in the book class, a common problem is the uppercasing of page headings (which is hard-coded for things like ToC or bibliography) and the lack of horizontal ruling capabilities below the headings. Sure, you can use fancyhdr, memoir, or KOMA-Script, but why is there no update to the book class which makes this stuff customizable? (This would probably amount to changing less than 1% of the class code). To summarize again:

The standard classes have been unchanged for decades, yet some of their issues could be fixed with very simple modifications to the class code(s). Why is this possibility not being pursued?

Joseph Wright
  • 259,911
  • 34
  • 706
  • 1,036
Daniel Steck
  • 281

3 Answers3

20

Three aspects here, one on design, one on macro programming, one policy.

At the design level, it's well-known that the standard classes are somewhat esoteric without modification. However, there are many (probably millions) of documents out there which rely on the standard designs or on altering them in a predictable way. Any changes to the core styling would have a severe knock-on.

The second aspect is that changing anything in a macro can affect usage. For example, any code wanting to check 'is the header set up unchanged' will be caught out if the standard header code is altered. For example, if a change to the standard classes broke fancyhdr, that would be much worse than leaving the standard classes alone.

The third aspect is consistency. Yes, there are few hooks for style changes in the core. That's been the case from day one and it's self-consistent if sometimes annoying. Adding some style hooks ad hoc without a complete overhaul would potentially be much more confusing. Packages can do that as they focus on one area. The team are keen to have new interfaces, but want those to apply in a systematic way: that's much more tricky.

Joseph Wright
  • 259,911
  • 34
  • 706
  • 1,036
  • 1
    Thank you for your answer. So, in a nutshell, the concern is backward compatibility. I might be slightly naive here, but shouldn't it be possible to simply hide certain "new" features behind documentclass options? There are other potential mechanisms for backward compatibility, but this seems to be a particularly simple one. – Daniel Steck Aug 22 '18 at 16:20
  • 3
    Would this be partially addressed by one of: 1. Having a set of articlev2, reportv2, bookv2 classes, with suggestions to use them in all sorts of places? 2. Having a v2 class option for these classes trigger the changes? – einpoklum Sep 04 '18 at 10:09
18

I am the author of the memoir class. I had used the standard classes for my documents, usually with some added packages or preamble code to get the look I wanted, often writing new packages for that purpose. I eventually decided to produce the memoir class, based on the book/report classes with options for article class type output and including those packages that I found useful, and which hopefully others would be happy with. Even so, there are many questions about how to do this or that with memoir to satisfy the particular user's desires.

There are thousands of LaTeX users and a (significant) portion of these want their own typographical layout. You can't cater for this diversity of opinion in any standard class which would require hundreds of options and much never used internal code. The LaTeX ability to develop and provide packages to support users (idiosynchratic) needs is one of its major strengths.

Peter Wilson
  • 28,066
  • It is true that the standard classes, or any class for that matter, can never cater to all users. I did not claim that this was possible and, frankly, such a statement would be absurd. However, I somtimes find myself falling just short with the standard classes, the uppercase headings in book being a particular example. In my opinion, this example is far from exotic or idiosynchratic, and it is common use cases like these which a revised set of standard classes could address. The "full complexity" solutions which cater to (nearly) all use cases are of course best left to packages. – Daniel Steck Aug 22 '18 at 19:56
  • Other than the official package documentation, is there some succinct description of how memoir differs from the standard classes? – einpoklum Sep 04 '18 at 10:10
  • Also - I didn't even know memoir was usable for articles, that's good to know. – einpoklum Sep 04 '18 at 10:11
  • @einpoklum No succinct summary. If you have a standard book class document (no packages) then changing the class from book to memoir will produce the same output (except for putting references to the ToC, LoF and LoT into the Toc). What memoir does is provide many ways of changing that output. – Peter Wilson Sep 05 '18 at 18:06
10

Thinking about it, I guess, it would not be worth the trouble. Thousands of packages rely on a certain feature of the LaTeX core and now somebody changes something. How in the world can you avoid breaking some peoples documents or other peoples packages? And then, all the angry users »this kind of document compiled for years!1!«

There is a striking xkcd comic, what happens if one tries: https://xkcd.com/1172/

On the other hand, it is so much easier to release a new package or even post the code of a feature.

Yes, it is simply not worth the time and effort.

Keks Dose
  • 30,892
  • Same comment as for @JosephWright's answer: So why not make an articlev2, reportv2 and bookv2 classes, which do break things, and suggest that packages support them? Within a relatively short period of time, almost all actively-maintained packages would indded support the new standard, and then one could consider deprecating the old ones. – einpoklum Sep 04 '18 at 10:13
  • @einpoklum So your question is, why nobody wrote a documentclass »article-version2«. I have no idea who could answer this question. My guess is that once LaTeX2e existed, many authors published their own classes and thus something like a new standard never was needed. – Keks Dose Sep 04 '18 at 11:21
  • 1
    I'm not talking about "someone", I'm talking about the LaTeX project and the official distributions deciding to set a new standard, but circumventing the backwards-compatibility issue somehow. – einpoklum Sep 04 '18 at 11:34