[Tustep-Liste] #Satz und #Formatiere

Di Apr 19 04:13:55 CEST 2005

Liebe Freunde und Kollegen

vor zwei Monaten habe ich hier in der Liste den Anstoss
zu einer Diskussion ueber die Frage gegeben, ob es nicht
zweckmaessig sei, das seit fast 20 Jahren arg vernachlaes-
sigte #Formatiere weiterzuentwickeln.

Es gab erfreulich viele Wortmeldungen zum Thema, einige
Argumente contra, die meisten jedoch pro, im ganzen aber
eine so lebhafte Diskussion, wie ich sie auf diesem Forum
noch nicht erlebt habe - uebrigens auch von Kontribuenten
gefuehrt, die sich bis dahin noch nie zu Wort gemeldet
hatten (was ich insgesamt als Indiz dafuer werte, dass die
Frage in weiteren Kreisen der TUSTEP-Benutzer als Problem
von vitalem Belang angesehen wird). Zahlreiche, teilweise
sogar recht detaillierte Wortmeldungen sind darueber hinaus
bei mir persoenlich eingegangen; sie waeren m.E. eine wich-
tige Bereicherung der Diskussion gewesen, wenn sich ihre
Verfasser haetten erweichen lassen, das Statement auch an
die Liste zu schicken. Leider ist nur einer davon meiner
Bitte gefolgt, die anderen scheuten den Schritt in die
oeffentliche Debatte, weil sie - m.E. zu Unrecht - ihre
Sicht des Problems fuer zu eng, sich selbst fuer nicht
kompetent genug oder als zu unerfahren einstuften. Das
ist schon deshalb sehr schade, weil meine Initiative
nicht zuletzt auf eben diesen Anwenderkreis besonders
zielte.
  In einigen dieser Zuschriften wurde mir der Vorwurf ge-
macht, mein Vorstoss sei in Wirklichkeit eine Kritik am
Satzprogramm, in einigen anderen, ich sei ein allzu un-
kritischer Verfechter des Satzprogramms. Das mutet auf
den ersten Blick widerspruechlich an - aber wenn ich's
recht bedenke, ist an beidem etwas dran: Ich bin tat-
saechlich ein begeisterter Anwender des Satzprogramms,
komme bestens damit zurecht (und wo nicht, ist die Ko-
operation mit dem Programmautor so vorbildlich wie bei
keiner anderen mir bekannten Anwendersoftware); das be-
deutet aber nicht, dass ich etliche (bes. historisch
gewachsene) Seiten des Satzprogramms nicht fuer reno-
vierungsbeduerftig hielte - und ich weiss aus zahlrei-
chen Gespraechen mit dem Programmautor, dass er selbst
in vielem diese Einschaetzung teilt.
  Um es noch einmal zu sagen: Ich selbst habe nicht
die geringsten Probleme mit den Ecken und Kanten des
Satzprogramms. Aber es gelingt mir immer seltener, ei-
nen TUSTEP-Aussenstehenden zu den Qualitaeten des Pro-
gramms zu fuehren, weil dieser schon beim ersten An-
blick der noetigen prozeduralen Zwischenschritte und
gewisser Inkonsistenzen der Satzanweisungen zurueck-
schreckt. Das Abschreckende ist dabei interessanter-
weise nicht die TUSTEP-typische Batchverarbeitung -
denn ueberraschend viele Interessenten sind damit zu-
mindest schon rudimentaer vertraut oder wissen, was
sie erwartet -, sondern die Notwendigkeit, sich auf
eine Art 'Programmierebene' und Spezialkenntnisse nur
fuer die Erfordernisse des Satzprogramms einzulassen.
Was damit gemeint ist? Man sehe beispielsweise:
- Zuerst muessen die Fussnoten vom Haupttext separiert
  und durchnumeriert werden;
- dann muessen Fnn und HT *getrennt* gesetzt werden;
- der verwendete Parametersatz kann nicht blind ver-
  verwendet werden, sondern es muss jedesmal der drit-
  te Wert von GRO in Abhaengigkeit davon geaendert
  werden, ob Fussnoten vorkommen oder nicht (oder es
  muss zur Ueberlistung von #Satz ein Trick verwendet
  werden, den ich hier lieber unerwaehnt lasse);
- bei Experimenten mit Ueberschriftendefinitionen
  muss der Anwender seit einiger Zeit darauf achten,
  dass der fuenfte Wert (NOCH) mindestens so gross
  ist wie der erste und der zweite Wert (LEER1+LEER2)
  zusammen;
- eine weitere Teilprozedur mit eigenem Satzlauf ist
  noetig, wenn ein- und zweispaltiger Satz gemischt
  werden sollen;
- eine weitere Teilprozedur mit eigenem Satzlauf ist
  noetig, wenn linkslaeufige Schriften verwendet wer-
  den sollen;
- bei allen Anweisungen muss der Anwender wissen,
  ob Blanks drumherum stehen *duerfen* oder stehen
  *muessen* oder ganz verboten sind;
- bei @-z, @.0, @..0 und @-0 beispielsweise muss er
  wissen, dass die simultane Verwendung von Kolumnen-
  titel- oder Marginalienkodierungen zum Ausfall der
  Zentrierung fuehrt (und mit welchen Tricks man das
  Problem ggf. umgeht), usw.
Ich fuehre diese Aufzaehlung nicht weiter, denn es geht
mir ausdruecklich *nicht* um eine Kritik am Satzprogramm.
Und auf die Gefahr hin, mich zu wiederholen: *Ich* habe
mit den geschilderten Stolpersteinen nicht das geringste
Problem. Aber machen Sie doch bitte einmal die Probe aufs
Exempel, und erzaehlen Sie einem windows-GUI-geschaedigten
Interessenten - gerne auch jemandem, der das Satzprogramm
fuer seine Aufgaben eigentlich dringend braucht - von den
skizzierten Erfordernissen. Zu den Hinweisen, dass besagte
prozeduralen Zwischenschritte sogar beachtliche *Vorteile*
haben koennen, gelangt die Unterhaltung dann meist gar
nicht mehr, weil die Gegenseite schon laengst nicht mehr
zuhoert.
  In etlichen Faellen habe ich das Problem dadurch 'ge-
loest', dass ich fuer meine Klientel projektspezifische
Satzroutinen und Blackboxes geschneidert, in der Folge-
zeit dann auch gewartet und auf neue bzw. zusaetzliche
Beduerfnisse angepasst habe. Innerhalb Triers funktio-
niert das auch ganz gut, ausserhalb und auf lange Di-
stanz schon deutlich schlechter - aber in jedem Fall
gilt, dass dieses Verfahren zu meinem allergroessten
Bedauern in der Regel unmuendige Benutzer heranzieht,
die nur noch rudimentaer verstehen, was denn ueberhaupt
an welcher Stelle der Prozedur passiert.
  Zur Loesung dieses Problems wurde vielfach - so
auch jetzt wieder in der Debatte um die Aufwertung
von #Formatiere - vorgeschlagen, dem Satzprogramm
doch einfach eine Makrooberflaeche (sprich: eine
eigene Bedienershell, eine Art 'Frontend', wie man
heute sagt) ueberzustuelpen, die bestimmte Lei-
stungen wie z.B. das Trennen und separate Setzen
von Fussnoten fuer den Benutzer unsichtbar erledi-
gen soll. Davon ist nun schon mehr als zehn Jahre
die Rede, aber nirgendwo ist eine entsprechende
funktionsfaehige Loesung in Sicht. Ich weiss von
wenigstens drei engagierten Anwendern, die ein sol-
ches Projekt mit grossem Elan in Angriff genommen
haben. Ich kann nur fuer mich selbst sprechen: Meine
eigenen einschlaegigen Versuche endeten immer in der
Unbrauchbarkeit, und zwar so gruendlich, dass ich in-
zwischen nicht mehr an die Loesbarkeit dieser Aufgabe
glaube. Warum? Man sehe sich die beiden vielverspre-
chenden Bildchen an, die Herr Giacomazzi seinem Votum
(vom 9.+10. Febr. 2005) fuer eine solche Benutzer-
oberflaeche beigelegt hat: So koennte die Parameter-
abfrage und -einstellung fuers Satzprogramm *tatsaech-
lich* aussehen und funktionieren. Aber das ist nur ein
winzigkleiner Teil der Aufgabe: Ich fuer mein Teil
habe jedenfalls noch keine *einzige* Satzroutine ein-
gesetzt, in der *nur* #Satz verwendet worden waere.
Zusaetzliche Prozedurteile (siehe etwa die obige Auf-
zaehlung), an denen regelmaessig geflickt, ergaenzt,
verbessert und umgestellt werden muss, sind eigent-
lich *immer* enthalten, will sagen: das Satzprogramm
ist ganz wesentlich auf Modularitaet (sprich: auf die
Interaktion mit anderen TUSTEP-Systemteilen) hin an-
gelegt - und dieser Eigenart kann *nur* eine Prozedur
gerecht werden, die ihrerseits wieder in einer GUI
(in deren Auswahlangebot der Problemhorizont des Be-
nutzers ja vollstaendig antizipiert sein muss) *un-
moeglich* abgefragt und zusammengestellt werden kann.
Ich lasse mich bereitwillig vom Gegenteil ueberzeu-
gen - aber bis ich eine solche funktionsfaehige GUI
nicht gesehen und ausgetestet habe, zweifle ich ener-
gisch an ihrer Realisierbarkeit. NB und nur fuer den
Fall, dass dieser Aspekt zu kurz gekommen waere: Nach
meiner Einschaetzung stellt dieser Charakterzug des
Satzprogramms sogar eine seiner Staerken dar, denn
unzaehlige Male habe ich schon Leistungen, die ueber
die native Funktionalitaet des Satzprogramms hinaus-
gehen, durch zwischengeschaltete Prozedurteile (KO-
piere, EInfuege, Registerprogramme u. dgl.) ergaenzt
- konkurrenzlose Funktionen zumeist, die anderwaerts
in muehsamer Handarbeit realisiert werden muessen.
  Ich sehe deshalb weder die Notwendigkeit noch die
Chance, am modularen und prozeduralen Charakter des
Satzprogramms etwas zu aendern. Herr Seck hat mir
mit seinem abgewogenen Votum vom 21. Febr. 2005 fuer
"Weiterentwicklung, aber bis auf weiteres nicht Neu-
programmierung des Satzprogramms" aus dem Herzen ge-
sprochen.
  Zugleich aber bleibt das geschilderte grundsaetz-
liche Problem bestehen, dass dem Satzprogramm der
Nachwuchs mehr und mehr wegbroeckelt, weil niemand
von aussen uebergangslos fuer diese Art der 'Satz-
programmierung' zu gewinnen ist. Und selbst wenn
er's waere: Warum sollte er so viel Lernaufwand be-
treiben, wenn er (zunaechst) bloss einen einfachen
wissenschaftlichen Text mit Fussnoten, Einschaltun-
gen und Ueberschriften, vielleicht auch noch mit
einem bibliographischen Anhang herstellen will?
Wie das Remedium aussehen koennte, habe ich schon
in meinem ersten Posting geschildert: Ich habe frue-
her sehr haeufig die Erfahrung gemacht, dass alle
Anwender, die mit dem "leicht und logisch zu erler-
nenden #Formatiere" (so die Formulierung von Marc-
Wilhelm Kuester, der ich mich gerne anschliesse)
schon vertraut waren, fast nahtlos und vor allem
ohne die skizzierten inneren Blockaden aufs Satz-
programm umsteigen konnten. Das #Formatiere in sei-
ner jetzigen Gestalt (die Ende der 80er Jahre fest-
geschrieben und seitdem nicht mehr gepflegt wurde)
leistet das nicht mehr - aber ein weiterentwickel-
tes #Formatiere koennte es, davon bin ich ueberzeugt.

Wie ich den bisherigen Wortmeldungen entnehmen konn-
te, sehen das auch die meisten anderen Diskutanten
so. Viele haben auch schon ganz konkrete Vorstellun-
gen und Wuensche angemeldet, wie das neue #FO aus-
sehen koennte. Darauf will ich hier und heute (noch)
nicht eingehen, denn zunaechst sollte ja erst ein-
mal in Abstimmung mit den Entwicklern geprueft wer-
den, ob es fuer ein solches neue #FO ueberhaupt eine
realistische Chance gibt. Wenn ja, reden wir weiter.
Aber es gab auch handfeste Kritik am Plan eines neuen
#FO: Herr Till etwa hielt es (im Gegensatz zu mir) fuer
illusorisch, neue Anwenderkreise durch ein solches Pro-
gramm gewinnen zu koennen, und Herr Giacomazzi formu-
lierte sogar "Denn für ein Programm, das weniger kann
als 'Word', nur ohne dessen Komfort, habe ich keine
Verwendung." In der Tat, das waere ein Killerkrite-
rium - wenn es sich denn als stichhaltig erwiese!
Aber bevor es stichhaltig ist, muss es erst einmal
konkret unterlegt werden. Wuerde das Argument von
einem Aussenstehenden vorgebracht, koennte ich es
vielleicht verstehen, jedoch von einem, der TUSTEP
kennt und schaetzt, verstehe ich es nicht. Was genau
ist denn dieses "weniger als 'Word'"? Das fehlende
WYSIWYG? Die kinderleichte Einrichtung von Tabellen
in Word? Die fehlende automatische Erzeugung von In-
haltsverzeichnissen und Registern auf Knopfdruck?
Die VB-Programmierung? Oder was? Das kann's doch
eigentlich nicht sein, denn das waeren allesamt
Funktionen, die Winword selbst dem Satzprogramm vor-
aushat. (Entschuldigung: Was heisst hier ueberhaupt
"voraushat"? Sowohl das unbrauchbare WYSIWYG wie auch
die minderwertigen automatisch erzeugten Inhaltsver-
zeichnisse und Register sollten in dieser Diskussion
eigentlich gar nicht erwaehnt werden duerfen.) Herr
Buedenbender und Herr Delfosse, von denen ich weiss,
dass sie beide gut mit Winword umzugehen verstehen,
haben sich gleichwohl mit guten Gruenden fuer die
Aufwertung von #FO ausgesprochen. Und ich verweise
auf den grossen Office-Report, den das Computerma-
gazin c't im vergangenen Jahr veroeffentlicht hat,
wo ausgerechnet dem teuersten Produkt (MS Office)
bescheinigt wurde, geradezu dilettantisch mit kom-
plexen Dokumenten, mit eingebetteten Grafiken und
Tabellen und Fussnoten umzugehen! Und es sei mir
gestattet, auf meine taegliche Beratungspraxis in
einem Universitaetsrechenzentrum zu verweisen, aus
der hysterische Winword-Anwender mit defekten, ir-
reparablen oder ganz einfach 'spinnerten' Dokumen-
ten nicht mehr wegzudenken sind. Ich verstehe ein-
fach nicht im geringsten, wie man *damit* ein Pro-
gramm vergleichen kann, das sich durch einfachste,
klarste Bedienung, Konzentration aufs Wesentliche
und durch hoechste Robustheit auszeichnet. Hundert
Seiten in einem Winword-Dokument koennen ja schon
ein Problem sein - zehn*tausend* Seiten sind da-
gegen fuer #FO eine Kleinigkeit. *DAS* nenne ich
einen Unterschied! Mehr als 98% aller Winword-Be-
nutzer brauchen von der ganzen Winword-Funktiona-
litaet nur einen Bruchteil - aber alle *sehnen*
sich geradezu nach einem Programm, mit dem sie
die staendigen Risiken und Unwaegbarkeiten des Win-
word-Einsatzes umgehen koennten. Denen koennte ich
14 Tage Satzprogramm-Schulung nicht zumuten, aber
zwei Tage #FO ohne weiteres. Natuerlich wuerden
sie nicht alle mit fliegenden Fahnen die Seiten
wechseln, aber allein schon zwei bis drei Prozent
davon wuerden dem TUSTEP-Nachwuchs einen betraecht-
lichen Schubs geben - und beide Seiten haetten viel
davon.

Mehr dazu bei naechster Gelegenheit. Ich wuerde
mich jedenfalls freuen, wenn das Thema auf diesem
Forum noch weiter diskutiert wuerde.

Viele Gruesse reihum von

Michael Trauth

---------------------------------------------------------------
Dr. Michael Trauth                  e-mail: trauth at uni-trier.de
Rechenzentrum                       office: Tel. 0651-201-3413
der Universitaet                            Fax  0651-201-3921
Universitaetsring                secretary: Tel. 0651-201-3417
D-54286 Trier
---------------------------------------------------------------