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..3e84de3479da5ac319b7f257430f98c237686f8b 100644
--- a/usrguide/referenceguide/4-ttcn3_language_extensions.adoc
+++ b/usrguide/referenceguide/4-ttcn3_language_extensions.adoc
@@ -880,7 +880,7 @@ myFunction(p_par2 := false, 1); // unnamed part cannot follow
 
 Although TITAN supports the behaviour type package (<<13-references.adoc#_5, [5]>>) of the TTCN-3 standard, but this feature was included in the standard with a different syntax.
 
-It is allowed to create TTCN–3 types of `functions`, `altsteps` and `testcases`. Values, for example variables, of such types can carry references to the respective TTCN–3 definitions. To facilitate reference using, three new operations (`refers`, `derefers` and `apply`) were introduced. This new language feature allows to create generic algorithms inTTCN–3 with late binding, (i.e. code in which the function to be executed is specified only at runtime).
+It is allowed to create TTCN–3 types of `functions`, `altsteps` and `testcases`. Values, for example variables, of such types can carry references to the respective TTCN–3 definitions. To facilitate reference using, three new operations (`refers`, `derefers` and `apply`) were introduced. This new language feature allows to create generic algorithms in TTCN–3 with late binding, (i.e. code in which the function to be executed is specified only at runtime).
 
 [[function-types-with-a-runson-self-clause]]
 == Function Types with a RunsOn_self Clause
@@ -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
@@ -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]
@@ -3071,7 +3071,7 @@ variant (ptr2) "POINTERTO(field2)";
 variant (ptr2) "PTROFFSET(field1)"
 }
 
-//In the example abovethe distance will not include//the pointer itself.
+//In the example above the distance will not include//the pointer itself.
 ----
 
 *UNIT*
@@ -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:
 
@@ -4231,9 +4231,9 @@ Usable attribute: `repeatable`
 |===
 |*attr* |*Description* |*Parameter* |*Default value*
 |`length` |Determines the length of the coded value. |value |number of charactersof value
-|`convert` |Converts string values to lower orupper case during encoding or decoding. |`lower_case`, `upper_case` |no conversion
-|`just` |If the string is shorter than the value definedby the length attribute, just controls the justification of the value. |`left`, `right`, `center` |`left`
-|`leading0` |Controls the presence of the leading zerosof the coded integer value. |`true`, `false` |`false`
+|`convert` |Converts string values to lower or upper case during encoding or decoding. |`lower_case`, `upper_case` |no conversion
+|`just` |If the string is shorter than the value defined by the length attribute, just controls the justification of the value. |`left`, `right`, `center` |`left`
+|`leading0` |Controls the presence of the leading zeros of the coded integer value. |`true`, `false` |`false`
 |`repeatable` |The attribute repeatable controls whether the element of the record of or set of can be mixed with other elements of the set or they are grouped together. |`true`, `false` |`false`
 |===
 
@@ -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).
 
@@ -7186,7 +7186,7 @@ Compiling this module with TITAN R8B or below may result in a different compiler
 
 ==== Specifying the Version of a TTCN-3 Module
 
-A module’s own version information can be specified in an extension attribute. The format of the extension attribute is"version <version data>"that is, the literal string "version" followed by the version information (R-state).
+A module’s own version information can be specified in an extension attribute. The format of the extension attribute is "version <version data>" that is, the literal string "version" followed by the version information (R-state).
 
 Example:
 [source]
@@ -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
@@ -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..9ed38ba57e8516452511567e1333bc341053bf8c 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.
 
@@ -547,7 +547,7 @@ makefilegen –FWrZH –t MyTopLevelProj.tpd
 [source]
 makefilegen –V –P $(pwd) –t TopLevelProj.tpd
 
-. Create archive file of all files in all hierarchical projects:Go to the root directory of your projects then use the following bash command:
+. Create archive file of all files in all hierarchical projects: Go to the root directory of your projects then use the following bash command:
 +
 [source]
 makefilegen –V –P $(pwd) –t path/to/your/TopLevelProj.tpd | xargs tar cfz YourArchive.tgz
@@ -601,7 +601,7 @@ If the `<defaultTarget>` is library and `<dynamicLinking>` is true, the followin
 
 Position dependent code cannot be linked with position independent code. This is a known limitation of the GNU linker. The third party libraries shall be added to LD_LIBRARY_PATH, or be copied to a directory contained by the LD_LIBRARY_PATH
 
-If the <defaultTarget> is library and and <dynamicLinking> is false, the following aspects are to be considered:
+If the <defaultTarget> is library and <dynamicLinking> is false, the following aspects are to be considered:
 
 * it can be linked together with another static library
 * it cannot be linked together with a dynamic library
diff --git a/usrguide/referenceguide/7-the_run-time_configuration_file.adoc b/usrguide/referenceguide/7-the_run-time_configuration_file.adoc
index f4b95f53885f81b47bbca1abd34419d78f5f2efc..2e7876e613aa10e441a3fb1e36e65150f9f2a4d6 100644
--- a/usrguide/referenceguide/7-the_run-time_configuration_file.adoc
+++ b/usrguide/referenceguide/7-the_run-time_configuration_file.adoc
@@ -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.
 
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.
-