Sie sind hier

Verzeichniseintragsstile

Es gab einige tiefgreifende Änderungen in KOMA-Script. Neuerdings wird das komplette Inhaltsverzeichnis, Abbildungsverzeichnis und Tabellenverzeichnis über Verzeichniseintragsstile in Paket tocbasic geregelt. Das hat einige Vorteile bezüglich der Konfigurierbarkeit derselben. Allerdings ist es auch eine sehr tiefgreifende Änderung, die auch dann Auswirkungen haben kann, wenn man die neuen, noch undokumentierten Möglichkeiten gar nicht nutzt. Deshalb wäre es schön, wenn ein paar Leute einfach testen würden, ob ihre Dokumente mit der aktuellen Pre-Release noch funktionieren.

Ohne das, kann ich nur feststellen, dass meine mager ausgestattete Testsuite (seit gestern) fehlerfrei durchläuft.

Hallo!
Ich habe mir aus dem SVN-repo r2403 geholt und in meinen local-texmf-tree installiert. Das ganze in einem aktuellem TeXLive 2015 (LaTeX2e 2016/02/01). Mein Dokument (scrbook) verarbeite ich mit LuaTeX, Version beta-0.80.0 (TeX Live 2015) (rev 5238).
Das lief dann ohne zu maulen durch. Das PDF sieht auch gut aus.
Da noch tocstyle drin war, stand dann im Log-File die entsprechende Meldung tocstyle vs. tocbasic. Die Doku sagt ja, dass tocstyle überholt ist. Ich hab es dann rausgeworfen. Würde aber gerne das:

\usetocstyle{nopagecolumn}

mit tocbasic erhalten. Ich mag die dotted leaders lines und die rechtsbündigen Seitenzahlen einfach nicht. Nach ein wenig Doku lesen, hatte:

\DeclareTOCStyleEntry[raggedpagenumber=true,linefill={}]{tocline}{part}
\DeclareTOCStyleEntry[raggedpagenumber=true,linefill={}]{tocline}{chapter}
\DeclareTOCStyleEntry[raggedpagenumber=true,linefill={}]{tocline}{section}
\DeclareTOCStyleEntry[raggedpagenumber=true,linefill={}]{tocline}{subsection}

den gewünschten Effekt. Jedoch nur für das Inhaltsverzeichnis. tocstyle hat dagegen auf alle Verzeichnisse gewirkt. In meinem Dokument habe ich:

  • toc von scrbook fürs Inhaltsverzeichnis
  • table/lot von scrbook fürs Tabellenverzeichnis
  • figure/lof von scrbook fürs Abbildungsverzeichnis
  • algorithm/loa von algorithm2e via float fürs Algorithmenverzeichnis
  • listing/lol von minted fürs Programmcodeverzeichnis

loa und lol sind wohl nicht zu kriegen, solange die jeweiligen Paketautoren nicht auf tocbasic umstellen oder man mit scrhack nachhilft. Die Beschreibung von \tocbasicautomode klingt nicht mächtig genug. Aber wie stellt man denn den Stil der Tabellen- und Abbildungsverzeichnisse um? Die sind ja aus scrbook.
Mehr Doku lesen und nachdenken führt dann zu:

\DeclareTOCStyleEntry[raggedpagenumber=true,linefill={}]{tocline}{table}
\DeclareTOCStyleEntry[raggedpagenumber=true,linefill={}]{tocline}{figure}

Kurioserweise wirkt das dann, ohne weiteres Zutun, auch auf listing/lol/minted.
algorithm/loa/algorithm2e kriege ich im Moment nicht beeinflusst.
Aus reinem Wahnsinn habe ich dem

\tableofcontents
\listoftables
\listoffigures
\listofalgorithms
\listoflistings

noch ein \listtheorems{Lemma,Theorem,Satz} von ntheorem hinzugefügt. Das macht nichts kaputt. Soweit ich das erkennen kann, scheint alles so zu arbeiten, wie ich es erwarten würde.
Viele Grüße
Uli Laube

Wenn ich das mal zusammenfassen darf: Es funktioniert so wie es soll.

listings wird übrigens durch Verwendung von scrhack wirklich kompatibel zu tocbasic. Wobei das alleine noch nicht \l@lstlisting umdefiniert.

Bei algorithm2e ist das nicht so einfach. Da habe ich mal vor langer Zeit (ganz am Anfang von tocbasic) eine Version erstellt, die kompatibel war und habe sie sogar an den Autor geschickt. Ob ich darauf überhaupt eine Antwort bekommen habe, kann ich nicht mehr nachvollziehen, da ich seither zwei E-Mail-Crashs hatte, bei denen ich einen Großteil meines KOMA-Script-E-Mail-Archives verloren habe. Die gepatchte Version habe ich außerdem inzwischen entsorgt, damit ich die nicht versehentlich weitergebe, müsste mir die Arbeit also ggf. noch einmal neu machen. Ich verspüre dazu aber auch nicht so viel Lust, weil sich die Algorithmen dieses Pakets auch optisch eher schlecht integrieren, ich das also ohnehin nicht verwende. Ich setze Algorithmen entweder in while-Sprache mit listings oder als Fluss-/Ablaufdiagramm mit tikz. Beides kommt nur noch selten vor.

BTW:

\RedeclareSectionCommands[tocraggedpagenumber,toclinefill={}]{part,chapter,section,subsection}

müsste theoretisch auch funktionieren und wäre dann ggf. kürzer. Für figure, table etc. kann man das natürlich nicht verwenden.

Ich denke es wäre am saubersten, aber (leider) auch utopisch, aus all den Paketen: algorithm2e, minted, listings, ntheorem, usw. alles zu entfernen was mit Verzeichnissen zu tun hat. Das muss ja nicht jeder für sich lokal neu implementieren. TikZ hat sein \begin{tikzpicture}...\end{tikzpicture}. Am Ende kommt da eine Box raus, die ich in \begin{figure}...\end{figure} packen kann, wenn ich möchte, dass sie gleitet, eine Bildunterschrift bekommt und nummeriert in einem Verzeichnis erscheinen soll. Genau wie \begin{tabular}...\end{tabular} eine Box füllt, die ich in ein \begin{table}...\end{table} einpacken kann, wenn sie gleiten soll, eine Nummerierung und Überschrift bekommen soll. Ein \begin{minted}...\end{minted} ist eine Box in \begin{listing}...\end{listing}.

Mh.. Ich muß ja die Verzeichnis-Funktionen von algorithm2e nicht benutzen. \begin{algorithm}...\end{algorithm} ist eine Gleitumgebung. Vielleicht kommt man ja leicht an die Interna ran, die nur die Box füllen. Dann lass ich mir von tocbasic ein \begin{myalgorithm}...\end{myalgorithm} geben und packe die Box da rein.

Deshalb war es auch so geschrieben, dass es selbst keine anderen KOMA-Script-Pakete benötigt hat, der Quelltext bestand nur aus tocbasic.dtx und scrlogo.dtx und durfte unabhängig vom restlichen KOMA-Script verteilt werden, die (englische) Anleitung war in tocbasic.dtx enthalten. Da sich aber in über 7 Jahren kein anderer Paketautor dafür interessiert hat, habe ich das jetzt aufgegeben. Künftig benötigt tocbasic auch scrkbase (die KOMA-Script-Erweiterung des anderen, ursprünglich allgemein angelegten Pakets scrbase) und ist integrierter Bestandteil von KOMA-Script, der nicht mehr alleine verteilt werden darf. Ich passe mich also an.

Du darfst übrigens gerne probieren, mit \DeclareNewTOC eine eigene Gleitumgebung für Algorithmen zu erzeugen. Bis zur endgültigen Release von KOMA-Script 3.20 ist derzeit geplant auch dabei Verzeichniseintragsstile zu unterstützen. Derzeit ist das aber noch nicht der Fall.

algorithm2e packt seine Ausgabe bei Verwendung von [H] an seiner Umgebung \begin{algorithm}[H]...\end{algorithm} in eine Minipage statt einer Gleitumgebung. Dann erzeugt

\DeclareNewTOC[%
type=myalgorithm,%
types=myalgorithms,%
float,%
floattype=4,%
name=Algorithmus,%
listname={Algorithmenverzeichnis}%
]{loa}
\setuptoc{loa}{chapteratlist}

alles nötige, damit

\begin{myalgorithm}
\caption{Lorem ipsum dolor sit amet}
\label{alg:test}
\begin{algorithm}[H]
...
\end{algorithm}
\end{myalgorithm}

so funktioniert wie bei allen anderen Verzeichnissen auch. Das Verzeichnis \listofmyalgorithms wird jedoch nicht so formatiert wie die anderen, da nur bei den Standardumgebungen (figure, table, chapter, section, ...) die Stile mit Standardwerten initialisiert werden. Es braucht also noch ein:

\DeclareTOCStyleEntry[raggedpagenumber=true,linefill={},indent=1.5em,numwidth=2.3em]{tocline}{myalgorithm}

damit die Dinge, die sich gleichen, auch gleich aussehen. Die Standardwerte hätten einen Platz in der Dokumentation verdient, dann müsste man sie nicht aus tocbasic.sty heraussuchen.

Seit gerade eben ist in der deutschen KOMA-Script-Anleitung der Quellen auch dokumentiert, wie man raggedpagenumber etc. direkt bei \DeclareNewTOC mit setzen kann.

Comments for "Verzeichniseintragsstile" abonnieren