Hauptmenü
Sie sind hier
Versatz im ToC mit tocstyle
Hallo zusammen,
habe hier unten stehendes Beispiel, welches mir an bestimmten Stellen im ToC eine Unstimmigkeit aufwirft. Je nachdem welche Gliederungsebene im Anhang definiert ist, ergibt sich im ToC beim 1. Kapitel ein Versatz.
Beispiel: Wenn eine section im Appendix vorhanden ist, entsteht nach genügendem Kompilieren (habe definitiv oft genug kompiliert!) ein Versatz zwischen "Überschrift auf Ebene 1" und dem darunter stehenden "1.1.1.". Ist im Appendix eine subsection vorhanden, so ergibt sich der Versatz zwischen "Überschrift auf Ebene 2" und "1.1.1.1.".
Ich habe diese Frage schon auf mrunix gestellt, wo mir als vorläufige Abhilfe geraten wurde, tocindentmanual statt tocindentauto zu verwenden. Dies klappt, wenn auch mit recht großem Abstand zwischen Gliederungsnummer und Überschrift. Könnte dies mit den bereits gemeldeten Bugs zusammenhängen? Ich wollte es aber auf jeden Fall berichten, falls es doch einen eigenständigen Grund hat.
Danke und Gruß
Kristian
\listfiles \documentclass{scrbook} \usepackage[ngerman]{babel} \usepackage{blindtext} \usepackage[tocindentauto,tocgraduated]{tocstyle} \usetocstyle{KOMAlike} \setcounter{secnumdepth}{3} \setcounter{tocdepth}{3} \begin{document} \tableofcontents \Blinddocument \appendix \chapter{asdf} \section{asdf} %\subsection{asdf} \end{document}
*File List* scrbook.cls 2009/07/24 v3.04a KOMA-Script document class (book) scrkbase.sty 2009/07/24 v3.04a KOMA-Script package (KOMA-Script-dependent ba sics and keyval usage) scrbase.sty 2009/07/24 v3.04a KOMA-Script package (KOMA-Script-independent basics and keyval usage) keyval.sty 1999/03/16 v1.13 key=value parser (DPC) scrlfile.sty 2009/03/25 v3.03 KOMA-Script package (loading files) tocbasic.sty 2009/06/08 v3.03b KOMA-Script package (handling toc-files) scrsize11pt.clo 2009/07/24 v3.04a KOMA-Script font size class option (11pt) typearea.sty 2009/07/24 v3.04a KOMA-Script package (type area) babel.sty 2008/07/06 v3.8l The Babel package ngermanb.ldf 2008/07/06 v2.6n new German support from the babel system blindtext.sty 2009/01/27 V1.8 blindtext-Package xspace.sty 2006/05/08 v1.12 Space after command names (DPC,MH) tocstyle.sty 2008/10/20 v0.2c-alpha LaTeX2e KOMA-Script package (versatile t oc styles) omscmr.fd 1999/05/25 v2.5h Standard LaTeX font definitions
Aktuelle KOMA-Script Release
Die aktuelle KOMA-Script-Release finden sich primär im Dateien-Bereich des Projekts KOMA-Script auf SourceForge.
Schnelle Bugfixes und Prereleases finden sich im KOMA-Script-Repository.
Näheres zur aktuellen und früheren Releases ist dem Beitrag »Welches ist die aktuelle KOMA-Script-Release und wo finde ich sie?« zu entnehmen.
Beispiele aus der 7. Auflage des KOMA-Script-Buchs
Hingucker
Sponsoren
In der Reihenfolge der Spendeneingänge:
2024
Paul Kloß, Manuel Kuehner, Julian u. a.
2023
Paul Kloß, Manuel Kuehner, Martin Bierbaum, Ulrich Groh, Elke Schubert u. a.
Näheres zu Kosten und Betrieb ist in einem Blog-Beitrag zu finden. Natürlich sind auch Spenden ohne Namensnennung möglich.
Newsfeeds
Neuer Bug
Ich vermute, dass das ein neuer Bug ist. Offenbar ist es so, dass bei der automatischen Berechnung des Einzugs nicht das Breitenmaximum der übergeordneten Ebene verwendet wird, sondern das bisherige Breitenmaximum bis zum letzten verwendeten Eintrag der jeweiligen Ebene.
Ich habe schon damals beim Entwurf und der Implementierung einen Knoten in meinen Gedankengängen fabriziert. Das ist auch mit ein Grund, warum der andere Fehler noch nicht beseitigt ist. Ich habe da leider saumäßig schlecht dokumentierten Source. Das bedeutet, dass ich Zeit brauche, um mich hineinzudenken und dann gleich die Lösung zu erarbeiten. Wenn ich nur mal eben eine Stunde zur Verfügung habe, bringt es nichts, das überhaupt anzufassen.
Danke jedenfalls für Deine Meldung.
Bug gefunden und beseitigt
Das Problem war tatsächlich, dass für die Berechnung des Einzugs von Ebene n nicht der Einzug und die Nummernbreite von Ebene n-1 aus dem letzten Lauf verwendet wurde, sondern der Einzug und die Nummernbreite von Ebene n-1 aus dem aktuellen Lauf.
Die Änderung führt allerdings dazu, dass der Einzug bei n Gliederungsebenen im Inhaltsverzeichnis erst nach n+1 LaTeX-Läufen terminiert.
Dass ich diesen Bug vorgezogen habe, liegt übrigens daran, dass ich vermute, dass der andere Einzugs-Bug ähnlich gelagert ist und ich diesen Bug enfacher testen konnte.