![]() |
Physical Layout |
<<< Logical Layout | Chapters | Model Structure >>> |
The XT common header recommended to Frustrum writers consists of:
The ‘part 1’ data is ‘standard’ information which should be accessible to the Frustrum (e.g. by operating system calls). It is the responsibility of the Frustrum to gather the relevant information and to format it as described in this specification.
SCH = SCH_m_n // name of schema key e.g.
USFLD_SIZE = m // length of user field (0 - 16 integer words) |
Applications writing XT data must use a schema name of SCH_3400000_34000
The ‘part 3’ data is non-standard information, which is only comprehensible to the Frustrum which wrote it. However, other Frustrum implementations must be able to parse it (in order to reach the end of the header), and it should therefore conform to the same keyword/value syntax as for ‘part 1’ and ‘part 2’ data. However, the choice and interpretation of keywords for the ‘part 3’ data is entirely at the discretion of the Frustrum which is writing the header.
All keyword definitions which appear in the three parts of data are written in the form
<name>=<value> e.g. MC=hppa;MC_MODEL=9000/710; |
<name>
consists of 1 to 80 uppercase, digit, or underscore characters
<value>
consists of 1 or more ASCII printing characters (except space)
Escape sequences provide a way of being able to use the full (7 bit) set of ASCII printing characters and the new line character within keyword values. Certain characters must be escaped if they are to appear in a keyword value:
The two character escape sequences may be split by a new line character as they are written to file. They must not cause any output lines to be longer than 80 characters.
Only those characters which belong to the ASCII (7 bit) printing sequence, plus the new line character, can be included as part of a keyword value.
XT has no knowledge of how data is stored. On writing, XT produces an internal bytestream which is then split into roughly 80-character records separated by newline characters ('
\n
'). The newlines are not significant.
As operating systems vary in their treatment of text data, on reading all newline and carriage return characters ('
\r
') are ignored, along with any trailing spaces added to the records. However, leading spaces are not ignored, and the XT data must not contain adjacent space characters not at the end of a record.
Text XT files written by version 12.1 and later versions use escape sequences to output the following characters, except for '
\n
' at the end of each line:
These characters are not escaped by versions 12.0 and earlier.
The flag sequence is the character ‘T’. This is followed by the length of the modeler version, separated by a space from the characters of the modeler version, similarly the ‘, finally the userfield size. For example:
T 51 : TRANSMIT FILE created by modeller version
17 SCH_3000000_30000 0 |
NB: because of ignored layout, what Parasolid would read is as follows:
T51 : TRANSMIT FILE created by modeller version 300000017 SCH_3000000_300000 |
For partition files, the modeller version string would be given as follows:
63 : TRANSMIT FILE (partition) created by modeller version 3000000 |
All numbers are followed by a single space to separate them from the next entry. Fields of type c and l are not followed by a space.
Logical values (0,1) are represented as characters F,T.
There are two special numeric values (-32764 for integral values, -3.14158e13 for floating point) which are used inside Parasolid to mark an ‘unset’ or ‘null’ value, and they are represented in a text transmit file as the question mark ‘?’. If a vector has one component null, then all three components must be null, and it will be output in a text file as a single ‘?’.
There are three types of binary file: 'bare' binary, typed binary, and neutral binary. They are distinguished by a short flag sequence at the beginning of the file. In all cases, the flag sequence is followed by the length of the modeller version as a 2-byte integer, the characters of the modeller version, the length of the schema version as a 4-byte integer, the characters of the schema version, and finally the userfield size as a 4-byte integer.
As with text files, there are two special numeric values (-32764 for integral values, -3.14158e13 for floating point) which are used inside XT to mark an ‘unset’ or ‘null’ value, and they are represented in the text XT data as the question mark ‘?’.
In bare binary, data is represented in the natural format of the machine which wrote the data. The flag sequence is the single character 'B' (for ASCII machines, '
\102
'). The data must be read on a machine with the same natural format with respect to character set, endianness and floating point format.
In typed binary, data is represented in the natural format of the machine that wrote the data. The flag sequence is the 4-byte sequence “
PS
” followed by a zero byte and a one byte, i.e., ‘
P
’ ‘
S
’ ‘
\0
’ ‘
\1
’, followed by a 3-by te sequence of machine description.
In neutral binary, data is represented in big-endian format, with IEEE floating point numbers and ASCII characters. The flag sequence is the 4-byte sequence "
PS
" followed by two zero bytes, i.e., '
P
' '
S
' '
\0
' '
\0
'. At Parasolid V9, the initial letters are ASCII, thus '
\120
' '
\123
'. The nodetype at the start of a node is a 2-byte integer, the variable length which may follow it is a 4-byte integer.
Logical values (0,1) are represented as themselves in 1 byte.
Small pointer indices (in the range 0-32766) are implemented as a 2-byte integer, larger indices are represented as a pair, thus:
where
op_short
outputs a 2-byte integer.
The inverse is performed on reading:
short q = 0, r; ip_short( &r ); if (r < 0) { ip_short( &q ); r = -r; } index = q * 32767 + r - 1; |
where
ip_short
reads a 2-byte integer.
<<< Logical Layout | Chapters | Model Structure >>> |