Some users are very interested in what the future holds for KOMA-Script. Well, the most important news is that development is continuing—in fact, it’s currently in full swing. At the same time, however, there doesn’t seem to be any visible progress.
As you may know, PDF tagging is currently one of the topics being intensively
discussed at KOMA-Script. In this regard, Ulrike Fischer recently demonstrated
at the DANTE conference how KOMA-Script classes can already be taught to
perform tagging in a few places. Until now, however, this has been more of a
piecemeal effort in the form of stopgap solutions. Behind the scenes, however,
a great deal has been happening in this direction. Marei and I have discussed
this at great length and have come to the conclusion that we cannot currently
rely on the still very unstable template interface of
latex-lab. We don’t want a KOMA-Script that might suddenly start throwing
errors left and right from one day to the next, but rather one that works as
reliably as possible. Given the very rapid ongoing development of LaTeX,
this isn’t easy anyway.
Instead, we decided to adapt the existing code to meet the requirements for PDF tagging. First and foremost, this means that the necessary sockets are integrated and plugs are implemented with the appropriate functions. Marei is handling this part of the work. As a perfectionist, she’s also setting up a fully automated testing system to ensure the correctness of the changes, including the highest possible visual compatibility.
In the course of the discussions on PDF tagging, it became clear—once again!—
that the large amount of compatibility code in KOMA-Script makes the work
significantly more difficult. Another task, therefore, is to get rid of this
code. We didn’t take this decision lightly, but we believe that now is exactly
the right time to do so. Nevertheless, we will soften the transition just a
little. Specifically, this means that the next version will only respond to
deprecated options with a warning that explains how to do it
correctly. Deprecated commands, on the other hand, will generate an error
message. The error list on the
Wiki will be
expanded accordingly in parallel, so that anyone who has ignored such warnings
over the past few years—or even decades—can still find help. While this will
initially involve a great deal of extra work, it will pay off in the end. The
plan is to move to the next phase within the next six to twelve months and
permanently remove the deprecated options and commands from the code. This
will also affect the version option. I am primarily responsible for this
part of the work.
However, there are also a few overlaps. When simplifying code, we don’t want
to stop at simply removing obsolete options and commands. For example, it has
become apparent that the code for headings commands contains some unsightly
duplication. Due to the focus on the interface for class authors, which was
previously provided by the LaTeX kernel, the asterisk form (such as
\chapter*{…}) and the standard form (such as \chapter[…]{…}) are
implemented almost entirely independently of one another. For the most part,
however, the implementations are identical. So if something needs to be
changed in one form, the corresponding section in the other often has to be
adjusted as well. We want to eliminate such code duplication and avoid it in
the future. Other simplifications are now also possible and sensible thanks to
the move away from LaTeX kernel commands. There is no clear distinction
here between tasks for me and tasks for Marei. In the example mentioned, it
was easier for Marei to take care of this as part of her
adjustments. Incidentally, this also resulted in a new feature. You can now
freely choose whether headings create a new column title or not. Excluding
numbered headings from the table of contents was, of course, already possible.
Users are naturally wondering when a new version with all these changes will
be released. The answer is as simple as it is unsatisfying: When we’re done
with it. In fact, though, we’re already quite far along. I certainly wouldn’t
be bragging about it if there weren’t hope that Marei will soon merge my
changes with hers. Anyone who wants to test it thoroughly—whether with PDF
tagging enabled or not—can already get a head start and, for example, take a
look at the dev branch of
komascript-tagging-lab. Everyone else will just have to wait and see.
So long Markus