Version 2015/05/19 v3.18.2106
, Abschnitt 18.2 Definition eigener Seitenstilpaare
Beim Lesen der Dokumentation bin ich davon ausgegangen, dass in folgendem Minimalbeispiel der Elternstil auf das Kind vererbt wird. Momentan zeigt Seitenstil Kind allerdings lediglich die footseplines
.
Habe ich die Dokumentation falsch verstanden, oder liegt momentan ein Missgeschick vor?
\listfiles \documentclass{scrreprt} \usepackage{blindtext} \usepackage[automark]{scrlayer-scrpage} \providepairofpagestyles{elter}{% \ohead*{\pagemark}% \ihead{\headmark}% \KOMAoptions{headsepline,% plainheadsepline}% } \providepairofpagestyles[elter]{kind}{% \KOMAoptions{footsepline,% plainfootsepline% } } \pagestyle{kind} \begin{document} \chapter{walzing wombat} \currentpagestyle \blindtext[6] \end{document}
Jain
Die Anleitung ist an der Stelle sehr ungenau. Der Kind-Stil erbt tatsächlich nur die aktuelle Konfiguration des Eltern-Stils, also die aktuelle Einstellung der drei Kopf- und der drei Fußelemente, nicht jedoch dessen Init-Code. Man vergleiche:
Wenn man mal einen Blick in die aktuelle TODO-Liste wirft, dann sieht man außerdem, dass auch die Behandlung der Optionen noch nicht in Stein gemeiselt ist. Es gibt durchaus Überlegungen, Optionen mehr Stil-abhängig zu interpretieren als global. Dann würde auch das
\KOMAoptions
des Elternstils sich nicht mehr auf den Kindstil auswirken. Umgekehrt könnte man aber in der Tat darüber nachdenken, den Init-Code der Eltern bzw. eine aktuelle Kopie desselben mit zu vererben. Das ist alles noch ein wenig unbestimmt. Eigentlich sollte es bis zum Verlassen des Beta-Status längst festgeklopft sein. Ist es aber tatsächlich noch nicht. Es gab dazu u. a. nicht genügend Rückmeldungen (genauer: keine) und wenig Entscheidungsfreude auf meiner Seite, so dass ich das vor mir her geschoben habe.Aktueller Anwendungsfall wäre
Aktueller Anwendungsfall wäre das Bereitstellen verschiedener Seitenstile in einer Wrapperklasse für Diplomarbeiten und ähnliches. Aktuell arbeiten diese noch mit
scrpage2
Der
normal
Stil hätte im Fuß Informtationen, welche nur während des Entwurfs wirklich wichtig wären, beispielsweise Autor und Titel. Dann entsprechend ein Stil ohne diese Info und einer komplett ohne Fußzeile.Durch vollständige Vererbung wäre der Code kürzer, in einer Wrapperklasse wäre das allerdings egal.
Rein vom Gefühl her, war das Leeren der Fußzeile in Stil
nonofoot
unerwartet.Soll nofoot in jedem Fall die
Soll
nofoot
in jedem Fall die Fußzeilenlinie haben? Dann wäre es vielleicht besser, wenn Du für diesen auch noch\KOMAoptions{footsepline,plainfootsepline}
einfügst. Die Notwendigkeit sehen kannst Du, wenn Du im folgenden Beispiel die markierte Zeile wieder raus nimmst.Stimmt, wenn das mit der
Stimmt, wenn das mit der Vererbung so nicht anwendbar ist, dann muss das explizit rein.
Im Anwendungsfall wäre das egal, aber sicher ist sicher. Danke für den Hinweis.
Im tatsächlichen Code übrigens vorhanden; aufgrund des momentanen beta-Status wurde die Umstellung jedoch zurückgestellt.
Ich habe erst jetzt gesehen,
Ich habe erst jetzt gesehen, dass es in dem Anwendungsfall gar nicht mehr so sehr um die Linien ging, sondern um
\ofoot*
und das sollte tatsächlich vererbt werden. Ich habe Dein Beispiel mal noch etwas für dieses Problem angepasst:Jetzt kann man durch Ein- und Auskommentieren der Zeile
\pagestyle{normal}
deren Einfluss auf den Fuß von Seite 3 und 4 erkennen. Vermutlich muss ein Seitenstil einmal mit\pagestyle
(oder ähnlichem?) aufgerufen worden sein, damit das Vererben der Inhalte (nicht der Optionen wie Linien etc) tatsächlich erfolgen kann. Beim Klonen von scrheadings gibt es keine Schwierigkeiten, weil der Seitenstil ja schon beim Laden des Paketes aktiviert wurde.In Deinem Beispiel musst Du also nur das
\pagestyle{nofoot}
vor die Definition des abgeleiteten Stils setzen:Ich glaube aber nicht, dass das so beabsichtigt ist. Oder es müsste zumindest in die Doku.
Wie bereits geschrieben
Der Init-Code des Stils wird nicht vererbt. Wenn also der Stil erst durch den Init-Code konfiguriert wird, dann wird dies nicht vererbt. Wird der Stil hingegen dadurch konfiguriert, dass er zunächst aktiviert und dann über die Befehle für Kopf und Fuß konfiguriert wird, dann wird das vererbt.
Konfiguration über den Init-Code ist nichts anderes, als wenn man den Seitenstil nach der Aktivierung verändert. Auch bei:
soll das Kind ja nicht plötzlich
eltern
im Kopf anzeigen. Vererbt werden bisher nur die aktuellen Einstellungen von\ihead
etc. zum Zeitpunkt der Definition des Kind-Stils.Das jeweils nur die gerade
Das jeweils nur die gerade aktuellen Eigenschaften vererbt werden, war mir schon klar. Ich habe nur aus der Doku nicht herausgelesen, dass die Definitionen im letzten Argument von
\newpairofpagestyles
nicht sofort bzw. nicht automatisch zu den aktuellen Eigenschaften des so definierten Seitenstils gehören. Aber ich denke, dass ich das jetzt auch verstanden habe. Und stimmt, in dem anderen Kommentar hast Du schon geschrieben hast, dass noch unklar ist, oben man das ändern kann bzw. ob eine Änderung da auch überhaupt sinnvoll ist. Also ist es zumindest momentan doch so beabsichtigt.In unserem Anwendungsfall
In unserem Anwendungsfall wäre für den Anwender egal, was im Paket bzw. der Klasse passiert. Dem wäre auch die Implementierung vollkommen egal.
Ich kann den Maintainer der Klassen allerdings verstehen, wenn er mit der vollständigen Umstellung noch warten will. Hier hocken Mitarbeiter und Studenten gleicherweise vor alten Distributionen und scheuen sich vor Updates.
Ich bin allerdings gespannt, wie dann das endgültige Interface funktioniert.
Das ist die alte Geschichte
Das ist die alte Geschichte von Leuten, die neue Klassen, Pakete oder Möglichkeiten nutzen, aber bitte kein Update durchführen oder etwas neues installieren wollen. Denen ist nicht zu helfen. Bis KOMA-Script 3 habe ich auf solche Leute noch Rücksicht genommen und beispielsweise massenhaft Workarounds für Leute implementiert, die kein e-TeX verwendet haben, obwohl es das schon gab, als ich mit KOMA-Script angefangen habe. Die Zeiten sind vorbei. Seit die Installation von TeX-Live oder MiKTeX so einfach ist und es auch sehr einfach ist, diese aktuell zu halten (und notfalls sogar mehrere Versionen zu installieren), sehe ich absolut nicht mehr ein, auf jeden alten Krempel Rücksicht zu nehmen.
Früher habe ich oft auch noch Zeit investiert, um Supportanfragen zu uralten KOMA-Script-Versionen ohne Update zu lösen. Das ist vorbei. Wenn das Problem mit der aktuellen Version nicht auftritt oder leichter zu lösen ist, dann gibt es keine Lösung mehr, die stattdessen mit der alten Version herumdoktert. Das Leben ist dafür einfach zu kurz.
Autoren von irgendwelchen Institutslösungen würde ich empfehlen, zu dokumentieren, was man braucht und ggf. wie man daran kommt. Falls es alte Lösungen mit anderen Anforderungen gibt, ist es auch fair diese mit zu dokumentieren. Ansonsten: Wenn man immer Rücksicht auf die ewig Gestrigen nimmt, bleibt auf dem Stand von Vorgestern stehen. Wissenschaftler sollten den Fortschritt und nicht die Stagnation im Blick haben.
Absolute Zustimmung zum
Absolute Zustimmung zum letzten Satz, leider handeln viele Wissenschaftler die ich kenne nach dem Motto: Never touch a running System. :-/
Das erklärt für mich jetzt
Das erklärt für mich jetzt auch ein wenig, warum im folgenden Beispiel der Layer
kind.foot.above.line
noch einmal explizit vonscrheadings.foot.above.line
geklont werden muss, damit die Linie bei beiden Stilen auf der gleichen Höhe ist.Genau
Prinzipiell könnte ich das Eltern-Prinzip durchaus aufbohren. Wie weit, ist ohne genauere Untersuchung schwer zu sagen. Das könnte beispielsweise bedeutet, dass dann alle späteren Änderungen des Elten-Stils sich auch auf den Kind-Stil auswirken können (aber je nach Definition des Kind-Stils nicht müssen) und die Vernichtung des Eltern-Stils auch zu einer Vernichtung des Kind-Stils führen müsste. Ob ich stattdessen einbauen kann, dass der Kind-Stil die zum Definitionszeitpunkt gültige Definition des Eltern-Stils erbt, müsste ich erst untersuchen. Außerdem stellt sich dabei die Frage, ob es nicht sinnvoller wäre, eine Option
clone
o. ä. für Seitenstile ähnlich zur Option bei der Definition von Layern zu implementieren.Es gibt da leider viele Für und Wider (angefangen von Änderungen in der Benutzerschnittstelle bis hin zu dem Problem, dass unterschiedliche Anwender sicher unterschiedliches erwarten).
Vielleicht sollte ich die Eltern-Option erst einmal wieder aus der Dokumentation entfernen oder sie explizit als Beta markieren. Dann kann ich später entscheiden, wie sie genau funktionieren soll.