Leserbriefe
Fragen zu Spectre 128
Ihrem Bericht über die COMDEX'88 ist zu entnehmen, daß dort eine Macintosh-Emulation unter dem Namen “Spectre 128“ von der Firma “Gadgets by small” vorgestellt wurde.
Als Mega ST4-Besitzer. der den ST fast ausschließlich als “Aladin-Mac-Emulalor“ einsetzt und inzwischen sogar einen MAC LaserWriter II NTX mit Erfolg an den ST angebunden hat. wäre ich sehr interessiert, “Spectre 128” zu kaufen. Auch wenn ich mit dem Aladin. Version 2.1, weitgehend arbeiten kann, so nervt doch, daß viele neuere Programme bzw. Updates wie zum Beispiel Foxbase, HyperCard, Ragtime 2.2, Excel 1.5 usw. nicht laufen und auch in absehbarer Zeit nicht laufen werden, da ALADIN nur die 64k-ROMs unterstützt. Trifft es zu, daß
- “Spectre 128” tatsächlich so kompatibel ist, wie in dem Artikel angegeben?
- “Spectre 128” den LaserWriter II NTX (nach Möglichkeit Apple-Talk) unterstützt?
- auch HyperCard auf der Emulation läuft?
- es die europäische (die deutsche) Betriebssystemversion und die deutsche ST-Tastatur unterstützt?
Peter S., Berlin
Red.: Spectre 128 ist so kompatibel, wie wir es in unserem Messebericht angegeben haben. das heißt, daß die dort angegebenen Programme wie beispielsweise HYPERCARD im großen und ganzen laufen (näheres in unserem Testbericht). Ein sehr großer Nachteil ist aber, daß der SPECTRE 128 z.Zt. praktisch keinen Drucker (ganz zu schweigen den LaserWriter II NTX) unterstützt - dies soll zwar in der nächsten Version verbessert werden, aber warten wir es ab. Apple-Talk läuft, wie könnte es anders sein, leider auch nicht, sondern das Anwählen in Auswahl-DA führt zum Absturz. Zu Ihrer Tastaturfrage läßt sich sagen, daß bisher keine Anpassung an die ST-Tastatur erfolgt ist, was übrigens möglich ist und nicht unmöglich, wie eine andere Zeitschrift berichtete. Also besteht noch Hoffnung, zumal vom Hersteller versichert wurde, daß wenigstens die Cursortasten ab der Version 1.9 unterstützt werden (aktuelle Version ist die 1.75). Die europäischen MAC-Betriebssystemversionen werden unterstützt. Abgesehen davon ist es momentan sehr schwierig, 128k ROMs für den MAC zu bekommen.
ST-Ecke: Lupenerweiterung
Das Programm “LUPE” funktioniert bei mir sehr gut. Nur kann man leider mit den Vergrößerungen nichts weiter anfangen, als sie sich auf dem Bildschirm zu betrachten. Ich habe ein kleines Zusatzunterprogramm geschrieben, mit dem man sich über ALTERNATE-HELP die Vergrößerung auch ausdrucken lassen kann. Mit speziellen Hilfsprogrammen kann man sich die Vergrößerung auch, anstatt auszudrucken, in eine Datei schreiben. Diese Datei kann man mit Mal- oder Zeichenprogrammen weiterverarbeiten. Ich habe das Programm im monochromen Grafikmodus getestet - bei mir läuft es einwandfrei. Das Listing habe ich gut kommentiert, so daß sich weitere Erklärungen (hoffentlich) erübrigen.
Klaus-Dieter Litteck, Stade
Zwischen Zeile 182 und 183 muß folgender Befehl eingefügt werden:
182: GO_SYSTEM
bsr HARDCOPY ** diese Zeile einfügen
183: movem.l (sp), d0-d2/a0-a2
Dann muß an irgendeiner Stelle im Listing folgendes Unterprogramm eingefügt werden:
HARDCOPY:
tst.b MODE * Ist MODE = 0, nichts tun
beq.s NO_SCRDMP * Keine Vergrößerung aktiv
tst.w $4EE * Wurde ALT-HELP gedrückt
bne.s NO_SCRDMP * Nein, dann Sprung
tst.w DMP_ZAHL * Wurde Routine schon mal durchlaufen
bne.s END_DMP * Ja, dann Sprung
move.w #1, DMP_ZAHL * Beim 1. mal Zähler setzen, damit wird
* mehrmaliges Durchlaufen verhindert
** FLIPBASE_2 wird zur logischen Bildadresse
move.L FLIPBASE_2(pc),$44E
bra.s END_DMP * Nun findet richtige Hardcopy statt
NO_SCRDMP:
tst.w DMP_ZAHL * Ist Zähler =0, nichts tun
beq.s END_DMP * Ja, dann Sprung
cmpi.w #-1,$4EE * Hardcopy beendet ?
bne.s END_DMP * Nein, dann Sprung
clr.w DMP_ZAHL * Zähler zurücksetzen
move.l PHYSBASE(pc), $44E * Alte Bildadr. restaurieren
END_DMP:
rts
DMP_ZAHL: dc.w 0 * Zähler, oder Merkzelle
Illegale Adressen in ‘variablen Bildausschnitten ’
Im Listing meines Beitrags 'Variable Bildausschnitte' (ST Computer 3/89, S.88ff) habe ich zur Positionierung des Mauszeigers seinerzeit zwei 'illegale', also nicht dokumentierte Adressen benutzt. Die Dpokes in den Zeilen 81 und 82 erfüllen zwar beim alten TOS ihren Zweck, beim Blitter-TOS hingegen bleibt der erwünschte Effekt aus, da sich dort die entsprechenden Adressen verschoben haben. Derartige Adressen sollten allerdings grundsätzlich nicht benutzt werden, da ständig die Gefahr ihrer Verschiebung besteht. Als Ersatz der erwähnten Dpokes bieten sich zwei Möglichkeiten an:
1 In den GFA-BASIC-Version 3.xx: der neue Befehl Setmouse Xpos%, Ypos% 2. Für die BASIC-Version 2.xx: Einsatz der VDI-Funktionen vsm_locator in einer geeigneten Prozedur (vgl. hierzu auch: Leserbrief von M. Seelis in ST 3/89, S.184). Das Listing sollte also wie folgt korrigiert wer den:
81: Dpoke 9952, XI%+1
82: Dpoke 9954, YI%+38
durch folgende Zeilen ersetzen:
81: Gosub Setm(XI%+1, YI%+38)
82: !entfällt
Procedure Setm(Xm%, Ym%)
Hand%=Dpeek(Contrl+12)
Dpoke Contrl+2,0
Dpoke Contrl+6,2
Dpoke Contrl+12, Hand%
Dpoke Intin,1
Dpoke Intin+2,2
Vdisys 33
Dpoke Ptsin,Xm%
Dpoke Ptsin+2,Ym%
Dpoke Contrl+2,1
Dpoke Contrl+6,0
Dpoke Contrl+12,Hand%
Vdisys 28
Return
Hans-H. Ackermann, Kassel
Eine weitere Reaktion auf diesen kleinen Lapsus bekamen wir von Herrn Uwe Klatt aus Braunschweig:
In der Programmierpraxis „variable Bildschirmausschnitte“ in GFA-BASIC hat der Autor leider auf feste Adressen des LINE-A zugegriffen. Da das Programm so nur mit dem TOS vom 6.2.86 läuft, möchte Ihnen folgendes Listing anbieten ($A000 und RTS, dabei Rückgabe über Register D0)
Uwe Klatt, Braunschweig
'*******************
'* Setmaus *
'* Uwe Klatt 2/89 *
'* GFA-BASIC 2.0 *
'*******************
'
Gosub Init
'
For I%= 0 to 640
Gosub Setmaus(1%, 100)
next I%
'
Gosub Setmaus(320,250)
'
End
'
Procedure Init
mc$ = chr$(&HA0)+ chr$(0)+chr$(&H4E)+chr$(&H75)
mc% = VARPTR(mc$)
linea_base%=C:mc%()
Return
'
Procedure setmaus(xm%, ym%)
If Ym%>=0 AND Ym%<400
Dpoke linea_base%-&H258, Ym%
Endif
if Xm%>=0 AND Xm%<640
Dpoke linea_base%-&H25A, XM%
Endif
Dpoke linea_base%-&H256, 0
Vsync
Hidem
showm
Return
Adimens-Tips
Um das Umsteigen von Adimens 2.1 auf 2.3 zu erleichtern, möchte ich auf ein kleines Problem hinweisen, das den Anwender einige Zeit kosten kann. Wie im Handbuch beschrieben, ist ab Version 2.3 das Programm zur GEM-Maskenerzeugung nicht mehr notwendig. Will man nun eine alte Datenbank mit Hilfe des neuen INIT-Programms verändern (und nicht nur an 2.3 anpassen), so ist unbedingt darauf zu achten, daß man die bislang von DRC erzeugten Dateien *.DEF und *.RSC löscht (oder umbenennt), weil ansonsten die INIT-Änderungen, die die Masken betreffen, von EXEC nicht erkannt werden! EXEC sieht nämlich die alten Masken-Dateien *.DEF und *.RSC und denkt überhaupt nicht daran, neue Masken zu kreieren. Die Folge ist, daß man auf eine neue Datenbankstruktur mit alten Masken zugreift, was einen ziemlich verwirren kann: man glaubt nämlich, INIT hätte nicht funktioniert und die Dateien seien hoffnungslos kaputt!
Also: Wenn DRC nicht mehr benutzt werden soll, immer vor dem EXEC-Aufruf die oben erwähnten Dateien löschen, dann gibt es keine Probleme. Wenn EXEC die Masken selbst aufbaut, erscheint auch eine entsprechende Meldung beim Start, bleibt diese aus, so weiß man, daß DRC-erzeugte Masken verwendet werden. Bei der Version 2.3 fällt sofort auf, daß das Scrollen in der Datei-Listenanzeige erheblich langsamer als bisher vonstatten geht. Mein Anruf bei ATARI brachte die Lösung: Beim Scrollen werden jetzt sehr viel mehr Quer-Checks durchgeführt, was zu höherer Anzeigesicherheit, aber eben auch zu Geschwindigkeitsverlust führt. Der Vorteil ist zum Beispiel, daß beim Rückwärtsscrollen mit aktivem Filter (WAHL=...) das Füllen der Fenster nunmehr fehlerfrei funktioniert. Die alte Geschwindigkeit beim Scrollen kann man im übrigen zurückgewinnen, indem man die ganze Datei aufs Klemmbrett zieht und dort scrollt.
Nichtsdestotrotz ist das Update sein Geld wert, denn gerade der Paßwortschutz wird in kommerziellen Anwendungen mit mehreren Arbeitsplätzen von Nutzen sein. So kann ein Arbeitsplatz/Benutzer definiert werden, der als Einsteiger Datenänderungen vornehmen darf, während die anderen selektieren, ansehen etc. dürfen, was erst eine einheitliche Datenbasis auf mehreren Rechnern möglich macht. Wenn jeder ändern darf, hat jeder bald eine andere Datei. So ändert nur eine Person, und die anderen bekommen die Änderungen täglich/wöchentlich via Export eingespielt...
Michael K, Hürth-Hermiilheim
Button-Abfragen
In einem GFA-Programm habe ich eine Dialogbox mit Radio-Buttons geöffnet (form_do). Wie kann ich nun wahlweise die Buttons mit Maus oder Taste bedienen? Meine bisherige Lösung besteht darin, die Box zu zeichnen (objc_draw) und dann mit ON MENU BUTTON die Mausbedienung zu simulieren — umfangreiche X/Y-Abfragen, Setzen des Objektstatus und Neuzeichnen der Box inklusive... Daneben läuft auch noch ein ON MENU KEY. Geht das auch eleganter ?
Peter V., Heide
Red.: Ja. es geht eleganter, indem man die von GEM zur Verfügung gestellten Routinen FORM_KEYBD() und FORM_BUTTON() benutzt. Diese Routinen sind beispielsweise im Profi-Buch von SYBEX beschrieben. Aber schon in der ST-Computer 7/87 haben wir in der ST-Ecke beschrieben, wie man sich sehr einfach eine eigene form_do()-Routine schreiben kann. Dabei werden mit evnt_multi (bei GFA wären das, falls man evnt_multi des GEMs partout nicht verwenden möchte, ON MENU ...) die Ereignisse abgefragt, die Tasten mit form_keybd() gefiltert und verarbeitet und die Maus mit form_button auswertet. In dieser ST-Ecke wird an einem Beispiel gezeigt, wie man dafür sorgt, daß die RETURN-Taste ein Springen von EDIT-Feld zu EDIT Feld veranlaßt, sofern kein Objekt als DEFAULT gesetzt ist. Weiter führt zum Beispiel die UNDO-Taste zum Abbruch der Form_do( )-Routine.
Viele benutzen ein Programm und keine Raubkopie
Als Privatanwender des ATARI habe ich ein Problem mit der für diesen Rechner angebotenen Software: Sie ist hervorragend und erfüllt (fast) alle meine Wünsche. doch leider ist sie zu teuer, uni mir alles zu kaufen.
Konkret könnte ich SIGNUM! 2 ganz gut gebrauchen, um z.B. Referate und Studienarbeiten zu schreiben, aber die cirka 400 DM sind mehr, als ich ausgeben möchte.
Angenommen, ich kenne jemanden, der sich SIGNUM!2 legal angeeignet hat. Kann ich mir dann, ohne irgendwelche Urheberrechte zu verletzen, das Programm leihen und meinen Text damit erstellen? Wenn das ginge, wäre der nächste logische Schritt, teure Programme in einer Gruppe zu kaufen, nur eine Person als Eigentümer registrieren zu lassen, und die anderen leihen sich dann das Programm. Das wäre auch ein Vorteil für Softwarehäuser, denn so könnten sie mir (und meinen Freunden) ein Programm verkaufen, ich kann es guten Gewissens benutzen und nehme nicht heimlich eine Raubkopie.
Wolfgang W., Karlsruhe
Red.: Zunächst einmal sei vorausgeschickt, daß hier keine allgemeingültige Aussage getroffen werden kann, sondern daß immer die Lizenzbestimmungen gelten, die bei dem entsprechenden Produkt dabei sind. Häufig läßt sich aber sagen, daß Software wie ein Buch benutzt werden darf: Es kann nur von einer einzigen Person zur selben Zeit gelesen, kann aber auch weitergegeben werden. Es ist aber diejenige Person haftbar für das Programm. die bei der jeweiligen Herstellerfirma als Käufer registriert ist. Wichtig ist dabei auch, daß (falls nicht ausdrücklich erlaubt) ausschließlich eine Sicherheitskopie angelegt werden darf. Sicher ist die von Ihnen angesprochene Idee recht gut, denken Sie aber daran, daß es häufig der Fall sein wird, daß mehrere der Gruppenkäufer gleichzeitig das Programm nutzen möchten. Dies verführt leicht dazu, daß das Programm (nicht als Sicherheitskopie) kopiert wird, was - wie schon erwähnt - nicht erlaubt ist. Sehr leicht entsteht der Streit um das Objekt. Außerdem steht bei den diversen Produkten dabei, daß das Programm nur auf ein und demselben Rechner genutzt werden darf - ob das sinnvoll ist, sei dahingestellt.
Im Einzelfall kann ich Ihnen nur raten, das entsprechende Softwarehaus darauf anzusprechen. Sie werden sicherlich eine Auskunft bekommen. Sollte diese negativ ausfallen. fragen sie doch einfach einmal nach der Begründung!
Was ist ein Screenformat?
Im ST-Computer Heft 12/88 steht auf Seite 88 bei der Beschreibung über eine 9-Nadler-Hardcopy folgender Textausschnitt: "Das Bild, welches im gängigen Screenformat ..abgespeichert sein muß. usw...” Meine Frage lautet nun: Wie geht das? Was ist ein Screen-Format?
Eberhard K., Göttingen
Red.: Bei dem Wort Screenformat haben die Angelsachsen mal wieder böse zu geschlagen. Wie Sie sich sicher schon denken können, heißt Screenformat auf deutsch einfach Bildformat. Damit ist die Art gemeint, wie der ATARI seine Bilder im Speicher ablegt. Die von Ihnen angesprochene Hardcopy-Routine bezieht sich nur auf die hohe Auflösung des ATARIs mit einer Auflösung von 640x400 Punkten. In dieser Auflösung liegen alle gesetzten Punkte (Bits) in einer Reihe hintereinander im Bildspeicher des STs. Auf diese Weise kommen dann 640x400/8 (8 Bits in einem Byte) = 32000 Bytes zustande. Nun gibt es die unterschiedlichsten Malprogramme und damit auch viele unterschiedliche Möglichkeiten, ein Bild abzuspeichern. Die einfachste Methode ist aber immer noch die, die Daten einfach so abzuspeichern, wie sie auch im Speicher vorliegen. Eine so abgespeicherte Datei ist im Screen- oder auch Doodle-Format abgelegt. Doodle ist der Name eines kleinen Zeichenprogramms, welches in der Lage ist, die Daten im Screenformat abzuspeichern. Das Doodle-Programm finden Sie auf unserer PD-Disk 1 und in erweiterter Form auf der Nr. 18, allerdings unterstützen praktisch alle Zeichenprogramme für den ST dieses Format. Auf PD-Disk 18 finden Sie weiter ein Programm, mit dem Sie die unterschiedlichsten Bildformate auch in das Screen-/Doodle-Format umwandeln können.
Ein Problem im Zusammenhang mit der von Ihnen angesprochenen Hardcopy-Routine besteht allerdings, wenn Sie den aktuellen Bildschirm mit dieser Routine ausdrucken möchten, da die Daten als Datei vorliegen müssen. Aber auch dafür gibt es Programme, die das aktuelle Bild als Datei auf Diskette ablegen. Ein solches Programm finden Sie auf unserer PD-Disk Nr. 74 unter dem Namen MONO_NEO. Der Vorgang wäre dann, das aktuelle Bild mit Mono_neo auf Diskette abzuspeichern und mit der veröffentlichten Hardcopy auszudrucken.
GFA-BASIC-Resource-Textfragen
Ist es in GFA-BASIC möglich, sich ein eigenes Desktop zu erstellen, wie es beispielsweise im Resource-Editor von Kuma gemacht wird - also nur 2 Icons im *.RSC-File, aber alle angemeldeten Laufwerke werden durch Icons dargestellt? Eigentlich muß doch hierzu die OBJC_ADD-Routine weiterhelfen, doch ist es mir bisher nicht gelungen, vernünftige Ergebnisse zu erzielen.
Im GFA-Buch wird eine Textausgabe in Assembler realisiert. Leider beachtet dieser Assembler-Quelltext kein vorgegebenes Clipping, welches für eine vernünftige Fensterverwaltung doch(?) notwendig ist. Welche Lösung gibt es dafür?
Wo kann man das bisher wenig erwähnte PROFESSIONAL GEM von Tim Oren erwerben, was ist dort nieder geschrieben und wie teuer ist dieses Buch?
Red.: Sicherlich ist es auch in GFA-BASIC möglich, ein Desktop zu kreieren, auf dessen Oberfläche Icons erscheinen, allerdings ist diese Aufgabe (unabhängig von der Sprache) nicht so einfach - Sprachen mit Records oder Strukturen eignen sich aber besser. Prinzipiell ist es zunächst einmal Ihre Aufgabe, den eigentlichen Desktop-Hintergrund zu schaffen. Dieser Hintergrund kann im RCS erstellt werden, sie müßten dann aber nach dem Laden die Adresse erfragen (rsrc_load() und rsrc_gaddr()) und dann die Daten dieses Baums in ein Feld (Array) kopieren, in die Sie auch die Icons schreiben. Ein Objekt belegt 24 Bytes. Nun müssen Sie sich für jedes auf dem Desktop erscheinende Icon ein Objekt erzeugen, welches die richtigen Eintragungen in der Objektstruktur enthält. Diese Objektstruktur finden Sie in allen gängigen Büchern, die sich mit dem GEM des ST beschäftigen. Das Erstellen des Baumes im einzelnen wäre hier zu aufwendig, um es zu beschreiben. Um es kurz zu fassen: Sie müssen sich im Speicher einen eigenen Objektbaum zusammenstellen. Sie können sich die Arbeit dahingehend erleichtern, daß Sie im RCS ein ICON im Desktop erzeugen und dessen Werte in Ihrem Programm beim Erstellen der weiteren Icons kopieren - die ICONBLK-Struktur wird auf diese Weise schon mitgeliefert und muß nicht erst mühsam zusammengebastelt werden. Dann müssen sie nur noch die Koordinaten des neuen, kopierten Objektes anpassen.
Zu dem Problem mit der Textausgabe: Ich würde Ihnen abraten, irgendwelche in Assembler geschriebenen Textausgaben zu verwenden, da sie meist nicht kompatibel zu späteren Betriebssystemversionen sind oder auch jetzt schon Dinge wie Clipping aussparen - für eine vernünftige Fensterverwaltung IST Clipping eine Voraussetzung. Am besten ist es immer noch, das VDI zu benutzen - wenn Sie beispielsweise auf Texteffekte verzichten und darauf achten, daß die X-Koordinate auf einer Vielfachen von acht anfängt, ist die VDI-Textausgaberoutine gar nicht so langsam. Wenn Sie aber eine Stufe niedriger gehen wollen, verwenden Sie doch die Line-A Routinen Ihres ATARIs (voraussichtlich ST-Ecke 6/89), was zugegebenermaßen aus GFA-BASIC schwierig, aber machbar ist.
Das PROFESSIONAL GEM von Tim Oren, der übrigens ein Autor des allseits geliebten ATARI-Resource-Construction-Sets ist, ist in Zusammenhang mit der amerikanischen Zeitschrift ANTIC entstanden und ist. soweit mir bekannt, nie als Buch erschienen, sondern konnte über eine Mailbox abgerufen werden. Auch in Deutschland kann es bei ATARI von Entwicklern über die Mailbox (06142/211...) abgerufen werden. Das Professional GEM von Tim Oren, das nun auch schon zwei Jahre alt ist, beschäftigt sich mit den Routinen des GEM und zeigt auf, wie diese auf geschickte Weise ausgenutzt werden -zum Beispiel der Tip, daß die VDI-Textausgabe bei 8er-X-Koordinaten schneller geht, stammt von ihm. Es ist in Englisch verfaßt und in diesem unserem Land in Deutsch wahrscheinlich nie erschienen. An und für sich sind aber alle dort erwähnten Information in den zahlreichen bis heute erschienenen Artikeln der ST-Computer verwertet und ausführlich(er) dargestellt worden.
Fehler in ‘gemalten Farben’
In der ST-Computer 1/89 ist mir unter der Programmierpraxis folgender Fehler bezüglich ‘Colcon’, Seite 88, aufgefallen: Im Modul ‘Get_memory()’ steckt ein gemeiner Programmierfehler, das heißt, wenn der Autor den Megamax-C-Compiler verwendet, wird der Fehler wahrscheinlich nicht auffallen, da dort die Funktion ‘calloc()’ einen durch 256 teilbaren Wert zurückliefert (zufällig?). Da ich einen LATTICE-C-Compiler verwende, hatte ich beim Probelauf von COLCONV. PRG gleich einen Systemabsturz.
Der Fehler besteht darin, daß man eine besorgte Speicheradresse nicht ausmaskieren darf, ohne vorher die höchstmöglichen Maskenbits aufzuaddieren. Daraus erfolgen folgende Änderungen in Zeile 141 und 142:
WrkScr1= (char*)( ((long)WS1 + 256L) & 0xffffff00L);
WrkScr2= (char*)( ((long)WS2 + 256L) & 0xffffff00L);
Wenn also das Programm zusätzlichen Platz besorgt und die ausmaskierte Adresse noch tiefer liegt, kann dies voll in den Stack hauen (wie bei mir mit ca. 8 Bomben).
Berthold Benning, Ennepetal
Feste Spaces in Word Plus
Jeder, der wie ich auf dem PC Texte entwirft und sie zu Hause auf dem ATARI unter Word Plus weiterverarbeiten möchte, hat sich bestimmt schon darüber geärgert, daß die übertragenen Texte, obwohl im ASCII-Format, unter Word Plus im WP-Modus nicht mit ‘Neu formatieren in eine angenehme Form zu bringen sind. Des Rätsels Lösung liefert das Leerzeichen von Word Plus: Ein normaler Space ist laut ASCII-Tabelle 20 hex. Word Plus nimmt aber gerade diese als ‘fixed‘ (feste) Spaces. Bei ‘Neu formatieren‘ werden diese also als fest gesehen und die ganze Textzeile als Wort betrachtet. Ein normales Leerzeichen ist bei Word Plus IE hex.
Thomas Trolldenier. Hannover
Red.: Herr Trolldenier hat uns freundlicherweise ein Programm geschickt, mit dem es möglich ist, die festen Spaces in variable umzuwandlen. Vielen Dank! Trotzdem wollen wir hier einen kleinen Tip veröffentlichen, der nicht so bekannt ist. Es geht auch einfacher: Sie brauchen nur in Word Plus im WP-Modus einen Space ‘ ‘ durch einen Space ‘ ‘ zu ersetzen. So witzig es auch klingt, es funktioniert: Word Plus macht aus dem vorhandenen Zeichen 20 hex ein 1E hex. Damit dürfte das Problem gelöst sein.