FrameMaker 7 internally uses its own "FrameRoman" encoding. When specifying strings within Plugins or FrameScripts, or dealing with non-ascii file names a special conversion might be necessary regarding "umlauts".
Actually, no American/English FS programmer *ever* had any problem with encoding conversion, dealing with special chars neither within file & format names nor with string specification within FrameScript scripts - they simply don't use special chars at all. (And, of course, they also never had any problem with the software localization differences and localized object names of FrameMaker.) Trying to write FrameScript scripts that works not only in the German (or: English) speaking part of the world, one ever had to put multiple Ifs and Elses into the scripts to make the scripts compatible when used on multiple platforms and/or in different countries. In the course of time, different enhancements were introcuded into FrameScript, facilitating the need of complicated conversion routines. More differences to take into account when writing "interoperable" scripts. Now - these all are things of the past! As a matter of fact, FrameMaker 8 actually *does* support Unicode - so why thinking about encoding, script and platform conversion at all? Well ... (warum schreib ich eigentlich in Englisch?!) Also: Ich bin ja seit jeher ein Verfechter der Entwicklung von "kompatiblen" Scripts. FS Mac 2.0, Win 2.1 mit und ohne aktiviertes eSystemObject, PlatformEncodingMode True oder False - ein Script sollte im besten Fall unabhängig davon immer funktionieren. Nun stellt sich mit der vollständigen Unicode-Unterstützung von FrameMaker/FDK wieder mal die Frage, ob man nicht besser einen CUT machen, alte Zöpfe abschneiden, die existierenden Scripts einfrieren und Scripts für den Einsatz in FM8 einfach neu entwickeln sollte. So sehr mir dieser Ansatz generell widerstrebt, lässt sich nicht leugnen, dass durch die fehlende Weiterentwicklung der Mac-Version von FrameScript, die fehlende Weiterentwicklung der Mac-Version von FrameMaker selbst sowie durch die zunehmende Umständlichkeit der Pflege solcher Scripts die vielbeschworene "Kompatibilität" in ihrem Grundsatz selbst von mir zunehmend in Frage gestellt wird. Also: "Die Anpassung existierender sowie die Entwicklung neuer FrameScripts unterstützen nur noch den Unicode-Mode"?? Mir erscheint ein solch radikaler Schnitt nicht in jedem Fall notwendig bwz. in einigen Fällen auch nicht machbar. Für eine Entscheidungsfindung, ob und wie man bestenfalls zukünftige Scripts bezüglich Unterstützung der verschiedenen "Encoding Modes" entwickeln sollte, möchte ich gerne eine Übersicht über den aktuellen Stand der Dinge liefern. 1. In FS 2.0 gab es keine spezielle Unterstützung durch FrameScript für Encoding-Issues. Es gab rudimentäre Funktionen z.B. für das Durchsuchen von Verzeichnissen - die Berücksichtigung von Unterordnern oder das Handling von Dateien mit Umlauten war bereits nur sehr umständlich zu bewerkstelligen. 2. Mit FS 2.1 kamen durch das ESystemObject verschiedene Hilfsfunktionen dazu, die allerdings leider nicht durchgängig die notwendige Arbeit abnehmen konnten - außer der Berücksichtigung voriger FS-Versionen galt es nun außer den neuen Funktionen auch sonstige Abweichungen zu berücksichtigen (z.B. die Kodierung in Scrollboxen). 3. FS 3.1 führte sowohl eine erweiterte Unterstützung zur automatischen Konvertierung ein (PlatformEncodingMode), als auch die Einführung der Entwicklung von benutzerspezifischen Dialogboxen. Eine Besonderheit dieser Dialogboxen und deren Controls war, dass das im Script spezifizierte Encoding hierfür nicht berücksichtigt wurde - dereren Strings mussten also immer im "Platform"-Encoding spezifiziert werden. 4. FS 5.1: FM8/Unicode. FrameMaker 8 unterstützt nun grundsätzlich Unicode, erlaubt aber Plugins die Verwendung des sog. "Compatibility Mode" (def), wo wie bisher allein das FrameRoman-Encoding zulässig ist und verwendet werden muss. Für den sog. "Unicode Mode" oder "UTF-8 Mode" müssen Strings durch das Plugin entsprechend in das UTF-8-Encoding umgewandelt werden - und zwar bei seiner Initialisierung. Nun ist es für ein simples Plugin tendenziell einfach, eine Variante zu erstellen, die halt statt dem Default-Compatibility-Mode den Unicode-Mode unterstützt. Das Plugin FrameScript erlaubt in der Version 5.1 nun aber auch einem Script, während der Laufzeit das aktuelle Encoding zu ändern - wie an anderer Stelle zu diskutieren ist, ist das äußerst sinnvoll. Ein Script an sich muss nun aber wiederum den aktuell eingestellten "Encoding-Mode" berücksichtigen - ob dieser nun vom Anwender oder durch irgendein anderes Script festgelegt bwz. geändert wurde. Für mich persönlich (als Scriptentwickler) ist es problematisch, abhängig von der Art und Anzahl der vorhandenen Scripts und deren Komplexität dem Anwender zu sagen: Hmm - nee: Keine Zeit für die Anpassung. Wenn Du meine Scripts weiterhin einsetzen möchtest, musst Du FrameScript im "Compatibility Mode" einsetzen. (Und: "Irgendwie" verhindern, dass "irgendein" Script den aktuellen "Encoding Mode" unerwünschterweise ändert ...) Der nächste Scriptentwickler hat seine Scripts (allerdings ohne Berücksichtigung des "Compatibility Mode") auf UTF-8 umgesetzt, und sacht nun dasselbe für den Einsatz der Scripts im Comp.Mode. Ein Patt für den gemeinen Anwender. Für diesen wird das m.E. ungemein schwierig, diese Thematik auszusteuern, Fehler (die dann eigentlich durch niemand wirklich verursacht wurden) vorherzusehen oder verhindern zu können. Insofern plädiere ich dafür, bei der Anpassung/Entwicklung von FrameScripts beide Modi (Compatibility/UTF-8) zu berücksichtigen. Und machbar ist dies durchaus. Zwar konnten bisher Zeichen direkt im Script ohne spezielle Kodierung angegeben werden: 'MŸller' ergibt unter FS Windows "Müller". Fortgeschrittene Entwickler haben aber seit jeher die Upper-ASCII-Zeichen entsprechend kodiert: New String IntValue(159) NewVar(gvsue); Set gvMyName = 'M'+gvsue+'ller'; Durch Inkonsistenzen z.B. durch Kodierungs-Abweichung in den FS3-Dialogboxen ergaben sich allerdings weitere Ungereimtheiten. Es ergeben sich also die folgenden Mög- und Notwendigkeiten (zur Deklaration von Strings): 1. Compatibility Mode, PlatformEncodingMode = False: New String IntValue(138) NewVar(gvsae); New String IntValue(165) NewVar(gvsBullet); 2. Compatibility Mode, PlatformEncodingMode = True: New String IntValue(228) NewVar(gvsae); New String IntValue(149) NewVar(gvsBullet); 3. UTF-8 Mode: New String IntValue(228) NewVar(gvsae); New String IntValue(8226) NewVar(gvsBullet); Punkt 1 ist dann nicht mehr notwendig, wenn - FrameScript für Macintosh nicht mehr unterstützt werden soll, - mindestens FrameScript 3.1 vorausgesetzt wird, - *nicht* die speziellen Zeichen anderer Codepages verwendet werden, die erst seit FM7.2p158 unterstützt werden (CE: 143S/x0179, RU: 129S/x0403, 143S/x040F, 144S/x0452) bzw. ausschließlich der Unicode-Mode unterstützt/erwartet wird. Theoretisch lässt sich eine Scriptdatei auch im UTF-8-Encoding speichern und die Strings uncodiert direkt verwenden - dies funktioniert dann aber natürlich nur im UTF-8-Mode und dürfte beim Posting, bei der Weitergabe und der Änderung von Scripts durch den Anwender unweigerlich zu Problemen führen. Seit einigen Wochen bin ich damit beschäftigt, die wichtigsten Scripts entsprechend (kompatibel) anzupassen - allerdings stellt sich heraus, dass diese Anpassung (bei 150 Scripts) doch ziemlich aufwendig ist. Es wird also noch eine geraume Zeit dauern, bis die itl-Scripts mit FrameMaker 8 und FrameScript 5.1 fehlerfrei funktionieren ... Schöne Grüße, Klaus _______________________________________________ Talk mailing list [email protected] http://lists.framemaker.de/mailman/listinfo/talk
