Alles neu macht der ...

Nun, in diesem Fall war ich es, der ein paar Neuerungen zu verantworten hat. Einige dieser Neuerungen sind aus der Not entstanden, andere haben sich im Zuge der Umsetzung geradezu aufgedrängt. Einige betreffen nur das KOMA-Script Documentation Project andere betreffen KOMA-Script selbst. Aber der Reihe nach ...

In letzter Zeit beobachte ich mich Besorgnis, dass neue Teilnehmer im KOMA-Script Documentation Project nicht nur den eigentlichen Zweck dieses Web-Auftritts ignorieren. Das beobachten wir ja bereits seit langem. Inzwischen werden aber auch zunehmend Formalien ignoriert.

Dass ich fehlende vollständige Minimalbeispiele einfordern muss, ist dabei auch nichts neues. Anfänger glauben immer wieder, dass diese Forderung für sie selbstverständlich nicht gelte und ihre Frage die eine Ausnahme von der Regel sei. Gerade bei Anfängern ist aber das Gegenteil der Fall. Diese stellen ihre Fragen sehr oft, sehr ungenau, so dass Menschen wie ich, viel Zeit damit verschwenden, herauszufinden, was denn eigentlich das Problem sein könnte und wie man es am besten löst.

Nicht selten geben Anfänger durchaus ein paar Zeilen Code an. Leider sehen sie sich aber anscheinend außer Stande einmal auf »Eingabeformat« zu klicken, um zu sehen, wie man Beiträge formatieren kann. Deshalb habe ich extra einen Hinweis auf das Speichern von Beiträgen getriggert, der deutlich in grüner Farbe mit blau hervorgehobenem Link nochmal auf die Formatierungsoptionen hinweist. Geholfen hat das genau gar nichts. Offenbar glauben dieselben Anwender, die es nicht für nötig erachten, ein vollständiges Minimalbeispiel an Stelle von ein paar Code-Fragmenten beizufügen, oder ihre Beispiele wirklich zu minimalisieren, dass auch solche Hinweise ausgerechnet für sie nicht gelten.

Das Problem habe ich nun zweigeteilt in Angriff genommen. Zum einen gibt es einen neuen FAQ-Eintrag, der sich mit häufigen Mängeln von Beiträgen beschäftigt. Erstaunlich, wieviel Zeit es kostet, so eine solche Negativ-Liste zu verfassen und wie umfangreich die dabei dann wird. Dabei wäre eine Positiv-Liste ganz kurz:

• Gib bei Fragen, Fehlermeldungen und einfach immer ein vollständiges Minimalbeispiel an.
• Nutze insbesondere für die Formatierung von Code die dafür vorgesehenen Formatierungsoptionen

wird aber leider kaum beachtet. Jetzt kann man also statt auf diese beiden Dokumenten auch auch gleich auf die eine Auflistung der Kriterien unzureichender Beiträge verweisen.

Desweiteren habe ich das KOMA-Script Forum in verschiedene Bereiche unterteilt. Da wäre zum einen die Punkte, für die das Forum ursprünglich mal gedacht war, nämlich als erstes die Mithilfe an KOMA-Script und der Doku, als zweites Verbesserungsvorschläge und als drittes Fehlermeldungen zu KOMA-Script. Da Support-Fragen wohl auch zukünftig unvermeidbar sind und ja aus der einen oder anderen Support-Frage durchaus auch ein Bug-Report oder Feature-Request entsteht, habe ich dann auch noch zwei Unterforen dafür eingerichtet. Das erste der beiden ist für Anfänger gedacht, das zweite für Anwender. Dabei beabsichtige ich alle Anwenderbeiträge, die sich nicht an die Forenbeschreibung halten und deren Beiträge insbesondere obige Mängel aufweisen, bei den Anfängern einzuordnen. Die Beiträge der anderen Unterforen werden dann von mir bevorzugt behandelt.

Achja, die Forenbeschreibungen habe ich außerdem noch extrem erweitert, um ebenfalls auf die Anforderungen zu verweisen. Dadurch leidet leider die Übersicht. Schade, dass solche Maßnahmen notwendig sind.

Tja und dann gibt es noch die Neuerungen bei KOMA-Script selbst. Wie schon im letzten Blog erwähnt, betrifft das scrlttr2 bzw. die lco-Dateien. Es gibt nun offiziell vier neue lco-Dateien, die teilweise als BETA gekennzeichnet sind. Die NF.lco war eher unproblematisch. Hier haben Anwender sehr schön vorgearbeitet, so dass ich die in erster Linie in KOMA-Script integrieren musste. Schwieriger war der Fall bei UScommercial9.lco und UScommercial9DW.lco. Leider konnte niemand der Beteiligten verbindliche Angaben für Anschrift, Faltmarken etc. in amerikanischen Briefen finden. Bei den Fensterbriefumschlägen wiederum gibt es eine reiche Auswahl an teilweise erheblich unterschiedlichen Formen. Mal gibt es ein, mal zwei Fenster. Die Fenster sind je nach Hersteller unterschiedlich groß und an unterschiedlicher Stelle platziert. Die Umschläge selbst gibt es in extrem vielen Formaten. Angeblich ist das Format commercial No. 9 eines der am häufigsten verwendeten. Aber auch dafür gibt es bezüglich der Fenster unzählige Ausprägungen. Ich habe deshalb beispielhaft eine Fassung mit einem Fenster und eine mit zwei Fenstern herausgegriffen und dafür die beiden lco-Dateien geschrieben.

Im Zuge der Erstellung der lco-Dateien für amerikanische Briefe habe ich dann noch eine uralte Test-lco von mir wieder ausgegraben. Die konnte bis dahin nur einige Felder auf dem Briefbogen markieren, so dass man sie ausmessen konnte. Ich habe dann fast zwei Tage darauf verwendet, das so aufzubohren, dass man nun auch Umschläge damit darstellen kann, wobei die existierenden Pseudo-Längen für die Position der Darstellung von Briefbogen und Anschriftfeld verwendet werden. Diese neue lco-Datei habeich visualize.lco genannt, weil man damit Dinge visualisieren kann. Ich hätte sie auch debug.lco nennen können. In UScommercial9DW.lco ist dann noch eine Erweiterung für visualize.lco enthalten, um beide Fenster anzuzeigen.

Es ist erstaunlich wieviel Zeit man für solche Kleinigkeiten verwenden kann. Aber immerhin hat mir das zumindest teilweise Spaß gemacht. Außerdem hatte mich einfach der Ehrgeiz gepackt, weil ich wollte, dass auch US-Anwender scrlttr2 endlich direkt verwenden können. Damit werden von scrlttr2 inzwischen diverse Regionen in Amerika, Europa und Asien abgedeckt. Gleichzeitig zeigen die verschiedenen lco-Dateien das Potential, das in scrlttr2 steckt.

Bis demnächst
Markus