Introduction
Before version 2007, Drafting used different internal and external
encoding schemes. Version 2007 uses only Unicode encoding.
Now all textual and string data processed by OneSpace Drafting 2007 is held
internally in Unicode (UTF-8) encoding. That means most of Drafting's
functionality now processes user input from almost any language, and string data
from different languages can be mixed. For example, it is now possible to
have German, Japanese, and Russian characters within a single string, such as a
part name.
Drafting's font list contains all the OS true type fonts that are dynamically
converted to internal font format when referenced. An appropriate
font containing all desired characters must be selected to display
texts and dimension texts correctly. Fonts containing characters from the whole
Unicode range are relatively rare, and they usually contain the word Unicode in
their name (for example, Arial Unicode MS).
Symbols
Symbols are a special Drafting feature and are still displayed with
hp_symbols and hp_symbols2 fonts. They can still be composed in old-style escape
sequences (#14#XY#15) but for compatibility with Unicode are
now mapped to a private-use Unicode area [E000-E1FF]:
- #14#XY#15 --> 0xE000 + XY
- #30#XY#31 --> 0xE100 + XY
MI file
format
Version 3.20 MI files are now encoded in Unicode (UTF-8). Files stored to
older MI versions are encoded as before, depending on
the current locale.
When loading files with MI formats 2.90 to 3.10, the OneSpace Drafting 2007 loader uses the
encoding information recorded in the MI file's info section (~1) to display the
file's information correctly.
OneSpace Drafting 2007 treats files with MI formats prior to 2.90 without
encoding information in their info sections as if they are encoded in
ROMAN8 (for most Western language locales) or SJIS (Japanese locale).
Macro file
encoding
Old macro files did not contain any encoding information. They were assumed
to be encoded for current locales (e.g., ROMAN8 for English and SJIS for
Japanese). However, this caused problems when using the same macros in different
locales.
Version 2007 supports Unicode macros but maintains backward
compatibility.
We recommend that you change old macro files such that their encoding is
explicitly specified with the DEFINE_ENCODING directive.
Text macro files containing Unicode UTF-8 or UTF-16 BOMs (Byte Order
Markers), supported by most popular Windows text editors, are read as
Unicode.
Files containing the DEFINE_ENCODING directive are always read in the
specified encoding. Otherwise they are treated as old macro files and encodings
are locale dependent:
- SJIS for Japanese
- BIG5 for traditional Chinese
- GB2312 for simplified Chinese
- ROMAN8 for all else
Limitations
- CHR, NUM and # still work in old locale-dependent internal encodings
(ROMAN8 and SJIS) and return different results with different locales.
For example, ((CHR 154)+(CHR 223)) or its equivalent (#154#223) display a
Japanese character with Unicode code 22756 (hex 58E4) on a Japanese locale,
and two Latin characters on other locales.
- Macros with function calls to CHR, NUM and # should be reworked to call
the new Unicode functions UCHR, UNUM and #u. To display, for example, the
character u with an umlaut, use UCHR (220), UCHR('DC'), #u220, or #uxDC.
The functions CHR, NUM and # are only maintained for backward compatibility.
- Combinations of # and CHR to compose 2-byte characters and symbols are no
longer allowed. For example, ((CHR 154)+#223) does not work.
- Strings that begin with (CHR 255) are icons and are not encoded in UTF-8.
Pre-2007 Drafting versions let you compose icons using a large variety of
combinations (for example #255'abc'#212+CHR 12). Now only CHRs can be used to
compose icons.
- Use of arithmetic functions like POS and SUBSTR on icons can deliver
strange results.
- The phi symbol with code 49 (hex 31) can be defined
and displayed in 2 ways:
- Unicode style: TEXT #uxE031 or TEXT #u57393
- Via escape sequences: TEXT #14#49#15
- Old-style escape sequences are internally converted into the new Unicode
format. Therefore, a string "s" defined as "LET s (#14#49#15)" consisted of 3
characters in previous Drafting versions, but of only one
Unicode character in OneSpace Drafting 2007. Because of that, before version
2007, the function "SUBSTR s 2 1" returned the second character of the
string, which is a character with code 49, while OneSpace Drafting 2007
returns an empty string because string "s" consists of only one character.
Therefore you must rework macros that extract portions of a symbol.
- The arithmetic functions POS and SUBSTR now expect indices to characters
instead of indices to bytes in a string. Therefore you must rework macros
with these functions that included special handling for Japanese strings.
- The displaying of Unicode texts is limited. Features such as combining
characters, Arabic cursive connection, and bidirectional algorithm are not
fully implemented.
- MI files of versions prior to 2.90 that do not contain encoding
information in their info section (~1) now load correctly only if loaded in
the same locale as they were drawn. You have two options to correctly
load a Japanese MI file of version 2.80 in English Drafting:
- Load the file in the Japanese locale and store it back in new format:
- CHANGE_LOCALE 'ja'
- LOAD 'Japanese.mi'
- STORE MI ALL DEL_OLD 'Japanese.mi'
- CHANGE_LOCALE 'en'
- Load the MI file in a text editor and manually add section ~1 at the
beginning of MI file:
- #~1
- ENCODING:SJIS
- Such files load correctly in any locale.
- Font files from Drafting version 2003 (version 12.00) or before do not
contain encoding information. Thus after loading these old font files you
should explicitly specify their encoding:
-
- SET_FONT_ENCODING '<fontname>' '<encoding>' END
Set the encoding to:
- SJIS for Japanese
- BIG5 for traditional Chinese
- GB2312 for simplified Chinese
- ROMAN8 for all else
- Drawings created with OneSpace Drafting 2006 or earlier running on a
non-Japanese locale and using a 1-byte Katakana font will only load
correctly in OneSpace Drafting 2007 if the MI file's encoding is changed to SJIS.
- AI modules call internal Drafting functions and use strings in internal
encoding. Before OneSpace Drafting 2007 these strings were encoded in ROMAN8 or SJIS,
depending on locale. Compatibility is maintained only for characters in range
[0, 127]. If AI modules use characters in a different range, they must be
changed and recompiled to support UTF-8.
|
OneSpace Drafting 2007 does not distinguish between 1-byte and 2-byte fonts
(in terms of default settings or text properties). Because OneSpace Drafting
2007 has
Unicode support, there is just one current font at a time and each text and
dimension text has just one assigned font.
The following commands are now obsolete; their use
does not affect OneSpace
Drafting 2007's behavior:
- CURRENT_FONT_2BYTE
- CHANGE_TEXT_FONTNAME_2BYTE
- Option FONT_2BYTE in CURRENT_DIM_TEXTS
- Option FONT_2BYTE in
CHANGE_DIM_TEXTS
OneSpace Drafting 2007 includes new default fonts combined from the old 1-
and 2-byte definitions:
- osd_default combines hp_i3098_v, hp_kanj2_c, and hp_hangul_c
- osd_default2 combines hp_i3098_c, hp_kanj2_c, and hp_hangul_c
- osd_default3 combines hp_d17_v, hp_kanj2_c, and hp_hangul_c
When loading old 2D files with texts or dimension texts using characters
from 1- and 2-byte fonts (fonts that are not already included in any of the
osd_default fonts), OneSpace Drafting 2007 automatically combines the two fonts into a
single font containing the character definitions from both fonts. It names
them "1-byte font name#2-byte font name".
You can combine those fonts (1- and 2-byte fonts) into a single font
using a new command MERGE_TWO_FONTS.
TrueType fonts converted to Drafting fonts contain all defined characters.
Separate symbol fonts are still used.
Custom-made fonts may contain characters
that were defined in either an invalid range of the encoding or in a range
that translates to Unicode's Private Use Area (PUA) that is reserved for
Drafting symbols (0xE000 - 0xE1FF). We encourage you to change such
character positions in the font definition. If that is not possible, you can
remap your user-defined characters to a free area of the Unicode PUA
(0xE200-xF8FF) with the DEFINE_UDC_MAPPING command.
|
Translators call internal OneSpace Drafting 2007 functions and use strings in
internal encoding. In previous Drafting versions these strings were
encoded in ROMAN8 or SJIS, depending on configuration files' settings. For
example, the DXF/DWG translator used the "KanjiTranslate" ON/OFF switch,
which controls Kanji character translation. The DXF/DWG translator's
"KanjiTranslate" switch is now obsolete. DXF/DWF always writes UTF-8, and reads
UTF-8, UTF-16, Roman8, and SJIS.
OneSpace Drafting 2007 encodes translators' modules' strings in UTF-8. That
is, translators write the new MI format 3.20. Translators read all formats
-- UTF-8, Roman8, and SJIS. See the file formats and encoding
table for details.
The IGES2D translator cannot write strings as Unicode because the
current IGES format does not support Unicode. Thus, IGES2D always writes Roman8
or SJIS depending on configuration files' switches.
For example, to properly write IGES2D strings to SJIS, set the following in
the IGESo.con configuration file:
- String ** Product ID (sending system) : Japanese
- String ** Product ID (receiving system) : Japanese
Translators no longer differentiate between 1-byte and 2-byte fonts. There is
only one current font at a time, and each text and dimension text has only
one font (osd_default). The DXF/DWG translator includes settings for controlling
the font mapping from AutoCAD to Drafting fonts and vice versa. New
default fonts were added for proper font mappings.
- FontMapMItoACAD "osd_default" "txt.shx" 0.90 "" 0 1.666
- FontMapMItoACAD "osd_default2" "txt.shx" 1.07 "" 0 1.666
- FontMapMItoACAD "osd_default3" "simplex.shx" 0.95 "" 0 1.666
- FontMapACADtoMI "txt.shx" "osd_default" "osd_default" 0.90 1.666 1.3333
- FontMapACADtoMI "simplex.shx" "osd_default3" "osd_default3" 0.95 1.666
1.3333
OneSpace Drafting 2007 translators support storing to Unicode files
names.
File formats and
encodings |
This table shows which encodings OneSpace Drafting 2007 supports for use in
strings of various native and external file types.
Nr. |
Format |
Ext. |
Module |
Encoding 2006 |
Encoding 2007 (read) |
Encoding 2007 (write) |
Encoding 2007 (backwards)
|
1 |
Model Interface standard |
*.mi |
Drafting |
Roman8/SJIS |
UTF-8, Roman8, SJIS |
UTF-8 |
Roman8, SJIS |
2 |
Compressed MI |
*.bi |
Drafting |
Roman8/SJIS |
UTF-8, Roman8, SJIS |
UTF-8 |
Roman8, SJIS |
3 |
Initial Graphics Exchange Format
|
*.igs |
Iges2d |
Roman8/SJIS |
UTF-8, Roman8, SJIS |
Roman8, SJIS |
n/a |
4 |
Virtual Reality Modeling Language
|
*.wrl |
Vrml |
Roman8/SJIS |
n/a |
UTF-8 |
n/a |
5 |
Drawing Web Format |
*.dwf |
Dwf |
Roman8/SJIS |
n/a |
UTF-8 |
n/a |
6 |
Scalable Vector Graphics |
*.svg |
Dxfdwg |
Roman8/SJIS |
UTF-8, UTF-16, Roman8, SJIS |
UTF-8 |
n/a |
7 |
MI version <= 3.10 |
*.mi |
Drafting |
Roman8/SJIS |
Roman8, SJIS |
Roman8, SJIS |
Roman-8, SJIS |
8 |
AutoCAD DXF |
*.dxf |
Dxfdwg |
Roman-8/SJIS |
UTF-8, UTF-16, Roman8, SJIS |
UTF-8 |
n/a |
9 |
AutoCAD DWG |
*.dwg |
Dxfdwg |
Roman-8/SJIS |
UTF-8, UTF-16, Roman8, SJIS |
UTF-8 |
n/a |
Key
- Format: File format type.
- Ext.: File extension for this file format.
- Module: Application module in which this file
format is used/supported.
- Encoding 2006: Encoding used in OneSpace
Drafting 2006 for strings in files of this file format.
- Encoding 2007 (read): Supported string
encodings in OneSpace Drafting 2007 for this format when reading
files.
- Encoding 2007 (write): String encoding used
in OneSpace Drafting 2007 when writing files of the given type.
- Encoding 2007 (backwards): String encoding
used in OneSpace Drafting 2007 when writing files of the given
type in backwards-compatible mode, i.e., in OneSpace Drafting 2006
format.
|
© CoCreate
Software GmbH. All Rights Reserved. |
|