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

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

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.

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.

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.