von Auch ein » Di 16. Okt 2018, 19:34
Es gibt viele Pakete, die mit KOMA-Script-Klassen verträglich sind – weit mehr als nur
caption. Es gibt aber eben auch einige, bei denen das eher schlecht bis gar nicht der Fall ist. Und vor denen, die am häufigsten Probleme verursachen, warnen die KOMA-Script-Klassen ggf. Wer diese Warnungen ignoriert, weiß entweder, was er tut, oder ist ggf. schlicht selbst schuld. Wer eine Vorlage verbreitet, die solche Warnungen ignoriert, handelt fahrlässig. Wer die Warnungen sogar abschaltet (ja, das gibt es leider auch), handelt in meinen Augen absolut unverantwortlich und führt die Anwender wissentlich auf das Glatteis. Solche Leute sind in meinen Augen für einigen Frust bei Anwendern und Helfern verantwortlich. Es fällt mir schwer, dafür Verständnis aufzubringen.
Übrigens funktionieren umgekehrt KOMA-Script-Pakete wie das bereits genannte
scrlayer-scrpage aber auch
typearea und
tocbasic und natürlich das speziell für die Zusammenarbeit mit den Standardklassen geschriebene
scrextend sehr gut mit den Standardklassen und vielen anderen Klassen. Jedoch wird beispielsweise nicht empfohlen, eines der KOMA-Script-Pakete mit
memoir zu kombinieren. Wobei das auch für das hier Probleme verursachende
titlesec gilt.
Das neue scrlayer-fancyhdr funktioniert übrigens ebenfalls mit den Standardklassen (und mit
fancyhdr aber nicht mit
scrlayer-scrpage und genauso suboptimal mit den KOMA-Script-Klassen wie
fancyhdr selbst).
Aber in der Tat betreibt der Autor von
caption einigen Aufwand, um sein Paket mit vielen Klassen und vielen Paketen, die Gleitumgebungen bereit stellen, kompatibel zu machen und zu halten. Es gab auch einiges an Featureaustausch zwischen
KOMA-Script und
caption, was auch dem intensiven Austausch zwischen den beiden Autoren zu verdanken ist.
Es gibt viele Pakete, die mit KOMA-Script-Klassen verträglich sind – weit mehr als nur [p]caption[/p]. Es gibt aber eben auch einige, bei denen das eher schlecht bis gar nicht der Fall ist. Und vor denen, die am häufigsten Probleme verursachen, warnen die KOMA-Script-Klassen ggf. Wer diese Warnungen ignoriert, weiß entweder, was er tut, oder ist ggf. schlicht selbst schuld. Wer eine Vorlage verbreitet, die solche Warnungen ignoriert, handelt fahrlässig. Wer die Warnungen sogar abschaltet (ja, das gibt es leider auch), handelt in meinen Augen absolut unverantwortlich und führt die Anwender wissentlich auf das Glatteis. Solche Leute sind in meinen Augen für einigen Frust bei Anwendern und Helfern verantwortlich. Es fällt mir schwer, dafür Verständnis aufzubringen.
Übrigens funktionieren umgekehrt KOMA-Script-Pakete wie das bereits genannte [p]scrlayer-scrpage[/p] aber auch [p]typearea[/p] und [p]tocbasic[/p] und natürlich das speziell für die Zusammenarbeit mit den Standardklassen geschriebene [p]scrextend[/p] sehr gut mit den Standardklassen und vielen anderen Klassen. Jedoch wird beispielsweise nicht empfohlen, eines der KOMA-Script-Pakete mit [p]memoir[/p] zu kombinieren. Wobei das auch für das hier Probleme verursachende [p]titlesec[/p] gilt. [url=https://komascript.de/node/2197]Das neue [tt]scrlayer-fancyhdr[/tt][/url] funktioniert übrigens ebenfalls mit den Standardklassen (und mit [p]fancyhdr[/p] aber nicht mit [p]scrlayer-scrpage[/p] und genauso suboptimal mit den KOMA-Script-Klassen wie [p]fancyhdr[/p] selbst).
Aber in der Tat betreibt der Autor von [p]caption[/p] einigen Aufwand, um sein Paket mit vielen Klassen und vielen Paketen, die Gleitumgebungen bereit stellen, kompatibel zu machen und zu halten. Es gab auch einiges an Featureaustausch zwischen [p]KOMA-Script[/p] und [p]caption[/p], was auch dem intensiven Austausch zwischen den beiden Autoren zu verdanken ist.