longtable erhöht Tabellenzähler auch ohne caption

[IrenaSekuta]

Ich fände es schade, wenn es an "ungeklärten Lizensverhältnissen" liegen würde, ein Paket zu entwickeln, was die bereits genannten Mängel beseitigt.

Viel schwieriger ist die Frage, wer (hier) in der Lage ist, so ein Vorhaben tex-programmtechnisch umzusetzen. Ich bin es leider nicht, würde mich aber gerne bereit erklären, andere Tätigkeiten beizusteuern, z.B. die Erstellung der Dokumentation.

Eventuell wäre es auch möglich, die programmtechnische Erstellung stückweise als Learning-by-doing-Prozess hier im Forum durchzuführen. Ich würde sehr, sehr gerne das Programmieren von Latex-Paketen lernen, leider bin ich jedoch eine sehr schlechte Autodidatik und an Fachbüchern magelt es offenkundig.

Ich stelle mir das ganze in der Art vor, wie Markus in seinem "KOMA-Script"-Buch die Erstellung von "chapterthumb.sty" erklärt hat, mit dem Vorteil, dass man quasi "live" hier im Forum beim Verständnis des den Tex-Code nachfragen könnte, und so die Grundlagen von Tex lernen würde.

Ich möchte das einmal am Beispiel der ltablex-sty erläutern. Der Autor würde z.B. mit dem Paket anfangen und am ersten Tag das folgende schaffen:

\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{ltablex}[1995/11/06 v1.0 Modified tabularx]
\RequirePackage{longtable}[1994/12/08]
\RequirePackage{tabularx}[1994/02/03]

Und schon tauchen bei mir die erste Frage auf:

• Bedeutet das Datum in den eckigen Klammern, dass genau dieses Paket benötigt wird, oder mind. dieses Paket?

Und diese Frage könnten dann andere erfahrene Nutzer beantworten.

Ich hoffe, dass ich euch meien Idee näher bringen könnte. Mir würde es enorm helfen, das Programmieren von Latex endlich zu erlernen und nicht immer nur eine "Anwenderin" sein zu müssen.

Gruß,

Irena

PS: Ich habe den Status der Frage mal auf "beantwortet" geändert, da sie ja quasi beantwortet ist.

[KOMA]

• Bedeutet das Datum in den eckigen Klammern, dass genau dieses Paket benötigt wird, oder mind. dieses Paket?

Statt die Frage zu beantworten - was natürlich leicht möglich wäre - sei hier lieber auf den clsguide und auf source2e verwiesen, weil ich denke, dass es sinnvoller ist, wenn Paketlehrlinge erfahren, wo sie solche Informationen her bekommen.

Die Idee, quasi ein Paketautoren-Tutorium durchzuführen, hat durchaus etwas für sich. Ich bezweifle allerdings ein wenig, dass dieses Projekt hier wirklich gut geeignet ist. longtable und tabularx sind durchaus recht anspruchsvolle, trickreiche Pakete, die zusammenzuführen erst recht anspruchsvoll ist. Das gilt umso mehr, wenn man die Mängel der bisherigen Lösungen beseitigen will. Wobei für mich weniger ein Problem wäre, dass die "Tutoren" dabei Gefahr laufen unfreiwillig zu demonstrieren, dass man bei der Entwicklung der Idee mehrfach etwas wesentliches übersehen kann, was einem im Test dazu zwingt, mehrfach neu in Entwurf und Implementierung einzusteigen. Solche Irrwege gehören - zumindest bei mir - dazu und es schadet nichts, wenn Lehrlinge das selbst erfahren. Aber ich denke, dass es schwer wird, TeX-Feinheiten, e-TeX-Spezialitäten und LaTeX-Grundlagen gleichzeitig zu erarbeiten, ohne sich dabei in Details zu verlieren und gleichzeitig eine heillose Verwirrung anzurichten.

Kleinere Aufgaben wie die im KOMA-Script-Buch sind da einfacher zu beherrschen. Aus demselben Grund fordere ich Anwender auf, Dinge, die ich im Forum erkläre, zu studieren und Verständnisfragen dazu zu stellen. Das schlimmste, was passieren kann ist, dass ich nicht antworte, oder den Verdacht äußere, dass jemand bestimmte Teile des TeXbooks (oder von TeX by Topic) verstanden haben sollte, um das zu verstehen.

PS: Ich habe den Status der Frage mal auf "beantwortet" geändert, da sie ja quasi beantwortet ist.

Falls wir wirklich so ein Projekt beginnen, wäre es eventuell besser, dafür ein eigenes Thema zu beginnen.

PS: So ein gemeinsames Projekt durchzuziehen bedeutet übrigens für die Tutoren häufig einen größeren Aufwand, als das Ding einfach zu schreiben. Bei mir selbst ist es so, dass ich für die Quellcodedoku min. so lange brauche wie zur Implementierung selbst. Für die Anwenderdoku brauche ich in der Regel mehr als doppelt so lange.
Den Code dann auch noch einem Anfänger zu erklären, bzw. Code aus unterschiedlichen Quellen - darunter auch von Lehrlingen - zusammen zu führen, kann noch einmal erhebliche Zeit kosten. Diskussionen um Design und Implementierung noch nicht mit gerechnet. Zeit ist bei mir aber eines der Hauptprobleme. Ich müsste also etwas anderes dafür bleiben lassen.

[sommerfee]

longtable und tabularx sind durchaus recht anspruchsvolle, trickreiche Pakete, die zusammenzuführen erst recht anspruchsvoll ist. Das gilt umso mehr, wenn man die Mängel der bisherigen Lösungen beseitigen will.

Hier sehe ich auch das Hauptproblem. Man müsste longtable, tabularx, ltxtable und ltablex als ersten Schritt verstanden haben. Das läuft darauf hinaus, erstmal "The TeXbook" von Knuth und "TeX by Topic" durchzuarbeiten, und sich dann in die dafür relevanten LaTeX2e-Quellen einzuarbeiten. Hinzu kommt, daß David Carlisle einen eigenen TeX-Programmierstil hat, in den man sich auch erstmal hineindenken können muß.

Insgesamt eine ganze Menge Holz, und insbesondere nicht mal eben so einfach nebenbei zu machen.