Sie sind hier

Bugs in (bzw. Featurewunsch für) Paket tocstyle

Das Paket tocstyle liegt zwar erst als Alpha-Version vor; ich benutze es jedoch seit einigen Monaten zu Testzwecken und empfinde es als bereits recht ausgereift. Die von mir nachfolgend dargestellten Bugs (einer könnte auch als Featurewunsch verstanden werden) sind vielleicht ein Anreiz für Markus Kohm, tocstyle in den wohlverdienten Beta-Status zu erheben.

Bug 1 und 2 betreffen die Verzeichniseinträge der Ebenen part und (in scrbook) chapter; diese werden anders (im Fall des Stils standard deutlich anders) formatiert als in der Dokumentation zu tocstyle angegeben. Bug 3 betrifft die Option toctextentriesindented; bei Verwendung von \addchap und \addsec im gleichen Dokument werden die Verzeichniseinträge zu \addsec zu weit eingerückt. Einzelheiten siehe Minimalbeispiel:

\documentclass{scrbook}
 
\usepackage[latin1]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[ngerman]{babel}
 
% Im voreingestellten Stil standard werden (entgegen den Angaben in der Dokumentation) 
% die Ebenen part und chapter im Inhaltsverzeichnis nicht fett gesetzt (Bug 1); auch 
% wird part nicht in größerer Schrift gesetzt (Bug 2).
\usepackage[toctextentriesindented]{tocstyle}
 
% Bei Verwendung des Stils KOMAlike (oder eines daraus abgeleiteten Stils) werden part 
% und chapter korrekt auf serifenlose fette Schrift umgeschaltet; Bug 2 tritt weiterhin 
% auf.
% \usetocstyle{KOMAlike}
 
\begin{document}
 
\tableofcontents
 
\addchap{\abstractname}
 
Der Text der Zusammenfassung.
 
\part{Ein Teil}
 
\chapter{Ein Kapitel}
 
\section{Ein Abschnitt}
 
Der Text des Abschnitts.
 
% Bei Verwendung der Option toctextentriesindented wird der folgende unnummerierte 
% Abschnitt im Inhaltsverzeichnis zu weit eingerückt (Bug 3 bzw. Featurewunsch).
\addsec{\abstractname\ zu \thechapter}
 
Der Text der Kapitel-Zusammenfassung.
 
\end{document}

Anmerkung zu Bug 3 ("Featurewunsch"): Die Kombination von \addchap und \addsec hat vermutlich nicht allzu viele praktische Anwendungsmöglichkeiten. Ich benutze \addsec, um (wie im Minimalbeispiel angedeutet) einen unnummerierten zusammenfassenden Abschnitt an das Ende jedes Kapitels (ausgenommen Einleitung und Schluss) zu stellen.

forum: 
Bild von Markus Kohm

Das Problem bei tocstyle ist, dass es in Bereiche eingreift, die von vielen, vielen anderen Paketen genutzt oder ebenfalls verändert werden. Es wäre deshalb eigentlich erforderlich, die Kompatibilität mit diversen Paketen zu prüfen. Gemeldet wurde bisher ein Problem im Zusammenspiel mit hyperref, das ich bisher aber nicht reproduzieren konnte. Demnach haben zwei Anwender eine Fehlermeldung bekommen, wenn sie beide Pakete verwenden aber kein color oder xcolor laden. Das ist deshalb für mich verwunderlich, weil tocstyle überhaupt nichts mit Farben macht.

Desweiteren würde ich eigentlich noch gerne ein paar Features hinzufügen. Dabei ist derzeit hinderlich, dass scrpage2 auf eine Grundüberholung wartet und so lange ein dort und in den KOMA-Script-Klassen anzusiedelndes Feature, das Rückwirkungen auf tocstyle haben könnte, noch nicht implementiert werden kann.

Aufgrund der Bedeutung dieses Foren-Eintrags habe ich ihm mal vorübergehend einen URL-Alias gegeben.
Derzeit sind nicht einmal alle Features im Anwenderbereich der Doku erfasst. Manches ist nur rudimentär in der Implementierungsdoku zu finden, wobei die Doku selbst teilweise ein Beispiel für die Verwendung liefert. Hier wäre schlichte Man-Power von Nöten, um die fehlenden Dinge auch noch zu dokumentieren.

tocstyle ist derzeit nicht einmal auf optimale Zusammenarbeit mit tocbasic getrimmt. tocbasic ist nämlich erst nach tocstyle entstanden, wurde aber vorgezogen, weil es mir vieles erleichtert. Ob da überhaupt irgendwelche Anpassungen sinnvoll oder notwendig sind, wurde bisher nicht einmal geprüft.

Auch die Schnittstelle von tocstyle ist noch nicht in Beton gegossen. Es gibt Anfragen, ob es nicht sinnvoll wäre, das Paket direkt mit key=value-Schnittstelle zu versehen. Ich hatte das anfänglich nicht gemacht, weil ich tocstyle nicht in KOMA-Script integrieren, sondern wahlweise als getrenntes Paket anbieten wollte, die key=value-Schnittstelle aber natürlich auf scrbase oder scrkbase aufsetzen würde.

Ich könnte natürlich die ALPHA-Warnung rauswerfen und einfach irgendwo darauf hinweisen, dass bei mir alle Pakete mit einer Versionsnummer

Bild von Markus Kohm

Du gehst in Deiner Darstellung davon aus, dass der Stil standard voreingestellt ist. In der tocstyle-Anleitung heißt es aber:

Note: Before you're setting a style the style of the TOCs are unspecified. This means that some entries may be set using tocstyle others may not.

Das bedeutet, dass gar kein definierter Stil voreingestellt ist. Auch das ist ein Punkt, der für eine Alpha-Version völlig in Ordnung ist. Für eine Beta oder eine Release sollte man aber entweder sicher Stelle, dass tocstyle in diesem Zustand gar keinen Einfluss nimmt oder aber tatsächlich ein Stil voreingestellt ist.

Fügt man in Deinem Beispiel ein \usetocstyle{standard} ein, dann verschwindet Bug 1.

Bild von Markus Kohm

Hiermit hast Du auch dann noch recht, wenn man den entsprechenden Stil tatsächlich einstellt. Da fehlen schlicht ein paar \large in der Einstellung für des Features entryhook.

Tatsächlich kommt es aber bei Verwendung einer KOMA-Script-Klasse noch ein wenig schlimmer. Inzwischen kennen die KOMA-Script-Klassen nämlich diverse Font-Elemente für Inhaltsverzeichniseinträge. tocstyle verwendet hier aber noch immer nur \sectfont, also das obsolete interne Makro für das Element disposition. Das ist also schon einmal ein Punkt, an dem das Paket zu aktualisieren ist, bevor es BETA werden kann.

Gibt es eigentlich einen Grund für das unterschiedliche Verhalten bei der Größe der Part-Einträge im Inhaltsverzeichnis zwischen dem Standard-KOMA-Script und dem tocstyle-Stil "KOMAlike"? Meiner Meinung nach sollte tocstyle allein schon aus Gründen der Konsistenz das Verhalten der KOMA-Klassen 1:1 abbilden. Wenn sich dies nur sehr schwierig bis gar nicht umsetzen lässt, könnte man die Abweichung ja zumindest in der Dokumentation erwähnen.

Bild von Markus Kohm

Wie bereits erwähnt, ist das Paket noch in Entwicklung. Die Entwicklung stockt derzeit aber, weshalb das durchaus bekannte und wie bereits erwähnte eigentlich sehr viel tiefer gehende Problem bisher nicht beseitigt wurde. Nichts desto trotz kann man sich entsprechend der Anleitung natürlich einen abgeleiteten oder einen neuen Stil definieren, bei dem dieses Problem nicht auftritt.

Um es noch einmal ganz deutlich zu sagen: Dieses Paket ist alpha! Es gibt dafür weder Support, noch ist garantiert, dass künftige Versionen kompatibel mit der derzeitigen sind. Es ist nicht einmal garantiert, dass das Paket weiterentwickelt wird!

Entschuldige bitte, falls du das in den falschen Hals bekommen hast. Ich wollte nicht in irgendeiner Form drängeln oder nerven. Was der Status alpha bedeutet, ist mir durchaus bewusst. Da die letzte Anfrage diesbezüglich aber mehr als 3 Jahre her ist und sich an dem Problem seitdem nichts geändert hat, wollte ich nur mal vorsichtig nachfragen, schließlich hast du ja selber hier auf tocstyle hingewiesen. Allerdings ist mir der kleine dezente Hinweis, dass das Paket seit Jahren als alpha deklariert ist, wohl entgangen.

Ich möchte dir an dieser Stelle gerne mal ein Dankeschön aussprechen. Was du durch KOMA-Script aber auch durch weitere Pakete an Möglichkeiten geschaffen hast und wie viel Zeit du dabei investiert haben musst, ist einfach großartig und schier unglaublich. Die kompetente und wohlwollende Unterstützung bei Problemen ist daher umso bemerkenswerter. Vielen Dank!

Bild von Markus Kohm

Warum mit Option toctextentriesindented die nicht nummerierten \section- und \addsec-Einträge zu tief eingezogen werden, weiß ich noch nicht, kann ich aber ebenfalls als Bug bestätigen. Das Debuggen ist nicht ganz einfach, weil es so viele unterschiedliche Fälle gibt und die automatische Berechnung des Einzugs die Geschichte nicht gerade vereinfacht.

Hier zunächst die Versionenliste aus der Logdatei. Die verwendeten Pakete wurden zuletzt vor einer Woche via MiKTeX 2.7 aktualisiert.

 *File List*
 scrbook.cls    2009/04/03 v3.03a KOMA-Script document class (book)
scrkbase.sty    2009/04/03 v3.03a KOMA-Script package (KOMA-Script-dependent ba
sics and keyval usage)
 scrbase.sty    2009/04/03 v3.03a 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/01/20 v3.02a(package)
scrsize11pt.clo    2009/04/03 v3.03a KOMA-Script font size class option (11pt)
typearea.sty    2009/04/03 v3.03a KOMA-Script package (type area)
inputenc.sty    2006/05/05 v1.1b Input encoding file
  latin1.def    2006/05/05 v1.1b Input encoding file
 fontenc.sty
   t1enc.def    2005/09/27 v1.99g Standard LaTeX file
   babel.sty    2008/07/06 v3.8l The Babel package
 bblopts.cfg    2006/07/31 v1.0 MiKTeX 'babel' configuration
ngermanb.ldf    2008/07/06 v2.6n new German support from the babel system
tocstyle.sty    2008/10/20 v0.2c-alpha LaTeX2e KOMA-Script package (versatile t
oc styles)
  t1cmss.fd    1999/05/25 v2.5h Standard LaTeX font definitions
 ***********

Bei meiner Meldung von "Bug" 1 bin ich einer typischen Enduser-Erwartungshaltung erlegen - "Der Stil standard ist natürlich voreingestellt - warum sonst sollte er so heißen?" Für spätere tocstyle-Versionen rege ich an, diesen Stil oder den Stil KOMAlike tatsächlich voreinzustellen; dies könnte auch von der verwendeten Klasse abhängig gemacht werden (Featurewunsch!).

Bug 3 wird offenbar nicht allein durch \addsec verursacht - dieser Befehl erzeugt im folgenden neuen Minimalbeispiel (mit der Klasse scrartcl) eine korrekte Einrückung im Inhaltsverzeichnis, jedoch nur, sofern das Dokument keinen \part-Befehl enthält.

\documentclass{scrartcl}
 
\usepackage[latin1]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[ngerman]{babel}
 
\usepackage[toctextentriesindented]{tocstyle}
\usetocstyle{standard}
 
\begin{document}
 
\tableofcontents
 
% Einkommentieren dieser Zeile erzeugt fehlerhafte Einrückung von \addsec
% \part{Ein Teil}
 
\section{Ein Abschnitt}
 
Der Text des Abschnitts.
 
\addsec{Ein unnummerierter Abschnitt}
 
\end{document}

Zum Alpha-Status bzw. zur Zuverlässigkeit: Mir war nicht bewusst, dass tocstyle zahlreiche Kompatibilitätsfragen aufwirft - das rechtfertigt natürlich weitere Tests. Ich selbst arbeite mit einer umfangreichen individuell konfigurierten LaTeX-Präambel (ca. 30 Pakete und einige Dutzend selbstgeschriebene Codezeilen) und konnte bis jetzt keine Unvereinbarkeit von tocstyle mit hyperref oder einem anderen Paket beobachten (natürlich verwende ich nicht gleichzeitig tocloft oder titletoc). Hinweise, bei welcher Art von Paketen oder Zusatzcode besondere Aufmerksamkeit angebracht ist, beachte ich gerne.

Für eine verbesserte Zusammenarbeit von tocstyle mit anderen KOMA-Script-Paketen nehme ich gern das weitere Warten auf den Beta-Status in Kauf - mit der doch recht deutlichen Alpha-Warnung habe ich inzwischen zu leben gelernt. ;-) Wenn die verbesserte Version auch zusätzliche Features enthält - umso besser. Dabei plädiere ich jedoch dafür, weiterhin auf die einfache Bedienbarkeit des Pakets zu achten (z.B. vorgefertigte Stile, Umschalten gleichartiger Formatierungen mit nur einem Befehl). Und gerade wegen des eleganten, auch für LaTeX-Einsteiger gut handhabbaren Designs sollte tocstyle aus meiner Sicht trotz der Verknüpfung mit KOMA-Script auch mit anderen Klassen verwendet werden können.

lockstep

P.S.: Der URL-Alias dieses Forenbeitrages sollte tocstyle (und nicht tocbasic) lauten.

Bild von Markus Kohm

Wenn ich das mal wüsste. So ist mir selbst absolut unklar, warum Anwender eine Fehlermeldung beobachtet haben, wenn unter gewissen Umständen hyperref und tocstyle geladen werden, diese aber verschwindet, wenn color oder xcolor geladen werden. Bisher gibt es kein Minimalbeispiel dazu. Das es aber zwei unabhängige Berichte dazu gibt, kann ich das nicht einfach als Hirngespinst abtun. Nun, notfalls muss ich das als bekanntes Problem dokumentieren.

Rechnen würde ich persönlich mit Problemen bei allen Paketen, die selbst Verzeichnisse erzeugen. Erwarten würde ich Probleme bei allen Paketen, die in die Erzeugung von Verzeichnissen eingreifen. Dabei ist natürlich noch zu unterscheiden, welches Paket zuerst geladen wird.

Natürlich wird es auch bei einer Erweiterung oder bei einer Änderung der Schnittstelle vorgefertigte Stile geben. Und natürlich soll die Schnittstelle nicht komplizierter, sondern eher einfacher werden. Ein entsprechendes Redesign ist aber noch nicht in Sicht. Bisher existiert nur der Gedanke, dass es sinnvoll sein könnte.

Natürlich soll tocstyle auch zukünftig mit anderen Klassen verwendet werden können. Die Bedingung, dass es unabhängig vom restlichen KOMA-Script-Paket weitergegeben werden darf, wäre aber natürlich sinnlos, sobald es auf andere KOMA-Script-Pakete zurückgreifen würde, für die das nicht gilt, beispielsweise scrkbase (im Gegensatz zu scrbase). Inwieweit es überhaupt eine Rolle spielt, ob man das Paket ohne das restliche KOMA-Script weitergeben darf, weiß ich nicht. Das TeX-Live-Team tut aber immer so, als wäre die Größe von KOMA-Script ein Riesenproblem. Mir ist in den letzten Jahren aber niemand mehr begegnet, der nicht (meist unbemerkt) mit LaTeX auch KOMA-Script installiert hatte. Das TeX-Live-Team führt immer gerne Entwicklungsländer als Beispiel auf. Wie ich gestern im Radio gehört habe steht Deutschland bei der Breitbandversorgung nur auf Platz 22 und Süd-Korea auf Platz 1.

Bild von Markus Kohm

Der Bug im Zusammenhang mit scrartcl hatte einen ganz einfachen Grund. Im Gegensatz zu article war bei scrartcl die Ebene \part noch immer als 0 einsortiert. Ich dachte zwar, dass ich das schon einmal geändert hätte, da habe ich mich aber entweder getäuscht oder es war eine Änderung in den 2.9er-Versionen, die ich nicht nach 2.95 übernommen hatte. Jedenfalls habe ich das nun geändert und es passt.

Wichtig zu wissen ist, dass die section-Ebene nicht gegenüber der part-Ebene eingezogen wird. Das ist auch bei den Standardklassen nicht anders.

Allerdings habe ich jetzt ein Problem, wenn man article statt scrartcl verwendet. Die Ursache muss ich auch noch finden und beseitigen.

Der Bug im Zusammenhang mit scrbook ist offenbar ein anderer.

Bild von Markus Kohm

Ich habe in den letzten Tagen eine ganze Reihe von Korrekturen an tocstyle vorgenommen. Leider waren einige davon so tiefgreifend, dass ich nicht ausschließen kann, dass ich dabei eventuell auch wieder etwas kaputt gemacht habe. Bevor ich die deutsche Doku anfasse, wäre es deshalb schön, wenn diejenigen, die ein Problem mit tocstyle gemeldet haben, und diejenigen, die tocstyle mit zufriedenstellendem Ergebnis verwendet habe, das mal testen würden. Dazu werden die Dateien tocstyle.dtx, scrlogo.dtx und scrbeta.dtx aus dem SVN benötigt. Mit »tex tocstyle.dtx« erhält man dann ein funktionsfähiges tocstyle.sty. Mit scrartcl kann man das allerdings derzeit nicht verwenden, wenn man gleichzeitig Inhaltsverzeichniseinträge der Ebene part hat. Dazu würde man auch noch eine neue Version von scrartcl und ggf. von scrpage2 benötigen.

Natürlich kann man sich theoretisch auch eine komplette SVN-Version von KOMA-Script ziehen. Im README.SVN steht prinzipiell beschrieben, wie man dabei vorgeht. Aber trotzdem ist das nicht für jeden zweckmäßig und durchführbar.

Dokumentiert sei hiermit, dass bei Klassen, die nummerierte Einträge ohne \numberline erzeugen, Option toctextentriesindented nicht korrekt funktionieren kann. Das betrifft beispielsweise die part-Einträge bei den Standardklassen. Immerhin habe ich einen Workaround implementiert, der bei den Standardklassen dann dafür sorgen sollte, dass die nicht nummerierten und nummerierten part-Einträge wenigstens nicht mit irgendeinem negativen Einzug gesetzt werden.

Leider habe ich erst heute bemerkt, dass in diesem Forenthema neue Kommentare erfolgt sind. Ich habe nun die aktuelle SVN-Version von tocstyle (0.2d vom 9.11.) getestet (bzw. werde sie in den nächsten Wochen weiter testen). Erste Eindrücke:

- Der Bug in meinem Minimalbeispiel vom 19.6. tritt nicht mehr auf. Dies ist insofern verblüffend, als ich lediglich tocstyle.sty, nicht jedoch scrartcl.cls via SVN aktualisiert habe (und somit eigentlich Inkompatibilität bestehen sollte.)

- Die drei Bugs in meinem Minimalbeispiel vom 18.6. sind nach wie vor präsent. (Mir ist nicht klar, ob die "diversen Fixes" auch diese Bugs beseitigen hätten sollen.)

- Ich bin auf einen möglichen neuen Bug gestoßen, der jedoch auch Folge eines unzulässigen Workarounds für einen alten Bug sein könnte. Konkret arbeite ich derzeit mit \protect\numberline, um korrekte Einrückungen für nichtnummerierte Abschnitte zu erreichen. Bei Verwendung von \part (und nur dann) bewirkt dies mit scrbook einen zusätzlichen Punkt vor dem \addsec-Verzeichniseintrag. Minimalbeispiel:

\documentclass{scrbook}
 
\usepackage[latin9]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[ngerman]{babel}
 
\usepackage[toctextentriesindented]{tocstyle}
\usetocstyle{KOMAlike}
 
\begin{document}
 
\tableofcontents
 
\addchap{\abstractname}
 
Der Text der Zusammenfassung.
 
% Einkommentieren dieser Zeile erzeugt Punkt vor \addsec-Eintrag
% \part{Ein Teil}
 
\chapter{Ein Kapitel}
 
\section{Ein Abschnitt}
 
Der Text des Abschnitts.
 
% Workaround, um korrekte Einrückung von \addsec-Eintrag zu erreichen
\addsec[\protect\numberline{}\abstractname\ zu \thechapter]{\abstractname\ zu \thechapter}
 
Der Text der Kapitel-Zusammenfassung.
 
\end{document}

Die Fileübersicht aus der Logdatei:

 *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 basics 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)
inputenc.sty    2008/03/30 v1.1d Input encoding file
  latin9.def    2008/03/30 v1.1d Input encoding file
 fontenc.sty
   t1enc.def    2005/09/27 v1.99g Standard LaTeX file
   babel.sty    2008/07/06 v3.8l The Babel package
 bblopts.cfg    2006/07/31 v1.0 MiKTeX 'babel' configuration
ngermanb.ldf    2008/07/06 v2.6n new German support from the babel system
tocstyle.sty    2009/11/09 v0.2d-alpha LaTeX2e KOMA-Script package (versatile toc styles)
  t1cmss.fd    1999/05/25 v2.5h Standard LaTeX font definitions
 ***********

Ich hoffe, dass diese Rückmeldung dazu beiträgt, tocstyle weiter zu verbessern. Bei dieser Gelegenheit möchte ich Markus Kohm allgemein für seine bisherige - und hoffentlich auch zukünftige - Arbeit an KOMA-Script danken.

lockstep

Ich bin auf einen weiteren Bug in der Version 0.2d (die immer noch die aktuelle Version im SVN ist) gestoßen: Bei Verwendung der Klasse scrartcl funktioniert das Setzen von entryhook mittels \settocfeature - im konkreten Fall, um (typographisch vielleicht fragwürdig) "Abb.~" an den Beginn jedes Eintrags im Abbildungsverzeichnis zu setzen - nur, solange nicht mittels \usetocstyle ein Stil für die Verzeichnisse ausgewählt wird. Mit scrbook tritt das Problem nicht auf.

\documentclass{scrartcl}
 
\usepackage[latin9]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[ngerman]{babel}
 
\usepackage{tocstyle}
% \usetocstyle{KOMAlike}
\settocfeature[lof]{entryhook}{Abb.~}% funktioniert nur ohne \usetocstyle
 
\begin{document}
 
\listoffigures
 
\captionof{figure}{Eine Abbildung}
 
\end{document}

File List:

 *File List*
scrartcl.cls    2010/02/15 v3.05 KOMA-Script document class (article)
scrkbase.sty    2010/02/15 v3.05 KOMA-Script package (KOMA-Script-dependent bas
ics and keyval usage)
 scrbase.sty    2010/02/15 v3.05 KOMA-Script package (KOMA-Script-independent b
asics 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    2010/01/05 v3.04b KOMA-Script package (handling toc-files)
scrsize11pt.clo    2010/02/15 v3.05 KOMA-Script font size class option (11pt)
typearea.sty    2010/02/15 v3.05 KOMA-Script package (type area)
inputenc.sty    2008/03/30 v1.1d Input encoding file
  latin9.def    2008/03/30 v1.1d Input encoding file
 fontenc.sty
   t1enc.def    2005/09/27 v1.99g Standard LaTeX file
   babel.sty    2008/07/06 v3.8l The Babel package
 bblopts.cfg    2006/07/31 v1.0 MiKTeX 'babel' configuration
ngermanb.ldf    2008/07/06 v2.6n new German support from the babel system
tocstyle.sty    2009/11/09 v0.2d-alpha LaTeX2e KOMA-Script package (versatile t
oc styles)
  t1cmss.fd    1999/05/25 v2.5h Standard LaTeX font definitions
 ***********

lockstep

Der von mir am 29.11.2009 gemeldete "mögliche neue Bug" lässt sich durch Setzen der KOMA-Script-Option "numbers=noendperiod" vermeiden.

lockstep

Comments for "Bugs in (bzw. Featurewunsch für) Paket tocstyle" abonnieren