From friedhelm.hoffmann at mail.uni-wuerzburg.de  Thu Mar  6 16:02:32 2003
From: friedhelm.hoffmann at mail.uni-wuerzburg.de (Friedhelm Hoffmann)
Date: Thu, 06 Mar 2003 16:02:32 +0100
Subject: [Tustep-Liste] doppelter umgekehrter Apostroph
Message-ID: <3E676307.23CFF674@mail.uni-wuerzburg.de>

Liebe TUSTEPler,

in einem mehrsprachigen Sammelband soll jeder Beitrag nach den
typographischen Konventionen der jeweiligen Sprache gestaltet werden.
Wer kann mir sagen, wie man den doppelten umgekehrten Apostroph =
dasjenige Zeichen, das in den englischen typographischen Konventionen
das oeffnende Anfuehrungszeichen bildet, kodiert? Waehrend man das
schliessende mit #." von Hand erzeugen kann, komme ich mit dem
oeffnenden nicht zurecht. Der Code ^'^' erzeugt ja nur zwei einzelne
(also zu weit ausenanderstehende) umgekehrte Apostrophe. Auch hilft die
Karte AFZ im #satz nur insofern weiter, als ich zwar englische Belegung
der Anfuehrungszeichen erzielen koennte - ich muesste dann halt alle
anderen Anfuehrungszeichen (die nicht nach englischen Konventionen
erscheinen sollen), in ihre explizite Kodierung #.< und #.> austauschen
(lassen). Aber vielleicht geht es ja einfacher - und ich bin einfach nur
zu bloed oder blind, im Handbuch den entsprechenden Code zu finden.

Mit bestem Dank im Voraus und vielen Gruessen reihum,

Friedhelm Hoffmann


From friedhelm.hoffmann at mail.uni-wuerzburg.de  Thu Mar  6 17:02:14 2003
From: friedhelm.hoffmann at mail.uni-wuerzburg.de (Friedhelm Hoffmann)
Date: Thu, 06 Mar 2003 17:02:14 +0100
Subject: [Tustep-Liste] doppelter umgekehrter Apostroph
Message-ID: <3E677106.4026ADCC@mail.uni-wuerzburg.de>

Liebe TUSTEPler, lieber Herr Delfosse,

die rasche Antwort hat mich natuerlich sehr gefreut.. Dennoch mochte/muss ich
noch einmal auf das Problem zurueckkommen.

Herr Delfoss schrieb:

> in einem ähnlichen Fall habe ich das Problem wie folgt gelöst. Sie
> machen sich für jedes Anführungszeichen eine eigene
> Makrodefinition. Also z.B.:
>
> <'> wird '
> </'> wird ^'
> <x> wird #.,
> </x> wird #.'
> <y> wird #.>
> </y> wird #.< usw.

"usw." - ja, eben! Damit ist mein Problem nicht geloest, da ich nicht weiss,
was ich fuer den doppelten umgekehrten Apostroph als Kodierung einzusetzen
habe. Die Liste von Herrn Delfosse enthaelt: Apostroph, umgekehrten Apostroph,
Anfuehrungszeichen oben, Anfuehrungszeichen unten, Anfuehrungszeichen doppelt
(Spitze nach rechts und nach links) - aber nicht den doppelten umgekehrten
Apostroph! Es muss doch eine (explizite) Kodierung fuer ihn geben, wenn TUSTEP
ihn auch von sich aus im Satzprogramm erzeugen kann.

> Wenn Sie zeichenorientiert (und nicht sprachorientiert) vorgehen,
> haben Sie sicher bald alles im Griff.

Die ist natuerlich von meinem Problem unabhaengig. In meinem Fall, wo die
Daten fuer jeden Beitrag sowieso jeweils in einer eigenen Datei vorliegen,
erscheint es mir einfacher, wenn ich jede Datei durch ein #kopiere jage, in
dem in Abhaengigkeit von der Position und Umgebung von " bzw. #.? die
explizite Kodierung eingesetzt wird. Dann muss ich mir die einzelnen Zeichen
gar nicht mehr angucken.

> PS.: Gibt es noch eine bessere Lösung? Ich bitte um Mitteilung.
>

> On 6 Mar 2003 at 16:02, Friedhelm Hoffmann wrote:

Nochmals viele Gruesse an alle,

Friedhelm Hoffmann

>
>
> > Diskussionsforum Tustep-Liste
> > Weitere Informationen: www.itug.de
> > ------------------------------------------------------------
> >
> > Liebe TUSTEPler,
> >
> > in einem mehrsprachigen Sammelband soll jeder Beitrag nach den
> > typographischen Konventionen der jeweiligen Sprache gestaltet werden.
> > Wer kann mir sagen, wie man den doppelten umgekehrten Apostroph =
> > dasjenige Zeichen, das in den englischen typographischen Konventionen
> > das oeffnende Anfuehrungszeichen bildet, kodiert? Waehrend man das
> > schliessende mit #." von Hand erzeugen kann, komme ich mit dem
> > oeffnenden nicht zurecht. Der Code ^'^' erzeugt ja nur zwei einzelne
> > (also zu weit ausenanderstehende) umgekehrte Apostrophe. Auch hilft die
> > Karte AFZ im #satz nur insofern weiter, als ich zwar englische Belegung
> > der Anfuehrungszeichen erzielen koennte - ich muesste dann halt alle
> > anderen Anfuehrungszeichen (die nicht nach englischen Konventionen
> > erscheinen sollen), in ihre explizite Kodierung #.< und #.> austauschen
> > (lassen). Aber vielleicht geht es ja einfacher - und ich bin einfach nur
> > zu bloed oder blind, im Handbuch den entsprechenden Code zu finden.
> >
> > Mit bestem Dank im Voraus und vielen Gruessen reihum,
> >
> > Friedhelm Hoffmann
>


From reeg at zedat.fu-berlin.de  Thu Mar  6 17:21:09 2003
From: reeg at zedat.fu-berlin.de (Gottfried Reeg)
Date: Thu, 6 Mar 2003 17:21:09 +0100
Subject: [Tustep-Liste] doppelter umgekehrter Apostroph
In-Reply-To: <3E676307.23CFF674@mail.uni-wuerzburg.de>
References: <3E676307.23CFF674@mail.uni-wuerzburg.de>
Message-ID: <Pine.SGI.4.53.0303061714520.39076339@Komma.ZEDAT.FU-Berlin.DE>

Lieber Herr Hoffmann,

vielleicht hilft Ihnen folgender Hinweis weiter. Im Handbuch
findet sich auf S. 896 ein Druckfehler: #.' sind die öffnenden und #."
die schließenden Anführungszeichen für das Englische. Es wird für beide
Kodierungen in der zweiten Spalte das gleiche Zeichen angegeben.

Da ich mir die unterschiedlichen Kodierungen nicht merken kann,
benutze ich für die Anführungszeichen Satzmakros, z.B.

<za> und </za>

und wenn die Sprachen unterschieden werden sollen, dann

<za:en> </za:en> <za:fr> </za:fr>

Viel Erfolg

Gottfried Reeg

On Thu, 6 Mar 2003, Friedhelm Hoffmann wrote:

> Diskussionsforum Tustep-Liste
> Weitere Informationen: www.itug.de
> ------------------------------------------------------------
>
> Liebe TUSTEPler,
>
> in einem mehrsprachigen Sammelband soll jeder Beitrag nach den
> typographischen Konventionen der jeweiligen Sprache gestaltet werden.
> Wer kann mir sagen, wie man den doppelten umgekehrten Apostroph =
> dasjenige Zeichen, das in den englischen typographischen Konventionen
> das oeffnende Anfuehrungszeichen bildet, kodiert? Waehrend man das
> schliessende mit #." von Hand erzeugen kann, komme ich mit dem
> oeffnenden nicht zurecht. Der Code ^'^' erzeugt ja nur zwei einzelne
> (also zu weit ausenanderstehende) umgekehrte Apostrophe. Auch hilft die
> Karte AFZ im #satz nur insofern weiter, als ich zwar englische Belegung
> der Anfuehrungszeichen erzielen koennte - ich muesste dann halt alle
> anderen Anfuehrungszeichen (die nicht nach englischen Konventionen
> erscheinen sollen), in ihre explizite Kodierung #.< und #.> austauschen
> (lassen). Aber vielleicht geht es ja einfacher - und ich bin einfach nur
> zu bloed oder blind, im Handbuch den entsprechenden Code zu finden.
>
> Mit bestem Dank im Voraus und vielen Gruessen reihum,
>
> Friedhelm Hoffmann
>
> ------------------------------------------------------------
> Tustep-Liste at itug.de
> https://lists.uni-wuerzburg.de/mailman/listinfo/tustep-liste
>


From friedhelm.hoffmann at mail.uni-wuerzburg.de  Thu Mar  6 17:48:34 2003
From: friedhelm.hoffmann at mail.uni-wuerzburg.de (Friedhelm Hoffmann)
Date: Thu, 06 Mar 2003 17:48:34 +0100
Subject: [Tustep-Liste] doppelter umgekehrter Apostroph
Message-ID: <3E677BE2.5A7085AC@mail.uni-wuerzburg.de>

Liebe TUSTEPler,

Herr Trauth und Herr Reeg haben mich mit der Nase draufgestossen - ich
suchte tatsaechlich #.'

Vielen Dank allen, die sich Muehe gemacht haben und mir weitergeholfen
haben - wir sehen der naechsten (verbesserten) Auflage des Handbuches
mit Spannung entgegen :-) Koennte man die Satzsonderzeichen nicht
ausserdem in die Liste des Zeichenvorrates integrieren?

Viele Gruesse an alle,

Friedhelm Hoffmann


From wilhelm.ott at zdv.uni-tuebingen.de  Fri Mar  7 07:30:35 2003
From: wilhelm.ott at zdv.uni-tuebingen.de (Wilhelm Ott)
Date: Fri, 7 Mar 2003 07:30:35 +0100 (CET)
Subject: [Tustep-Liste] doppelter umgekehrter Apostroph 
Message-ID: <Pine.LNX.4.30.0303070729540.10873-100000@textserv1.zdv.uni-tuebingen.de>

Lieber Herr Hoffmann,

das Handbuch ist auf Seite 896 in der Tat etwas verwirrend, weil dort,
wie in den Ergänzungen zum Handbuch (zugänglich beispielsweise über
#*drube,er,win-10,+ oder über www.uni-tuebingen.de/zdv/tustep/ergaenz.html)
beschrieben, das mit #." kodierte Anführungszeichen falsch dargestellt
ist. Die Darstellung des mit #.' kodierten Anführungszeichens (nämlich
der von Ihnen gesuchte doppelte umgekehrte Apostroph) ist dagegen richtig.

Für alle, die sich für die unterschiedlichen Formen der
Anführungszeichen in den verschiedenen Sprachen und ihre
Kodierung in TUSTEP interessieren, sei auf eine Übersicht unter
  http://www.uni-tuebingen.de/zdv/bi/bi00/bi001t1-anfuehrung.html
bzw. (für eine PostScript-Fassung der gleichen Übersicht)
  http://www.uni-tuebingen.de/zdv/bi/bi00/bi001t1-anfuehrung.ps
verwiesen. Über die TUSTEP-homepage
  (http://www.uni-tuebingen.de/zdv/tustep)
kommt man über "Sonstige Informationsquellen zu TUSTEP", dort
"BI-Artikel", dort "BI-Artikel zu TUSTEP 2000" und dort
"Welche Anführungszeichen?" zu dieser Übersicht.

Mit den besten Grüßen aus Tübingen
Wilhelm Ott
----------------------------------------------------------------------
Prof. Dr. Wilhelm Ott               phone: +49-7071-2970307
Universitaet Tuebingen              fax:   +49-7071-295912
c/o Zentrum fuer Datenverarbeitung  e-mail: wilhelm.ott at uni-tuebingen.de
Waechterstrasse 76
D-72074 Tuebingen



On Thu, 6 Mar 2003, Friedhelm Hoffmann wrote:

> Date: Thu, 06 Mar 2003 16:02:32 +0100
> From: Friedhelm Hoffmann <friedhelm.hoffmann at mail.uni-wuerzburg.de>
> To: tustep-liste at itug.de
> Subject: [Tustep-Liste] doppelter umgekehrter Apostroph
>
> Diskussionsforum Tustep-Liste
> Weitere Informationen: www.itug.de
> ------------------------------------------------------------
>
> Liebe TUSTEPler,
>
> in einem mehrsprachigen Sammelband soll jeder Beitrag nach den
> typographischen Konventionen der jeweiligen Sprache gestaltet werden.
> Wer kann mir sagen, wie man den doppelten umgekehrten Apostroph =
> dasjenige Zeichen, das in den englischen typographischen Konventionen
> das oeffnende Anfuehrungszeichen bildet, kodiert? Waehrend man das
> schliessende mit #." von Hand erzeugen kann, komme ich mit dem
> oeffnenden nicht zurecht. Der Code ^'^' erzeugt ja nur zwei einzelne
> (also zu weit ausenanderstehende) umgekehrte Apostrophe. Auch hilft die
> Karte AFZ im #satz nur insofern weiter, als ich zwar englische Belegung
> der Anfuehrungszeichen erzielen koennte - ich muesste dann halt alle
> anderen Anfuehrungszeichen (die nicht nach englischen Konventionen
> erscheinen sollen), in ihre explizite Kodierung #.< und #.> austauschen
> (lassen). Aber vielleicht geht es ja einfacher - und ich bin einfach nur
> zu bloed oder blind, im Handbuch den entsprechenden Code zu finden.
>
> Mit bestem Dank im Voraus und vielen Gruessen reihum,
>
> Friedhelm Hoffmann
>
> ------------------------------------------------------------
> Tustep-Liste at itug.de
> https://lists.uni-wuerzburg.de/mailman/listinfo/tustep-liste
>


From friedhelm.hoffmann at mail.uni-wuerzburg.de  Thu Mar 13 15:41:37 2003
From: friedhelm.hoffmann at mail.uni-wuerzburg.de (Friedhelm Hoffmann)
Date: Thu, 13 Mar 2003 15:41:37 +0100
Subject: [Tustep-Liste] Sonderzeichen im #satz
Message-ID: <3E7098A0.35C7E7EA@mail.uni-wuerzburg.de>

Liebe TUSTEPler,

eine Frage zu Sonderzeichen im Satzprogramm: Sehe ich es richtig, dass
die alten Digiset-Sonderzeichen (die mit &!(#nnnn) aufrufbar waren - ich
habe da noch eine Liste aus dem Jahr 1989!),  nicht mehr im Satzprogramm
zur Verfuegung stehen - es sei denn, sie sind jetzt in einer der mit
TUSTEP mitgelieferten Schriften oder einer dazugekauften drin - oder man
scannt sich das Zeichen irgendwo ein und behandelt es als Abbildung?

Mit vielen Gruessen

F. Hoffmann


From friedhelm.hoffmann at mail.uni-wuerzburg.de  Sun Mar 16 21:14:30 2003
From: friedhelm.hoffmann at mail.uni-wuerzburg.de (Friedhelm Hoffmann)
Date: Sun, 16 Mar 2003 21:14:30 +0100
Subject: [Tustep-Liste] "Bitte melden Sie diesen Fehler dem Programmautor
Message-ID: <3E74DB26.30F9619F@mail.uni-wuerzburg.de>

Liebe TUSTEPler, lieber Herr Ott, lieber Herr Schaelkle,

gerade erhielt ich die oben angegebene Bitte. Was ist passiert?:

Laut Handbuch sollte es moeglich sein, bei #*psaus mehr als eine
Grafikdatei anzugeben. Ich habe also zwei Dateien (jeweils nach dem
Schema Projekt*Dateiname) durch Apostroph getrennt angegeben. Die
Grafiken in der zweiten Datei schliessen hinsichtlich der Nummerierung
unmittelbar an die in der ersten Datei an. Aber: #*psaus kann saemtliche
Grafiken aus der zweiten Datei nicht finden. Was koennte ich falsch
gemacht haben? Ich weiss es nicht. Ich versuchte es also mit folgendem
"workaround": Da ich bemerkt hatte, dass die Seitennummern in den
Grafikdateien den Bildnummern entsprechen, habe ich die beiden
Grafikdateien in eine (neue, temporaere Datei) zusammenkopiert (#ko mit
mo=- und natuerlich lo=- bei der zweiten hineinkopierten Grafikdatei).
Als ich #*psaus dann wieder startete  (als Grafikdatei war jetzt nur die
neue Gesamtgrafikdatei angegeben), erhielt ich die folgende Meldung:
"Illegaler Aufruf eines Unterprogramms. TPILOC: Satznummern unsortiert;
Positionieren verboten (LU=11). Bitte melden Sie diesen Fehler dem
Programmautor"
Dem komme ich hiermit gerne nach, in der Hoffnung, zugleich eine Loesung
fuer mein Problem zu erhalten.

Noch ein Hinweis: Bei der neuesten Version von Tustep (2003) hat sich
die Behandlung der angegebenen Zahlenwerte beim Satzparameter &&&
geaendert. Bisher lief &&&    0 1 0 0 0 ohne Probleme durch, obwohl die
letzte 0 schon nicht haette sein duerfen. Ok, das wird jetzt
angemeckert, und das Programm bricht ab. Schreibe ich jetzt &&&   0 1 0
0 und hoffe fuer die fuenfte Zahl auf die Voreinstellung <LEER
1+LEER2+3> so funktioniert das nicht. Vielmehr muss ich explizit eine
fuenfte Zahl angeben. (Ob sich im Verhalten der Parameter &, && und &n&
ebenfalls etwas geaendert hat, habe ich nicht ueberprueft.)

Mit vielen Gruessen, vor allem in Richtung Tuebingen :-)

Friedhelm Hoffmann


From wilhelm.ott at zdv.uni-tuebingen.de  Mon Mar 17 07:39:08 2003
From: wilhelm.ott at zdv.uni-tuebingen.de (Wilhelm Ott)
Date: Mon, 17 Mar 2003 07:39:08 +0100 (CET)
Subject: [Tustep-Liste] "Bitte melden Sie diesen Fehler dem Programmautor
Message-ID: <Pine.LNX.4.30.0303170738100.23369-100000@textserv1.zdv.uni-tuebingen.de>

Lieber Herr Hoffmann,

der Programmautor bittet Sie, ihm die beiden Grafikdateien zur
Fehleranalyse zur Verfügung zu stellen. Er vermutet im übrigen, dass Sie
diese Dateien nicht ausschließlich mit dem Makro *grafik bearbeitet
haben.

An die Runde: für wie sinnvoll halten Sie es, dass Meldungen an
den Programmautor über die Tustep-Liste gestellt werden?

Bezüglich der Angaben zu &&&: Es war der Wunsch von TUSTEP-Nutzern,
die seit der Version 2003 vorgenommenen Plausibilitätsprüfungen
einzubauen.

Freundlichen Gruß
W. Ott

P.S. Der Programmautor kann sich, da er heute nachmittag verreist,
erst in der zweiten Hälfte der ersten Aprilwoche wieder melden.
----------------------------------------------------------------------
Prof. Dr. Wilhelm Ott               phone: +49-7071-2970307
Universitaet Tuebingen              fax:   +49-7071-295912
c/o Zentrum fuer Datenverarbeitung  e-mail: wilhelm.ott at uni-tuebingen.de
Waechterstrasse 76
D-72074 Tuebingen



On Sun, 16 Mar 2003, Friedhelm Hoffmann wrote:

> Date: Sun, 16 Mar 2003 21:14:30 +0100
> From: Friedhelm Hoffmann <friedhelm.hoffmann at mail.uni-wuerzburg.de>
> To: tustep-liste at itug.de
> Subject: [Tustep-Liste] "Bitte melden Sie diesen Fehler dem Programmautor
>
> Diskussionsforum Tustep-Liste
> Weitere Informationen: www.itug.de
> ------------------------------------------------------------
>
> Liebe TUSTEPler, lieber Herr Ott, lieber Herr Schaelkle,
>
> gerade erhielt ich die oben angegebene Bitte. Was ist passiert?:
>
> Laut Handbuch sollte es moeglich sein, bei #*psaus mehr als eine
> Grafikdatei anzugeben. Ich habe also zwei Dateien (jeweils nach dem
> Schema Projekt*Dateiname) durch Apostroph getrennt angegeben. Die
> Grafiken in der zweiten Datei schliessen hinsichtlich der Nummerierung
> unmittelbar an die in der ersten Datei an. Aber: #*psaus kann saemtliche
> Grafiken aus der zweiten Datei nicht finden. Was koennte ich falsch
> gemacht haben? Ich weiss es nicht. Ich versuchte es also mit folgendem
> "workaround": Da ich bemerkt hatte, dass die Seitennummern in den
> Grafikdateien den Bildnummern entsprechen, habe ich die beiden
> Grafikdateien in eine (neue, temporaere Datei) zusammenkopiert (#ko mit
> mo=- und natuerlich lo=- bei der zweiten hineinkopierten Grafikdatei).
> Als ich #*psaus dann wieder startete  (als Grafikdatei war jetzt nur die
> neue Gesamtgrafikdatei angegeben), erhielt ich die folgende Meldung:
> "Illegaler Aufruf eines Unterprogramms. TPILOC: Satznummern unsortiert;
> Positionieren verboten (LU=11). Bitte melden Sie diesen Fehler dem
> Programmautor"
> Dem komme ich hiermit gerne nach, in der Hoffnung, zugleich eine Loesung
> fuer mein Problem zu erhalten.
>
> Noch ein Hinweis: Bei der neuesten Version von Tustep (2003) hat sich
> die Behandlung der angegebenen Zahlenwerte beim Satzparameter &&&
> geaendert. Bisher lief &&&    0 1 0 0 0 ohne Probleme durch, obwohl die
> letzte 0 schon nicht haette sein duerfen. Ok, das wird jetzt
> angemeckert, und das Programm bricht ab. Schreibe ich jetzt &&&   0 1 0
> 0 und hoffe fuer die fuenfte Zahl auf die Voreinstellung <LEER
> 1+LEER2+3> so funktioniert das nicht. Vielmehr muss ich explizit eine
> fuenfte Zahl angeben. (Ob sich im Verhalten der Parameter &, && und &n&
> ebenfalls etwas geaendert hat, habe ich nicht ueberprueft.)
>
> Mit vielen Gruessen, vor allem in Richtung Tuebingen :-)
>
> Friedhelm Hoffmann
>
> ------------------------------------------------------------
> Tustep-Liste at itug.de
> https://lists.uni-wuerzburg.de/mailman/listinfo/tustep-liste
>


From trauth at uni-trier.de  Mon Mar 17 18:14:18 2003
From: trauth at uni-trier.de (Michael Trauth)
Date: Mon, 17 Mar 2003 18:14:18 +0100
Subject: [Tustep-Liste] "Bitte melden Sie diesen Fehler dem Programmautor
In-Reply-To: <3E74DB26.30F9619F@mail.uni-wuerzburg.de>
Message-ID: <3E76107A.16173.1E6279EA@localhost>

Lieber Herr Hoffmann,

der Programmautor hat sich ja bereits zur Sache geaeus-
sert, kann nur infolge einer Reise bis Anfang April keine
weitere Fehleranalyse unternehmen. Meine Wortmeldung hat
hier nur zum Ziel, Ihnen bis zu seiner Rueckkehr das Ar-
beiten mit dem Grafikcontainer zu ermoeglichen:

> Ich versuchte es also mit folgendem "workaround": Da
> ich bemerkt hatte, dass die Seitennummern in den Grafik-
> dateien den Bildnummern entsprechen, habe ich die beiden
> Grafikdateien in eine (neue, temporaere Datei) zusammen-
> kopiert (#ko mit mo=- und natuerlich lo=- bei der zweiten
> hineinkopierten Grafikdatei).

Nehmen wir an, Sie haben zwanzig Grafiken, und die ersten
zehn (numeriert von 1.0 bis 10.999) befinden sich in der
Datei GRAF.1, und die folgenden zehn (numeriert von 11.0
bis 20.999) befinden sich in GRAF.2; der 'Zusammenschluss'
von beiden soll GRAF.0 heissen. Dann muesste folgendes
funktionieren:
   #ko,graf.1,graf.0,,+
   #ko,graf.2,graf.0,-,-
NICHT jedoch funktioniert (obwohl man sich durchaus fragen
darf, warum nicht, wo es doch so logisch scheint):
   #ko,graf.2,graf.0,,+
   #ko,graf.1,graf.0,-,-
Sie koennen das gegenpruefen, indem Sie versuchen, mit dem
Editor die Zieldatei GRAF.0 zu oeffnen: Wenn der Editor
sich weigert, in die Datei reinzugehen ("Satznummern ... 
nicht aufsteigend"), haben Sie's verkehrt herum angefangen. 

Wenn's mit diesen Hinweisen noch immer nicht klappen will,
koennten Sie mir die beiden Grafikdateien - sofern sie
nicht zu gross sind - einmal zuschicken, und ich schaue
sie mir an, um vielleicht einen besseren 'workaround'
(ich bevorzuge das praegnantere deutsche 'Schaffdrumrum')
zu finden.

> Noch ein Hinweis: Bei der neuesten Version von Tustep
> (2003) hat sich die Behandlung der angegebenen Zahlen-
> werte beim Satzparameter &&& geaendert. Bisher lief
> &&&    0 1 0 0 0 ohne Probleme durch, obwohl die letzte
> 0 schon nicht haette sein duerfen. Ok, das wird jetzt
> angemeckert, und das Programm bricht ab. Schreibe ich
> jetzt &&&   0 1 0 0 und hoffe fuer die fuenfte Zahl auf
> die Voreinstellung <LEER 1+LEER2+3> so funktioniert das
> nicht. Vielmehr muss ich explizit eine fuenfte Zahl an-
> geben. (Ob sich im Verhalten der Parameter &, && und &n&
> ebenfalls etwas geaendert hat, habe ich nicht ueberprueft.)

Hierzu schliesse ich mich Ihrem Plaedoyer an, dass es
'logisch' (was auch immer das genau in der schwierig zu
fassenden Beziehung zwischen Programmautor und Anwender
bezeichnet) und benutzerfreundlich waere, wenn ein evtl.
weggelassener fuenfter Wert durch die die Voreinstellung
<LEER 1+LEER2+3> ersetzt wuerde. Will sagen: Sowohl ich
selbst wie auch mehrere andere Trierer Anwender sind
schon gegen dieselbe Wand gelaufen (teilweise durch
meine Schuld, weil besagter Fehler in aelteren Muster-
routinen von mir schon vielfach ueberwintert hatte).
Und eine innere Stimme sagt mir, dass das wohl nicht
nur in Trier passiert ist.

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
---------------------------------------------------------------


From trauth at uni-trier.de  Mon Mar 17 19:29:13 2003
From: trauth at uni-trier.de (Michael Trauth)
Date: Mon, 17 Mar 2003 19:29:13 +0100
Subject: [Tustep-Liste] "Bitte melden Sie diesen Fehler dem Programmautor
In-Reply-To: <Pine.LNX.4.30.0303170738100.23369-100000@textserv1.zdv.uni-tuebingen.de>
Message-ID: <3E762209.24027.1EA70F3A@localhost>

Lieber Herr Ott,

Ihre Frage an die tustep-liste war:

> An die Runde: für wie sinnvoll halten Sie es, dass Meldun-
> gen an den Programmautor über die Tustep-Liste gestellt
> werden?

Darueber kann man streiten:
- Angesichts des in jeder Hinsicht vorbildlichen Services
  des Programmautors (von den sagenhaften Reaktionszeiten
  nicht zu reden: einmal war ein Fehler schon behoben, BE-
  VOR ich ihn gemeldet hatte) und des Umstands, dass die
  Software selbst nur die Kontaktaufnahme mit dem Programm-
  autor verlangt, liegt es nahe, Fehlermeldungen nicht auf
  das Diskussionsformum zu tragen.
- Des weiteren koennte man damit argumentieren, dass eine
  groessere Publizitaet solcher Fehlermeldungen geeignet
  ist, das Ansehen der Software zu untergraben.
- Beiden Argumenten halte ich ein wohlfundiertes "Na und?"
  entgegen. In der Windowswelt (ich erinnere nur an die
  staendigen ueblen Erfahrungen mit Office-Software) hat
  man sich schon an die blutigen Nasen gewoehnt, die man
  sich an allen Ecken holt. Mein Vertrauen in eine Soft-
  ware wird dadurch gesteigert, wenn auf einem Diskussions-
  forum frisch von der Leber weg ueber ALLE Fehlermeldungen
  (auch wenn es nicht wirklich um solche, sondern vielleicht
  nur um Handhabungsfehler handelt) und Probleme debattiert
  wird. Auf Linux-Foren wird das seit vielen Jahren schon
  ausgiebig und mit grossem Erfolg so gemacht, wobei ins-
  besondere mit Einsteigern sehr geduldig und paedagogisch
  wertvoll verfahren wird. Es waere mir als Anwender ausser-
  dem durchaus eine  Beruhigung, wenn ich mich beim Auflau-
  fen auf eine Sandbank daran erinnern wuerde "Da war doch
  kuerzlich irgendwas auf der tustep-liste... Vielleicht
  ist das gerade mein aktuelles Problem, und vielleicht
  gibt's dafuer schon eine Loesung... Gleich mal eine
  Anfrage an den Programmautor richten..."
Es wuerde mich interessieren, wie andere darueber denken.

> Bezüglich der Angaben zu &&&: Es war der Wunsch von TUSTEP-
> Nutzern, die seit der Version 2003 vorgenommenen Plausibi-
> litätsprüfungen einzubauen.

Dem sei nicht widersprochen. Aber ich glaube nicht, dass
es dem Nutzen einer solchen Plausibilitaetskontrolle oder
gar dem Geiste der TUSTEP-Philosophie entgegensteht, wenn
ein vom Benutzer evtl. weggelassener fuenfter Wert durch
die Voreinstellung <LEER 1+LEER2+3> ersetzt wuerde. (Der
Begriff "Voreinstellung" insinuiert doch eigentlich immer,
dass eben dieser Wert eingesetzt wird, wenn der Benutzer
nichts anderes angibt, nicht weahr?)

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
---------------------------------------------------------------


From friedhelm.hoffmann at mail.uni-wuerzburg.de  Tue Mar 18 10:31:05 2003
From: friedhelm.hoffmann at mail.uni-wuerzburg.de (Friedhelm Hoffmann)
Date: Tue, 18 Mar 2003 10:31:05 +0100
Subject: [Tustep-Liste] "Bitte melden Sie diesen Fehler dem Programmautor"
Message-ID: <3E76E759.25A4A00@mail.uni-wuerzburg.de>

Lieber Herr Ott, lieber Herr Trauth, liebe TUSTEPler,

zuerst eine positive Mitteilung. Ich glaube zu wissen, wodurch die
mitgeteilte Fehlermeldung verursacht wurde. Es lag nicht daran, denke,
ich, dass ich die Dateien mit irgendetwas anderem als dem Makro *grafik
bearbeitet haette - das habe ich wirklich nicht (sieht man davon ab,
dass ich zwei mit *grafik erstellte Dateien zusammenkopiert habe). Es
lag einfach daran, dass ich versehentlich ein Bild als das letzte in der
einen und zugleich als erstes in der zweiten Grafikdatei abgelegt habe.
Beim Zusammenkopieren entstand dann natuerlich eine Grafikdatei, in der
zweimal dieselbe Seitenzahl vergeben war. Eine Loeschung der
ueberzaehligen Seite im Editor hat das Problem behoben. Mein Wunsch als
Benutzer: eine Fehlermeldung, die darauf hinweist, dass in der
Grafikdatei zweimal dieselbe Bildnummer vergeben ist.

Aber ein Problem besteht fuer mich weiterhin, naemlich das Verhalten von
*psaus bei Angabe von mehr als einer Grafikdatei (nehmen wir hier zwei
Dateien an, graf1 und graf2). Wenn ich in *psaus graf1 allein als
Grafikdatei aufrufe (Spezifikation grafik=graf1), werden alle Bilder,
die dort drin sind, gefunden und eingebunden, wenn ich graf2 aufrufe,
nur die dortigen Bilder. Soweit ok.

Eine Angabe *psaus,...,grafik=graf1'graf2 funktioniert aber nur, wenn
jede Datei
genau eine Grafik enthaelt. Sind aber in der graf2 zwei Bilder, wird bei
...,grafik=graf1'graf2 nur das Bild aus graf1 in die Postscriptausgabe
gesetzt. Sind in der Datei graf1 *und* der Datei graf2 zwei Bilder,
werden die beiden Bilder aus der ersten Datei eingesetzt. Kopiere ich
die Dateien zu einer einzigen zusammen, kommen
alle Bilder in die Postscript-Ausgabe!

Mir sind daher Zweifel gekommen, ob mit der Auskunft des Handbuchs, 8
Grafikdateien koennten bei *psaus angegeben werden, wirklich 8
Einzeldateien (mit jeweils mehreren Bildern) gemeint sind oder nicht
eine Regelung, wie sie in der Beschreibung zu *grafik auf S. 943 unter
"Hinweis" notiert ist (also
eine "Steuergrafikdatei" + max. 7(?) davon "abhaengige" Dateien mit der
eigentlichen Bildinformation).

Bezueglich Herrn Otts Frage nach einer oeffentlichen Behandlung von
Programmfehlern kann ich mich nur Herrn Trauth anschliessen. Im Uebrigen
hatte ich ueber diese Frage gar nicht gross nachgedacht. Weil sich mir
zunaechst einfach ein die Interna von TUSTEP betreffendes Problem
darbot, wollte ich moeglichst schnell moeglichst viele Kenner erreichen.

Hinsichtlich &&& begruesse ich die Realisierung einer
Plausibilitaetspruefung, sehe aber darin keinen Widerspruch zu einer
Voreinstellung, die zudem als Rechenoperation und nicht als fester Wert
formuliert ist, so dass dem Benutzer suggeriert wird, das Programm
ermittele von sich aus einen passenden Wert.

Mit herzlichen Gruessen

F. Hoffmann


From stahl at germanistik.uni-wuerzburg.de  Wed Mar 19 10:02:41 2003
From: stahl at germanistik.uni-wuerzburg.de (stahl at germanistik.uni-wuerzburg.de)
Date: Wed, 19 Mar 2003 10:02:41 +0100
Subject: [Tustep-Liste] "Bitte melden Sie diesen Fehler dem Programmautor
In-Reply-To: <3E762209.24027.1EA70F3A@localhost>
References: <3E762209.24027.1EA70F3A@localhost>
Message-ID: <1048064561.3e7832310c04b@webmail.uni-wuerzburg.de>

Liebe Tustep-Liste-Leserinnen und -Leser,

Michael Trauth hatte auf die Frage, ob Fehlermeldungen mit
einer Aufforderung zur Kontaktaufnahme mit dem Programmautor
an die Tustep-Liste geschickt werden sollen, u.a. geantwortet:

"Mein Vertrauen in eine Software wird dadurch gesteigert, wenn auf einem
Diskussionsforum frisch von der Leber weg ueber ALLE Fehlermeldungen
[...] und Probleme debattiert wird."

Dem kann ich nur voll und ganz zustimmen und alle Tustep-Users
an dieser Stelle ermutigen, Fragen, Anregungen und Tipps zu
Tustep an diese Liste zu schicken.

Mit vielen Grüßen
P.Stahl


From delfosse at uni-trier.de  Wed Mar 19 13:27:58 2003
From: delfosse at uni-trier.de (delfosse at uni-trier.de)
Date: Wed, 19 Mar 2003 13:27:58 +0100
Subject: [Tustep-Liste] Fehler
Message-ID: <3E78705E.12252.E94076@localhost>

Liebe TUSTEPianer,

Gelegentlich gelingt es auch einem Philosophen, TUSTEP zu 
verstehen. Es ist wichtig, ja unerläßlich, Fehler zu machen. In Fehlern 
begegnet die Wirklichkeit. Fehler wirken als Korrektiv; werden Fehler 
vermieden, wird auch das Richtige verfehlt. Zudem lernen wir aus 
unseren Triumphen viel weniger als aus unseren Fehler. Warum 
sollte das bei unserem liebsten Kind anders sein? Je ehrlicher wir mit 
den "Fehlern" von TUSTEP umgehen, je besser wird TUSTEP -- bei 
den Programmautoren allemal.

Fehlerfreie Grüße von
Heinrich Delfosse



Dr. Heinrich P. Delfosse
Forschungsstelle Kant-Index 
dienstlich:                            privat:
Fachbereich I: Philosophie             Zuckerberg 1
Universität Trier - 54286 Trier        54317 Lorscheid
office:    (0651) 2012347              Tel.: (06500)1681
Fax:       (0651) 2013922              Fax:  (06500)988253
secretary: (0651) 2012346

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://lists.itug.de/pipermail/tustep-liste/attachments/20030319/f48a80e0/attachment.htm>

From trauth at uni-trier.de  Thu Mar 20 19:57:21 2003
From: trauth at uni-trier.de (Michael Trauth)
Date: Thu, 20 Mar 2003 19:57:21 +0100
Subject: [Tustep-Liste] Tag-Suche- und kopiere-Kurs in Trier
Message-ID: <3E7A1D21.6098.5A51A4@localhost>

Liebe Tustepler,

KOPIERE-Kompaktkurse in Trier haben eine gewisse
Tradition. (Vermutlich wird's auch diesmal im Som-
mer wieder einen geben.) Aber ein auf nur drei Tage
komprimierter 'Crashkurs' - so der Newspeakbegriff
fuer 'kompakter Kompaktkurs' - ist etwas Neues: In
ihm geht's im wesentlichen darum, an Hand von Uebungs-
beispielen das Hoppeln durch die Sprungtabellen zu
verstehen und dann natuerlich auch zu beherrschen.

Wer sich dafuer interessiert:
   1., 2. & 3. April, Universitaet Trier, Raum E-44,
   jeweils von 9-12 Uhr (nachmittags gibt's wie immer
   Gelegenheit zum fakultativen betreuten Ueben). Aus-
   waertige Gaeste sind - nach Anmeldung beim Endunter-
   fertigenden - wie immer herzlich willkommen, in Uni-
   versitaetsnaehe (ca. 8 Min. zu Fuss) gibt es Gele-
   genheit zu preiswerter Unterkunft (ca. 20,- EUR pro
   Tag und Person mit Fruehstueck).

Eine zweite, wesentlich kuerzere Veranstaltung ist der
neuen Tag-Suche im Editor gewidmet. Viele kennen diese
Funktion noch nicht oder haben womoeglich nur einen kur-
zen Blick draufgeworfen, weil die Tuebinger Entwickler
wie gewohnt (voellig zu Unrecht) auf das Ruehren der Re-
klametrommel verzichtet haben. Und wer kann sich unter
der unspektakulaeren Bezeichnung 'Tag-Suche' schon irgend-
etwas Grossartiges vorstellen, das man fuer die eigene Ar-
beit mit Gewinn verwenden koennte? Stimmt's? ABER: Es ist
nach meiner Einschaetzung eine der besten und wichtigsten
Neuerungen im Editor in den letzten Jahren.
   Wofuer man sie einsetzen kann? Nun, jeder TUSTEP-Anwen-
der kennt das Problem, dass er Kodierungen verwendet, die
paarig sein SOLLEN oder gar MUESSEN: #/+...#/-, #f+...#f-
usw., @f+... at f-, &&...&&{, &xx...&xx{, $$...$${, die Liste
der Exempla dafuer liesse sich ins Uferlose fortsetzen.
Die Paarigkeit zu kontrollieren, ist eine zeitraubende
Angelegenheit - und manchmal gibt es aergerliche (und auf
den ersten Blick nicht immer verstaendliche) Seitenwirkun-
gen, wenn man aus Konzentrationsmangel nicht alle Kodie-
rungsfehler behoben hat. Hoere ich Zustimmung? Da waere
es doch SEHR praktisch, wenn man den Editor veranlassen
koennte, bitteschoen die Paarigkeit dieser Kodierungen
selbst zu ueberpruefen, nicht wahr? Und genau das kann
der Editor jetzt mit dem neuen Tag-Suche!
   Aber halt, da gibt's doch noch ein ganz erhebliches
Problem: Nehmen wir an, dass in einem Text eine Passage
kursiv gesetzt wird und darin eingebettet Fussnoten
oder Apparateintraege vorkommen, in denen ebenfalls
Kursive ein- und ausgeschaltet wird, zum Beispiel:
   Text ... #/+kursiver Text ... kursiver @f+ Fussnoten-
   text ... #/+kursiver Fussnotentext#/-. @f- Text#/-
In einem solchen Fall wird zwar zweimal hintereinander
Kursive eingeschaltet - aber auf verschiedenen Textebenen.
Kein Problem: Auch das kann das Tag-Suche auseinander-
halten (wenn man es ihm sagt). Und wie die Bezeichnung
'Tag-Suche' schon zu verstehen gibt, kann man damit auch
HTML-, SGML- und XML-kodierte Texte auf Auszeichnungspro-
bleme hin untersuchen. Wirklich eine feine Sache, die dem
Anwender viel Muehe abnehmen und Aerger ersparen hilft.
Und schwierig ist es auch nicht. Herr Schaelke hat ein
kleines Handout vorbereitet (als Protokolldatei, die jeder
selbst bei sich ausdrucken kann), mit dessen Hilfe man
sich die Chose selbst beibringen kann. Aber wer es vor-
zieht, ein paar Anwendungsbeispiele aus der Praxis vor-
gestellt zu bekommen, ist herzlich eingeladen, am Dienstag,
dem 8. April, nach Trier zu kommen: Da wird das Tag-Suche
um 11 Uhr in E-44 in einer Mini-Veranstaltung vorgestellt.


Schoene 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
---------------------------------------------------------------


From stahl at germanistik.uni-wuerzburg.de  Tue Mar 25 14:16:16 2003
From: stahl at germanistik.uni-wuerzburg.de (stahl at germanistik.uni-wuerzburg.de)
Date: Tue, 25 Mar 2003 14:16:16 +0100
Subject: [Tustep-Liste] Formatiere-Steuerzeichen
In-Reply-To: <3E7A1D21.6098.5A51A4@localhost>
References: <3E7A1D21.6098.5A51A4@localhost>
Message-ID: <1048598176.3e8056a0b917a@webmail.uni-wuerzburg.de>

Liebe Tustep-Anwenderinnen und -Anwender,

seit langem habe ich wieder einmal eine Tue-Datei erstellt, um
einen Text formatieren zu können. In der Beschreibung ist mir
dabei aufgefallen, dass die Steueranweisungen $n und $$$n nicht
mehr erwähnt werden, sondern nur noch &!n und &?n. 

Mir ist schon klar, dass dies mit der Möglichkeit, Steuermakros
zu definieren zusammenhängt. Wenn ich allerdings keine Makros
verwende, funktionieren $n und $$$n immer noch. Es wäre deshalb
wünschenswert, wenn diese Befehle auch noch in der Beschreibung zu
finden wären. Denn &!n und &?n sind nun wirklich keine
brauchbare Alternative, weil z.B. &?1 mit dem voreingestellten
Namen für einen Platzhalter, nämlich ?1, zusammenfällt.
Das aber kann nur umgangen werden, wenn man als Kennung dafür
beispielsweise ein Ausrufezeichen nimmt, was dann aber 
dann mit dem Steuerbefehl &!n kollidiert.

Zudem hat dieses Verfahren den großen Nachteil, dass schon
beim Aufruf einer Tue-Datei mit Formatiere-Parametern die
Kennung für Platzhalter geändert werden muss, damit derartige
Steuerbefehle richtig interpretiert werden. Einer Tue-Datei
kann ich aber von außen nicht ansehen, was in ihr drin steckt.

Deshalb habe ich folgende Bitte: $n und $$$n sollten wieder in die
Beschreibung kommen.

Und statt &?n sollte beispielsweise &~n möglich sein bzw.
für &!n könnte man &\n vorsehen. 

Oder seh ich das völlig falsch? Und es gibt einen ganz
anderen Ausweg aus diesem Problem.

Mit vielen Grüßen 
P.Stahl


From trauth at uni-trier.de  Wed Mar 26 19:18:49 2003
From: trauth at uni-trier.de (Michael Trauth)
Date: Wed, 26 Mar 2003 19:18:49 +0100
Subject: [Tustep-Liste] Formatiere-Steuerzeichen
In-Reply-To: <1048598176.3e8056a0b917a@webmail.uni-wuerzburg.de>
References: <3E7A1D21.6098.5A51A4@localhost>
Message-ID: <3E81FD19.20722.1F1D5DF8@localhost>

Lieber Peter,

Deine Frage an die TUSTEP-Liste war:

> seit langem habe ich wieder einmal eine Tue-Datei erstellt, um
> einen Text formatieren zu können. In der Beschreibung ist mir
> dabei aufgefallen, dass die Steueranweisungen $n und $$$n nicht
> mehr erwähnt werden, sondern nur noch &!n und &?n. 
> 
> Mir ist schon klar, dass dies mit der Möglichkeit, Steuermakros
> zu definieren zusammenhängt. Wenn ich allerdings keine Makros
> verwende, funktionieren $n und $$$n immer noch. Es wäre deshalb
> wünschenswert, wenn diese Befehle auch noch in der Beschreibung zu
> finden wären. Denn &!n und &?n sind nun wirklich keine
> brauchbare Alternative, weil z.B. &?1 mit dem voreingestellten
> Namen für einen Platzhalter, nämlich ?1, zusammenfällt.
> Das aber kann nur umgangen werden, wenn man als Kennung dafür
> beispielsweise ein Ausrufezeichen nimmt, was dann aber 
> dann mit dem Steuerbefehl &!n kollidiert.
> 
> Zudem hat dieses Verfahren den großen Nachteil, dass schon
> beim Aufruf einer Tue-Datei mit Formatiere-Parametern die
> Kennung für Platzhalter geändert werden muss, damit derartige
> Steuerbefehle richtig interpretiert werden. Einer Tue-Datei
> kann ich aber von außen nicht ansehen, was in ihr drin steckt.
> 
> Deshalb habe ich folgende Bitte: $n und $$$n sollten wieder in
> die Beschreibung kommen.
> 
> Und statt &?n sollte beispielsweise &~n möglich sein bzw.
> für &!n könnte man &\n vorsehen. 
> 
> Oder seh ich das völlig falsch? Und es gibt einen ganz
> anderen Ausweg aus diesem Problem.

Damit ist ein - wie ich meine - grundsaetzliches Problem
des Umgangs mit TUSTEP und TUE-Prozeduren angesprochen.

Zunaechst: Ich selbst war mit den 'neuen' FO-Makros (sie sind
ja gar nicht mehr neu, haben vielmehr schon etliche Jahre auf
dem Buckel) auch nicht gluecklich, und zwar i.w. aus denselben
Gruenden wie Du. Und wenn's schnell gehen soll, verwende ich
auch heute noch im Text '$n' und '$$$n' (aber das muss unter
uns bleiben).
   Aber es ist auch bei einem Programmsystem wie TUSTEP, das
sich selbst treu bleiben will, unvermeidlich, dass Innovatio-
nen irgendwann einmal mit bewaehrten alten Funktionen in Kon-
flikt geraten. Das Gesetz der Evolution verlangt dann, dass
das Alte dem Neuen Platz macht. Ueber die Anweisungen '&?n'
und '&!n' kann man in der Tat streiten, und ich denke, dass
H. Schaelkle aus den von Dir genannten Gruenden sich heute
wohl auch fuer eine anderen Namensgebung entscheiden wuerde.
Aber diese Aenderung jetzt durchzufuehren, nachdem '&!?n' und
'&!n' schon so viele Jahre im Gebrauch sind, ist ein folgen-
schwerer Schritt, den man nicht ohne weiteres, jedenfalls 
nicht ohne zwingende Gruende, tun sollte.
   Bei dem von Dir genannten Grund (dass naemlich das '?n' in
der Anweiung '&?n' mit der Kennung fuer Platzhalter '?n' kol-
lidiert) sollte man sich vergegenwaertigen, dass es gleich
mehrere Gruende gibt, auf diese Platzhalter heute nach Moeg-
lichkeit zu verzichten:
   Du sagst ja selbst, dass man einer TUE-Prozedur von aussen
nicht ansieht, was in ihr drinsteckt. Wenn mehrere Platzhalter
'?1', '?2' usw. verwendet werden, weiss der Anwender erfahrungs-
gemaess nach kurzer Zeit schon nicht mehr, welcher Platzhalter
wofuer steht. Wenn es bei den Platzhaltern bloss um Dateinamen
u.dgl. geht, steht deshalb in meinen TUE-Prozeduren im Kopf
beispielsweise ein kleiner Abschnitt mit Deklarationen, der
mir schnell ueber die verwendeten Variablen und deren Belegung
Auskunft gibt, und in der Prozedur werden die Variablen dann
(eingeschlossen in spitzen Klammern) verwendet. Zum Beispiel:
   #de,,*
   TXT = Sammelband.TXT
   FNT = Sammelband.FNT
   PSD = Sammelband.PS
   SCH = Schriften.XYZ
   GRA = Sammelband.GRA
   *eof
   #an,,<TXT>'<FNT>'<SCH>'<GRA>
   #da,<PSD>,sdf-ap
   #sa,<TXT>,.....,SCH=<SCH>
   <usw.>
Es ist wesentlich einfacher und weniger fehleranfaellig,
solche Variablen an EINER Stelle der Prozedur (am besten
natuerlich in ihrem Kopf) einzutragen, als sie ins TUE-
Kommando einzutippen.
  Freilich haben sowohl dieses Verfahren wie auch das der
Platzhalter einige Schwaechen. Die mit #de,,* definierten
Variablen funktionieren nur auf der Kommandoebene, nicht
auf der Parameterebene. (Das ist ein SEHR alter Wunsch von
mir an die Programmautoren, diese Einschraenkung aufzu-
heben ;o)) Man koennte also beispielsweise damit NICHT
den Text eines Kolumnentitels definieren und in den FO-
Parameter KT einsetzen. Wollte man diesen 'Inhalt' des
Parameters KT mit #TUE,...,pa=____ an die Prozedur ueber-
geben, so geht das auch nur mit der (durchaus erheblichen)
Einschraenkung, dass KEIN Spatium in der Formulierung des
Kolumnentitels vorkommen darf. So recht ueberzeugend ist
das also auch nicht.


Aber es gibt m.E. dennoch eine wirklich gute Loesung da-
fuer, naemlich die der Kommandomakros. Nein, ich rede jetzt
nicht davon, dass die Kommandmakros in den letzten Jahren
schier unglaublich an Funktionalitaet zugelegt haben und
dass man sich doch bitteschoen in diese neuen Funktionen
einarbeiten sollte. Sondern ich rede davon, dass auch
derjenige Kommandomakros verwenden kann, der kaum Ahnung
davon hat.
  Um es zu exemplifizieren: Eine TUE-Prozedur der von Dir
verwendeten Art (mit dem Namen FORMAT.PRG) koennte etwa so
aussehen:
   #an,,?1
   #fo,?1,...,*
   drt       ?2
   kt        |#/+?3#/-@/xxx|
   *eof
Aufrufen wird man die Prozedur dann etwa mit
   #t,format.prg,pa=sammelband.txt'ps-10'Kopftext

Ein funktionsgleiches Kommandomakro aber ist nur unwesent-
lich groesser:
   $$! QUELLE, TYP, KOLT
   $$= $ { }
   #an,,
   #fo,{QUELLE},...,*
   drt       {TYP}
   kt        |#/+{KOLT}#/-@/xxx|
   *eof
wobei in der ersten Zeile einfach die verwendeten Variablen
deklariert und in der zweiten Zeile die geschweiften Klammern
{...} als Variablenkennung definiert werden. Wenn dieses
Makro in einer Makrodatei unter dem Segmentnamen FORMAT ab-
gespeichert ist, wird es aufgerufen mit
   #$format,sammelband.txt,ps-10,Kopftext

Von der Benutzung her hat sich also kaum etwas geaendert.
Aber schon aus der Sicht des Programmiereres hat dieses
Verfahren den erheblichen Vorteil, dass in der Routine
selbst die Variablen mit 'sprechenden' Namen (statt der
nichtssagenden Platzhalter '?1', '?2' usw.) belegt sind.
Es kommen etliche Vorteile hinzu, unter anderem fallen die
oben skizzierten Einschraenkungen und Probleme weg. Weitere
Vorteile (dass man beispielsweise falsche und fehlenden An-
gaben des Benutzers ueberpruefen und ggf. nachfordern kann)
seien hier nur angedeutet. Und all dem steht bloss ein mini-
maler zusaetzlicher Schreibaufwand in der Prozedur als
kleiner Nachteil gegenueber - und den halte ich nun wirk-
lich fuer vernachlaessigbar.

Aus diesen Gruenden wuerde ich heute (obwohl ich mit Dei-
nem Standpunkt sympathisiere) fuer die Beibehaltung des
Status quo plaedieren und eher empfehlen, die kleine Um-
stellung der eigenen Prozeduren auf Kommandomakros vor-
zunehmen.

Es wuerde mich interessieren zu erfahren, wie andere dar-
ueber denken. Ueber Rueckmeldungen und Diskussionsbei-
traege zum Thema wuerde ich mich freuen.

Ganz nebenbei sei noch darauf hingewiesen, dass es in
FORMATIERE auch schon seit Jahren die Moeglichkeit gibt,
Spitzklammernmakros '<...>' zu definieren und zu ver-
wenden. Und da ich schon seit vielen Jahren aus voller
Ueberzeugung die Abkehr von jeglicher harten Formatie-
rung predige und statt dessen die Verwendung der sach-
lichen Auszeichnung (fuer die besagte Spitzklammermakros
nach dem bewaherten Vorbild von HTML und XML bestens ge-
eignet sind) nahelege, will ich an die damit verbundenen
Vorteile und Chancen (der Plattformunabhaengigkeit, der
Portierbarkeit und der Konservierbarkeit der Daten) mit
Nachdruck erinnern.

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
---------------------------------------------------------------


From stahl at germanistik.uni-wuerzburg.de  Thu Mar 27 13:31:20 2003
From: stahl at germanistik.uni-wuerzburg.de (stahl at germanistik.uni-wuerzburg.de)
Date: Thu, 27 Mar 2003 13:31:20 +0100
Subject: [Tustep-Liste] Formatiere-Steuerzeichen
In-Reply-To: <3E81FD19.20722.1F1D5DF8@localhost>
References: <3E7A1D21.6098.5A51A4@localhost> <3E81FD19.20722.1F1D5DF8@localhost>
Message-ID: <1048768280.3e82ef189bf6b@webmail.uni-wuerzburg.de>

Lieber Michael,

vielen Dank für Deinen langen Kommentar zu meiner Mail.

> > Deshalb habe ich folgende Bitte: $n und $$$n sollten wieder in
> > die Beschreibung kommen.
> >
> > Und statt &?n sollte beispielsweise &~n möglich sein bzw.
> > für &!n könnte man &\n vorsehen.

> Damit ist ein - wie ich meine - grundsaetzliches Problem
> des Umgangs mit TUSTEP und TUE-Prozeduren angesprochen.
> [...] Aber es ist auch bei einem Programmsystem wie TUSTEP, das
> sich selbst treu bleiben will, unvermeidlich, dass Innovatio-
> nen irgendwann einmal mit bewaehrten alten Funktionen in Kon-
> flikt geraten. Das Gesetz der Evolution verlangt dann, dass
> das Alte dem Neuen Platz macht.
Das sehe ich auch so. Aber hier geht es nicht so sehr um ein
Verdrängen des Alten, sondern eher um eine Koexistenz:

Die Formatiere-Steuerzeichen '&!n' und '&?n' können jetzt 
auf keinen Fall abgeschafft werden. Sie sollten weiterhin
verwendet werden können (in alten Tue-Dateien), sollten
aber nicht mehr dokumentiert sein. An deren Stelle könnten
neue treten, nämlich '?\n' und '&~n'. Und außerdem wäre
es meiner Meinung nach nützlich, wenn die ganz alten
Steuerbefehle '$n' und '$$$n' wieder in der Beschreibung
stünden.

> Du sagst ja selbst, dass man einer TUE-Prozedur von aussen
> nicht ansieht, was in ihr drinsteckt. Wenn mehrere Platzhalter
> '?1', '?2' usw. verwendet werden, weiss der Anwender erfahrungs-
> gemaess nach kurzer Zeit schon nicht mehr, welcher Platzhalter
> wofuer steht. Wenn es bei den Platzhaltern bloss um Dateinamen
> u.dgl. geht, steht deshalb in meinen TUE-Prozeduren im Kopf
> beispielsweise ein kleiner Abschnitt mit Deklarationen, der
> mir schnell ueber die verwendeten Variablen und deren Belegung
> Auskunft gibt, und in der Prozedur werden die Variablen dann
> (eingeschlossen in spitzen Klammern) verwendet. Zum Beispiel:
>    #de,,*
>    TXT = Sammelband.TXT
>    FNT = Sammelband.FNT
>    PSD = Sammelband.PS
>    SCH = Schriften.XYZ
>    GRA = Sammelband.GRA
>    *eof
>    #an,,<TXT>'<FNT>'<SCH>'<GRA>
>    #da,<PSD>,sdf-ap
>    #sa,<TXT>,.....,SCH=<SCH>
>    <usw.>
> [...]
>   Freilich haben sowohl dieses Verfahren wie auch das der
> Platzhalter einige Schwaechen. Die mit #de,,* definierten
> Variablen funktionieren nur auf der Kommandoebene, nicht
> auf der Parameterebene.
Das geschieht wohl aus Gründen der Praktikabilität. Denn wenn
Variablen der Kommandoebene auch in der Ebene der Parameter
verarbeitet werden, kommst Du mit Tags und allerlei anderen
Kodierungen nur in andere, womöglich noch größere
Schwierigkeiten.

> Aber es gibt m.E. dennoch eine wirklich gute Loesung da-
> fuer, naemlich die der Kommandomakros.
Das stimmt wohl. Aber wenn ich Tustep-Anfängern zeigen
möchte, dass man nicht immer einen Buchsatz herstellen
muss, um etwas auszudrucken, dann bietet sich eben
nach wie vor das Formatieren an. Wenn ich dann aber, um
einen einfachen Formatiere-Job mit wenigen überschaubaren
Kommandos in ein Makro stecken muss, um die Steueranweisungs-
probleme zu umgehen, dann ist das einfach zu umständlich
und gerade für Anfänger nicht überzeugend. 

> [...] Aus diesen Gruenden wuerde ich heute [...]
> fuer die Beibehaltung des
> Status quo plaedieren und eher empfehlen, die kleine Um-
> stellung der eigenen Prozeduren auf Kommandomakros vor-
> zunehmen.

Ich wünschte mir, dass Du Dir die Sache nochmals durch
den Kopf gehen lässt. Und ich gebe die Hoffnung auf
neue, alternative zusätzliche Steueranweisungen nicht
auf.

> Ganz nebenbei sei noch darauf hingewiesen, dass es in
> FORMATIERE auch schon seit Jahren die Moeglichkeit gibt,
> Spitzklammernmakros '<...>' zu definieren und zu ver-
> wenden. Und da ich schon seit vielen Jahren aus voller
> Ueberzeugung die Abkehr von jeglicher harten Formatie-
> rung predige und statt dessen die Verwendung der sach-
> lichen Auszeichnung (fuer die besagte Spitzklammermakros
> nach dem bewaherten Vorbild von HTML und XML bestens ge-
> eignet sind) nahelege, will ich an die damit verbundenen
> Vorteile und Chancen (der Plattformunabhaengigkeit, der
> Portierbarkeit und der Konservierbarkeit der Daten) mit
> Nachdruck erinnern.
Das war ja der Ursprung der Problematik, die ich dargestellt
habe. Um solche Spitzklammermakros aufzulösen, muss ja
'&?n' und '&!n' verwendet werden, womit wir wieder am
Anfang unserer Diskussion stehen.

Mit neuem Stoff zum Grübeln und besten Grüßen
pst


From lf001 at germanistik.uni-wuerzburg.de  Mon Mar 31 15:59:04 2003
From: lf001 at germanistik.uni-wuerzburg.de (lf001 at germanistik.uni-wuerzburg.de)
Date: Mon, 31 Mar 2003 14:59:04 +0100 (NFT)
Subject: [Tustep-Liste] test
Message-ID: <Pine.A32.3.90.1030331145852.13632A@wcpx06.germanistik.uni-wuerzburg.de>

test