Only typo in docs

Signed-off-by: balaskoa <Jeno.Balasko@ericsson.com>
Change-Id: I60466071bfc7f8fa4f0045b70d2cde94a450816b

usrguide/referenceguide/1-about_the_document.adoc

@@ -7,7 +7,7 @@ The purpose of this document is to provide detailed information on writing compo
 
 == Target Groups
 
-This document is intended for programmers of TTCN–3 test suites with information in addition to that provided in the <<_13, TITAN User Guide>>. It is recommended that the programmer reads the TITAN User Guide before reading this document.
+This document is intended for programmers of TTCN-3 test suites with information in addition to that provided in the <<_13, TITAN User Guide>>. It is recommended that the programmer reads the TITAN User Guide before reading this document.
 
 == Typographical Conventions
 

usrguide/referenceguide/10-code_coverage_of_ttcn-3_modules.adoc

@@ -33,7 +33,7 @@ tcov2lcov
 . Generate HTML using LCOV’s `genhtml` and the generated `output.info` (see <<converting-code-coverage-data-from-xml-to-html, here>> for more information):
 +
 [source]
-genhtml –no-branch-coverage –t "Titan Coverage" –legend output.info –o titan_coverage
+genhtml -no-branch-coverage -t "Titan Coverage" -legend output.info -o titan_coverage
 
 . Open `titan_coverage/index.html` in a browser.
 
@@ -43,7 +43,7 @@ genhtml –no-branch-coverage –t "Titan Coverage" –legend output.info –o t
 The `tcov2lcov` tool (binary tool) shipped with Titan and LCOV’s `genhtml` tool (Perl script) are provided to generate human readable HTML from the Titan generated .tcd XML code coverage data files. LCOV’s `genhtml` is not part of the Titan distribution and needs to be installed separately. The basic process is the following:
 
 . Execute `tcov2lcov` to collect and merge all the .tcd files generated during test execution. One .tcd file per component. By default an `output.info` file will be generated in the current working directory, which can be processed directly by LCOV’s `genhtml`. More detailed information about `tcov2lcov` can be found in 10.3.
-. Execute `genhtml` with `output.info` as its input parameter. The recommended parameters are the following:` genhtml –no-branch-coverage -t "Titan Coverage" –legend output.info -o titan_coverage`. For more detailed introduction to `genhtml` and LCOV in general please read their user manuals at http://ltp.sourceforge.net/coverage/lcov.php.
+. Execute `genhtml` with `output.info` as its input parameter. The recommended parameters are the following:` genhtml -no-branch-coverage -t "Titan Coverage" -legend output.info -o titan_coverage`. For more detailed introduction to `genhtml` and LCOV in general please read their user manuals at http://ltp.sourceforge.net/coverage/lcov.php.
 
 [[command-line-syntax-of-tcov2lcov]]
 == Command Line Syntax of tcov2lcov
@@ -86,4 +86,4 @@ The Titan compiler implements some optimizations which can affect the accuracy o
 
 External functions are not yet supported and they’re not shown in the statistics.
 
-The Titan code coverage implementation is based on Titan’s internal location tracking mechanism enabled by the `–L` compiler flag, which must be used together with `-K`. Sometimes it can lead to a little bit confusing or strange code coverage output. E.g. multiple location objects are generated when multiple variable declarations appear on the same line in the TTCN-3 source code. In this case the code coverage output will show that the given line is executed twice. For more complex statements like `for` three location objects are generated etc.
+The Titan code coverage implementation is based on Titan’s internal location tracking mechanism enabled by the `-L` compiler flag, which must be used together with `-K`. Sometimes it can lead to a little bit confusing or strange code coverage output. E.g. multiple location objects are generated when multiple variable declarations appear on the same line in the TTCN-3 source code. In this case the code coverage output will show that the given line is executed twice. For more complex statements like `for` three location objects are generated etc.

usrguide/referenceguide/11-the_ttcn-3_debugger.adoc

@@ -4,7 +4,7 @@
 
 The TTCN-3 debugger is a feature in TITAN, which allows the user to pause (halt) the execution of a TTCN-3 program and print (or in some cases overwrite) information about the current state of the program.
 
-The compiler option `–n` activates the debugger and augments the generated {cpp} code to store debug information and to allow the addition of breakpoints at runtime. For convenience this option is available for `ttcn3_makefilegen` as well.
+The compiler option `-n` activates the debugger and augments the generated {cpp} code to store debug information and to allow the addition of breakpoints at runtime. For convenience this option is available for `ttcn3_makefilegen` as well.
 
 == Gathered information
 
@@ -43,10 +43,10 @@ These snapshots contain a time stamp, the function’s name (or the module name
 
 The debugger provides several ways to halt a TTCN-3 program:
 
-* user breakpoints – breakpoints can be set by the user to any line or function in the TTCN-3 code;
-* automatic breakpoints – certain events can be set to halt the program automatically;
-* stepping – the user can step to the next line of code (when the program is already halted), or to a specific line or function;
-* manual halt – the user can halt the program manually (regardless of which line is currently being executed).
+* user breakpoints - breakpoints can be set by the user to any line or function in the TTCN-3 code;
+* automatic breakpoints - certain events can be set to halt the program automatically;
+* stepping - the user can step to the next line of code (when the program is already halted), or to a specific line or function;
+* manual halt - the user can halt the program manually (regardless of which line is currently being executed).
 
 When the program is halted, no further TTCN-3 code is executed, until the user manually resumes the program’s execution.
 
@@ -157,13 +157,13 @@ Description: Removes the breakpoint at the specified location (if it exists), or
 Examples:
 [source]
 ----
-Example 1 – removing one breakpoint, from module MyModule, line 114:
+Example 1 - removing one breakpoint, from module MyModule, line 114:
 drembp MyModule 114
 
-Example 2 – removing all breakpoints from module MyModule:
+Example 2 - removing all breakpoints from module MyModule:
 drembp MyModule all
 
-Example 3 – removing all breakpoints:
+Example 3 - removing all breakpoints:
 drembp all
 ----
 
@@ -177,8 +177,8 @@ Description: Activates or deactivates an automatic breakpoint, or changes the ba
 
 Automatic breakpoints are breakpoints triggered by specific events. The first argument indicates which automatic breakpoint to change:
 
-* *error* – triggered when the component’s verdict is set to `error` by a dynamic test case error (not all dynamic test case errors trigger this breakpoint, only those that actually change the local verdict to `error`);
-* *fail* – triggered when the component’s verdict is set to `fail` (by a `setverdict` operation.
+* *error* - triggered when the component’s verdict is set to `error` by a dynamic test case error (not all dynamic test case errors trigger this breakpoint, only those that actually change the local verdict to `error`);
+* *fail* - triggered when the component’s verdict is set to `fail` (by a `setverdict` operation.
 
 If the automatic breakpoint has a batch file set, then this batch file is automatically executed when the breakpoint is triggered.
 
@@ -200,7 +200,7 @@ NOTE: In parallel mode output files are created in the host’s working director
 [cols="m,",options="header",]
 |===
 |Meta-character |Substituted with . . .
-|%e |the name of the TTCN–3 executable. The `.exe` suffix (on Windows platforms) and the directory part of the path name (if present) are truncated.
+|%e |the name of the TTCN-3 executable. The `.exe` suffix (on Windows platforms) and the directory part of the path name (if present) are truncated.
 |%h |the name of the computer returned by the `gethostname`(2) system call. This usually does not include the domain name.
 |%l |the login name of the current user. If the login name cannot be determined (e.g. the current UNIX user ID has no associated login name) an empty string is returned.
 |%n a|* the name of the test component if the PTC has been given a name with the command `create` in the TTCN-3 `create` operation; an empty string otherwise. +
@@ -218,9 +218,9 @@ Default setting: all
 
 Description: Changes the method of storing function call data. The new configuration is specified by the command’s first argument:
 
-* 'all' – In this case all function calls are stored by the debugger. This option damages the program’s performance the most (specifically its memory consumption), since two long strings are stored every time a function is called and they are not deleted until the program’s execution ends.
-* _buffer size_ – This option sets an upper limit to the amount of function call snapshots stored (equal to `<buffer size>`). The function calls are stored in a ring buffer. If the buffer is full, then storing a new snapshot will cause the oldest stored snapshot to be erased. The buffer size can also be set to zero, in which case no function call data is stored.
-* 'file' – In this case the function call data is sent directly to a file and not stored by the debugger. The file is specified by the second argument.
+* 'all' - In this case all function calls are stored by the debugger. This option damages the program’s performance the most (specifically its memory consumption), since two long strings are stored every time a function is called and they are not deleted until the program’s execution ends.
+* _buffer size_ - This option sets an upper limit to the amount of function call snapshots stored (equal to `<buffer size>`). The function calls are stored in a ring buffer. If the buffer is full, then storing a new snapshot will cause the oldest stored snapshot to be erased. The buffer size can also be set to zero, in which case no function call data is stored.
+* 'file' - In this case the function call data is sent directly to a file and not stored by the debugger. The file is specified by the second argument.
 +
 The file name may contain special metacharacters, which are substituted dynamically during test execution.
 
@@ -434,7 +434,7 @@ NOTE: In parallel mode batch files are searched for in the MC’s working direct
 
 == Example
 
-This section contains an example for some of the debugger’s features. The example contains one TTCN-3 module with one test case, executed in single mode. Two tests are run. In both cases the debugging process is fully automated with the use of batch files. The executable’s –b command line option is used to run the first batch file.
+This section contains an example for some of the debugger’s features. The example contains one TTCN-3 module with one test case, executed in single mode. Two tests are run. In both cases the debugging process is fully automated with the use of batch files. The executable’s -b command line option is used to run the first batch file.
 
 The TTCN-3 module (demo.ttcn):
 [source]

usrguide/referenceguide/12-tips_&_troubleshooting.adoc

@@ -5,11 +5,11 @@ This chapter deals with various topics, which could not have been assigned to an
 
 == Type Aliasing
 
-Type aliasing in TTCN–3 means that you can assign an alternative name to an existing type. The syntax is similar to a subtype definition, but the subtype restriction tag (value list or length restriction) is missing.
+Type aliasing in TTCN-3 means that you can assign an alternative name to an existing type. The syntax is similar to a subtype definition, but the subtype restriction tag (value list or length restriction) is missing.
 
 `type MyType MyAlternativeName;`
 
-The type aliasing is implemented in the test executor, but it translates this TTCN–3 definition to a C `typedef` statement.
+The type aliasing is implemented in the test executor, but it translates this TTCN-3 definition to a C `typedef` statement.
 
 `typedef MyType MyAlternativeName;`
 
@@ -18,15 +18,15 @@ The limitation of the C typedef is that the {cpp} compiler cannot distinguish be
 As a work-around to this problem you can repeat the definition of the original type using the alternative name instead of type aliasing. In this case two differently named, but identical classes will be generated and the polymorphism problem will not occur.
 
 [[reusing-logged-values-or-templates-in-ttcn-3-code]]
-== Reusing Logged Values or Templates in TTCN–3 Code
+== Reusing Logged Values or Templates in TTCN-3 Code
 
 Writing templates can be time-consuming task. To save some time and work, you can use the logs of the messages already sent or received to write templates.
 
-If you would like to use a logged value in TTCN–3 code, then using the `logformat` utility (see the section 13.3 of the TITAN User Guide [13] about this utility) you have to follow these steps:
+If you would like to use a logged value in TTCN-3 code, then using the `logformat` utility (see the section 13.3 of the TITAN User Guide [13] about this utility) you have to follow these steps:
 
-. Start a text editor and open the (formatted) log file and the TTCN–3 source file.
+. Start a text editor and open the (formatted) log file and the TTCN-3 source file.
 . Select and copy the desired value from the log file.
-. Paste the value at the corresponding position in the TTCN–3 code.
+. Paste the value at the corresponding position in the TTCN-3 code.
 . Finally, make the following changes:
 +
 * The enumerated values are followed by their numerical equivalents within parentheses. Delete them including the parentheses.
@@ -56,10 +56,10 @@ There are minor issues when precompiling TTCN-3 code with a C preprocessor, thes
 
 * There are some predefined macros in the C preprocessor which will be always replaced, do not use any TTCN-3 identifier identical to these. These macros start with double underscore followed by uppercase letters. Some of the most common macros which might be useful:
 
-** – *FILE* This macro expands to the name of the current input file, in the form of a C string constant.
-** – *LINE* This macro expands to the current input line number, in the form of a decimal integer constant.
-** – *DATE* This macro expands to a string constant that describes the date on which the preprocessor is being run.
-** – *TIME* This macro expands to a string constant that describes the time at which the preprocessor is being run.
+** - *FILE* This macro expands to the name of the current input file, in the form of a C string constant.
+** - *LINE* This macro expands to the current input line number, in the form of a decimal integer constant.
+** - *DATE* This macro expands to a string constant that describes the date on which the preprocessor is being run.
+** - *TIME* This macro expands to a string constant that describes the time at which the preprocessor is being run.
 
 When writing preprocessor directives keep in mind that within the directive the C preprocessor syntax is in use, not the TTCN-3. Operators such as `defined` or || can be used.
 

usrguide/referenceguide/13-references.adoc

@@ -4,13 +4,13 @@
 * [1] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.01.01_60/es_20187301v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 1: Core Language European Telecommunications Standards Institute ES 201 873-1 Version 4.1.1, July 2009]
 
 [[_2]]
-* [2] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187304/04.01.01_60/es_20187304v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 4: TTCN–3 Operational Semantics European Telecommunications Standards Institute. ES 201 873-4 Version 4.1.1, June 2009]
+* [2] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187304/04.01.01_60/es_20187304v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 4: TTCN-3 Operational Semantics European Telecommunications Standards Institute. ES 201 873-4 Version 4.1.1, June 2009]
 
 [[_3]]
-* [3] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187307/04.01.01_60/es_20187307v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 7: Using ASN.1 with TTCN–3 European Telecommunications Standards Institute. ES 201 873-7 Version 4.1.1, July 2009]
+* [3] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187307/04.01.01_60/es_20187307v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 7: Using ASN.1 with TTCN-3 European Telecommunications Standards Institute. ES 201 873-7 Version 4.1.1, July 2009]
 
 [[_4]]
-* [4] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.01.01_60/es_20187309v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 9: Using XML Schema with TTCN–3 European Telecommunications Standards Institute. ES 201 873-9 Version 4.1.1, June 2009]
+* [4] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.01.01_60/es_20187309v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 9: Using XML Schema with TTCN-3 European Telecommunications Standards Institute. ES 201 873-9 Version 4.1.1, June 2009]
 
 [[_5]]
 * [5] link:https://www.etsi.org/deliver/etsi_es/202700_202799/202785/01.05.01_60/es_202785v010501p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. TTCN-3 Language Extensions: Behaviour Types European Telecommunications Standards Institute. ES 202 785 Version 1.5.1, Aug 2017]
@@ -31,7 +31,7 @@
 * [10] link:https://www.itu.int/rec/T-REC-X.690-200207-S[ITU-T, X.690, Information Technology ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)International Telecommunication Union, July 2002]
 
 [[_11]]
-* [11] ISO/IEC 10646-1, Information technology – Universal Multiple-Octet Coded Character Set (UCS) – Part 1: Architecture and Basic Multilingual Plane, Second edition, 200009-15
+* [11] ISO/IEC 10646-1, Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane, Second edition, 200009-15
 
 [[_12]]
 * [12] link:https://tools.ietf.org/html/rfc3629[RFC3629: UTF-8, a transformation format of ISO 10646]
@@ -73,7 +73,7 @@
 * [24] link:https://docs.mongodb.com/manual/reference/mongodb-extended-json/#bson-data-types-and-associated-representations[MongoDB Extended JSON document]
 
 [[_25]]
-* [25] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187311/04.08.01_60/es_20187311v040801p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 11: Using JSON with TTCN–3 European Telecommunications Standards Institute. ES 201 873-11 Version 4.8.1, May 2018]
+* [25] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187311/04.08.01_60/es_20187311v040801p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 11: Using JSON with TTCN-3 European Telecommunications Standards Institute. ES 201 873-11 Version 4.8.1, May 2018]
 
 [[_26]]
 * [26] link:https://www.etsi.org/deliver/etsi_es/202700_202799/202782/01.03.01_60/es_202782v010301p.pdf[ETSI ES 202 782 V1.3.1. (2015-06 Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: TTCN-3 Performance and Real Time Testing)]

usrguide/referenceguide/14-abbreviations.adoc

@@ -10,7 +10,7 @@ ATS:: Abstract Test Suite
 
 BER:: Basic Encoding Rules (of ASN.1)
 
-BNF:: Backus–Naur Formalism
+BNF:: Backus-Naur Formalism
 
 CER:: Canonical Encoding Rules (of ASN.1)
 
@@ -88,9 +88,9 @@ TR:: Trouble Report
 
 TTCN:: Testing and Test Control Notation
 
-TTCN–2:: Tree and Tabular Combined Notation version 2
+TTCN-2:: Tree and Tabular Combined Notation version 2
 
-TTCN–3:: Tree and Tabular Combined Notation version 3 (formerly)Testing and Test Control Notation (new resolution)
+TTCN-3:: Tree and Tabular Combined Notation version 3 (formerly)Testing and Test Control Notation (new resolution)
 
 UDP:: User Datagram Protocol
 

usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc

 = TTCN-3 Limitations in this Version
 :toc:
 
-The present Test Executor is an implementation of TTCN–3 Core Language standard (<<13-references.adoc#_1, [1]>>) with support of ASN.1 (<<13-references.adoc#_3, [3]>>). However, the following TTCN–3 language constructs are not supported in the current version of the Test Executor. When applicable, the relevant clause of the standard text (<<13-references.adoc#_1, [1]>>) is given within parentheses after each limitation. The list of ASN.1 related limitations can be found in chapter *4.25*.
+The present Test Executor is an implementation of TTCN-3 Core Language standard (<<13-references.adoc#_1, [1]>>) with support of ASN.1 (<<13-references.adoc#_3, [3]>>). However, the following TTCN-3 language constructs are not supported in the current version of the Test Executor. When applicable, the relevant clause of the standard text (<<13-references.adoc#_1, [1]>>) is given within parentheses after each limitation. The list of ASN.1 related limitations can be found in chapter *4.25*.
 
 * {cpp} code generation for parameterized local templates is not supported.footnote:[The semantic analyzer is able to verify modules with such definitions, but the generated {cpp} code will be incomplete or erroneous.] (5.0, relevant cells of Table 1)
-* Parameterized TTCN–3 `record`, `set` and `union types`. (5.4 in <<13-references.adoc#_1, [1]>>))
-* TTCN–3 sub-typing constraints are checked only at compilation time. In the run-time environment the restricted types are substituted with the corresponding base type and no run-time error is produced if the assigned value violates the subtype constraint.
-* The special TTCN–3 type `anytype` is supported with restrictions. (6.2.6 in <<13-references.adoc#_1, [1]>>)
+* Parameterized TTCN-3 `record`, `set` and `union types`. (5.4 in <<13-references.adoc#_1, [1]>>))
+* TTCN-3 sub-typing constraints are checked only at compilation time. In the run-time environment the restricted types are substituted with the corresponding base type and no run-time error is produced if the assigned value violates the subtype constraint.
+* The special TTCN-3 type `anytype` is supported with restrictions. (6.2.6 in <<13-references.adoc#_1, [1]>>)
 * Type compatibility of structured types.footnote:[Type compatibility for structured types is enabled only in the function test run-time due to performance considerations (except record of/set of types for certain element types, see section 4.32.2). In the load test run-time aliased types and sub-types are treated to be equivalent to their unrestricted root types. Different structured types are incompatible to each other. Two array types are compatible if both have the same size and index offset and the element types are compatible according to the rules above.] (6.3 in <<13-references.adoc#_1, [1]>>)
 * Two (non-empty) component types are considered to be compatible only if the compatibility relation is explicitly specified by the test suite writer. Details can be found in section 4.21. (6.3.3 and 9.3 in <<13-references.adoc#_1, [1]>>)
-* Selective import statements. All TTCN–3 imports are treated as `import all`.footnote:[Recursive and non-recursive import means exactly the same when importing all definitions from a module.] (8.2.3 and F.2 in <<13-references.adoc#_1, [1]>>)
-* Type `address` must not be an external type specified outside TTCN–3. The special value `null` cannot be assigned to variables of type `address`. (9.6 in <<13-references.adoc#_1, [1]>>)
-* The compiler does not check whether a TTCN–3 function invoked from within a `template`, Boolean guard expression of an alt construct, local variable initializer of an `altstep` or an `interleave` statement has side-effects. The run-time behavior is undefined if a function with side-effects (e.g. communication operations) is called while one of the above statements is being executed. (20 in <<13-references.adoc#_1, [1]>>)
+* Selective import statements. All TTCN-3 imports are treated as `import all`.footnote:[Recursive and non-recursive import means exactly the same when importing all definitions from a module.] (8.2.3 and F.2 in <<13-references.adoc#_1, [1]>>)
+* Type `address` must not be an external type specified outside TTCN-3. The special value `null` cannot be assigned to variables of type `address`. (9.6 in <<13-references.adoc#_1, [1]>>)
+* The compiler does not check whether a TTCN-3 function invoked from within a `template`, Boolean guard expression of an alt construct, local variable initializer of an `altstep` or an `interleave` statement has side-effects. The run-time behavior is undefined if a function with side-effects (e.g. communication operations) is called while one of the above statements is being executed. (20 in <<13-references.adoc#_1, [1]>>)
 * The `disconnect` and `unmap` operations cannot refer to multiple connections or mappings. (21.1.2, relevant parts in <<13-references.adoc#_1, [1]>>)
 * The `send` and `call` operations cannot be used for multicast or broadcast communication. (22.2.1 and 22.3.1 in <<13-references.adoc#_1, [1]>>)
 * Attributes of type definitions cannot be changed when they are being imported. (27.1.2.1 in <<13-references.adoc#_1, [1]>>)
 * Template instances cannot be used in the to clause of communication operations. Only values of `component` and `address` types are allowed. (stated only in BNF)
 * The additional predefined function `decomp` is not implemented. (D.2 of <<13-references.adoc#_3, [3]>>)
 * In `port type` definitions the list of incoming and outgoing message types or signatures must be explicitly specified, the `all` keyword is ignored by the compiler. (G.3 in <<13-references.adoc#_1, [1]>>)
-* The TTCN–3 and ASN.1 modules are identified only by their names. Object identifiers in module headers are ignored. Module object identifiers in `import` statements and references are skipped without any checking, the semantic analyzer uses the module identifier only. (7.2.3 of <<13-references.adoc#_3, [3]>>, 8.1 in <<13-references.adoc#_1, [1]>>)
+* The TTCN-3 and ASN.1 modules are identified only by their names. Object identifiers in module headers are ignored. Module object identifiers in `import` statements and references are skipped without any checking, the semantic analyzer uses the module identifier only. (7.2.3 of <<13-references.adoc#_3, [3]>>, 8.1 in <<13-references.adoc#_1, [1]>>)
 * The comparison operators do not work on `objid` values. Only the equality (==) and non-equality (!=) operators are allowed. (7.2.5.2 of <<13-references.adoc#_3, [3]>>, 7.1.3 in <<13-references.adoc#_1, [1]>>)
 * Templates can not be used in the parameter of `encvalue` built-in function. (C.38 in <<13-references.adoc#_1, [1]>>)
 * The declaration of object identifiers can only point to constant values and integer variables, references to `objid` variables are not supported.

usrguide/referenceguide/3-clarifications_to_the_ttcn-3_standard.adoc

 = Clarifications to the TTCN-3 Standard
 :toc:
 
-The TTCN–3 Core Language standard (<<13-references.adoc#_1, [1]>>) and its Operational Semantics (<<13-references.adoc#_1, [1]>>) give ambiguous description for some language constructs. This section specifies our resolution for these ambiguities that was followed during the implementation of our compiler and run-time environment.
+The TTCN-3 Core Language standard (<<13-references.adoc#_1, [1]>>) and its Operational Semantics (<<13-references.adoc#_1, [1]>>) give ambiguous description for some language constructs. This section specifies our resolution for these ambiguities that was followed during the implementation of our compiler and run-time environment.
 
 == Predefined Function Identifiers
 
@@ -29,7 +29,7 @@ In the standard, it is not clear that the `VariableList` notation in the `param`
 
 == References between Language Elements
 
-The TTCN–3 standard does not specify clearly the permitted references between different kinds of language elements. The following table shows our interpretation.
+The TTCN-3 standard does not specify clearly the permitted references between different kinds of language elements. The following table shows our interpretation.
 
 .References between TTCN-3 elements
 [cols=",,,,,",options="header",]
@@ -46,16 +46,16 @@ The TTCN–3 standard does not specify clearly the permitted references between
 
 Legend:
 
-* N Not allowed by the TTCN–3 language.
+* N Not allowed by the TTCN-3 language.
 
-* Y Allowed and fully supported by the current version of this TTCN–3 tool.
+* Y Allowed and fully supported by the current version of this TTCN-3 tool.
 
 * Y* Allowed and fully supported, but circular reference chains must be avoided.
 
 [NOTE]
 ====
 * The above table implies that the value of all constants and the attributes of all type constructs (type constraints, array sizes, etc.) shall be known at compilation time.
-* ASN.1 value assignments are treated as TTCN–3 constants.
+* ASN.1 value assignments are treated as TTCN-3 constants.
 * The value of constants shall refer only to built-in operators or additional predefined functions.
 * The body of non-parameterized templates and the default duration of timers shall be known at test startup (load) time when all module parameters are known.
 * The actual parameters of templates or the actual duration of timers shall be determined run-time because the actual value of variables may be referred.
@@ -77,22 +77,22 @@ The standard does not specify clearly some of the encoding rules.
 
 == Address Type
 
-The standard does not specify clearly the status of special TTCN–3 type `address`. Our implementation is based on the rules below.
+The standard does not specify clearly the status of special TTCN-3 type `address`. Our implementation is based on the rules below.
 
-The test suite writer can assign the name `address` to a regular data type. There can be at most one type named `address` in each TTCN–3 module. It is allowed that different modules of the test suite assign the name `address` to different types.
+The test suite writer can assign the name `address` to a regular data type. There can be at most one type named `address` in each TTCN-3 module. It is allowed that different modules of the test suite assign the name `address` to different types.
 
-The name `address` cannot be assigned to the following TTCN–3 types:
+The name `address` cannot be assigned to the following TTCN-3 types:
 
 * port types
 * component typesfootnote:[If component types were allowed for addressing the compiler would not be able to decide whether a component reference in the to or from clause of a communication operation denotes a test component, which is reachable through a port connection or an address inside the SUT, which is reachable through a port mapping.]
 * signatures
-* the built-in type defaultfootnote:[The values of type default (i.e. the TTCN–3 default references) cannot be passed outside the test component by any means.]
+* the built-in type defaultfootnote:[The values of type default (i.e. the TTCN-3 default references) cannot be passed outside the test component by any means.]
 
-Whenever the word `address` is used as a type, it is assumed to be a reference to the type named `address` in the current module. The type named `address` cannot be imported into another TTCN–3 module, that is, it can be referenced using the name `address` only within its own module. If one wants to use this type in other modules a regular alternate name must be assigned to it with type aliasing.
+Whenever the word `address` is used as a type, it is assumed to be a reference to the type named `address` in the current module. The type named `address` cannot be imported into another TTCN-3 module, that is, it can be referenced using the name `address` only within its own module. If one wants to use this type in other modules a regular alternate name must be assigned to it with type aliasing.
 
 Addressing the SUT in communication operations is allowed only if the `address` type is defined in the same module as the corresponding port type. In addition, the port type must have a special `extension` attribute to support `address` values (See section "Support of address type" in <<13-references.adoc#_16, [16]>> for more details).
 
-Note that it is possible to use different address types on different ports in the same TTCN–3 module if the respective port types are imported from different modules, but neither address type may be referenced with name `address` by the importing module.
+Note that it is possible to use different address types on different ports in the same TTCN-3 module if the respective port types are imported from different modules, but neither address type may be referenced with name `address` by the importing module.
 
 [[importing-import-statement-from-ttcn-3-modules]]
 == Importing import Statement from TTCN-3 Modules
@@ -170,9 +170,9 @@ This isn't the case in the TITAN runtime. Values only have 2 states: _bound_ and
 * `record` / `set`: unbound = uninitialized, bound = at least partially initialized, meaning that a `record` / `set` is bound if at least one of its fields is boundfootnote:[The bound state of fields or elements is also determined by using the isbound operation on the field or element.];
 * `record of` / `set of`: unbound = uninitialized, bound = at least partially initialized, meaning that the record of is only unbound if it has never received an initial value (even initializing with {} creates a bound `record of` / `set of` value);
 * `array`: unbound = uninitialized or partially initialized, bound = fully initialized, meaning that the array is only bound if all of its elements are bound;
-* `unions` can't be partially initialized, so TITAN stores their bound state correctly (although it's still possible to create `union` values, where the selected alternative is unbound, with the legacy command line option `–B`; these values would be considered bound by TITAN).
+* `unions` can't be partially initialized, so TITAN stores their bound state correctly (although it's still possible to create `union` values, where the selected alternative is unbound, with the legacy command line option `-B`; these values would be considered bound by TITAN).
 
-There is a workaround in TITAN's implementation of `records` / `sets` to allow the copying of partially initialized values (`union` values with unbound selected alternatives can also be copied when the compiler option `–B` is set). In all other cases the user is responsible for making sure the value is usable on the right hand side of an operation. The `isbound` function is usually not enough to ensure, that the value is usable.
+There is a workaround in TITAN's implementation of `records` / `sets` to allow the copying of partially initialized values (`union` values with unbound selected alternatives can also be copied when the compiler option `-B` is set). In all other cases the user is responsible for making sure the value is usable on the right hand side of an operation. The `isbound` function is usually not enough to ensure, that the value is usable.
 
 == Concatenation of templates
 

usrguide/referenceguide/5-supported_asn1_constructs_and_limitations.adoc

@@ -7,7 +7,7 @@ All kind of comments defined in X.680 clause 11.6 can be used (<<13-references.a
 
 All tagging environment is supported: `IMPLICIT`, `EXPLICIT` and also `AUTOMATIC`.
 
-The type constraints are ignored. The BER (de)coding is not influenced by the constraints, except for the table constraints. For details, see section <<6-compiling_ttcn3_and_asn1_modules.adoc#using-component-relation-constraints-from-ttcn-3, Using Component Relation Constraints from TTCN–3>>.
+The type constraints are ignored. The BER (de)coding is not influenced by the constraints, except for the table constraints. For details, see section <<6-compiling_ttcn3_and_asn1_modules.adoc#using-component-relation-constraints-from-ttcn-3, Using Component Relation Constraints from TTCN-3>>.
 
 Table 11 summarizes how the different ASN.1 types are supported.
 

usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc

@@ -14,7 +14,7 @@ Tpd files can be used without TITAN Designer for example for generating hierarch
 
 TPD files are designed to be created by the Eclipse Designer but it can be created or modified by experts.
 
-The data is stored in XML format. The schema definition of the project descriptor is delivered with the Titan package and can be found in the `${TTCN3_DIR}/etc/xsd/TPD.xsd` file. If the type of an element is a subtype of string, for example a file name or a path, the xsd file doesn’t restrict it but uses only string or NormalizedString as type. Although the compliance of a TPD file for TPD.xsd is a necessary but not sufficient statement, it is very useful to verify the tpd file against TPD.xsd for example with this command: `xmllint –noout –schema XSD_FILE XML_FILE`
+The data is stored in XML format. The schema definition of the project descriptor is delivered with the Titan package and can be found in the `${TTCN3_DIR}/etc/xsd/TPD.xsd` file. If the type of an element is a subtype of string, for example a file name or a path, the xsd file doesn’t restrict it but uses only string or NormalizedString as type. Although the compliance of a TPD file for TPD.xsd is a necessary but not sufficient statement, it is very useful to verify the tpd file against TPD.xsd for example with this command: `xmllint -noout -schema XSD_FILE XML_FILE`
 
 Each element is designed to be extendable, so for almost all elements there is a default value defined, if the element is missing this value is used.To simplify the reviews the elements are always saved in an ordered fashion thus limiting the effects of minor changes. The lists can contain from 0 to infinite elements. The O/M column in the tables describes if the element is optional or mandatory.
 
@@ -64,7 +64,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
-|`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
+|`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
 |===
 
 Example:
@@ -136,7 +136,7 @@ Example:
 
 The ActiveConfiguration element stores the name of the active build configuration whose parameters will be used by TITAN for building the project.
 
-NOTE: This can be overwritten from TITAN Designer (from Eclipse) or from command line generating Makefile(s) by ttcn3_makefilegen using the –b flag, see <<6-compiling_ttcn3_and_asn1_modules.adoc#using-the-makefile-generator-to-generate-makefile-s-from-titan-project-descriptor-file-s, here>>.
+NOTE: This can be overwritten from TITAN Designer (from Eclipse) or from command line generating Makefile(s) by ttcn3_makefilegen using the -b flag, see <<6-compiling_ttcn3_and_asn1_modules.adoc#using-the-makefile-generator-to-generate-makefile-s-from-titan-project-descriptor-file-s, here>>.
 
 See also chapter <<configurations, Configurations>>.
 
@@ -201,7 +201,7 @@ Useful information can be found in TITAN Designer documentation <<13-references.
 |`functiontestRuntime (use function test runtime (TITAN_RUNTIME_2)` |-R |-R |false |O
 |`singleMode` |-s |- |false |O
 |`codeSplitting (select code splitting mode for the generated {cpp} code)` |-U |-U |none |O
-|`defaultTarget ("executable" or "library", if –L applied, see 6.1.2)` |-L |- |executable |O
+|`defaultTarget ("executable" or "library", if -L applied, see 6.1.2)` |-L |- |executable |O
 |`targetExecutable` |-e |- |N/A |O
 |`TTCN3preprocessor (the name of the preprocessor meaningful only in Eclipse)` |- |- |cpp |O
 |`TTCN3preprocessorIncludes` |- |- |empty |O
@@ -280,7 +280,7 @@ Contents of the `ProjectSpecificRulesGenerator` element:
 
 Exactly one `GeneratorCommand` element that specifies the external command to be run
 
-An optional Targets element that contains any number of Target elements, each element having two attributes: name – name of the target, placement – the place of where the target shall be inserted. Possible places are defined in the TPD.xsd file.
+An optional Targets element that contains any number of Target elements, each element having two attributes: name - name of the target, placement - the place of where the target shall be inserted. Possible places are defined in the TPD.xsd file.
 
 The content of the `profiledFileList` element is the path to a text file, using the same path attributes as `FileResource` elements. The text file contains the list of files (TTCN-3 modules), that will be profiled, separated by new lines. This file is stored in the variable `PROFILED_FILE_LIST` in the generated makefile.
 

usrguide/referenceguide/9-xsd_to_ttcn-3_converter.adoc

@@ -295,7 +295,7 @@ Information in the `appinfo` tags are not translated.
 
 == Extensions
 
-The XSD to TTCN-3 Converted has the following non-standard additions to the Using XML Schema with TTCN–3 <<13-references.adoc#_4, [4]>> .
+The XSD to TTCN-3 Converted has the following non-standard additions to the Using XML Schema with TTCN-3 <<13-references.adoc#_4, [4]>> .
 
 TITAN allows the usage of constants and module parameters in the value of a `defaultForEmpty` encoding instruction. The `xsd2ttcn` tool generates the `defaultForEmpty` encoding instructions with a constant definition as a value to provide reusability of the `defaultForEmpty` values. Only the conversion of `default` and `fixed` attributes of elements is changed.
 

usrguide/referenceguide/ReferenceGuide.adoc

@@ -35,9 +35,9 @@ ifdef::env-github,backend-html5[]
 * link:1-about_the_document.adoc[About the document]
 * link:2-ttcn-3_limitations_in_this_version.adoc[TTCN-3 Limitations in this Version]
 * link:3-clarifications_to_the_ttcn-3_standard.adoc[Clarifications to the TTCN-3 Standard]
-* link:4-ttcn3_language_extensions.adoc[TTCN–3 Language Extensions]
+* link:4-ttcn3_language_extensions.adoc[TTCN-3 Language Extensions]
 * link:5-supported_asn1_constructs_and_limitations.adoc[Supported ASN.1 Constructs and Limitations]
-* link:6-compiling_ttcn3_and_asn1_modules.adoc[Compiling TTCN–3 and ASN.1 Modules]
+* link:6-compiling_ttcn3_and_asn1_modules.adoc[Compiling TTCN-3 and ASN.1 Modules]
 * link:7-the_run-time_configuration_file.adoc[The Run-time Configuration File]
 * link:8-the_titan_project_descriptor_file.adoc[The TITAN Project Descriptor File]
 * link:9-xsd_to_ttcn-3_converter.adoc[XSD to TTCN-3 Converter]