diff --git a/usrguide/installationguide/installationguide.adoc b/usrguide/installationguide/installationguide.adoc
index 41ac40d091b75178cb3f0bd19b3725300dfeaf27..ed0b2edef5707855519511fdd535cab377fd9ab8 100644
--- a/usrguide/installationguide/installationguide.adoc
+++ b/usrguide/installationguide/installationguide.adoc
@@ -151,7 +151,7 @@ Download the Titan package for your platform, OS and GCC version from the provid
 
 A binary distribution, suitable for the used operating system (Solaris, Linux, FreeBSD), and for a C++ compiler, in a tar-gzip archive will be received. For Windowsfootnote:[For using TITAN on Windows platforms, installing the Cygwin programming environment is required see chapter 1.5 Installing Prerequisites on Cygwin (on Windows)] users there is no pre-built version, but compiling the open-source version is possible.
 
-WARNING: the version of C++ compiler used is important. If the version difference between the system’s compiler and the compiler that the basic TTCN–3 library was built with is large enough, the linking of executable test suites will fail with strange error messages. The reason is the different mapping of C++ class and (polymorphic) member function names into linker symbols.For example, this problem persists between versions 2.8.x and 2.95.x of GCC. Different C++ compilers (e.g. Sun Workshop and GCC) are, of course, totally incompatible. The solution for this problem is to use nearly the same version of the C++ compiler as the binary package was built with.
+WARNING: the version of C++ compiler used is important. If the version difference between the system’s compiler and the compiler that the basic TTCN–3 library was built with is large enough, the linking of executable test suites will fail with strange error messages. The reason is the different mapping of C++ class and (polymorphic) member function names into linker symbols. For example, this problem persists between versions 2.8.x and 2.95.x of GCC. Different C++ compilers (e.g. Sun Workshop and GCC) are, of course, totally incompatible. The solution for this problem is to use nearly the same version of the C++ compiler as the binary package was built with.
 
 Binaries for other operating systems or C++ compilers are available only on request.
 
diff --git a/usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc b/usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc
index 2e2e4e29446863f63009ffc0954ab4218d4a8e36..1b1299654ab1b77cbdb308794574e5fb4723bf41 100644
--- a/usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc
+++ b/usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc
@@ -25,7 +25,7 @@ The present Test Executor is an implementation of TTCN–3 Core Language standar
 * The Configuration and Deployment Support and the Advanced Parameterization packages of the TTCN-3 standard are not supported yet, except the Port with translation capability clause. ([21]).
 * In contrast to the standard, TITAN does not allow applying the same name to a structured type and to an element of the same type.
 * From version 1.8.pl3 (or R8D) the logging machinery uses an internal TTCN-3 module, named `TitanLoggerApi`, hence using this module name in user code is not allowed.
-* Referencing into an omitted field of any non-const variable/template of record/set type is allowed and it will expand the structure to the level of reference. All the expanded fields under `omit` will be unbound. This behavior is TITAN specific. According to the TTCN-3 standard (15.6.2 of <<13-references.adoc#_1, [1]>>), the proper behavior would be a dynamic test case error in this situation.In case of variable templates referencing into a matching mechanism will change the template regardless of it being a left hand side or a right hand side value.In case of non-variable templates referencing into a matching mechanism will cause an error. According to the TTCN-3 standard the proper behavior for right hand side templates would be to return an expanded value but not change it’s own value in case of AnyValue matching mechanism or stop with an error in case of other matching mechanisms.
+* Referencing into an omitted field of any non-const variable/template of record/set type is allowed and it will expand the structure to the level of reference. All the expanded fields under `omit` will be unbound. This behavior is TITAN specific. According to the TTCN-3 standard (15.6.2 of <<13-references.adoc#_1, [1]>>), the proper behavior would be a dynamic test case error in this situation. In case of variable templates referencing into a matching mechanism will change the template regardless of it being a left hand side or a right hand side value. In case of non-variable templates referencing into a matching mechanism will cause an error. According to the TTCN-3 standard the proper behavior for right hand side templates would be to return an expanded value but not change it’s own value in case of AnyValue matching mechanism or stop with an error in case of other matching mechanisms.
 * According to the standard, before matching the tools have to make sure that the template being used is completely initialized, with no fields or elements left unbound. For performance reasons this check is not done before the matching is done. Instead the matching will report the error, when it tries to use an unbound field or elements.
 * In case the compiler is not able to decide at compile time, if all possible execution branches contain a return statement, that is, in cases of alt statements, loops and branching statement like if-else, select case, and so on, it will report an error without generating code. For example:
 +
@@ -77,4 +77,3 @@ x := { i1 := x.i2 }; // assignment notation with self-reference (not OK)
 x.i3 := x.i1; // individual field assignment with self-reference (OK)
 // result: x := { i1 := 3, i2 := <unbound>, i3 := 3 }
 ----
-
diff --git a/usrguide/referenceguide/3-clarifications_to_the_ttcn-3_standard.adoc b/usrguide/referenceguide/3-clarifications_to_the_ttcn-3_standard.adoc
index 52b0393159991ca59d1d9fd381f2a05e630848d5..33f52a16999d057cec20f56c914ab0b809df8922 100644
--- a/usrguide/referenceguide/3-clarifications_to_the_ttcn-3_standard.adoc
+++ b/usrguide/referenceguide/3-clarifications_to_the_ttcn-3_standard.adoc
@@ -132,7 +132,7 @@ setverdict(pass);
 
 == Description of Behavior Types Syntax
 
-TITAN supports the behaviour type package of the TTCN-3 standard,but with a different syntax. For details of the behaviour types see <<13-references.adoc#_5, [5]>>.
+TITAN supports the behaviour type package of the TTCN-3 standard, but with a different syntax. For details of the behaviour types see <<13-references.adoc#_5, [5]>>.
 
 .Behaviour types - refers shows the different syntax of the function behaviour type.
 [cols=",",options="header",]
diff --git a/usrguide/referenceguide/4-ttcn3_language_extensions.adoc b/usrguide/referenceguide/4-ttcn3_language_extensions.adoc
index a0fa56edda7aee2de8dee639efc25e17f65652c2..bee905316591aa2d98bdcd9d767adffcd1f164a1 100644
--- a/usrguide/referenceguide/4-ttcn3_language_extensions.adoc
+++ b/usrguide/referenceguide/4-ttcn3_language_extensions.adoc
@@ -266,7 +266,7 @@ The compiler accepts `altsteps` containing only an `[else]` branch. This is not
 
 The compiler realizes TTCN–3 `interleave` statements using a different approach than it is described in section 7.5 of <<13-references.adoc#_1, [1]>>. The externally visible behavior of the generated code is equivalent to that of the canonical mapping, but our algorithm has the following advantages:
 
-* Loop constructs `for`, `while` and `do-whil`e loops are accepted and supported without any restriction in `interleave` statements. The transformation of statements is done in a lower level than the TTCN–3 language, which does not restrict the embedded loops.
+* Loop constructs `for`, `while` and `do-while` loops are accepted and supported without any restriction in `interleave` statements. The transformation of statements is done in a lower level than the TTCN–3 language, which does not restrict the embedded loops.
 * Statements `activate`, `deactivate` and `stop` can also be used within `interleave`. The execution of these statements is atomic so we did not see the reason why the standard forbids them.
 * The size of our generated code is linear in contrast to the exponential code growth of the canonical algorithm. In other words, the C++ equivalent of every embedded statement appears exactly once in the output.
 * The run-time realization does not require any extra operating system resources, such as multi-threading.
@@ -718,7 +718,7 @@ Syntax:
 decode_base64(in charstring str) return octetstring
 ----
 
-The function `decode_base64 (in charstring str) return octetstring` converts a chartstring `str` encoded in Base64 to an octetrstring. The octetstring will contain the decoded Base64 string of `str`.
+The function `decode_base64 (in charstring str) return octetstring` converts a charstring `str` encoded in Base64 to an octetstring. The octetstring will contain the decoded Base64 string of `str`.
 
 Example:
 
@@ -1172,7 +1172,7 @@ Mappings are given for each source type separately. Several mapping targets may
 
 The following transformation rules may apply to the automatic conversion between the messages of the external and internal interfaces of a dual-faced port:
 
-* No conversion. Applicable to any message type, this is a type preserving mapping, no value conversion is performed. Source and target types must be identical. This mapping does not have any options. For example, control or status indication massages may transparently be conveyed between the external and the internal interfaces.Keyword used in attribute `user` of port type definition: `simple`.
+* No conversion. Applicable to any message type, this is a type preserving mapping, no value conversion is performed. Source and target types must be identical. This mapping does not have any options. For example, control or status indication massages may transparently be conveyed between the external and the internal interfaces. Keyword used in attribute `user` of port type definition: `simple`.
 * Message discarding. This rule means that messages of the given source type will not be forwarded to the opposite interface. Thus, there is no destination type, which must be indicated by the not used symbol (-). This mapping does not have any options. For example, incoming status indication massages of the external interface may be omitted on the internal interface. Keyword used in attribute `user` of port type definition: `discard`.
 * Conversion using the built-in codecs. Here, a corresponding encoding or decoding subroutine of the built-in codecs (for example RAW, TEXT or BER) is invoked. The conversion and error handling options are specified with the same syntax as used for the encoding/decoding functions, see section <<attribute-syntax, Attribute Syntax>>. Here, source type corresponds to input type and target type corresponds to output type of the encoding. Keyword used in attribute `user` of port type definition: `encode` or `decode`; either followed by an optional `errorbehavior`.
 * Function or external function. The transformation rule may be described by an (external) function referenced by the mapping. The function must have the attribute `extension` specifying one of the prototypes given in section <<encoder-decoder-function-prototypes, Encoder/decoder Function Prototypes>>. The incoming and the outgoing type of the function must be equal to the source and target type of the mapping, respectively. The function may be written in TTCN-3, C++ or generated automatically by the compiler. This mapping does not have any options. Keyword used in attribute `user` of port type definition: `function`.
@@ -1206,7 +1206,7 @@ The following rules may be used with more than one target when there is a slidin
 * an (external) function with prototype `sliding` is invoked;
 * decoding a structured message (keyword `decode`)
 
-Above rules imply that the source type of this mapping be either `octetstring` or `charstring`. The run-time environment maintains a separate buffer for each connection of the dual-faced port. Whenever data arrives to the buffer, the conversion rules are applied on the buffer in the same order as given in the attribute. If one of the rules succeeds (that is, the function returns `0` or decoding is completed without any error) the outcome of the conversion will appear on the destination side. If the buffer still contains data after successful decoding, the conversion is attempted again to get the next message.If one of the rules indicates that the data in the buffer is insufficient to get an entire message (the function returns `2 INCOMPLETE_MESSAGE` or decoding fails with error code `ET_INCOMPL_MSG`), then the decoding is interrupted until the next fragment arrives in the buffer.If all conversion rules fail (the function returns `1 NOT_MY_TYPE` or decoding fails with any other error code than `ET_INCOMPL_MSG`), dynamic test case error occurs.
+Above rules imply that the source type of this mapping be either `octetstring` or `charstring`. The run-time environment maintains a separate buffer for each connection of the dual-faced port. Whenever data arrives to the buffer, the conversion rules are applied on the buffer in the same order as given in the attribute. If one of the rules succeeds (that is, the function returns `0` or decoding is completed without any error) the outcome of the conversion will appear on the destination side. If the buffer still contains data after successful decoding, the conversion is attempted again to get the next message. If one of the rules indicates that the data in the buffer is insufficient to get an entire message (the function returns `2 INCOMPLETE_MESSAGE` or decoding fails with error code `ET_INCOMPL_MSG`), then the decoding is interrupted until the next fragment arrives in the buffer. If all conversion rules fail (the function returns `1 NOT_MY_TYPE` or decoding fails with any other error code than `ET_INCOMPL_MSG`), dynamic test case error occurs.
 
 [[encoder-decoder-function-prototypes]]
 === Encoder/decoder Function Prototypes
@@ -1396,7 +1396,7 @@ Differences from the new method:
 
 * each codec has its own rules for defining `encode` and `variant` attributes;
 * a type can only have one `encode` attribute (if more than one is defined, then only the last one is considered), however, it can have `variant` attributes that belong to other codecs (this can make determining the default codec tricky);
-* ASN.1 types automatically have `BER`, `JSON`, `PER` (see section <<PER-encoding, PER encoding and decoding through user defined functions>>), and `XML` (if the compiler option -a is set) encoding, however the method of setting a default codec (for the predefined functions `encvalue`, `decvalue`, encvalue_unichar, `decvalue_unichar`, for `decmatch` templates, and for the `@decoded` modifier) is different (see section <<setting-the-default-codec-for-asn-1-types, Setting the default codec for ASN.1 types>>);
+* ASN.1 types automatically have `BER`, `JSON`, `PER` (see section <<PER-encoding, PER encoding and decoding through user defined functions>>), and `XML` (if the compiler option -a is set) encoding, however the method of setting a default codec (for the predefined functions `encvalue`, `decvalue`, `encvalue_unichar`, `decvalue_unichar`, for `decmatch` templates, and for the `@decoded` modifier) is different (see section <<setting-the-default-codec-for-asn-1-types, Setting the default codec for ASN.1 types>>);
 * encoding-specific `variant` attributes are not supported(e.g.: `variant "XML"."untagged"`);
 * the parameters `encoding_info/decoding_info` and `dynamic_encoding` of predefined functions `encvalue`, `decvalue`, `encvalue_unichar` and `decvalue_unichar` are ignored;
 * the `setencode` operation is not supported;
@@ -2840,7 +2840,7 @@ Description: The encoder is able to calculate the encoded length of one or sever
 
 If the offset is present, it is added to or subtracted from (the operation specified in the attribute is performed) the calculated length during encoding. During decoding, the offset is subtracted from or added to (the opposite operation to the one specified in the attribute is performed) the decoded value of the length field.
 
-NOTE: The length is expressed in units defined by the attribute UNIT The default unit is octet. The length field should be a TTCN–3 `integer` or `union` type. Special union containing only integer fields can be used for variable length field. It must not be used with `LENGTHINDEX`. The length field can be included in to the sum of the lengths of multiple fields (e.g.` lengthField` + `field2` + `field3`). The `union` field is NOT selected by the encoder. So the suitable field must be selected before encoding! The fields included in the length computing need not be continuous.
+NOTE: The length is expressed in units defined by the attribute UNIT The default unit is octet. The length field should be a TTCN–3 `integer` or `union` type. Special union containing only integer fields can be used for variable length field. It must not be used with `LENGTHINDEX`. The length field can be included in to the sum of the lengths of multiple fields (e.g. `lengthField` + `field2` + `field3`). The `union` field is NOT selected by the encoder. So the suitable field must be selected before encoding! The fields included in the length computing need not be continuous.
 
 Examples:
 [source]
@@ -3182,7 +3182,7 @@ Can be used with: `record` or `set`.
 
 Description: The purpose of the attribute `TAG` is to identify specific values in certain fields of the `set`, `record` elements or `union` choices. When the `TAG` is specified to a `record` or a `set`, the presence of the given element can be identified at decoding. When the `TAG` belongs to a `union`, the union member can be identified at decoding. The attribute is a list of `field_identifications`. Each `field_identification` consists of a record, set or union field name and a `presence_indicator` expression separated by a comma (,). `Presence_indicators` are of form `<key> = <constant>` or `{ <key1> = <constant1>, <key2> = <constant2>, … <keyN> = <constantN> }` where each key is a field(.nestedField) of the `record`, `set` or `union` and each constant is a TTCN–3 constant expression (e.g.` 22`, `’25’O` or `’1001101’B`).There is a special presence_indicator: `OTHERWISE`. This indicates the default union member in a union when the TAG belongs to union.
 
-NOTE: `TAG` works on non-optional fields of a record as well.It is recommended to use the attributes `CROSSTAG` or `PRESENCE` leading to more effective decoding.
+NOTE: `TAG` works on non-optional fields of a record as well. It is recommended to use the attributes `CROSSTAG` or `PRESENCE` leading to more effective decoding.
 
 Examples:
 [source]
@@ -3378,7 +3378,7 @@ type record InnerRec {
 }
 
 // Note: decoding a value of type InnerRec alone does not force any of the
-// fields mentioned in the variants below to be omitted 
+// fields mentioned in the variants below to be omitted
 
 type record OuterRec1 {
   integer f1,
@@ -3590,7 +3590,7 @@ const BIT7align c_yourstring:=’0101’B
 
 *BOOLEAN*
 
-Coding: The `boolean` value `true` coded as ’1’B,the `boolean` value `false` coded as ’0’B.If `FIELDLENGTH` is specified, the given number of ones (`true`) or zeros (`false`) is coded. If the decoded bitfield is zero the decoded value will be false otherwise true.The default `FIELDLENGTH` for `boolean` type is 1.
+Coding: The `boolean` value `true` coded as ’1’B,the `boolean` value `false` coded as ’0’B.If `FIELDLENGTH` is specified, the given number of ones (`true`) or zeros (`false`) is coded. If the decoded bitfield is zero the decoded value will be false otherwise true. The default `FIELDLENGTH` for `boolean` type is 1.
 
 Attributes allowed: `FIELDLENGTH (0)`, `N bit` (0).
 
@@ -3978,7 +3978,7 @@ Coding: The characters are first converted to UTF-8 format, and the resulting oc
 
 The RAW encoding of a `universal` `charstring` value with no non-ASCII characters is equal to the RAW encoding of a `charstring` containing the same characters (with the same attributes).
 
-If the length of the UTF-8 encoded `universal` `charstring` is shorter than the specified `FIELDLENGTH`, aligning is governed by the attribute `ALIGN`.The default `FIELDLENGTH` for the `universal` `charstring` type is `variable`. The `FIELDLENGTH` is measured in UTF-8 octets.
+If the length of the UTF-8 encoded `universal` `charstring` is shorter than the specified `FIELDLENGTH`, aligning is governed by the attribute `ALIGN`. The default `FIELDLENGTH` for the `universal` `charstring` type is `variable`. The `FIELDLENGTH` is measured in UTF-8 octets.
 
 Attributes allowed:
 
@@ -4714,7 +4714,7 @@ The "name as "" (i.e. freetext is empty) form designates that the TTCN-3 field
 
 The "name as capitalized" and "name as uncapitalized" forms identify that only the first character of the related TTCN3 type or field name shall be changed to lower case or upper case respectively.
 
-The "name as lowercased“ and"name as uppercased" forms identify that each character of the related TTCN3 type or field name shall be changed to lower case or upper case respectively.
+The "name as lowercased“ and "name as uppercased" forms identify that each character of the related TTCN3 type or field name shall be changed to lower case or upper case respectively.
 
 The "name all as capitalized", "name all as uncapitalized", "name as lowercased" and "name as uppercased" forms has effect on all direct fields of the TTCN-3 definition to which the encoding instruction is applied (e.g. in case of a structured type definition to the names of its fields in a non-recursive way but not to the name of the definition itself and not to the name of fields embedded to other fields).
 
@@ -4852,7 +4852,7 @@ where `changeCase` has been defined as seen <<changeCase, here>>.
 
 Applicable to (TTCN-3) Enumeration types generated for XSD enumeration facets where the enumeration base is a string type, and the name(s) of one or more TTCN-3 enumeration values are different from the related XSD enumeration item. Also applies to XSD.Boolean types, instances of XSD.Boolean types.
 
-Description When _name_ is used, it shall be generated for the differing enumerated values only. The _name_ shall be the identifier of the TTCN-3 enumerated value the given instruction relates to. If the difference is that the first character of the XSD enumeration item value is a capital letter while the identifier of the related TTCN-3 enumeration value starts with a small letter, the "text `__name__' as capitalized" form shall be used. Otherwise, _freetext_ shall contain the value of the related XSD enumeration item.If the first characters of all XSD enumeration items are capital letters, while the names of all related TTCN-3 enumeration values are identical to them except the case of their first characters, the "text all as capitalized" form shall be used.The encoding instruction designates that the encoder shall use _freetext_ or the capitalized name(s) when encoding the TTCN-3 enumeration value(s) and vice versa.When the text encoding attribute is used with XSD.Boolean types, the decoder shall accept all four possible XSD boolean values and map the received value 1 to the TTCN-3 boolean value *true* and the received value 0 to the TTCN-3 boolean value *false*. When the text encoding attribute is used on the instances of the XSD.Boolean type, the encoder shall encode the TTCN3 values according to the encoding attribute (i.e. *true* as 1 and *false* as 0).
+Description When _name_ is used, it shall be generated for the differing enumerated values only. The _name_ shall be the identifier of the TTCN-3 enumerated value the given instruction relates to. If the difference is that the first character of the XSD enumeration item value is a capital letter while the identifier of the related TTCN-3 enumeration value starts with a small letter, the "text `__name__' as capitalized" form shall be used. Otherwise, _freetext_ shall contain the value of the related XSD enumeration item. If the first characters of all XSD enumeration items are capital letters, while the names of all related TTCN-3 enumeration values are identical to them except the case of their first characters, the "text all as capitalized" form shall be used. The encoding instruction designates that the encoder shall use _freetext_ or the capitalized name(s) when encoding the TTCN-3 enumeration value(s) and vice versa. When the text encoding attribute is used with XSD.Boolean types, the decoder shall accept all four possible XSD boolean values and map the received value 1 to the TTCN-3 boolean value *true* and the received value 0 to the TTCN-3 boolean value *false*. When the text encoding attribute is used on the instances of the XSD.Boolean type, the encoder shall encode the TTCN3 values according to the encoding attribute (i.e. *true* as 1 and *false* as 0).
 
 Comment For XSD.Boolean types, either of the forms "text 'true' as "1" and "text 'false' as '0' implies the other, i.e. Titan considers that both have been specified. Together, these two forms have the same effect as "text" (detailed in the last paragraph of Description).
 
@@ -7239,7 +7239,7 @@ A number of checks are performed during the build to ensure consistency of the T
 #endif
 ----
 * There is a preprocessor macro defined in the makefile which identifies the platform (operating system). It can be one of SOLARIS (for Solaris 6), SOLARIS8 (for Solaris 8 and above), LINUX, WIN32. Platform-dependent code can be isolated using conditional compilation based on these macro definitions.
-* If the TITAN runtime was compiled with the GNU Compiler Collection (GCC), the macro GCC_VERSION is defined by the TITAN runtime headers. Its value is 10000 * (GCC major version) + 100 * (GCC minor version). For example, for GCC 3.4.6, GCC_VERSION will be defined to the value 30400; for GCC 4.1.2 it will be 40100. The value of this macro is compared during C++ compilation to the version of the compiler that was used to build TITAN itself to ensure consistency of the build. The GCC patch level is ignored for this comparison; code generated by a compiler with the same major and minor version is considered compatible.User-written code can use this value if it requires a certain version of the compiler. Alternatively, the predefined macros of the GNU compiler (*GNUC* and *GNUC_MINOR*) can be used for this purpose.
+* If the TITAN runtime was compiled with the GNU Compiler Collection (GCC), the macro GCC_VERSION is defined by the TITAN runtime headers. Its value is 10000 * (GCC major version) + 100 * (GCC minor version). For example, for GCC 3.4.6, GCC_VERSION will be defined to the value 30400; for GCC 4.1.2 it will be 40100. The value of this macro is compared during C++ compilation to the version of the compiler that was used to build TITAN itself to ensure consistency of the build. The GCC patch level is ignored for this comparison; code generated by a compiler with the same major and minor version is considered compatible. User-written code can use this value if it requires a certain version of the compiler. Alternatively, the predefined macros of the GNU compiler (*GNUC* and *GNUC_MINOR*) can be used for this purpose.
 * If the TITAN runtime was built with the SunPro compiler, the compiler itself defines the __SUNPRO_CC macro. Please consult the compiler documentation for the possible values.
 
 == Negative Testing
@@ -7937,7 +7937,7 @@ UpdateKeyword ::= "@update"
 
 The `@update` statement can be used in functions, altsteps, testcases and control parts. Per the BNF productions in the TTCN-3 standard, the `UpdateStatement' defined here would be in the FunctionStatement and ControlStatement productions.
 
-The @update statement replaces the erroneous attributes of the value or template referenced by ExtendedIdentifier with the erroneous attributes specified in WithAttribList. The statement overwrites any erroneous attributes the value or template may have had before. If the `with' attributes are omitted, then the statement removes all the value’s or template’s erroneous attributes.
+The `@update` statement replaces the erroneous attributes of the value or template referenced by ExtendedIdentifier with the erroneous attributes specified in WithAttribList. The statement overwrites any erroneous attributes the value or template may have had before. If the `with' attributes are omitted, then the statement removes all the value’s or template’s erroneous attributes.
 
 Example:
 [source]
@@ -8618,7 +8618,7 @@ Limitations of implementation in TITAN:
 
 * The `connect to` port clause is unsupported
 * Translation of `address` types is unsupported
-* `address`, `map param` and `unmap para`m clauses are unsupported
+* `address`, `map param` and `unmap param` clauses are unsupported
 * The elements of the list of `form` and `to` clauses of the `in` and `out` messages are separated with a colon (:) instead of a comma (,)
 
 Restrictions:
diff --git a/usrguide/referenceguide/6-compiling_ttcn3_and_asn1_modules.adoc b/usrguide/referenceguide/6-compiling_ttcn3_and_asn1_modules.adoc
index 68ccd3dd3908e5f40edc997ce0315bc948a6ad76..917fa97f3e6c2448a9a038df37c71b705473a2de 100644
--- a/usrguide/referenceguide/6-compiling_ttcn3_and_asn1_modules.adoc
+++ b/usrguide/referenceguide/6-compiling_ttcn3_and_asn1_modules.adoc
@@ -148,7 +148,7 @@ Instructs the compiler to generate source file and line information (that is, #l
 
 * `-L`
 +
-Instructs the compiler to add source file and line number information into the generated code to be included in the log during execution. This option is only a prerequisite for logging the source code information. The run-time configuration file parameters `OptionsSourceInfoFormat` and `LogEntityName` in <<7-the_run-time_configuration_file.adoc#logging, `[LOGGING]`>> have also to be set appropriately.This feature can be useful for finding the cause of dynamic test case errors in fresh TTCN3 code. Using this option enlarges the size of the generated code a bit and reduces execution speed slightly; therefore it is not recommended when the TTCN3 test suite is used for load generation.
+Instructs the compiler to add source file and line number information into the generated code to be included in the log during execution. This option is only a prerequisite for logging the source code information. The run-time configuration file parameters `OptionsSourceInfoFormat` and `LogEntityName` in <<7-the_run-time_configuration_file.adoc#logging, `[LOGGING]`>> have also to be set appropriately. This feature can be useful for finding the cause of dynamic test case errors in fresh TTCN3 code. Using this option enlarges the size of the generated code a bit and reduces execution speed slightly; therefore it is not recommended when the TTCN3 test suite is used for load generation.
 
 * `-M`
 +
@@ -172,7 +172,7 @@ Disable the generation of OER encoding and decoding functions.
 
 * `-p`
 +
-Instructs the compiler only to parse the given TTCN–3 and ASN.1 modules. This will detect only the syntax errors in them because semantic checks are not performed. The presence of all imported modules is not necessary, thus, it is allowed (and recommended) to parse the modules one-by-one.All options that influence the code generation are silently ignored when used together with `-p`.
+Instructs the compiler only to parse the given TTCN–3 and ASN.1 modules. This will detect only the syntax errors in them because semantic checks are not performed. The presence of all imported modules is not necessary, thus, it is allowed (and recommended) to parse the modules one-by-one. All options that influence the code generation are silently ignored when used together with `-p`.
 +
 NOTE: This option includes complete syntax checks for TTCN–3 modules, but in ASN.1 there are some special constructs (e.g. the user-defined syntaxes) that cannot be parsed without semantic analysis. So there is no guarantee that an ASN.1 module is free of syntax errors if it was analyzed with compiler using the -p flag.
 
@@ -329,7 +329,7 @@ The switches denoted by square brackets are optional. More than one option may b
 
 * `-a`
 +
-The flag refers to files using absolute path names in the generated Makefile. Makefile uses by default relative path names to access files located outside the current working directory of the compiler. Files from the current working directory are always referenced using only the file name without any directory.The flag generates a Makefile that is capable of using pre-compiled C++ and object files from central directories in order to save disk space and compilation time.WARNING! This feature works only if the generated files of the central directory is kept up-to-date and all directories use exactly the same environment (platform, TTCN–3 Executor and C++ compiler version, etc.).
+The flag refers to files using absolute path names in the generated Makefile. Makefile uses by default relative path names to access files located outside the current working directory of the compiler. Files from the current working directory are always referenced using only the file name without any directory. The flag generates a Makefile that is capable of using pre-compiled C++ and object files from central directories in order to save disk space and compilation time. WARNING! This feature works only if the generated files of the central directory is kept up-to-date and all directories use exactly the same environment (platform, TTCN–3 Executor and C++ compiler version, etc.).
 
 * `-c`
 +
@@ -513,7 +513,7 @@ NOTE: This flag overrides the working directory coming from the TPD. In case of
 
 * `-W`
 +
-Prefix working directories with project name. This is needed if more than one TPD file is in the same directory, because this directory will then be the root of more than one project. The working directories (usually `bin') wil conflict, by using –W the working directory name will be prefixed by the project name, for example `MyProject_bin'.
+Prefix working directories with project name. This is needed if more than one TPD file is in the same directory, because this directory will then be the root of more than one project. The working directories (usually `bin') will conflict, by using –W the working directory name will be prefixed by the project name, for example `MyProject_bin'.
 +
 NOTE: In case of incorrect TPD files, the errors are displayed multiple times if the faulty TPD is included more than once in the project structure.
 
diff --git a/usrguide/referenceguide/7-the_run-time_configuration_file.adoc b/usrguide/referenceguide/7-the_run-time_configuration_file.adoc
index f4b95f53885f81b47bbca1abd34419d78f5f2efc..31b8f158380daf0cb37771b4db67e6d573a3a7e4 100644
--- a/usrguide/referenceguide/7-the_run-time_configuration_file.adoc
+++ b/usrguide/referenceguide/7-the_run-time_configuration_file.adoc
@@ -479,7 +479,7 @@ LoggerPlugins := { JUnitLogger := "libjunitlogger2" }
 *.JUnitLogger.filename_stem := "MyJunitLogFile"
 *.JUnitLogger.testsuite_name := "myJUnitTest"
 ----
-* The results are included in testcases (between <testcase> tags) within a testsuite (between <testsuite> tags) like the JUnitLogger butthe testsuite has attributes other than "name" which contains the name of the testsuite.
+* The results are included in testcases (between <testcase> tags) within a testsuite (between <testsuite> tags) like the JUnitLogger but the testsuite has attributes other than "name" which contains the name of the testsuite.
 +
 New attributes:
 +
@@ -657,7 +657,7 @@ The table below contains the list of available metacharacters in alphabetical or
 
 The outcome of substitution will result in the name of the log file. It may resolve either to a simple file name or to an absolute or relative path. The relative pathnames are always related to the current working directory of the executable tests in single mode or that of the Host Controller in parallel mode, respectively. If the pathname contains one or more nonexistent directories, those directories (and/or subdirectories) will be automatically created with permissions `0755` before the log file is opened.
 
-If the given string or the result of substitution is empty, no log file will be created and only console logging will be performed regardless the setting of `FileMask`. Empty log files will not be created when logging to files is completely disabled (i.e.` FileMask` is set to `LOG_NOTHING`) even if the value of `LogFile` would yield a valid file name.
+If the given string or the result of substitution is empty, no log file will be created and only console logging will be performed regardless the setting of `FileMask`. Empty log files will not be created when logging to files is completely disabled (i.e. `FileMask` is set to `LOG_NOTHING`) even if the value of `LogFile` would yield a valid file name.
 
 In parallel mode the user must ensure that the resulting log file names are unique for every component. Otherwise, if several components try to write into the same log file, the contents of the log will be unpredictable. The uniqueness is automatically provided if the host name (`%h`) and the component reference (`%r`) or the process ID (`%p`) is included in the file name.
 
@@ -716,7 +716,7 @@ It is also possible to apply the filtering on selected logger plugins of a compo
 .First level (coarse) log filtering
 [cols=",",options="header",]
 |===
-|Logging categories |Symbolic constantfootnote:[In order to be compatible with older configuration files, the following symbolic constants are also recognized: TTCN_ERROR, TTCN_WARNING, TTCN_PORTEVENT, TTCN_TIMEROP, TTCN_VERDICTOP, TTCN_DEFAULTOP, TTCN_TESTCASE, TTCN_ACTION, TTCN_USER, TTCN_FUNCTION, TTCN_STATISTICS, TTCN_PARALLEL, TTCN_EXECUTOR, TTCN_MATCHING and TTCN_DEBUG.These constants have the same meaning as their counterparts without the prefix TTCN_.]
+|Logging categories |Symbolic constantfootnote:[In order to be compatible with older configuration files, the following symbolic constants are also recognized: TTCN_ERROR, TTCN_WARNING, TTCN_PORTEVENT, TTCN_TIMEROP, TTCN_VERDICTOP, TTCN_DEFAULTOP, TTCN_TESTCASE, TTCN_ACTION, TTCN_USER, TTCN_FUNCTION, TTCN_STATISTICS, TTCN_PARALLEL, TTCN_EXECUTOR, TTCN_MATCHING and TTCN_DEBUG. These constants have the same meaning as their counterparts without the prefix TTCN_.]
 |TTCN–3 action(…) statements(No subcategory is implemented) |`ACTION`
 |Debug messages in Test Ports and external functions(For subcategories see Table 15) |`DEBUG`
 |Default operations (`activate`, `deactivate`, `return`)(For subcategories see Table 16) |`DEFAULTOP`
@@ -895,9 +895,9 @@ In both single and parallel modes some log events are created before processing
 
 === `SourceInfoFormat`
 
-Option `SourceInfoFormat` controls the appearance of the location information for the test events. The location information refers to a position in theTTCN–3 source code. It consists of the name of the TTCN–3 file and the line number separated by a colon character (:). Optionally, it may contain the name of the TTCN–3 entity (function, testcase, etc.) in parentheses that the source line belongs to. See also the option <<LogEntityName, `LogEntityName`>> below.
+Option `SourceInfoFormat` controls the appearance of the location information for the test events. The location information refers to a position in the TTCN–3 source code. It consists of the name of the TTCN–3 file and the line number separated by a colon character (:). Optionally, it may contain the name of the TTCN–3 entity (function, testcase, etc.) in parentheses that the source line belongs to. See also the option <<LogEntityName, `LogEntityName`>> below.
 
-The option can take one of the three possible values: `None`, `Single` and `Stack`. In case of `Single`, the location information of the TTCN–3 statement is logged that is currently being executed. When `Stack` is used the entire TTCN–3 call stack is logged. The logged information starts from the outermost control part or testcase and ends with the innermost TTCN–3 statement. An arrow (that is, the character sequence ->) is used as separator between the stack frames. The value `None` disables the printing of location information.The default value for `SourceInfoFormat` is `None`.
+The option can take one of the three possible values: `None`, `Single` and `Stack`. In case of `Single`, the location information of the TTCN–3 statement is logged that is currently being executed. When `Stack` is used the entire TTCN–3 call stack is logged. The logged information starts from the outermost control part or testcase and ends with the innermost TTCN–3 statement. An arrow (that is, the character sequence ->) is used as separator between the stack frames. The value `None` disables the printing of location information. The default value for `SourceInfoFormat` is `None`.
 
 The location information is placed in each line of the log file between the event type or timestamp and the textual description of the event.
 
@@ -935,7 +935,7 @@ It is also possible to limit the file size on selected logger plugins of a compo
 [[LogFileNumber]]
 === `LogFileNumber`
 
-Option `LogFileNumber`, a positive integer, sets the the maximum number of log files (fragments) kept. If the log file number limit is reached, the oldest log file of the component will be deleted and logging continues in the next log fragment file.
+Option `LogFileNumber`, a positive integer, sets the maximum number of log files (fragments) kept. If the log file number limit is reached, the oldest log file of the component will be deleted and logging continues in the next log fragment file.
 
 The default value is 1, meaning that the number of log files equals one.
 
diff --git a/usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc b/usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc
index 772def38935fb1f7c352fc5286c83856ed48fa56..8a1c7794862dfcc8d22c508662053a63898c2130 100644
--- a/usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc
+++ b/usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc
@@ -63,7 +63,7 @@ The following tags are supported:
 |===
 |*Name of the attributes* |*Meaning* |*O/M*
 |`name` |The name of the project referenced. This will create the relation between the actual and the referenced project. The value of this attribute must be equal to the `ProjectName` of the referenced project. |M
-|`projectLocationURI` |The path of the project descriptor of the referenced project, relative to the actual descriptor.If the project is not already loaded in eclipse, it will be loaded from this path. |M
+|`projectLocationURI` |The path of the project descriptor of the referenced project, relative to the actual descriptor. If the project is not already loaded in eclipse, it will be loaded from this path. |M
 |`tpdName` |The file name of the TPD file. This attribute is used with the `makefilegen’s` –I switch to provide search paths to find the referenced project if it is not found at `projectLocationURI`. |O
 |===
 
@@ -628,4 +628,3 @@ In the command line referenced projects are identified by the location of their
 In eclipse all information is persisted by the platform, as such the closing and re-opening of the workspace will not change any project information, or come with data loss.
 
 This is our own project information; it can not be expected from external tool vendors to support it. As such exporting/importing a project via the ClearCase Remote Client will not be possible using this format, or might not produce the expected results.
-