What is and how to use the Intelligent Text?

Intelligent text allows data to be automatically extracted from the Design, Catalogue or Drawing databases and entered on a Drawing. Intelligent text uses codewords, which all begin with a # character.

The advantages of intelligent text are: 

• If the data in any of the three databases changes then when the Drawing is updated the correct new values will be automatically obtained and entered upon the Drawing. 
• You do not have to navigate through the relevant database, retrieve the data, return to the DRAFT database and enter the data manually. 
• The same text string with its embedded codewords can be used many times to generate text strings that are similar in format but different in detail.

The text strings where you can use intelligent text are:

DMTX dimension line text (of Dimension Points and Directions,

PLTX projection line text (i.e. ADIR, APPT, DPOI, DPPT, DPBA)

BTEX general text string of General Labels (GLAB) and Template (TXTM)

The codewords fall into one of six categories:

1. Codewords that access data associated with the Design or Catalogue element referenced by the DDNM attribute of the Drawing database element.
2. Codewords that access data associated with the Drawing database element that owns the text string.
3. Codewords that access dimensioning data.
4. Codewords that access UDA data.
5. Codewords that access administrative data. 
6. Codewords with special functions

Accessing Data from the DESIGN or Catalogue Databases

All DESIGN and Catalogue database attributes are accessible. For example, attribute
ABCD would be accessed by code #ABCD (or #abcd). In addition, any Design element can
be accessed. For example:

#SITE Name of site owning the referenced element
#BRAN Name of Branch owning the referenced element

PDMS pseudo-attributes may be accessed in the same manner.
The codewords for position attributes can be modified so as to provide only one of the coordinates. For example:

#POS full 3D position, e.g. W12250 N7890 U3120
#POSE Easting coordinate only, e.g. E12250, W9675
#POSN Northing coordinate only, e.g. N7890, S22150
#POSU Upping coordinate only, e.g. U3120, D250

All DESIGN database position attributes can be modified in this way. These are POS, HPOS, TPOS, NPOS, POSS, POSE, DRPS and DELP. Note that the codeword #POSE can have two meanings, depending on the context: for SCTNs it means the POSE attribute
(Section End Position), in other cases it means the Easting of the POS attribute.

The position codewords generate values in World coordinates. It is possible to generate values in the coordinate systems of other elements by the use of transform keywords.

Note: As an alternative to the standard ENU position format, positions can be output with +/- format by appending ‘+’ to the codeword. For example:

#POS full 3D position, e.g. W12250 N7890 U3120
#POS+ would give -12250 +7890 +3120

P-point Data

P-point data can be obtained by a codeword of the form:

#Pnxa Data from p-point n of element where

n = p-point number, or ‘L’ for leave p-point or ‘A’ for arrive p-point
x = POS, DIR, BOR, BOP, TOP or CON
a = blank, E, N or U (valid for x = POS, BOP or TOP only)

For example:

#P3BOR bore at p-point 3
#PLBOPU Upping of leave p-point BOP position
#P1POS position of p-point 1

Ppoint codewords can have an optional ^ delimiter between the p-point number and the attribute, for example:

#P2^POS

The delimiter is optional, but it must be used when the number is omitted, for example:

#P^POS

in which case the value from the NPPT attribute of the relevant piece of annotation will be used.

P-line Data

The P-line syntax may refer to the p-line used for annotation (i.e. that defined by the PKEY attribute) or to a specified p-line. A specific codeword defining the p-line precedes strings requesting position, direction and offset.
The syntax for p-lines is #PK (for PKEY). This syntax on its own is a request for the p-line name (e.g. NA or TOS, stored as the PKEY attribute). #PK may optionally be followed by the p-line name, for example #PKNA for p-line neutral axis. The p-line name (if present) may be 1-4 characters long. #PK may also be followed by MEML (i.e. #PKMEML) if data for the Section’s member-line is required. (This is only valid if the SCTN has its MEML attribute set.)

The p-line name ma #PK^DIR or #PKNA^POSSU

The last format would mean ‘Upping of Start position of Neutral axis p-line’.
The internal delimiter ^ is necessary to separate the p-line attribute from the p-line name. There is nothing to stop you from having p-line names such as NAPO or even DIR. Names such as these would be impossible to separate from the p-line sub-codeword without this delimiter. Spaces are not permitted between the codeword and sub-codeword.
The following sub-codewords may follow the p-line codeword #PK or #PKname:

^DIR p-line direction
^POSS p-line start position
^POSSE Easting of p-line start position
^POSSN Northing of p-line start position
^POSSU Upping of p-line start position
^POSE line end position 
^POSEE Easting of p-line end position
^POSEN Northing of p-line end position
^POSEU Upping of p-line end position
^PKDI position of point along p line defined by PKDI attribute
^PKDIE Easting of point along p-line defined by PKDI attribute
^PKDIN Northing of point along p-line defined by PKDI attribute
^PKDIU Upping of point along p-line defined by PKDI attribute

For example:

#PKNA^POSS gives the start position of the NA p-line
#PK^DIR gives the direction of the p-line given by the PKEY attribute

The #PK^PKDI keyword will extract the position along a p-line at which a Label is attached. This will generate the position defined by the PKDI attribute of the label. Thus if PKDI = 0 the Label will be positioned at the start of the p-line (defined by the PKEY attribute) and the start position will be generated. If PKDI = 0.5 it will be at the p-line’s mid-point and its midpoint
position generated.

Besides GLABs and SLABs, the VNOT, ADIM, DPPT, RPPT and PPPT elements also possess the PKDI attribute.

In DRAFT p-lines are always cut back by SCTN end-preparations and member-lines are always extended to the ‘working point’. The positions generated by these codewords reflect this functionality.

The transform qualifier may be used with any of these sub-codewords, but not for p-line name. For example:

#PKTOS^POSEU Gives the upping with respect to /DATUM of the end position of the TOS p-line
#PKTOS^POSEU+ As above, but gives upping in ‘+/-’ format
#DERPOS[a] Derived position of a Joint, Fitting or Secondary Node, where a = N for Northing, E for Easting, U for Upping (optional)

Accessing Data in Catalogue Datasets 

Data in a Catalogue Dataset is obtained by a two-part codeword of the general form:  #attribute^qualifier

For example: 

#PROPERTY^WIDTH obtain Property value of WIDTH dataset entry
#PRTITLE^WIDTH obtain Property Title of WIDTH dataset entry

The Property Default (PRDEFAULT) and Property Purpose (PRPURPOSE) settings can be obtained in a similar manner. In each case the first part of the codeword (i.e. PROPERTY etc) can be abbreviated to four characters.

PROPERTY values are evaluated as distances or bores if the PTYPE attribute of the relevant DDTA (or DDAT) element is set to DIST or BORE respectively.

Accessing Data from the DRAFT Database

All DRAFT (PADD) attributes are accessible. For example, attribute ABCD of the current annotation element would be accessed by code #ABCD. In addition the name of any DRAFT element can be accessed. For example:

#VIEW The name of the View owning the annotation element
#DRWG The name of the Drawing owning the annotation element

Attributes of other DRAFT elements can be accessed using the FROM qualifier. For example:

#AUTH Generates the Author of the Drawing owning the annotation elements

The following special codewords are also available:

#DTITL Drawing title, equivalent to #TITL
#STITL Sheet title, equivalent to #TITL
#VTITL VIEW title, equivalent to #TITL

Special functionality is provided for the following codewords that extract revision data:

#APPR Approve
#APDT Approval date
#RVSN Revision
#RVDT Revision date
#RVAU Revision author

These codewords extract their data from the first REVI element in the Sheet’s list. If the qualifier is appended then data will be extracted from the first REVI element in the Drawing’s list. To extract data from a specific REVI element a qualifier should be used. The REVI element can be specified by name, for example: #RVAU or the pseudo-reference array attributes SREVAY and DREVAY can be used. For example:

#RVDT Generates the revision date from the sheet's second revision
#APPR Generates the approver from the drawing's third revision

Accessing Dimensioning Data

Codewords that are allowed values for the Dimension Line Text (DMTX) and Projection Line Text (PLTX) of Angular and Linear Dimensions (ADIM and LDIM) and Dimension Points/Directions (ADIR, APPT, DPOI, DPPT, DPBA) and have special meanings:

#DIM Calculated dimension value (DMTX or PLTX)
#DEF Use default text string supplied by owning ADIM or LDIM (Must appear alone in a text attribute, e.g BTEX ’#DEF’ is valid, ’name #DEF’ is not.)
#DIR Projection line direction (of ADIR)

The following codewords are valid in the PLTX of LDIMs and their members, and cause the 3D Dimension Point position to be generated in World coordinates.

#DIMPOS 3D position
#DIMPOSE, #DIMPOSN,#DIMPOSU Easting, Northing, Upping, respectively
#DIMPOSDD Coordinate in the Dimension Direction of the 3D Dimension Point position

For example, if the Dimension Direction is North, the Northing of the Dimension Position will be output - i.e. exactly the same result as #DIMPOSN. If the Dimension Direction is not orthogonal, the full 3D position will be output (i.e. as would be generated by #DIMPOS) together with error message

64,399: /ldim-name: Dimension direction not orthogonal, so unable to calculate single coordinate for codeword #DIMPOSDD

These codewords may be used in conjunction with the WRT qualifier to generate relative positions.

At a DPOI which has POS and optionally DDNM attributes set, #POS will always obtain data from the element referenced by DDNM. #POS will only obtain data from the POS attribute setting if DDNM = 0/0. Hence you should always use #DIMPOS to generate the coordinates of DPOI elements.

Accessing UDA Data

For those that extract (UDA) data from the database. The codewords to access Userdefined attribute (UDA) data have the format: #:uda_name

For example:
#:UDA1

All relevant qualifiers that apply to ordinary codewords may also be applied to UDAs. The output of data follows a format similar to that used by existing UDA queries. Real UDA may have distance or bore units and will be reported as such.

Accessing Administrative Data

Codewords relating to administrative data are:

#ADATE Date: format mm/dd/yyyy, e.g. 09/30/1998
#BDATE Date: format dd/mm/yyyy, e.g. 30/09/1998
#CDATE Date: format dd mon yyyy, e.g. 30 Sep 1998
#ADATEX Date: format mm/dd/yy, e.g. 09/30/98
#BDATEX Date: format dd/mm/yy, e.g. 30/09/98
#CDATEX Date: format dd mon yy, e.g. 30 Sep 98
#DFDATE Date: format specified by the DATEFOrmat attribute of the DEPT above the current element.
#TIME System time: format hh:mm:ss, e.g. 09:07:57
#SYSUSE current user’s System Name
#PROJECT^NUMBER Project number
#PROJECT^NAME Project name
#PROJECT^DESCRIPTION Project description
#PROJECT^MESSAGE Project message
#PROJECT^CODE Project code

DEPT and LIBY elements have a DATEFOrmat attribute. It controls the format of the values of DATE (of DRWGs) and RVDT (of REVIs) attributes which are automatically generated. DATEFOrmat may be set to:

DDMMYYYY which gives a format equivalent to ADATE
DDMMYY which gives a format equivalent to ADATEX
MMDDYYYY which gives a format equivalent to BDATE
MMDDYY which gives a format equivalent to BDATEX
DDMONYYYY which gives a format equivalent to CDATE
DDMONYY which gives a format equivalent to CDATEX

Codewords with Special Functions

Template Codeword

#T/name is the Template codeword, which enables complex text strings to be defined once in a Text Template (TXTM element). This template may then be referenced from other elements.

name refers to a text template TXTM. For example:  #T/TEM24

#T may be used in PLTX or DMTX attributes of Dimensions or Dimension Points, or in the BTEX attribute of Labels (GLAB or SLAB) or text primitives (TEXP).
The codeword #T/name must be the only content of the text string. The referenced text string may contain intelligent text codeword strings. However the BTEX attribute of a TXTM cannot itself contain a #T codeword since this could lead to recursion.

Tab Generator Codeword

#n is the tab generator codeword, where n is the number of the column where the next character is to be output.
The tabbing codeword controls tabbing, taking the form #n, where n is the number of the column where the next character is to be output. For example:

#NAME#24#CATR output NAME, then output Catalogue Reference starting in column 24

The blanks in the output character string will be padded with spaces. For example: ’ABC#10DEF’ would appear on a drawing as ABCvvvvvvDEF (where v is used here to denote a space). The string ’#NAME#15#CATR#25#CREF’ would expand (typically) to /PUMP1/NSvvvvv/NFJJvvvvv/PIPE1-1

If the number specified is already exceeded by the length of the output character string then a single space will be inserted. For example: ’#NAME#5#CATR#10#CREF’  would expand to /PUMP1/NSv/NFJJv/PIPE1-1

Tabbing will take account of linefeeds within the text string, whether specified explicitly or by the new line generator code ’#/’. Hence ’#5#NAME#/#8#CATR#/#8#CREF’ would expand to

vvvv/PUMP1/NS
vvvvvvv/NFJJ
vvvvvvv/PIPE1-1

The use of this feature in combination with a fixed-width font (e.g. style 6 or 7) allows you to arrange text neatly in a tabular form. Used in combination with Autotagging and the PDMS Programmable Macro Language (PML), it is possible to generate schedules on drawings easily.

New Line Generator

The codeword #/ generates a new line.

# Character

The codeword ##outputs a single # character.

Underlining

#< start underline
#> finish underline

When a GLAB text string has been underlined, GBOX should be set to zero in order for the leaderline to meet the underline.

Emboldening and Italicising

%B use the Bold style of the current font
%b turn off the Bold style of the current font
%I use the Italic style of the current font
%i turn off the Italic style of the current font

The codes above apply only to intelligent text rendered using a TrueType font. They are not treated as codewords when the PDMS font is in use. If one of the above codes is used, when the corresponding style is already set as requested by the codeword, it is not treated as a codeword.

The TrueType font assigned to the element can be set upfront as Bold or Italic without having to use the above codes in the string, when selecting a True Type font from the selection form:

 

Substrings

There are two methods of specifying that a substring of the data associated with a code word is required for output.

String Definition by Characters

Substrings can be extracted from text by following the code word with a substring descriptor of the form:
(Cn1:n2)
where C indicates that n1 and n2 refer to character positions and n1 and n2 are integers that indicate the leftmost and rightmost character positions of the substring respectively; if n1 is omitted then 1 is assumed by default, and if n2 is omitted then the last character of the string is assumed. For example:
If #PIPE expands to ‘/ZONE-4/PIPE-6’ then #PIPE(C2:6) expands to ‘ZONE-’
By default all PDMS names will be output with the initial slash. If you do #PIPE(C2:) expands to ‘ZONE-4/PIPE-6’

Substring Definition by Parts

You can define a substring by reference to the constituent parts of the original string. A part of a string is defined by delimiters, which are user-definable.
The substring required is specified by following the code word with a substring descriptor of the form: (P-n1:n2)

Here P indicates that n1 and n2 refer to delimiter numbers and ‘-‘ indicates the character used as the delimiter. If omitted, ‘/’ is assumed. The delimiter must not be numeric.
n1 and n2 are integers that indicate respectively the delimiter numbers at which the substring is to start and finish; the delimiter before n1 is always included in the output substring but the delimiter after n2 is always excluded. If n1 is omitted then the substring will start at the beginning of the ‘parent’ string, and if n2 is omitted then the substring will end at the end of the ‘parent’ string. The start and end of the ‘parent’ string are always assumed to be delimiters. For example:
If #PIPE expands to the parent string ‘/ZONE-4/PIPE-6’ then
#PIPE(P/2:) expands to ‘/PIPE-6’ and
#PIPE(P-:2) expands to ‘/ZONE-4/PIPE’
EIt is possible to append a number of substring definitions (both character type and part type) to a code word. These are processed sequentially, left to right. Any number of substring definitions is allowed. For example:
#PIPE(P2:)(C2:) expands to ‘PIPE-6’
There is a special form of the substring descriptor,
()
This is shorthand for (C1:)

This form can be used for putting codewords back to back in a text string where the other codeword delimiters are not suitable, for example, when a space is not required between codeword data. For example:

#POS #NAME would, when expanded, have a space between the two data items:
#POS()#NAME would not.

Array Indexing

The format used for the array indices is:
[n] or [n,m]
where n and m are integers and m is greater than n. The first format generates a single array element; the second generates a range of array elements. For example:
#CRFA[2]
#:ARRAY[4,6]
Embedded spaces are allowed within an array index but are not mandatory. In the second format, one of the integers may be omitted. Omission of the first integer implies n=1, and omission of the second implies m=K, where K is the significant length of the array.
Array indices may be used (where appropriate) with both basic codewords and UDA names.
Array indices cannot be used with text, position, displacement or direction attributes. Components of position attributes (Eastings, Northings and Uppings) should be extracted using the special codewords for that purpose (e.g. #POSU).
The length of an array attribute can be extracted and applied to a sheet using:
‘codeword[SIZE]’

SIZE may be abbreviated down to S and may be lower-case. The [SIZE] suffix may be used with any hash code-word for which array indices are valid.

Transforming Position/Direction Data

If qualified by a transform keyword, position and direction attributes will be reported in the coordinate system of the specified element. The qualifier may be used with any position or direction codeword, including those for p-points, P-lines and Structural derived attributes.

The qualifier uses the keyword WRT (‘with respect to’) to denote the coordinate system to be used. Lower case as wrt is also allowed; minimum abbreviation is W (or w).
WRT must be followed by a single parameter to define the coordinate system required. This parameter may be a word or name that specifies a Design element.
If a name is used, it must not contain the comma (,) or closed angle-bracket (>) characters.
For example:
#P1POS
This will output the position of p-point 1 of the DDNM element with respect to element /1201A. The word parameter may either define an element type or a reference attribute, for example:
#POS
#POSU
If an element type is specified, it must refer to an owner of the Design element specified in the DDNM attribute. This may be the immediate owner or an element in the database hierarchy above the DDNM element.
If a reference attribute is specified, it should refer to a reference attribute of the DDNM element, for example OWNE or CREF. The reference attribute may also be a UDA

Individual components of reference array attributes may also be used:

The default coordinate system is the Design World - i.e. the implied syntax is:

The qualifier ‘CE’ must be used to refer to the coordinate system of the current element. For example, to report the position of P3 of a Box with respect to the Box origin:
#P3POS
Only position, direction, displacement and orientation codewords may have transform qualifiers. This includes some P-line and p-point attributes.
When outputting a qualified position in +/- format, the ‘+’ must appear before the qualifier, for example:
#P1POSU+

Extracting Attribute Data from any Specified Element

Attribute data may be extracted from any element rather than the element defined by the DDNM attribute. This element may be specified by name, element type or reference attribute.
The keyword for this navigation qualifier is FROM (or from), which may be abbreviated to F(or f). This keyword may be followed by one or more parameters separated by spaces:

The format for each parameter is the same as that for the transform qualifier (WRT), i.e. element name, element type or reference attribute. For example:

#POS<FROM /VESS1>	Outputs the position of /VESS1 (in World coordinates)
#POSE<FROM SITE>	Outputs the Easting of the Site above the DDNMelement
#DTXR<FROM TUBE>	Outputs detailing RTEXT for the implied Tube associated with the DDNM element.
#HBOR<FROM CREF>	Outputs the HBOR of the Branch referred to by the CREF of the DDNM element
#SPRE<FROM :fred>	Outputs the SPRE of the element referred to by the :fred attribute of the DDNM
#PARA[3]<FROM SPRE CATR>	Outputs value of third array element of relevant PARA attribute from referenced catalogue Component.
#PARA[3]<FROM /VCHJJ>	Outputs value of third array element of relevant PARA attribute from referenced catalogue Component.
#DUTY<FROM CRFA[2]>	Outputs the DUTY of the Branch referred to by CRFA[2]

The first three examples refer explicitly to elements by name or type. The next three contain reference attributes of the current element, the referenced element being accessed. The last is a reference array attribute and must be followed by an array index.

More than one navigation parameter may be used to enable compound navigation to acces <FROM CRFA[2] OWNE>

means data from the owner of the element referred to by CRFA[2].

#MTXZ Outputs the ZTEXT relevant to the implied tubing of /VALVE1.

The order of parameters is important:

These two FROM keyword formats do not have the same meaning. The first means the owner of the element specified by the CREF attribute and the second means the element specified by the CREF attribute of the owner.
Up to five parameters may be used. A complicated case might be:

This means that data is to be extracted from the third element referred to in the UDA reference attribute ‘:UDARR’ of the owner of the CREF element of the owner of the current Design element.
The starting point for navigation is the current element. This is normally the current Design element, as referred to by the DDNM attribute of the annotation element. However where the codeword obviously refers to annotation data (for example #AUTH, #TITL refer to AUTH and TITL attributes in the DRAFT database), navigation is from the annotation element.
It is possible to apply both navigation and transform qualifiers. For example:
#POS
Note that the navigation qualifier is always applied before the transform qualifier, whatever the order of syntax. For example:
#POS
Here, the position of /EQUIP will be output in the coordinate system of the ZONE which owns /EQUIP, rather than the Zone of the DDNM element.
If the navigation qualifier is omitted, the appropriate current element is usually used for data extraction. However certain codewords extract data from a specific element type rather than from the current element. An example of this is #PRFL. Data is extracted from the PRFL attribute of the SUBS element which owns the current element.
Standard Codewords such as #BRAN and #DRWG are equivalent to #NAME etc.
Pseudo- reference attributes can be used within codeword navigation qualifiers. For example #XXXX will extract the data for attribute XXXX of the element referenced by attribute SPREF of the current Design element. (Note that SPREF is a
pseudo-attribute of NOZZ as well as being a standard attribute for all Piping Components.)

Distance, Position and Bore Data Output

General
The format of distance, position and bore data generated by codewords is controlled by the UCOD attribute of the Layer element.
All intelligent text codewords generate the same format for ‘FINCH’ and ‘FINCH US’ units (as set in the UCOD attribute of the Layer):
UCOD FINCH DIST set distance units to ‘PDMS style’ feet and inches, e.g. 5’5.13/16
UCOD FINCH US DIST set distance units to ‘USA style’ feet and inches, e.g. 5’-5 13/16”
UCOD INCH BORE set bores in inches
UCOD CM DIST set distances in centimetres
UCOD CM BORE set bores in centimetres

FINCH (PDMS): 25’3.1/2
FINCH US: 25’-3 1/2”

The INCH option may be qualified to allow different formats for distance, position, and bore values generated by intelligent text codewords. These are:

INCH USA output of the form: 1/2” or 1 1/2” or 24
INCH PDMS output of the form: 0.1/2 or 1.1/2 or 24
INCH DECIMAL output of the form: 0.5 or 1.5 or 24.0

If the qualifier is omitted then DECIMAL is assumed.
A nominal/actual qualifier is available for bores. For example
UCOD FINCH PDMS BORES ACT
UCOD FI US BO NOM
The setting is NOMINAL by default. The UCOD setting controls the bore sizes output to a drawing by DRAFT’s intelligent text system. The two qualifiers have exactly the same effect as the general PDMS PRECI BORE NOM (or PRECI BORE ACT) commands.
UCOD settings can be queried by using the pseudo-attributes:
Q UCODD and Q UCODB

Mixed Units within Intelligent Text Strings

The units used in intelligent text strings are determined by the UCOD attribute of the owning LAYE. However, it is possible to insert a ‘switch units’ code in the text string, which will cause all distances and bores which follow to be output in ‘alternate’ units, as defined below.

Layer Units	Alternate Units
UCOD INCH DECI	MM
UCOD INCH PDMS	MM
UCOD INCH US	MM
UCOD FINCH PDMS	MM
UCOD FINCH US	MM
UCOD MM	INCH DECI
UCOD CM	INCH DECI
UCOD METRE	INCH DECI

The ‘switch units’ code is %U so, for example, to generate a dimension in both Imperial and metric units, with the second value in brackets, the intelligent text string:
’#DIM() %U(#DIM())’
should be used. The units may be switched back to the standard units by a subsequent use of a %U code.   

Controlling the Precision of the Generated Output

The precision of both linear and angular data is controlled by the Precision Code (PCODE) attribute. PCODE is an attribute of the DEPT, REGI, DRWG, LIBY, SHLB, OVER and LAYE elements, with its value being cascaded down the database hierarchy. PCODE stores four values of precision for metric (decimal) values, Imperial decimal values, imperial fractional values, and angles. By default, these four values are 0 (dp), 1 (dp), 32nds and 1 (dp) respectively. (dp = decimal places.)

The following are examples of setting PCODE:

PCODE LIN MM TO 2 DPLS Set linear (metric) precision to two decimal places
PCODE LIN IN TO 2 DPLS Set linear (Imperial) precision to two decimal places
PCODE LIN FRA TO 32 NDS Set linear (Imperial, fractional) precision to 32nds
PCODE ANG DEG Set angular precision to nearest whole number of degrees
PCODE ANG TO 2 DPLS Set linear angular precision to two decimal places

Angles output in degrees, minutes or seconds will be in the standard format (i.e. using °, ’ or ”). Angles output in the decimal format will have no symbols. If required a ° symbol can be accessed from DRAFT’s alternative character set by using the code ~0.
Data output in metre or centimetre format will be to the precision specified by the PCODE MM option. Thus if the MM precision is set to 1 dp, output will be set to 4 dp for metre output and 2 dp for centimetre output.
Four pseudo-attributes exist to allow the querying of the individual parts of the PCODE attribute:

Q PCODMms query metric (mm) precision
Q PCODInches query Imperial (inch) precision
Q PCODFractions query fraction precision
Q PCODAngles query angle precision

Position Output Formats

Marine users do not use the ENU (East North Up) coordinate system. Instead they use the ship reference coordinate system or the XYZ format to describe the position of design model objects. The same coordinate system is used through a particular layer.
To control the output formats of the positional codewords, attributes POSFOR (positional code word format) and GRSYS (grid system) are provided for the following PADD data elements:

DEPT REGI DRWG SHEE VIEW LAYE LIBY SHLB OVER DRTMLB DRTMPL SHTMPL

These two attributes control the output format of the positional codewords that request the position of certain elements (e.g. #POS, #P2POS, #PKNA^POSS, #PKTOP^POSE).

POSFOR (Positional Code Word Format) Attribute

This attribute specifies the output format for the positional codewords used by elements owned by the layer (LAYE).
The following values are defined for the attribute:

Value	Test equivalent (query system)	Description
0	ENU	Default ENU output style (e.g. ‘E 1000’, ‘S 2000’)
1	XYZ	The XYZ output style (e.g. ‘X=1000’, ‘Y=-2000’)
2	SHIP	Ship reference coordinate format (e.g. ‘X=FR20+200’,‘Y=LP-5’, ‘Z=DECK02+1500’)
3	NUM/BERS	Numerical output style (e.g. ‘1000’, ‘-2000’), as if the ‘+’ suffix was present in the code word

If the project does not define the FR or LP positions along one or more of the axes, the request for a corresponding coordinate expressed in the Ship Reference System will return instead the coordinate expressed as a pure number in millimetres, as if the XYZ expansion had been requested (e.g. X=FR40, Y=LP4, Z=5000).
The value of the attribute will cascade down from the DEPT or LIBY element to their child elements when they are created.
If the ‘+’ modifier follows the position code word (e.g. #POS+), it overrides the expansion format setting defined by the LAYE, requesting a purely numerical output (NUMBERS format). Other than using the ‘+’ suffix, there is no other way to override the expansion format individually for a given code word. However, a separate LAYE with different settings can be created, and the element using intelligent text placed there.

Example:
POSFOR SHIP
sets the output format for positional codewords to ship reference coordinate format.

GRSYS (Grid System) Attribute

This attribute specifies the grid system to use during a search for the ‘nearest’ GRIDLN element, when generating the output from positional codewords used by elements whose POSFOR attribute has a value of 2 (Ship Reference System). If the POSFOR attribute has a different value, the GRSYS attribute is ignored. If the search for the GRIDLN element fails (no suitable grid lines), the XYZ output is generated instead.

The value of the attribute will cascade down from the DEPT or LIBY element to their child elements when they are created.

Example:
GRSYS NULREF tells DRAFT to use all available grid systems with the default orientation (0, 0, 0) and the purpose SHIP when searching for the nearest GRIDLN element
GRSYS /RO-RO tells DRAFT to use the grid system /RO-RO exclusively when searching for the nearest GRIDLN element.

Customizing Error Text

When it is not possible to extract data from an attribute, the intelligent text system returns an error and (by default) substitutes the text ‘---’ for the missing data. The NTEXT attribute allows you to substitute your own ‘null text’. For example:
NTEXT ’No data’
NTEXT may consist of up to 12 characters. It is an attribute of DEPT, REGI and DRWG. LIBY, SHLB, OVER and LAYE elements, and its setting will be cascaded down the hierarchy.

Intelligent Text Syntax - Summary

The combined format for a codeword string may be summarised as follows:

(The + signs are not literal.) All components except the first are optional. The substring editing qualifiers may appear more than once in any order. Some combinations have no meaning. All qualifiers may contain embedded spaces; therefore the closing delimiters cannot be omitted.
The combined format for the data qualifier list is:

Examples of Codeword Strings 

#POS position of owner in Site coordinates
#CRFA[2] name of second element of CRFA attribute of /VFWA1
#HREF(P/2:3) parts 2 and 3, delimited by '/', of the HREF of the owner
#PKNA^POSE end position of P-line NA in framework coordinates
#PK^POSSE Easting of P-line start position in world coordinates. The P-line name has been omitted, meaning the P-line used to position annotation
#POSE At a SCTN this means the POSE attribute, otherwise it means the Easting of the POS attribute
#OWNE owner of element 2 of CRFA attribute
#NAME name of element specified in :udarr[2] of element specified in CREF
#:FRED[3] array element 3 of UDA attribute :FRED of the owning Equipment.
#T/T24 use the value of the BTEX attribute of text template /T24
#DTXR detailing RTEXT from the implied rod of the current element
#VRAT[1] to #VRAT[1] outputs VIEW scale as a ratio, as specified by the VRATIO attribute. 

Notes

In the codeword descriptions given in this section, the words ‘owner’ or ‘owning’ (enclosed in quotes) refer to the element of the type described equal to or above the referenced element in the database hierarchy - not necessarily the true owner. Where the word owner appears (unenclosed by quotes) then this means the true owner.
General points:

• All text strings have a maximum length of 120 characters in unexpanded form, 180 characters in their expanded form.
• Lower case and upper case (but not mixed case) forms of all codewords are valid.
• When a piece of text generated from a # code word itself contains a # code (or a ~ code or % code then this code is not expanded unless the original piece of text comes from either a DRAFT or DESIGN database text attribute or a text user-defined attribute (UDA) from any database

 

 

 

 

 

 

Drawing World Hash Codes

#DTITL	Drawing title
#STITL	Sheet title
#VTITL	VIEW title
#DRWG	Drawing name
#DIMPOSa	3D Dimension Point position, where a = N, E or U
#AUTH	Author (of DRWG or SHEE)
#ADATE  #BDATE  #CDATE	date of creation (of DRWG)
#APPR	approver
#APDT	date of approval
#RVSN	revision
#RVDT	date of revision
#RVAU	revision author