From Schaelkle at zdv.uni-tuebingen.de Mon Apr 4 09:43:36 2005 From: Schaelkle at zdv.uni-tuebingen.de (Kuno Schälkle) Date: Mon, 4 Apr 2005 09:43:36 +0200 Subject: [Tustep-Liste] Import von RTF-Dateien Message-ID: <009701c538ea$0454dba0$11160286@zdv.unituebingen.de> Liebe TUSTEP-Fans, in letzter Zeit hauefen sich leider die Faelle, in denen RTF-Dateien mit dem Standard-Makro #*KONVERT nicht mehr nach TUSTEP konvertiert werden koennen. Die Ursache dafuer liegt nicht im Makro selbst, sondern in einem externen Programm, das vom Makro aufge- rufen wird, und das bei bestimmten RTF-Anweisungen streikt. Deshalb die Frage: Soll der Import von RTF-Dateien modernisiert werden? Wenn ja, welche Wuensche gibt es dazu? Falls Sie an einer Modernisierung interessiert sind, schicken Sie bitte an schaelkle at zdv.uni-tuebinge.de RTF-Dateien zum Testen. Vielen Dank fuer Ihre Antwort und freundliche Gruesse Kuno Schälkle From Schaelkle at zdv.uni-tuebingen.de Tue Apr 5 16:02:57 2005 From: Schaelkle at zdv.uni-tuebingen.de (Kuno Schälkle) Date: Tue, 5 Apr 2005 16:02:57 +0200 Subject: [Tustep-Liste] Import von RTF-Dateien (mit korrekter email-Adresse) Message-ID: <007301c539e8$2bd36f80$11160286@zdv.unituebingen.de> Liebe TUSTEP-Fans, in letzter Zeit hauefen sich leider die Faelle, in denen RTF-Dateien mit dem Standard-Makro #*KONVERT nicht mehr nach TUSTEP konvertiert werden koennen. Die Ursache dafuer liegt nicht im Makro selbst, sondern in einem externen Programm, das vom Makro aufge- rufen wird, und das bei bestimmten RTF-Anweisungen streikt. Deshalb die Frage: Soll der Import von RTF-Dateien modernisiert werden? Wenn ja, welche Wuensche gibt es dazu? Falls Sie an einer Modernisierung interessiert sind, schicken Sie bitte an schaelkle at zdv.uni-tuebingen.de RTF-Dateien zum Testen. Vielen Dank fuer Ihre Antwort und freundliche Gruesse Kuno Schälkle From trauth at uni-trier.de Tue Apr 19 04:13:55 2005 From: trauth at uni-trier.de (Michael Trauth) Date: Tue, 19 Apr 2005 04:13:55 +0200 Subject: [Tustep-Liste] #Satz und #Formatiere In-Reply-To: <20050211212520.GA6050@saphor.net> References: <420350BD.14929.3208123@localhost> Message-ID: <42648583.7275.10D79765@localhost> 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 ---------------------------------------------------------------