Structure of a plotter file

Both the described syntax and the text file where it is used will be called plotter layout or just layout.

A typical layout [layout] contains from one to several pages [page] of description of a plotter drawing.

The page [page] description specifies only:

Page attributes: paper format in millimeters (global length unit) and margins that determine the working area on a page.

Position, size and other attributes of rectangular fields called view-ports [views], where drawings will be located. The view-ports may contain additional texts (to be tackled below). Such texts should be located near the border of a view, for its center will be filled with a drawing.

Tables [table], organized in rows [row], consisting of cells [cell] that are, in turn, usually filled with texts [text].

Position and attributes of texts [text]. The text to be included in a drawing may be defined as a simple character string enclosed by quotation marks ("…"), or as the so called expressions, listed in the drawing module. Expressions have their own syntax. They may take the form of a date, project name, etc. They may also take more complex forms, depending on the contents of drawings on a page, e.g. drawing scale in a view, weight/mass of reinforcing steel in a beam/span, etc.

Example:

The below presented example is an extract from actual layouts to be found in the Robot configuration file folder. It contains a description of an RC beam drawing.

# Lines that begin with this sign belong to commentary.

# Commentary may of course be inserted with an indent.

# Commentaries at the beginning of a file should contain a short characteristics of the file contents.

# Here is an ideal header:

# Beam drawing (each span in a new page):

# single span + two sections + reinforcement list

# Table (containing data typical for RC) in the bottom part of a page

# (Recommended format - A4)

[LAYOUT]

[page]

format = 297, 210 # paper format

margins = left 7, right 7, bottom 7, top 7

[view]

label = @elev # label @elev, used in text expressions

pos = 3, 97 # lower-left corner: 3mm from left, 97mm from bottom

size = 213, 95 # size: 213x95mm

type = "beam/bay" # single beam span

[view]

label = @sec1 # label of the first section

pos = 3, 29

size = 105, 65

type = "beam/bay/section"

[view]

label = @sec2 # label of the second section

pos = 111, 29

size = 105, 65

type = "beam/bay/section"

[view]

pos = right 0, top 0 # upper-right corner: 0mm from right, 0mm from top

size = 65, 169

type = "beam/bay/steel" # reinforcement list in a beam span

[table]

pos = 0,0

# even if the user changes the paper format, he should maintain

# left and right margins (here: zero) and height of entire table

fixed = left right, vertical

# first, you should determine the width of successive table columns

col = 100

col = 100

col = 83

# now, you should describe each row

[row]

row = 4 # you should determine the row height

# you can describe cells in every row

[cell]

colspan = 2 # 2 columns are merged in this cell

[text]

pos = 3,50% # 3mm from the left and at mid-height

font = height 2 # font height 2mm

text = "Firm"

[text]

pos = 25%,50% # at 1/4 of the entire distance from the left and at mid-height

font = height 2

text = "Address"

[text]

pos = 65%,50%

font = height 2

text = "Telephone"

[text]

pos = 82%,50%

font = height 2

text = "Fax"

[cell]

rowspan = 2 # 2 columns are merged in this cell

[text]

pos = 3,top 25% # 3mm from the left and at 1/4 of the entire height from the top

font = height 2

# Below you can see an example of a text expression, where:

# periods - function as operators merging texts into one text

# @elev - object that will be required to perform

# a service (this is a label of a view-port on the page)

# "steel" - first argument on the list always

# determines the type of service (here: steel weight).

# The form (inscription/number) of the following arguments depends

# strictly on the type of service.

# NOTE:

# Listing the sub-expression @elev(...) may end in failure. Then, the entire expression

# fails and, as a result, you obtain an empty string, and not

# "Ribbed steel = kg", or "Ribbed steel = 0kg"

text = " Ribbed steel = " . @elev("steel","kg","L") . "kg"

[text]

pos = 50%,top 25%

font = height 2

text = "Concrete = " . @elev("concrete","m^3") . "m3"

[text]

pos = 3,bottom 25%

font = height 2

text = "Plain steel = " . @elev("steel","kg","T") . "kg"

[text]

pos = 50%,bottom 25%

font = height 2

text = "Formwork = " . @elev("formwork","m^2") . "m2"

[row]

row = 5

[cell]

rowspan = 3

[cell]

rowspan = 3

[text]

pos = 3,bottom 25%

font = height 5

text = "Section " . @elev("section","cm","x")

[row]

row = 9

[cell]

[text]

pos = 3,top 25%

font = height 2

text = "Lower cover " . @elev("cover","cm","B") . "cm"

[text]

pos = 3,bottom 25%

font = height 2

text = "Lateral cover " . @elev("cover","cm","L") . "cm"

[text]

pos = right 25,50%

font = height 5

text = ""

[row]

row = 9

[cell]

[text]

pos = 3,top 25%

font = height 2

text = "Elevation scale " . @elev("scale","m/m","/")

[text]

pos = 3,bottom 25%

font = height 2

text = "Section scale " . @sec1("scale","m/m","/")

[text]

pos = right 25,50%

font = height 4, aspect 0.7

text = "Page"

[end]

Concluding remarks:

The keywords are always in English. The same rule applies to services ("scale", "steel", "section", etc.). In both cases, the program is not case sensitive. It is possible to use abbreviations in keywords, e.g. "Pos" meaning "position".

Each page in a layout has always got a size. It does not mean that a page may only be used for the determined paper format. The drawing module will enlarge/reduce a layout page proportionately to the current configuration of the printing device (printer/plotter). However, if you create a layout that will be used for different paper formats, it is recommended to define it for the smallest but still feasible paper format.

A layout has a hierarchical structure, based on the parent-child/children dependence. The position and size of a child element is always expressed with respect to its parent element. Standard positioning of a (lower-left edge of a) child is performed with respect to the left page side and to the bottom of its parent, unless the relevant command says otherwise, e.g. 'pos = right 3, 50%'. While determining the position and size of a child, you can use absolute numbers (interpreted as millimeters) or percents of the parent size in the relevant direction (selection of one of these manners is significant in case of paper format modification).

Objects can be divided into those that have dimensions (represented as rectangular shapes) and those without dimensions (at present, there is only one: text). They can be called, for short, 1D-objects and 2D-objects. In the case of parents that have both types of child objects, you need to specify the dimensionless children first, and only then continue to list the spatial objects.

[page], [area] and [cell] can contain both types of objects, while [view] - only 1D-objects. Obviously, cells [cell] belong exclusively to table rows, while pages [page] - exclusively to a layout [layout].

Attributes (position, size, etc.) are assigned to object by means of relevant commands that are written directly after the keyword - in square brackets […] - opening the definition of an object.

A table [table] may be assigned the attribute of orientation. It is done by means of the command: 'orientation = ...'. In standard configuration, tables "stand", i.e. the program accepts the default command 'orientation = top'. If you would like, for instance, to situate a table along the right page edge, you should write 'orientation = left'.

The above presented example does not illustrate the possibilities of defining areas [area]. An area has the attributes of position and size. It is used to arrange other objects in a drawing. It may have some consequences for page format modification, but only in the case when a layout contains formulas: 'fixed = ...'. Areas may be used in exceptional situations. They are, of course, invisible in projected drawings.

The presented syntax is relatively "bug-proof", but you should pay particular attention to the fact that a description of a table [table] or an area [area] always ends with [end].

Empty table cells do not have to specified, if they end a described row and their size is 1x1.

The standard text font in table cells agrees with the following description: 'font = height 3, align left middle, angle 0'. The standard font position is defined by 'pos = 3, 50%'.

Types of drawings

It is assumed, that plotter layouts should not contain detailed information concerning the contents of drawings that fill view-ports. If they do contain such information, it should be minimized and transparent for the drawing module that will never make use of this type of information. Such information is often introduced in the form of the 'type = …' command addressed to a view-port. The information is used by Robot modules that are clients of the drawing module and activate it by a batch file. The modules are able to read a layout and, thanks to the 'type' information, to gain orientation as to the requirements of the layout author. Having read a layout, Robot modules may modify it, usually by adding more pages. This explains why the above layout example yields, e.g. two pages for a two-span beam, although the layout contains description of just one page.

Types of drawings in RC modules

"beam"

entire beam in an elevation

"beam/bay"

single beam span

"beam/bay/section"

beam span section

"beam/steel"

steel listing for the entire beam

"beam/bay/steel"

steel listing for one span

"column"

column in an elevation

"column/section"

column section

"column/steel"

column reinforcement listing