• Sie können vollständige Makros rückgängig machen bzw. wiederherstellen, aber Sie können Rückgängig/Wiederherstellen nicht innerhalb von Makros einsetzen.
• Folgendes können Sie nicht rückgängig machen bzw. wiederherstellen:
•  
  • Befehle mit Bezug zu Parametrik, verdeckte Linien, gerasterte Abbildungen, OLE oder in AI-Modulen definierte Befehle. Sobald Sie einen dieser Befehle ausführen, können Sie keinen der vorherigen Befehle rückgängig machen oder wiederherstellen.
  • Den Befehl RESET_SYSTEM.
  • Befehle für die Standardeinstellungen (obwohl sich diese Befehle nicht auf den Rückgängig/Wiederherstellen-Verlauf auswirken).

Vor Version 2007 verwendete Drafting unterschiedliche interne und externe Kodierungsschemen. Version 2007 verwendet nur Unicode-Kodierung.

Alle Daten aus Texten und Zeichenketten, die Drafting bearbeitet, werden intern in Unicode (UTF-8) kodiert. Die meisten Funktionen in Drafting bearbeiten somit Benutzereingaben in fast allen Sprachen. Zeichenkettendaten aus unterschiedlichen Sprachen können gemischt werden. Zum Beispiel kann eine einzige Zeichenkette, wie ein Teilename, jetzt deutsche, japanische und russische Zeichen enthalten.

Die Schriftartenliste in Drafting enthält alle TrueType-Schriftarten aus dem Betriebssystem, die bei Bezug dynamisch in interne Schriftartformate umgewandelt werden. Zur Darstellung von Texten und Bemaßungstexten muss eine entsprechende Schriftart ausgewählt werden, die alle gewünschten Zeichen enthält. Nur wenige Schriftarten enthalten Zeichen aus dem gesamten Unicode-Bereich. Ihr Name enthält normalerweise das Wort Unicode, z.B. Arial Unicode MS.

Symbole

Sonderzeichen sind eine spezielle Funktion von Drafting. Sie werden weiterhin durch hp_symbols und hp_symbols2-Schriftarten dargestellt. Sie können weiterhin aus den traditionellen Codefolgen bestehen (#14#XY#15). Um die Kompatibilität mit Unicode sicher zu stellen, werden sie jedoch jetzt einem eigenen Unicode-Bereich zugeordnet [E000-E1FF]:

• #14#XY#15 --> 0xE000 + XY
• #30#XY#31 --> 0xE100 + XY

MI-Dateiformat

MI-Dateien aus Version 3.20 sind jetzt in Unicode (UTF-8) kodiert. Dateien, die in älteren MI-Versionen gespeichert sind, werden kodiert wie gehabt, je nach dem aktuellen Gebietsschema.

Beim Laden von Dateien im MI-Format 2.90 bis 3.10 verwendet das Ladeprogramm von Drafting die Kodierungsinformationen, die im Abschnitt Info der MI-Datei gespeichert sind (~1), um die Dateiinformationen ordnungsgemäß darzustellen.

Drafting behandelt Dateien vor Version 2.90, die keine Kodierungsinformationen im Abschnitt Info enthalten, als wären sie in ROMAN8 (bei den meisten westlichen Gebietsschemen) oder in SJIS (Gebietsschema Japan) kodiert.

Makrodateikodierung

Frühere Makrodateien enthielten keine Kodierungsinformationen. Es wurde angenommen, dass sie im aktuellen Gebietsschema kodiert waren (z.N. ROMAN8 für Englisch und SJIS für Japan). Dies führte jedoch zu Problemen, wenn das gleiche Makro in unterschiedlichen Gebietsschemen ausgeführt wurde.

Version 2007 unterstützt Unicode-Makros, ist jedoch weiterhin abwärtskompatibel.

Es wird empfohlen, alte Makrodateien so zu ändern, dass ihre Kodierung entsprechend der Richtlinie DEFINE_ENCODING eindeutig angegeben ist.

Textmakrodateien mit Unicode UTF-8 oder UTF-16 BOMs (Byte Order Markers, Bytereihenfolgemarkierungen), die von den meisten üblichen Texteditoren unter Windows unterstützt werden, werden als Unicode eingelesen.

Dateien mit der Richtlinie DEFINE_ENCODING werden immer in der angegebenen Kodierung eingelesen. Andernfalls werden sie als alte Makrodateien behandelt, die Kodierung hängt vom Gebietsschema ab:

• SJIS für Japanisch
• BIG5 für Chinesisch (traditionell)
• GB2312 für Chinesisch (vereinfacht)
• ROMAN8 für alle anderen

Einschränkungen

• CHR, NUM und # funktionieren weiterhin bei den alten, Gebietsschema-abhängigen internen Kodierungen (ROMAN8 & SJIS), und sie ergeben unterschiedliche Ergebnisse in unterschiedlichen Gebietsschemen. Zum Beispiel stellt ((CHR 154)+(CHR 223)) bzw. das entsprechende (#154#223) beim Gebietsschema Japan ein japanisches Zeichen mit dem Unicode-Code 22756 (hex 58E4) und bei anderen Gebietsschemen zwei lateinische Zeichen dar.
• Makros mit Funktionsaufrufen an CHR, NUM und # sollten überarbeitet werden, so dass sie die neuen Unicode-Funktionen UCHR, UNUM und #u aufrufen. Um zum Beispiel das Zeichen u als Umlaut darzustellen, verwenden Sie UCHR (220), UCHR('DC'), #u220 oder #uxDC. Die Funktionen CHR, NUM und # werden nur beibehalten, um Abwärtskompatibilität zu sichern.
• Kombinationen aus # und CHR zur Erstellung von 2-Byte-Zeichen und Symbolen sind nicht mehr zulässig. Zum Beispiel ist ((CHR 154)+#223) nicht möglich.
• Zeichenketten, die mit (CHR 255) beginnen, sind Symbole und nicht in UTF-8 kodiert. In Drafting-Versionen vor 2007 können Symbole mit vielen Kombinationen erstellt werden (zum Beispiel #255'abc'#212+CHR 12). Jetzt können Symbole nur mit CHRs erstellt werden.
• Die Verwendung von arithmetischen Funktionen wie POS und SUBSTR mit Symbolen kann zu seltsamen Ergebnissen führen.
• Die Symbol phi mit dem Code 49 (hex 31) kann auf zweierlei Weise definiert und angezeigt werden:
  • Unicode-Stil: TEXT #uxE031 oder TEXT #u57393
  • Über Codefolgen: TEXT #14#49#15
• Traditionelle Codefolgen werden intern in das neue Unicode-Format umgewandelt. Daher besteht die Zeichenfolge "s", definiert als "LET s (#14#49#15)", in früheren Versionen von OneSpace Drafting aus 3 Zeichen, in OneSpace Drafting 2007 jedoch nur aus einem Unicode-Zeichen. Aufgrund dessen ergab die Funktion "SUBSTR s 2 1" vor Version 2007 das zweite Zeichen dieser Zeichenfolge, ein Zeichen mit dem Code 49, während OneSpace Drafting 2007 eine leere Zeichenfolge ergibt, da die Zeichenfolge "s" aus nur einem Zeichen besteht. Sie müssen also Makros überarbeiten, die Teile eines Symbols extrahieren.
• Die arithmetischen Funktionen POS und SUBSTR erwarten jetzt Indizes der Zeichen statt Indizes zu den Bytes einer Zeichenfolge. Sie müssen Makros mit diesen Funktionen, die spezielle Behandlung japanischer Zeichenfolgen enthalten, also überarbeiten.
• Unicode-Texte werden nur eingeschränkt dargestellt. Funktionen wie kombinierte Zeichen, arabisch kursive Verbindung und bidirektionale Algorithmen sind nicht vollständig umgesetzt.
• MI-Dateien aus Versionen vor 2.90, die keine Kodierungsinformationen im Info-Abschnitt (~1) enthalten, werden nur ordnungsgemäß geladen, wenn das Gebietsschema beim Laden das gleiche ist wie das beim Erstellen. Es gibt zwei Möglichkeiten, eine japanische MI-Datei aus Version 2.80 in Drafting mit einem englischen Gebietsschema korrekt zu laden:

1. Laden Sie die Datei mit dem Gebietsschema Japan, und speichern Sie sie im neuen Format:
   1. CHANGE_LOCALE 'ja'
   2. LOAD 'Japanese.mi'
   3. STORE MI ALL DEL_OLD 'Japanese.mi'
   4. CHANGE_LOCALE 'en'
       
2. Laden Sie die MI-Datei in einem Texteditor, und fügen Sie manuell den Abschnitt ~1 am Anfang der MI-Datei ein:
   • #~1
   • ENCODING:SJIS
   • Solche Dateien werden unter jedem Gebietsschema ordnungsgemäß geladen.

• Schriftartdateien aus Drafting Version 2003 (Version 12.00) oder früheren Versionen enthalten keine Kodierungsinformationen. Nach dem Laden dieser alten Schriftartdateien müssen Sie also ihre Kodierung angeben:
•  
  • SET_FONT_ENCODING '<fontname>' '<encoding>' END

Setzen Sie die Kodierung auf:

• SJIS für Japanisch
• BIG5 für Chinesisch (traditionell)
• GB2312 für Chinesisch (vereinfacht)
• ROMAN8 für alle anderen

• AI-Module rufen interne Drafting-Funktionen auf und verwenden Zeichenketten mit interner Kodierung. Vor Drafting 2007 waren diese Zeichenketten in ROMAN8 oder SJIS kodiert, je nach Gebietsschema. Kompatibilität wird nur bei den Zeichen im Bereich gewahrt [0, 127]. Wenn AI-Module Zeichen in einem anderen Bereich verwenden, müssen sie geändert und neu kompiliert werden, um UTF-8 zu unterstützen.

In Drafting 2007 werden Dateinamen auf die gleiche Weise dargestellt wie bei anderen Anwendungen unter Windows. Vor 2007 wurden sie mit unterschiedlicher interner Kodierung dargestellt, abhängig vom Gebietsschema. Dateinamen wurden dementsprechend unterschiedlich dargestellt, wenn erweiterte Zeichen verwendet wurden.

Wenn die Option MEEXTFN in der .ini-Datei auf Null gesetzt wird, bleibt es beim alten Verhalten.