Alpha- und Beta-Test für scrlayer-fancyhdr

Ich habe in den letzten Tagen eine alte Idee wiederbelebt: Bereits bei der Entwicklung von scrlayer war mir bewusst, dass die Möglichkeiten der Ebenen nur dann nutzbar sind, wenn diese durch Verwendung eines Ebenenseitenstils auch ausgegeben werden. Zwar wäre es theoretisch möglich, den LaTeX-Kern selbst so zu patchen, dass man gleichzeitig einen Ebenenseitenstil und einen normalen Seitenstil verwenden kann, die dabei möglichen Seiteneffekte sind aber durchaus kritisch. Mein Ansatz war daher, den Unterbau der Ebenen und Ebenenseitenstile vom eigentlichen Benutzerinterface zu trennen. Das hat dann die Aufteilung in scrlayer und scrlayer-scrpage bedingt. scrlayer-scrpage stellt dabei eine erweiterte, überarbeitete Version des Benutzerinterfaces von scrpage2 bereit.

Fast gleichzeitig mit scrlayer-scrpage ist damals auch ein Ansatz für eine Implementierung des Benutzerinterfaces von fancyhdr entstanden. Diesen habe ich damals aber wieder verworfen. Vor einigen Tagen habe ich dagegen begonnen, eine experimentelles Paket zu schreiben, das einen anderen Weg geht. Es lädt sowohl scrlayer als auch fancyhdr und ersetzt dann lediglich den grundlegenden Seitenstil von fancyhdr durch einen Layerseitenstil von scrlayer. Das eigentliche Benutzerinterface von fancyhdr bleibt hingegen unangetastet.

Derzeit bedeutet das auch, dass durch alleiniges Laden von scrlayer-fancyhdr nicht alle Probleme im Zusammenspiel von KOMA-Script-Klassen und fancyhdr beseitigt werden. So werden beispielsweise in der jetzigen rudimentären Form Elemente zur Fontänderung wie pageheadfoot, pagehead, pagefoot und pagenumber in der Voreinstellung weiterhin nicht unterstützt. Stattdessen muss der Anwender selbst diese Font-Elemente in den Seitenstil einfügen und dort beispielsweise \thepage durch \pagemark ersetzen. Ebenso ist fancy (bzw. eigentlich der grundlegende Seitenstil @fancy) weiterhin ein Seitenstil mit automatischen Kolumnentiteln. Zwar kann man die Markenerzeugung nachträglich über die scrlayer-Anweisung \automark konfigurieren, komplett abschalten kann man sie aber nicht, da die Abbildung von \@mkboth zu \markboth wie bei fancyhdr üblich fest mit dem Seitenstil @fancy verbunden ist.

Grundsätzlich soll sich an den Eigenarten von fancyhdr auch nichts ändern. Es ist allenfalls denkbar, dass es diesbezüglich optionale Änderungen geben wird. Derzeit ist jedoch wichtiger, dass möglichst viel von fancyhdr auch mit scrlayer-fancyhdr funktioniert und gleichzeitig die Ebenenmöglichkeiten von scrlayer nutzbar werden. Nur so ist beispielsweise eine Verwendung von scrlayer-notecolumn zusammen mit einem fancyhdr-Seitenstil möglich.

Das Paket befindet sich derzeit in einem sehr frühen Stadium. Laden und Verwendung von \pagestyle{fancy} sind bisher getestet. Zu testen wäre daher:

1. Verwendung von scrlayer-fancyhdr an Stelle von fancyhdr in möglichst vielen Einsatzszenarien mit unterschiedlichen Klassen (vor allem auch Nicht-KOMA-Script-Klassen), bei denen bisher fancyhdr zum Einsatz kam.
2. Verwendung all der dokumentieren Möglichkeiten von fancyhdr mit scrlayer-fancyhdr.
3. Verwendung undokumentierter Möglichkeiten von fancyhdr mit scrlayer-fancyhdr.
4. Kombination von Möglichkeiten von fancyhdr mit Möglichkeiten von scrlayer durch die Verwendung von scrlayer-fancyhdr.

Erschwerend kommt hinzu, dass es bisher nur wenig (für Laien schwer verständliche) Anwenderdokumentation gibt.

Derzeit wären im Zuge des Tests auch Kleinigkeiten wie »die Kopfzeile ist mit scrlayer-fancyhdr ca. 1/10 mm höher als mit fancyhdr« zu dokumentieren. Ob alles, was gefunden wird, letztlich als Bug eingestuft und beseitigt oder manches nur dokumentiert wird, ist jedoch ungewiss. Wie immer bei derartigen Experimenten gibt es auch keine Garantie, dass das Paket je veröffentlicht wird. Es ist sowohl möglich, dass das Paket wieder komplett eingestampft wird, als auch, dass es im Zuge der Entwicklung komplett umgeschrieben wird. Daher ist es Testern auch nicht gestattet, das Paket weiterzugeben.

Wer testen möchte, wendet sich per E-Mail an die bekannte KOMA-Script-E-Mail-Adresse (siehe KOMA-Script-Anleitung). Bitte nicht die Admin-Adresse für komascript.de dafür missbrauchen, da diese nicht für KOMA-Script-Support jeglicher Art zu verwenden ist!