Dokumentation zu dem Programm MACTEXT (C) ONKISOFT 1999 Geschrieben von Gero Zahn Bergring 27 4953 Petershagen Tel.: 05707/2501 KTO 57326548 BLZ 49050105 Sparkasse Minden Lbbecke Welchen Aladin-Nutzer hat die Tatsache noch nie gest”rt, daá Texte, die mit MacWrite, Turbo-Pascal, Ragtime oder irgendeinem anderen Programm eingetippt worden sind, auf immer und ewig in der H”lle des Aladin-Formates verschwunden blieben. Des gleichen umgekehrt: Hat man unter MSDos in Turbo-Pascal etwas geschrieben, will man es (weil PCDitto ja eine lahme Ente ist) sicher unter einem schnelleren System laufen lassen. Was liegt da n„her als Turbo-Pascal unter Aladin? Von MSDos hin zum Mac gibt's eigentlich keine Probleme: Es gibt da ein Programm namens "Gem To Mac", das unter Aladin l„uft. Normalerweise ausgeworfene Gem-Disketten beh„lt er bei sich und (vorausgesetzt, die Diskette ist 80 Tracks/9 Sektoren formatiert) l„át sich jedes beliebige File in die leers Superdisk kopieren. Von dort aus kann das gleiche Programm die Files weiterkonvertieren, entweder als Text-Files (MacWrite-Format) oder als Bilder (MacPaint-Format). Somit kein Problem. Wer das Programm nicht hat, hat natrlich Probleme ... Doch zurck: Man hat beispielsweise unter Ragtime einen Text geschrieben, sagen wir, eine Kurzgeschichte. Der Ausdruck ist ja ganz nett, doch andererseits w„re es schon ganz sch”n, das Ding unter Wordplus weitereditieren zu k”nnen, denn auf die Dauer hat man unter Atari-TOS doch mehr M”glichkeiten. Aladin ist in dieser Beziehung doch eine ziemliche Sackgasse. Auáerdem: Bis der Finder von Diskette hochgefahren ist, kann man getrost noch mal 'ne Tasse Kaffee trinken, w„hrend Wordplus nach ein paar Sekunden da ist. "Was tun?" sprach Zeus. šber eins sollten wir uns im Klaren sein: Die Schrift-Attribute werden den Weg eines verg„nglichen gehen. Doch fr Turbo-Pascal-Sourcetexte ist das ja nicht von Bedeutung. Bei Texten rollt schon die eine oder andere Krokodilstr„ne. Naja, was soll's. Als erstes speichern wir den Text als reines Textfile ab. MacWrite hat eine entsprechende Option. Exportiert man den Text unter RagTime, so hat man sofort ein reines Textfile, ebenso ist ein abgespeichertes Pascal-File schon so wie es soll. Nun steht man vor dem Problem: Wie bekomme ich dieses File ins Atari-Diskettenformat? Ein Programm wie "Gem To Mac" existiert meineswissens bis jetzt noch nicht, aber ich arbeite dran. Wer sich dafr interessiert, soll sich mal bei mit melden. Bis dahin behelfen wir uns mit einer Notl”sung: Wir kopieren das File auf eine frisch formatierte Diskette. Mit brauchbaren Diskettenmonitoren (PD gibt's die Dinger ja wie Sand am Meer) kann man per Such-Option leicht den Anfang und das Ende des Textes finden. Bei Pascal-Programmem sucht man am einfachsten "PROGRAM", das ja bekanntlich ganz am Anfang steht, und "END.", ditto am Ende. Brauchbare Monitoren lassen einem die M”glichkeit, den gesamten Bereich zwischen zwei Markierungen als Diskettenfile abzuspeichern, gegebenenfalls auf Ramdisk. Dadurch, daá die Diskette frisch formatiert war, kann man beruhigt davon ausgehen, daá das File zusammenh„ngend auf der Diskette steht. Somit hat man nun ein sauberes Mac-File vor sich. Wer ber keinen Monitor mit diesen speziellen F„higkeiten verfgt, soll sich entweder selbst einen schreiben oder sich bei mir melden, ich habe da ganz brauchbare Dinger. Frisch ans Werk: Gleich eingeladen mit der erstbesten Texterarbeitung. Doch ins neun von zehn F„llen wird sich das als (man verzeihe mir den Ausdruck) der sprichw”rtliche Griff in Klo herausstellen. Hat man mit MacWrite gearbeitet, hat man ja ein Flieátext-File vor sich. Das Format ist wie folgt: Es gibt keine Zeilen-Einschnitte, nach jedem Absatz steht mal gerade ein "CR". Normale ST-Textverarbeitungs-Programme ben”tigen aber normalerweise nach jeder Zeile "CR/LF", und zum Beispiel Tempus 2.0 braucht hinter einem Absatz zus„tzlich nochmal "CR". Auáerdem ist eine Zeile (daá sie mit "CR" aufh”rt, verstehen die meisten Programme noch) entschieden l„nger als gewohnt. Bei Tempus 2.0 ist eine Zeile maximal 160 Zeichen lang. Ein ganzer Absatz hat aber (z. B. bei 10 Zeilen) schon etwa 800 Zeichen. Und was nun? Bevor wir uns mit diesem Problem besch„ftigen, reden wir besser erstmal von einem anderen: Der Miáerfolg mit dem Textverarbeitungsprogramm hat uns nicht im geringsten abgeschreckt. Schauen wir uns das Mac-Textfile erstmal direkt vom Desktop an. Also: Doppelclick und dann "Anzeigen". Komischerweise zeigen sich im Text die wildesten Grafik-Zeichen und/oder Buchstaben, wo normalerweise Umlaute, Vokale mit Akzenten oder andere Zeichen stehen sollten. Das liegt an folgender b”sen Falle: Der Mac verfgt (wie die meisten normalen Computer) ber einen ASCII-Zeichensatz, zumindest alle Zeichen bis einschlieálich chr(127) stimmen exakt berein. Was dann folgt, ist ein planloses Tohuwabohu. Ein ST und ein PC verfgen (ungef„hr zumindest) ber einen USA-Zeichensatz. Der Mac hat da seine eigenen Konventionen. Faktisch ist es so, daá fast jedes USA-ASCII-Zeichen auch im Mac-Zeichensatz vorkommt, nur an einer anderen Stelle. Was man nun br„uchte, w„re zuallererst mal ein Zeichenkonverter, ein Programm also, das weiá, wo im ST-Zeichensatz jedes beliebige Mac-Zeichen steht. Stellen wir uns vor, wir h„tten ein solches Programm. De facto verrichtet MACTEXT diese Aufgabe ohne Anstand. Jetzt haben wir ein nettes ST-Textfile. Alle nicht implentierten Zeichen (wie zum Beispiel das angebissene Žpfelchen) wurden entfernt, ebenso automatische Trennungen, die RagTime produziert und desgleichen mehr. Was will der Mensch noch mehr? Noch immer stimmen die Zeilenende-Markierungen nicht. Daher hat MACTEXT des weiteren die Option, die Zeilenende-Kennungen gegen eigene auszutauschen. Man hat die Wahl zwischen "CR" (keine Žnderung), "CR/LF" (Standard-Zeilenende) und "CR/CR/LF" (Tempus 2.0 Flieátext). Wozu Punkt eins gut ist, weiá ich selbst nicht so genau. Man kann's ja vielleicht mal brauchen. Fr Pascal-Programme, die ja kein Flieátext sind, reicht Punkt zwei v”llig aus. Man kopiert das erhaltene File nur noch auf eine MSDos-Diskette und kann sofort mit Turbo-Pascal anfangen, herumzuexperimentieren. Ein paar kleine Žnderungen in der Implementation sind sicher erforderlich, aber so grob isses das schon mal. Doch zu Flieátext-Texten. Ich verfahre immer so: Als Zeilenende lasse ich mit "CR/CR/LF" einsetzen. Somit sind da, wo auch vorher welche waren, auch fr Tempus 2.0 Abs„tze. Probleme gibt's nur mit den berlangen Zeilen. Es gibt da aber eine M”glichkeit: Ich ben”tige einen Tempus, der gleich beim Einladen eines Textes im Flieátext-Modus steht. Tempus wird beim Einladen meckern, daá ihm die Zeilen zu lang sind. Ganz logisch. Er wird fragen, was er mit den zu langen Zeilen machen soll: 1. Zeilenl„nge anpassen. Dieser Punkt wird durchgestrichen sein, weil die Zeilenl„nge sicher l„nger als die maximale ist; 2. Abbruch. Das k”nnen wir uns schenken - Dazu haben wir Tempus nicht gestartet; 3. Zeilen abschneiden. Das k”nnen wir uns auch sparen. Von jedem Absatz h„tten wir nur die erste Zeile. Das ist also vollkommener Quatsch; 4. Zeilen abknicken. Das isses! Der Rest des Absatzes wird in die n„chste Zeile gesteckt. Paát das auch nicht, geht der Rest wieder in die n„chste Zeile, und so weiter. Somit haben wir immerhin schon mal den gesamten Text im Speicher, wenn auch mit etwas merkwrdigen Trennungen an den Zeilenenden. Nun kommt wieder einmal ein kleiner Trick mit einem groáen Effekt: Wenn wir nun die angestrebte Zeilenl„nge einstellen und den Menpunkt "Text reformatieren aufrufen, werden die auseinandergeschnittenen W”rter wieder zusammengeklebt. Wieso das? Nun, es ist so, daá Tempus (immer wenn er eine neue Zeile beginnt) das letzte Leerzeichen der letzten Zeile auch dort stehen l„át, als Wortende-Kennung eben. Daran erkennt er, daá hier eine neue Zeile beginnt, wenn auch im Flieátext. Beim "Zeilen abknicken" gab es keine Leerzeichen am Zeilenende. Die Zeile endete mit einem Buchstaben und einem "CR/LF". Beim neuerlichen formatieren fgt Tempus die W”rter wieder zusammen ohne ein Wort des Widerspruches. Die neuen W”rter kommen korrekt in den Blocksatz oder ins linksbndige Format. Das Wunder ist geschehen: Wie haben den ehemaligen Mac-Text im Tempus-Flieátext-Format. Doch wie ich mich kenne, kenne ich sicher auch andere Nutzer, die den Text gerne im Wordplus-Format h„tten. Das kostet nun auch nicht mehr viel Arbeit: Das Wordplus-File-Format ist irgendwie recht komplex, also konvertieren wir den Text doch besser einfach nur in Wordplus-Blockformat. Dabei entfallen logischerweise das Seitenformat, das Linieal etc. etc. ... Wordplus benutzt als Leerzeichen-Substitute (also statt chr(32)) den ASCII-Code chr(30). Das ist auch der Grund, warum Wordplus-Texte bei direkten Anzeigen vom Desktop aus immer so komisch unleserlich sind. Ein direkter Grund dafr war mir nicht direkt deutlich. Feste Leerzeichen haben sind jedenfalls auch chr(32) ... Das Prinzip des Flieátextes hat Wordplus ja auch, wenn auch nicht so sch”n wie Tempus. Die Erkennung der Abs„tze funktioniert aber etwas anders: Alle Zeilen enden mit "CR/LF". Eine Zeile, mit der nicht gleichzeitig der Absatz endet, hat ein Leerzeichen am Ende, bzw. ein chr(30). Wie ich bereits erw„hnte, hat Tempus das auch, als Wortendekennung. Somit entspricht die Sache schon richtig gut den Konventionen. Als erstes mssem wir alle Leerzeichen durch Substituten ersetzen. Das ist mit der "Suchen & Ersetzen"-Option von Tempus eine Arbeit von einer Sekunde. Was jetzt noch st”rt, sind die berflssigen "CR"'s am Ende der Abs„tze. Um die Wegzukriegen, schaltet man in den Quelltext-Modus und klickt den Menpunkt "Zeichenredundanz" an. Dabei werden alle einzelnen "CR"'s rausgestrichen. Den so erhaltenen Text speichert man einfach als "nnn.BLK" ab. Mit Wordplus ”ffnet man einfach ein neues Dokument "mmm.DOC" und l„dt "nnn.BLK" als Block ein. Durch neues formatieren des ganzen Textes wird der Text (in manchmal minutenlanger Arbeit) an das neue Lineal gew”hnt. Jetzt kann man anfangen, die verlorenen Text-Attribute mittels "Restyle" wieder einzubringen. Dann ist das n„chste Wunder geschehen: Der Mac-Text ist via Direktmodus-Tempus-Hamburg-Hannover zu Wordplus gekommen. Man verlange jetzt nicht von mir, ihn wieder zurck zu bringen. Theoretisch m”glich ist aber alles. MACTEXT konvertiert also "nur" die Zeichen und die Zeilen-Enden. Von daher ist die Bedienung auch ziemlich einfach: Nach einer kleinen Begráungs-Box erscheint eine File-Selector-Box und die Meldung, das Mac-Text-File anzuklicken. Danach kommt eine zweite File-Selector-Box, die den Namen eines ST-Textfiles verlangt. Man f„hrt immer gut mit den Endungen ".MAC" und ".TXT". Je nach vorhandensein des Ziel-Files wird entsprechend reagiert. Es bedarf wohl keiner weiteren Beschreibung. Nun folgt noch die Frage nach der neuen Zeilenende-Kennung: Default ist "CR/CR/LF" (fr Flieátxte). Nun folgt ein Window, in dem das prozentuale Fortschreiten des Programms angezeigt wird. Es ist sicher nicht das schnellste, aber es funktioniert immerhin. Die nunfolgende Frage nach einem neuerlichen Programm-Lauf erkl„rt sich sicherlich von selbst. Theoretisch war's das. Wer an dem Listing (vor allem interessant wegen der Konversions-Tabelle, die ich in ein durchwachten Nacht erstellt habe) interessiert ist, m”ge mir einfach schreiben. 10,- DM und eine formatierte und virenfreie Diskette sind dazu n”tig. Updates gibt's unter den gleichen Bedingungen. Als Update wird wohl demn„chst das komplette Paket "Mac To Gem" erscheinen, die Zeichen- und Zeilenende-Konversion inbegriffen, plus eine Routine, die das l„stige Suchen nach File-Anfang und -Ende beendet. Das wird dann wohl auch auf vollen (also nicht unbedingt frisch-formatierten) Aladin-Disketten funktionieren. Also, Leute, haltet Euch ran! Fr Bug-Reports bin ich natrlich immer offen. Ein Bug liegt brigens bei folgendem Sachverhalt nicht vor: Unter Aladin gibt es ein Zeichen, erreichbar ber ALT-".", das aussieht wie drei Punkte hintereinander. Dies ist das einzige Zeichen, dem MACTEXT bei der Konversion eine ganze Zeichenkette (n„mlich "...") zuordnet. Das ist durchaus so gewollt! Fr Spenden im 10,- -Bereich bin ich (also armer Schler) natrlich auch immer offen ... Tja, Leute, dann bis die Tage ... Gero Zahn, Petershagen, den 3.9.1989