diff --git a/chapters/annotations.tex b/chapters/annotations.tex
index fa2ee5768..f5fa9ca07 100644
--- a/chapters/annotations.tex
+++ b/chapters/annotations.tex
@@ -567,7 +567,7 @@ \section{Graphical Objects}\label{annotations-for-graphical-objects}\label{graph
 is no mechanism for defining an array of heterogeneous objects in Modelica.
 \end{nonnormative}
 
-These \lstinline!Icon!, \lstinline!Diagram!, and \lstinline!Documentation! annotations are only allowed directly in classes (e.g.\ not on components or connections).
+These \lstinline!Icon!, \lstinline!Diagram!, and \lstinline!Documentation! annotations are only allowed directly in classes (e.g., not on components or connections).
 The allowed annotations for a short class definition is the union of the allowed annotations in classes and on \lstinline!extends!-clauses.
 
 \subsection{Common Definitions}\label{common-definitions}
@@ -613,7 +613,7 @@ \subsubsection{Coordinate Systems}\label{coordinate-systems}
 application may use a different default value of \lstinline!initialScale!.
 
 The attribute \lstinline!grid! specifies the spacing between grid points which can
-be used by tools for alignment of points in the coordinate system, e.g.\ ``snap-to-grid''.
+be used by tools for alignment of points in the coordinate system, e.g., ``snap-to-grid''.
 Its use and default value is tool-dependent.
 
 \begin{lstlisting}[language=modelica]
@@ -630,7 +630,7 @@ \subsubsection{Coordinate Systems}\label{coordinate-systems}
 \begin{lstlisting}[language=modelica]
 CoordinateSystem(extent = {{-10, -10}, {10, 10}});
 \end{lstlisting}
-i.e.\ a coordinate system with width 20 units and height 20 units.
+i.e., a coordinate system with width 20 units and height 20 units.
 \end{example}
 
 The coordinate systems for the icon and diagram layers are by default defined as follows; where the array of \lstinline!GraphicItem! represents an ordered list of graphical primitives.
@@ -1666,7 +1666,7 @@ \subsubsection{Conversion Rules}\label{conversion-rules}
 corresponding to the old version.
 
 \begin{nonnormative}
-Whenever possible tools should preserve the original style of the model, e.g.\ use of imports.
+Whenever possible tools should preserve the original style of the model, e.g., use of imports.
 Conversions should be applied in all places where named element are used in code, including Modelica URIs (for example, in \lstinline!Documentation! annotations).
 \end{nonnormative}
 
@@ -1674,7 +1674,7 @@ \subsubsection{Conversion Rules}\label{conversion-rules}
 and vectorize according to \cref{scalar-functions-applied-to-array-arguments}.
 
 All of these convert-functions only use inheritance among user models, and not in the library that is used for the conversion -- thus conversions of base classes will require multiple conversion calls; this ensures that the conversion is independent of the new library structure.
-The name of the class used as argument to \lstinline!convertElement! and \lstinline!convertModifiers! is similarly the old name of the class, i.e.\ the name before it is possibly converted by \lstinline!convertClass!.
+The name of the class used as argument to \lstinline!convertElement! and \lstinline!convertModifiers! is similarly the old name of the class, i.e., the name before it is possibly converted by \lstinline!convertClass!.
 
 \begin{nonnormative}
 Specifying conversions using the old name of a class allows the conversion to be done without access to the old
@@ -1708,7 +1708,7 @@ \subsubsection{Conversion Rules}\label{conversion-rules}
 
 The old element should be of a \lstinline!Boolean!, \lstinline!Integer!, \lstinline!String!, or enumeration
 type and the match is based on the literal value of the modifier.
-For string elements the value argument to \lstinline!convertClassIf! shall be up-quoted, e.g.\ \lstinline!"\"My String\""!,
+For string elements the value argument to \lstinline!convertClassIf! shall be up-quoted, e.g., \lstinline!"\"My String\""!,
 and for enumeration literals only the enumeration literal part of the old value matters, e.g., \lstinline!red!
 for \lstinline!"Colors.red"!.
 
@@ -1796,7 +1796,7 @@ \subsubsection{Conversion Rules}\label{conversion-rules}
 connector \lstinline!B! is connected, there will be a parameter for enabling connector \lstinline!B!, and the conversion ensures that
 each component of model \lstinline!A! will have this parameter set accordingly.
 
-In case a parameter is simply renamed it is preferable to use \lstinline!convertElement!, since that also handles e.g.\ binding equations
+In case a parameter is simply renamed it is preferable to use \lstinline!convertElement!, since that also handles, e.g., binding equations
 using the parameter.
 \end{nonnormative}
 
@@ -1973,7 +1973,7 @@ \subsection{Version Date and Build Information}\label{version-date-and-build-inf
   \end{nonnormative}
 \item
   \lstinline!revisionId! is a tool specific revision identifier
-  possibly generated by a source code management system (e.g.\ Subversion
+  possibly generated by a source code management system (e.g., Subversion
   or CVS). This information exactly identifies the library
   source code in the source code management system.
 \end{itemize}
@@ -2020,7 +2020,7 @@ \section{Access Control to Protect Intellectual Property}\label{annotations-for-
 \end{definition}
 
 \begin{definition}[Obfuscation]\index{obfuscation!access control}
-Changing a Modelica class or generated code so that it is difficult to inspect by a user (e.g.\ by automatically renaming variables to non-meaningful names).
+Changing a Modelica class or generated code so that it is difficult to inspect by a user (e.g., by automatically renaming variables to non-meaningful names).
 \end{definition}
 
 \begin{definition}[Encryption]\index{encryption!access control}
@@ -2183,7 +2183,7 @@ \subsection{Licensing}\label{licensing}
 
 record License
   String licensee = "" "Optional string to show information about the licensee";
-  String id[:] "Unique machine identifications, e.g.\ MAC addresses";
+  String id[:] "Unique machine identifications, e.g., MAC addresses";
   String features[:] = fill("", 0) "Activated library license features";
   String startDate = "" "Optional start date in UTCformat YYYY-MM-DD";
   String expirationDate = "" "Optional expiration date in UTCformat YYYY-MM-DD";
diff --git a/chapters/arrays.tex b/chapters/arrays.tex
index ac28fad7f..82294f62f 100644
--- a/chapters/arrays.tex
+++ b/chapters/arrays.tex
@@ -40,7 +40,7 @@ \section{Array Declarations}\label{array-declarations}
 The following table shows the two possible forms of declarations and defines the terminology.
 % Is the use of "class" here meant to exclude types defined as array aliases (see comment in table below)?
 \lstinline!C! is a placeholder for any class, including the built-in type classes \lstinline!Real!, \lstinline!Integer!, \lstinline!Boolean!, \lstinline!String!, and enumeration types.
-The type of a dimension upper bound expression, e.g.\ $n$, $m$, $p$, \ldots in the table below, need to be a subtype of \lstinline!Integer! or \lstinline!EB! for a class \lstinline!EB! that is an enumeration type or subtype of the \lstinline!Boolean! type.
+The type of a dimension upper bound expression, e.g., $n$, $m$, $p$, \ldots in the table below, need to be a subtype of \lstinline!Integer! or \lstinline!EB! for a class \lstinline!EB! that is an enumeration type or subtype of the \lstinline!Boolean! type.
 
 Colon (\lstinline!:!) indicates that the dimension upper bound is unknown and is a subtype of \lstinline!Integer!.
 The size of such a variable can be determined from its binding equation, or the size of any of its array attributes, see also \cref{flexible-array-sizes-and-resizing-of-arrays-in-functions}.
@@ -51,7 +51,7 @@ \section{Array Declarations}\label{array-declarations}
 An array indexed by \lstinline!Boolean! or enumeration type can only be used in the following ways:
 \begin{itemize}
 \item
-  Subscripted using expressions of the appropriate type (i.e.\ \lstinline!Boolean! or the enumerated type).
+  Subscripted using expressions of the appropriate type (i.e., \lstinline!Boolean! or the enumerated type).
 \item
   Binding equations of the form \lstinline!x1 = x2! are allowed for arrays independent of whether the index types of dimensions are subtypes of \lstinline!Integer!, \lstinline!Boolean!, or enumeration types.
 \end{itemize}
@@ -227,7 +227,7 @@ \section{Built-in Array Functions}\label{built-in-array-functions}
 
 The argument $n$ must be a constant that can be evaluated during translation, as it determines the number of dimensions of the returned array.
 \begin{nonnormative}
-An $n$ that is not a constant that can be evaluated during translation for \lstinline!promote! complicates matrix handling as it can change matrix-equations in subtle ways (e.g.\ changing inner products to matrix multiplication).
+An $n$ that is not a constant that can be evaluated during translation for \lstinline!promote! complicates matrix handling as it can change matrix-equations in subtle ways (e.g., changing inner products to matrix multiplication).
 \end{nonnormative}
 \end{semantics}
 \end{operatordefinition}
@@ -860,7 +860,7 @@ \subsubsection{Concatenation along First and Second Dimensions}\label{array-conc
 \item
   \lstinline![A] = promote(A, max(2, ndims(A)))!, i.e., \lstinline![A] = A!, if \lstinline!A! has 2 or more dimensions, and it is a matrix with the elements of \lstinline!A!, if \lstinline!A! is a scalar or a vector.
 \item
-  There must be at least one argument (i.e.\ \lstinline![]! is not defined).
+  There must be at least one argument (i.e., \lstinline![]! is not defined).
 \end{itemize}
 
 \begin{example}
@@ -1312,7 +1312,7 @@ \subsection{Element-wise Exponentiation}\label{element-wise-exponentiation}
 2.^[1, 2; 3, 4]  // error; same as 2.0 ^ [1, 2; 3, 4]
 2 .^[1, 2; 3, 4] // fine; element-wise exponentiation
 \end{lstlisting}
-This is a consequence of the parsing rules, i.e.\ since \lstinline!2.! could be a lexical unit it seen as a lexical unit; using a space after
+This is a consequence of the parsing rules, i.e., since \lstinline!2.! could be a lexical unit it seen as a lexical unit; using a space after
 literals solves the problem.
 \end{example}
 
@@ -1343,7 +1343,7 @@ \subsection{Slice Operation}\label{slice-operation}
 \item
   If \lstinline!m! is also an array component, the slice operation is valid only if \lstinline!size(a[1].m)! = \lstinline!size(a[2].m)! = \ldots
 \item
-  The slicing operation can be combined with indexing, e.g.\ \lstinline!a.m[1]!.  It returns the array of components \lstinline!{a[1].m[1], a[2].m[1], $\ldots$}!,
+  The slicing operation can be combined with indexing, e.g., \lstinline!a.m[1]!.  It returns the array of components \lstinline!{a[1].m[1], a[2].m[1], $\ldots$}!,
   and does not require that \lstinline!size(a[1].m) = size(a[2].m)!.  The number of subscripts on \lstinline!m! must not be greater than the number of array dimension
   for \lstinline!m! (the number can be smaller, in which case the missing trailing indices are assumed to be `\lstinline!:!'), and is only valid if
   \lstinline!size(a[1].m[$\ldots$]) = size(a[2].m[$\ldots$])!.
diff --git a/chapters/classes.tex b/chapters/classes.tex
index cd886c75f..ab89615ef 100644
--- a/chapters/classes.tex
+++ b/chapters/classes.tex
@@ -46,7 +46,7 @@ \section{Access Control -- Public and Protected Elements}\label{access-control-p
 \end{example}
 
 All elements defined under the heading \lstinline!protected! are regarded as protected.  All other elements (i.e., defined
-under the heading \lstinline!public!, without headings or in a separate file) are public (i.e.\ not protected).  Regarding
+under the heading \lstinline!public!, without headings or in a separate file) are public (i.e., not protected).  Regarding
 inheritance of protected and public elements, see \cref{inheritance-of-protected-and-public-elements}.
 
 
@@ -130,7 +130,7 @@ \subsection{Syntax}\label{component-declaration-syntax}\label{syntax-and-example
 
 \begin{nonnormative}
 The declaration of a component states the type, access, variability, data flow, and other properties of the component.
-A \lstinline[language=grammar]!component-clause! i.e., the whole declaration, contains type prefixes followed by a \lstinline[language=grammar]!type-specifier! with optional \lstinline[language=grammar]!array-subscripts! followed by a \lstinline[language=grammar]!component-list!.
+A \lstinline[language=grammar]!component-clause!, i.e., the whole declaration, contains type prefixes followed by a \lstinline[language=grammar]!type-specifier! with optional \lstinline[language=grammar]!array-subscripts! followed by a \lstinline[language=grammar]!component-list!.
 
 There is no semantic difference between variables declared in a single declaration or in multiple declarations.
 For example, regard the following single declaration (\lstinline[language=grammar]!component-clause!) of two matrix variables:
@@ -464,7 +464,7 @@ \subsection{Component Variability Prefixes}\label{component-variability-prefixes
 A constant variable is similar to a parameter with the difference
 that constants cannot be changed after translation and usually not
 changed after they have been given a value. It can be used to represent
-mathematical constants, e.g.
+mathematical constants, e.g.:
 \begin{lstlisting}[language=modelica]
 final constant Real PI = 4*atan(1);
 \end{lstlisting}
@@ -926,7 +926,7 @@ \section{Balanced Models}\label{balanced-models}
 redeclaration cannot lead to an unbalanced model any more.
 \end{nonnormative}
 
-The restrictions below apply after flattening -- i.e.\ inherited components are included -- possibly modified.  The corresponding restrictions on connectors and connections are in
+The restrictions below apply after flattening -- i.e., inherited components are included -- possibly modified.  The corresponding restrictions on connectors and connections are in
 \cref{restrictions-of-connections-and-connectors}.
 
 \begin{definition}[Local number of unknowns]\index{local number of unknowns}
@@ -957,7 +957,7 @@ \section{Balanced Models}\label{balanced-models}
 The local equation size of a \lstinline!model! or \lstinline!block! class is the sum of the following numbers:
 \begin{itemize}
 \item
-  The number of equations defined locally (i.e.\ not in any \lstinline!model! or \lstinline!block! component), including binding equations, and equations generated from \lstinline!connect!-equations.
+  The number of equations defined locally (i.e., not in any \lstinline!model! or \lstinline!block! component), including binding equations, and equations generated from \lstinline!connect!-equations.
   \begin{nonnormative}
   This includes the proper count for \lstinline!when!-clauses (see \cref{when-equations}), and algorithms (see \cref{algorithm-sections}), and is also used for
   the flat Hybrid DAE formulation (see \cref{modelica-dae-representation}).
@@ -1006,7 +1006,7 @@ \section{Balanced Models}\label{balanced-models}
 \begin{definition}[Globally balanced]\index{globally balanced}\index{balanced!globally}
 Similarly as locally balanced, but including all unknowns and equations
 from all components. The global number of unknowns is computed by
-expanding all unknowns (i.e.\ excluding parameters and constants) into a
+expanding all unknowns (i.e., excluding parameters and constants) into a
 set of scalars of primitive types. This should match the global equation
 size defined as:
 \begin{itemize}
@@ -1027,7 +1027,7 @@ \section{Balanced Models}\label{balanced-models}
 \item
   In a non-partial \lstinline!model! or \lstinline!block!, all non-connector inputs of \lstinline!model! or \lstinline!block! components must have binding equations.
   \begin{nonnormative}
-  E.g.\ if the model contains a component, \lstinline!firstOrder! (of specialized class \lstinline!model!) and \lstinline!firstOrder! has
+  E.g., if the model contains a component, \lstinline!firstOrder! (of specialized class \lstinline!model!) and \lstinline!firstOrder! has
   \lstinline!input Real u! then there must be a binding equation for \lstinline!firstOrder.u!.
   Note that this also applies to components inherited from a partial base-class provided the current class is non-partial.
   \end{nonnormative}
@@ -1097,7 +1097,7 @@ \section{Balanced Models}\label{balanced-models}
 \end{align*}
 and 2 equations corresponding to the 2 flow variables \lstinline!p.i! and \lstinline!n.i!.
 
-These are 5 equations in 5 unknowns (locally balanced model).  A more detailed analysis would reveal that this is structurally non-singular, i.e.\ that
+These are 5 equations in 5 unknowns (locally balanced model).  A more detailed analysis would reveal that this is structurally non-singular, i.e., that
 the hybrid DAE will not contain a singularity independent of actual values.
 
 If the equation \lstinline!u = p.v - n.v! would be missing in the \lstinline!Capacitor! model, there would be 4 equations in 5 unknowns and the model
@@ -1397,7 +1397,7 @@ \section{Predefined Types and Classes}\label{predefined-types-and-classes}
 \end{nonnormative}
 
 \begin{nonnormative}
-It also follows that the only way to declare a subtype of e.g.\ \lstinline!Real! is to use the \lstinline!extends! mechanism.
+It also follows that the only way to declare a subtype of, e.g., \lstinline!Real! is to use the \lstinline!extends! mechanism.
 \end{nonnormative}
 
 The definitions use \lstinline!RealType!\indexinline{RealType}, \lstinline!IntegerType!\indexinline{IntegerType}, \lstinline!BooleanType!\indexinline{BooleanType}, \lstinline!StringType!\indexinline{StringType}, \lstinline!EnumType!\indexinline{EnumType} as mnemonics corresponding to machine representations.
@@ -1696,7 +1696,7 @@ \subsection{Attributes start, fixed, nominal, and unbounded}\label{attributes-st
 
 The attributes \lstinline!start! and \lstinline!fixed! define the initial conditions for a variable.  \lstinline!fixed = false! means an initial guess, i.e., value may be changed by static analyzer.  \lstinline!fixed = true! means a required value.  The resulting consistent set of values for \emph{all} model variables is used as initial values for the analysis to be performed.
 
-The attribute \lstinline!nominal! gives the nominal value for the variable.  The user need not set it even though the standard does not define a default value.  The lack of default allows the tool to propagate the nominal attribute based on equations, and if there is no value to propagate the tool should use a non-zero value, it may use additional information (e.g.\ \lstinline!min! attribute) to find a suitable value, and as last resort use 1.  If \lstinline!unbounded = true! it indicates that the state may grow without bound, and the error in absolute terms shall be controlled.
+The attribute \lstinline!nominal! gives the nominal value for the variable.  The user need not set it even though the standard does not define a default value.  The lack of default allows the tool to propagate the nominal attribute based on equations, and if there is no value to propagate the tool should use a non-zero value, it may use additional information (e.g., \lstinline!min! attribute) to find a suitable value, and as last resort use 1.  If \lstinline!unbounded = true! it indicates that the state may grow without bound, and the error in absolute terms shall be controlled.
 
 \begin{nonnormative}
 The nominal value can be used by an analysis tool to determine appropriate tolerances or epsilons, or may be used for scaling.  For example, the tolerance for an integrator could be computed as \lstinline!tol * (abs(nominal) + (if x.unbounded then 0 else abs(x)))!.  A default value is not provided in order that in cases such as \lstinline!a = b!, where \lstinline!b! has a nominal value but not \lstinline!a!, the nominal value can be propagated to the other variable).
diff --git a/chapters/connectors.tex b/chapters/connectors.tex
index d3d259857..fe34475f6 100644
--- a/chapters/connectors.tex
+++ b/chapters/connectors.tex
@@ -115,7 +115,7 @@ \subsection{Expandable Connectors}\label{expandable-connectors}
     The expandable connector instance is automatically augmented with a new component having the used name and corresponding type.
   \item
     If the undeclared component is subscripted, an array variable is created, and a connection to the specific array element is performed.
-    Introducing elements in an array gives an array with at least the specified elements, other elements are either not created or have a default value (i.e.\ as if they were only potentially present, and the same note regarding the use of \lstinline!size! also applies here).
+    Introducing elements in an array gives an array with at least the specified elements, other elements are either not created or have a default value (i.e., as if they were only potentially present, and the same note regarding the use of \lstinline!size! also applies here).
   \item
     If the variable on the other side of the \lstinline!connect!-equation is \lstinline!input! or \lstinline!output! the new component will be either \lstinline!input! or \lstinline!output! to satisfy the restrictions in \cref{restrictions-of-connections-and-connectors} for a non-expandable connector.
     \begin{nonnormative}
@@ -129,7 +129,7 @@ \subsection{Expandable Connectors}\label{expandable-connectors}
   When two expandable connectors are connected, each is augmented with the variables that are only declared in the other expandable connector (the new variables are neither \lstinline!input! nor \lstinline!output!).
   This is repeated until all connected expandable connector instances have matching variables.
   \begin{nonnormative}
-  I.e.\ each of the connector instances is expanded to be the union of all connector variables.
+  I.e., each of the connector instances is expanded to be the union of all connector variables.
   \end{nonnormative}
 
 \item
@@ -186,7 +186,7 @@ \subsection{Expandable Connectors}\label{expandable-connectors}
 \item
   All components in an expandable connector are seen as connector instances even if they are not declared as such.
   \begin{nonnormative}
-  I.e.\ it is possible to connect to e.g.\ a \lstinline!Real! variable.
+  I.e., it is possible to connect to, e.g., a \lstinline!Real! variable.
   \end{nonnormative}
 \begin{example}
 \begin{lstlisting}[language=modelica]
@@ -289,7 +289,7 @@ \subsection{Expandable Connectors}\label{expandable-connectors}
 This elaboration implies that expandable connectors can be connected even if they do not contain the same components.
 
 \begin{nonnormative}
-A tool may remove undefined variables in an expandable connector, or set them to the default value, e.g.\ zero for \lstinline!Real! variables.
+A tool may remove undefined variables in an expandable connector, or set them to the default value, e.g., zero for \lstinline!Real! variables.
 \end{nonnormative}
 
 \begin{nonnormative}
@@ -309,7 +309,7 @@ \subsection{Expandable Connectors}\label{expandable-connectors}
 \end{nonnormative}
 
 \begin{example}
-Engine system with sensors, controllers, actuator and plant that exchange information via a bus (i.e.\ via expandable connectors):
+Engine system with sensors, controllers, actuator and plant that exchange information via a bus (i.e., via expandable connectors):
 \begin{lstlisting}[language=modelica]
 import Modelica.Units.SI;
 import Modelica.Blocks.Interfaces.RealInput;
@@ -378,7 +378,7 @@ \section{Generation of Connection Equations}\label{generation-of-connection-equa
 \end{lstlisting}
 the primitive components of \lstinline!a! and \lstinline!b! form a connection set, together with an indication of whether they are from an inside or an outside connector.
 \begin{definition}[Primitive elements]\label{primitive-elements}\index{primitive element}\index{element!primitive}
-The primitive elements are of simple types or of types defined as \lstinline!operator record! (i.e.\ a component of an \lstinline!operator record! type is not split into sub-components).
+The primitive elements are of simple types or of types defined as \lstinline!operator record! (i.e., a component of an \lstinline!operator record! type is not split into sub-components).
 \end{definition}
 The elements of the connection sets are tuples of primitive variables together with an indication of inside or outside; if the same tuple belongs to two connection sets those two sets are merged, until every tuple is only present in one set.
 Composite connector types are broken down into primitive components.
@@ -416,7 +416,7 @@ \section{Generation of Connection Equations}\label{generation-of-connection-equa
   $z_{1} + z_{2} + (-z_{3}) + \ldots + z_{n} = \mathbf{0}$ (flow variables)
 \end{itemize}
 
-The bold-face $\mathbf{0}$ represents an array or scalar zero of appropriate dimensions (i.e.\ the same size as $z$).
+The bold-face $\mathbf{0}$ represents an array or scalar zero of appropriate dimensions (i.e., the same size as $z$).
 
 For an \lstinline!operator record! type this uses the operator \lstinline!'0'! -- which must be defined in the operator record -- and all of the flow variables for the \lstinline!operator record!
 must be of the same \lstinline!operator record! type.
@@ -585,7 +585,7 @@ \section{Restrictions of Connections and Connectors}\label{restrictions-of-conne
 I.e., a connection set must -- unless the model or block is partial -- contain one source of a signal (\cref{enum:exc-conn-case} covers the case where a connector of a component is left unconnected and the source given textually).
 \end{nonnormative}
 \item
-  Variables from a protected outside connector must be part of a connection set containing at least one inside connector or one declared public outside connector (i.e.\ it shall not be an implicitly defined part of an expandable connector).
+  Variables from a protected outside connector must be part of a connection set containing at least one inside connector or one declared public outside connector (i.e., it shall not be an implicitly defined part of an expandable connector).
   \begin{nonnormative}
   Otherwise it would not be possible to deduce the causality for the expandable connector element.
   \end{nonnormative}
diff --git a/chapters/dae.tex b/chapters/dae.tex
index dd656104d..1caeb0276 100644
--- a/chapters/dae.tex
+++ b/chapters/dae.tex
@@ -74,7 +74,7 @@ \chapter{Modelica DAE Representation}\label{modelica-dae-representation}
 
 \item
   $\mathit{relation}(v)$:
-  A relation containing variables $v_{i}$, e.g.\ $v_{1} > v_{2}$, $v_{3} \geq 0$.
+  A relation containing variables $v_{i}$, e.g., $v_{1} > v_{2}$, $v_{3} \geq 0$.
 \end{itemize}
 
 For simplicity, the special cases of \lstinline!noEvent! and \lstinline!reinit! are not contained in the equations above and are not discussed below.
@@ -170,7 +170,7 @@ \chapter{Modelica DAE Representation}\label{modelica-dae-representation}
 
 Solving \eqref{eq:hydrid-dae} for the unknowns is non-trivial, because this set of equations contains not only \lstinline!Real!, but also discrete-valued unknowns.
 Usually, in a first step these equations are sorted and in many cases the discrete-valued unknowns $m$ can be just computed by a forward evaluation sequence.
-In some cases, there remain systems of equations involving $m$ due to cyclic dependencies with $y$ and $z$ (e.g.\ for ideal diodes, Coulomb friction elements), and specialized algorithms have to be used to solve them.
+In some cases, there remain systems of equations involving $m$ due to cyclic dependencies with $y$ and $z$ (e.g., for ideal diodes, Coulomb friction elements), and specialized algorithms have to be used to solve them.
 
 Due to the construction of the equations by \emph{flattening} a Modelica model, the hybrid DAE \eqref{eq:hydrid-dae} contains a huge number of sparse equations.
 Therefore, direct simulation of \eqref{eq:hydrid-dae} requires sparse matrix methods.
diff --git a/chapters/equations.tex b/chapters/equations.tex
index b695547eb..b0f3d1bbf 100644
--- a/chapters/equations.tex
+++ b/chapters/equations.tex
@@ -204,7 +204,7 @@ \subsection{When-Equations}\label{when-equations}
 The equations within a \lstinline!when!-equation are activated only at the instant when the scalar expression or any of the elements of the vector expression becomes true.
 
 \begin{example}
-The order between the equations in a \lstinline!when!-equation does not matter, e.g.
+The order between the equations in a \lstinline!when!-equation does not matter, e.g.:
 \begin{lstlisting}[language=modelica]
 equation
   when x > 2 then
@@ -442,7 +442,7 @@ \subsection{reinit}\label{reinit}
 \end{lstlisting}
 
 The operator reinitializes \lstinline!x! with \lstinline!expr! at an event instant.
-\lstinline!x! is a \lstinline!Real! variable (or an array of \lstinline!Real! variables) that must be selected as a state (resp., states), i.e.\ \lstinline!reinit! on \lstinline!x! implies \lstinline!stateSelect = StateSelect.always! on \lstinline!x!.
+\lstinline!x! is a \lstinline!Real! variable (or an array of \lstinline!Real! variables) that must be selected as a state (resp., states), i.e., \lstinline!reinit! on \lstinline!x! implies \lstinline!stateSelect = StateSelect.always! on \lstinline!x!.
 \lstinline!expr! needs to be type-compatible with \lstinline!x!.
 For any given variable (possibly an array variable), \lstinline!reinit! can only be applied (either to an individual variable or to a part of an array variable) in one \lstinline!when!-equation (applying \lstinline!reinit! to a variable in several \lstinline!when!- or \lstinline!elsewhen!-clauses of the same \lstinline!when!-equation is allowed).
 If there are multiple \lstinline!reinit! for a variable inside the same \lstinline!when!- or \lstinline!elsewhen!-clause, they must appear in different branches of an \lstinline!if!-equation (in order that at most one \lstinline!reinit! for the variable is active at any event).
@@ -578,7 +578,7 @@ \section{Events and Synchronization}\label{events-and-synchronization}
 An \firstuse{event} is something that occurs instantaneously at a specific time or when a specific condition occurs.
 Events are for example defined by the condition occurring in a \lstinline!when!-clause, \lstinline!if!-equation, or \lstinline!if!-expression.
 
-The integration is halted and an event occurs whenever an event generation expression, e.g.\ \lstinline!x > 2! o or \lstinline!floor(x)!, changes its value.
+The integration is halted and an event occurs whenever an event generation expression, e.g., \lstinline!x > 2! o or \lstinline!floor(x)!, changes its value.
 An event generating expression has an internal buffer, and the value of the expression can only be changed at event instants.
 If the evaluated expression is inconsistent with the buffer, that will trigger an event and the buffer will be updated with a new value at the event instant.
 During continuous integration event generation expression has the constant value of the expression from the last event instant.
@@ -624,9 +624,9 @@ \section{Events and Synchronization}\label{events-and-synchronization}
 In this case \lstinline!x = y = z!, but a tool might generate events for \lstinline!z!.
 The \lstinline!if!-expression is taken literally without inducing state events.
 
-The \lstinline!smooth! operator is useful, if e.g.\ the modeler can guarantee that the used \lstinline!if!-expressions fulfill at least the continuity requirement of integrators.
+The \lstinline!smooth! operator is useful, if, e.g., the modeler can guarantee that the used \lstinline!if!-expressions fulfill at least the continuity requirement of integrators.
 In this case the simulation speed is improved, since no state event iterations occur during integration.
-The \lstinline!noEvent! operator is used to guard against \emph{outside domain} errors, e.g.\ \lstinline!y = if noEvent(x >= 0) then sqrt(x) else 0.!
+The \lstinline!noEvent! operator is used to guard against \emph{outside domain} errors, e.g., \lstinline!y = if noEvent(x >= 0) then sqrt(x) else 0.!
 \end{example}
 
 All equations and assignment statements within \lstinline!when!-clauses and all assignment statements within \lstinline!function! classes are implicitly treated with \lstinline!noEvent!, i.e., relations within the scope of these operators never induce state or time events.
@@ -650,7 +650,7 @@ \section{Events and Synchronization}\label{events-and-synchronization}
 
 \begin{nonnormative}
 The rules for the synchronous data flow principle guarantee that variables are always defined by a unique set of equations.
-It is not possible that a variable is e.g.\ defined by two equations, which would give rise to conflicts or non-deterministic behavior.
+It is not possible that a variable is, e.g., defined by two equations, which would give rise to conflicts or non-deterministic behavior.
 Furthermore, the continuous and the discrete parts of a model are always automatically ``synchronized''.
 Example:
 \begin{lstlisting}[language=modelica]
@@ -682,7 +682,7 @@ \section{Events and Synchronization}\label{events-and-synchronization}
 There is no guarantee that two different events occur at the same time instant.
 
 \begin{nonnormative}
-As a consequence, synchronization of events has to be explicitly programmed in the model, e.g.\ via counters.
+As a consequence, synchronization of events has to be explicitly programmed in the model, e.g., via counters.
 Example:
 \begin{lstlisting}[language=modelica]
   Boolean fastSample, slowSample;
@@ -787,7 +787,7 @@ \section{Initialization, initial equation, and initial algorithm}\label{initiali
 This is used in libraries to give rudimentary defaults so that users can quickly combine models and simulate without setting parameters; but still easily find the parameters that should be set properly.
 \end{nonnormative}
 
-All variables declared as \lstinline!parameter! having \lstinline!fixed = false! are treated as unknowns during the initialization phase, i.e.\ there must be additional equations for them -- and the \lstinline!start!-value can be used as a guess-value during initialization.
+All variables declared as \lstinline!parameter! having \lstinline!fixed = false! are treated as unknowns during the initialization phase, i.e., there must be additional equations for them -- and the \lstinline!start!-value can be used as a guess-value during initialization.
 
 \begin{nonnormative}
 In the case a parameter has both a binding equation and \lstinline!fixed = false! a diagnostic is recommended, but the parameter should be solved from the binding equation.
diff --git a/chapters/functions.tex b/chapters/functions.tex
index d50a26924..d44250e69 100644
--- a/chapters/functions.tex
+++ b/chapters/functions.tex
@@ -145,7 +145,7 @@ \section{Function as a Specialized Class}\label{function-as-a-specialized-class}
 
 \begin{nonnormative}
 The syntax and semantics of a function have many similarities to those of the \lstinline!block! specialized class. A function has many of the properties
-of a general class, e.g.\ being able to inherit other functions, or to redeclare or modify elements of a function declaration.
+of a general class, e.g., being able to inherit other functions, or to redeclare or modify elements of a function declaration.
 \end{nonnormative}
 
 Modelica functions have the following restrictions compared to a general
@@ -244,7 +244,7 @@ \section{Pure Modelica Functions}\label{pure-modelica-functions}
 \item
   \emph{Pure} Modelica functions always give the same output values or
   errors for the same input values and only the output values influence
-  the simulation result, i.e.\ is seen as equivalent to a mathematical
+  the simulation result, i.e., is seen as equivalent to a mathematical
   map from input values to output values. Some input values may map to
   errors. Pure functions are thus allowed to fail by calling \lstinline!assert!, or
   \lstinline[language=C]!ModelicaError! in C code, or dividing by zero. Such errors will only be
@@ -292,7 +292,7 @@ \section{Pure Modelica Functions}\label{pure-modelica-functions}
 containing function calls while still preserving their semantics. For
 example, a tool may use common subexpression elimination to call a pure
 function just once, if it is called several times with identical input
-arguments. However, since functions may fail we can e.g.\ only move a
+arguments. However, since functions may fail we can, e.g., only move a
 common function call from inside a loop to outside the loop if the loop
 is run at least once.
 \end{nonnormative}
@@ -302,7 +302,7 @@ \section{Pure Modelica Functions}\label{pure-modelica-functions}
 maintaining this property for pure non-external functions. Regarding
 external functions, the external function implementor is responsible.
 Note that external functions can have side-effects as long as they do
-not influence the internal Modelica simulation state, e.g.\ caching
+not influence the internal Modelica simulation state, e.g., caching
 variables for performance or printing trace output to a log file.
 \end{nonnormative}
 
@@ -754,7 +754,7 @@ \subsection{Initialization and Binding Equations}%
 (before executing the algorithm section or calling the external
 function). These bindings must be executed in an order where a variable
 is not used before its binding equations has been executed; it is
-an error if no such order exists (i.e.\ the binding must be acyclic).
+an error if no such order exists (i.e., the binding must be acyclic).
 
 % The first sentence below needs clarification: clearly, binding equation can also be used for components outside functions.
 Binding equations can only be used for components of a function.
@@ -822,7 +822,7 @@ \subsection{Flexible Array Sizes and Resizing of Arrays}\label{flexible-array-si
 
 \subsection{Automatic Vectorization}\label{scalar-functions-applied-to-array-arguments}\label{automatic-vectorization}
 
-Functions with one scalar return value can be applied to arrays element-wise, e.g.\ if \lstinline!A! is a vector of reals, then \lstinline!sin(A)! is a vector where each element is the result of applying the function \lstinline!sin! to the corresponding element in \lstinline!A!.
+Functions with one scalar return value can be applied to arrays element-wise, e.g., if \lstinline!A! is a vector of reals, then \lstinline!sin(A)! is a vector where each element is the result of applying the function \lstinline!sin! to the corresponding element in \lstinline!A!.
 Only \lstinline!function! classes that are transitively non-replaceable (\cref{transitively-non-replaceable} and \cref{restrictions-on-base-classes-and-constraining-types-to-be-transitively-non-replaceable}) may be called vectorized.
 
 Consider the expression \lstinline!f(arg1, $\ldots$, argn)!, an application of the function \lstinline!f! to the arguments \lstinline!arg1!, \ldots, \lstinline!argn!.
@@ -1353,7 +1353,7 @@ \subsection{Using the Derivative Annotation}\label{using-the-derivative-annotati
   and its derivative.
 \end{itemize}
 
-If the Modelica function call is a $n$th derivative ($n \geq 1$), i.e.\ this function call has been derived from an $(n-1)$th derivative by differentiation inside the tool, an {\lstinline!annotation(derivative(order=$n+1$) = $\ldots$)!}, specifies the $(n+1)$th derivative, and the $(n+1)$th derivative call is constructed as follows:
+If the Modelica function call is a $n$th derivative ($n \geq 1$), i.e., this function call has been derived from an $(n-1)$th derivative by differentiation inside the tool, an {\lstinline!annotation(derivative(order=$n+1$) = $\ldots$)!}, specifies the $(n+1)$th derivative, and the $(n+1)$th derivative call is constructed as follows:
 \begin{itemize}
 \item
   The input arguments are appended with the $(n+1)$th derivative, which are constructed in order from the $n$th {\lstinline!order!} derivatives.
@@ -1491,7 +1491,7 @@ \subsection{Using the Derivative Annotation}\label{using-the-derivative-annotati
   {\lstinline[language=grammar]!"zeroDerivative" "=" $\mathit{inputVar}_{1}$ { "," "zeroDerivative" "=" $\mathit{inputVar}_{2}$ }!}
 \end{itemize}
 
-The derivative function is only valid if $\mathit{inputVar}_{1}$ (and $\mathit{inputVar}_{2}$ etc.) are independent of the variables the function call is differentiated with respect to (i.e.\ that the derivative of $\mathit{inputVar}_{1}$ is zero).
+The derivative function is only valid if $\mathit{inputVar}_{1}$ (and $\mathit{inputVar}_{2}$ etc.) are independent of the variables the function call is differentiated with respect to (i.e., that the derivative of $\mathit{inputVar}_{1}$ is zero).
 The derivative of $\mathit{inputVar}_{1}$ (and $\mathit{inputVar}_{2}$ etc.) are excluded from the argument list of the derivative-function.
 If the derivative-function also specifies a derivative the common variables should have consistent {\lstinline!zeroDerivative!}.
 
@@ -1908,7 +1908,7 @@ \section{External Function Interface}\label{external-function-interface}
 \begin{itemize}
 \item
   Support for external functions written in C (specifically C89) and
-  FORTRAN~77. Other languages, e.g.\ C++ and Fortran 90, may be supported
+  FORTRAN~77. Other languages, e.g., C++ and Fortran 90, may be supported
   in the future, and provided the function is link-compatible with C89
   or FORTRAN~77 it can be written in any language.
 \item
@@ -1954,7 +1954,7 @@ \section{External Function Interface}\label{external-function-interface}
 Unless the external language is specified, it is assumed to be {\lstinline!"C"!}.
 
 \begin{nonnormative}
-The intended use of e.g.\ C99 is to detect if the user tries to link with a C99-function using a C89 compiler.
+The intended use of, e.g., C99 is to detect if the user tries to link with a C99-function using a C89 compiler.
 \end{nonnormative}
 
 The deprecated {\lstinline!"builtin"!} specification is only used for the elementary mathematical functions described in \cref{built-in-mathematical-functions-and-external-built-in-functions}.
@@ -1997,7 +1997,7 @@ \section{External Function Interface}\label{external-function-interface}
 \subsection{Argument type Mapping}\label{argument-type-mapping}
 
 The arguments of the external function are declared in the same order as in the Modelica declaration, unless specified otherwise in an explicit external function call.
-Protected variables (i.e.\ temporaries) are passed in the same way as outputs, whereas constants and {\lstinline!size!} calls are passed as inputs.
+Protected variables (i.e., temporaries) are passed in the same way as outputs, whereas constants and {\lstinline!size!} calls are passed as inputs.
 
 \subsubsection{Simple Types}\label{simple-types}
 
@@ -2218,7 +2218,7 @@ \subsubsection{Records}\label{records}
   Arrays cannot be mapped.
 \end{itemize}
 
-Records are passed by reference (i.e.\ a pointer to the record is being
+Records are passed by reference (i.e., a pointer to the record is being
 passed).
 
 \begin{example}
@@ -2325,7 +2325,7 @@ \subsection{Aliasing}\label{aliasing}
 inputs is to ensure that inputs can be stored in static memory and to
 avoid superfluous copying (especially of matrices). If the routine does
 not satisfy the requirements the interface must copy the input argument
-to a temporary. This is rare but occurs e.g.\ in {\lstinline!dormlq!} in some
+to a temporary. This is rare but occurs, e.g., in {\lstinline!dormlq!} in some
 Lapack implementations. In those special cases the writer of the
 external interface have to copy the input to a temporary. If the first
 input was changed internally in myfoo the designer of the interface
@@ -2379,7 +2379,7 @@ \subsection{Annotations for External Functions}\label{annotations-for-external-l
   The
   {\lstinline!annotation(LibraryDirectory="modelica://ModelicaLibraryName/Resources/Library")!}\annotationindex{LibraryDirectory}, used to specify a location for library files.
   The preceding one is the default and need not be specified; but another location could be specified by using an URI name for the library directory, see \cref{external-resources}.
-  Different versions of one object library can be provided (e.g.\ for Windows and for Linux) by providing a \emph{platform} directory below the {\lstinline!LibraryDirectory!}.
+  Different versions of one object library can be provided (e.g., for Windows and for Linux) by providing a \emph{platform} directory below the {\lstinline!LibraryDirectory!}.
   If no platform directory is present, the object library must be present in the {\lstinline!LibraryDirectory!}.
   The following \emph{platform} names are standardized:
   \begin{itemize}
@@ -2412,7 +2412,7 @@ \subsection{Annotations for External Functions}\label{annotations-for-external-l
 
 \begin{nonnormative}
 A tool may give a diagnostic if the directory corresponding to the selected compiler version is missing.
-The directories may use symbolic links or use a text-file as described below: e.g.\ a text-file \filename{vs2008} containing the text \emph{../win32/vs2005} (or \emph{vs2005}) suggesting that it is compatible with vs2005.
+The directories may use symbolic links or use a text-file as described below: e.g., a text-file \filename{vs2008} containing the text \emph{../win32/vs2005} (or \emph{vs2005}) suggesting that it is compatible with vs2005.
 \end{nonnormative}
 
 The {\lstinline!ModelicaLibraryName!} used for {\lstinline!IncludeDirectory!}, {\lstinline!LibraryDirectory!}, and {\lstinline!SourceDirectory!} indicates the top-level class where the annotation is found in the Modelica source code.
@@ -2818,7 +2818,7 @@ \subsection{External Objects}\label{external-objects}
   \end{nonnormative}
   \begin{nonnormative}
   External objects may be an input (or part of an input) to a function, in that case the destructor is not called (since the external object is active before and after the function call).
-  Normally this is an external function, but it could be a non-external function as well (e.g.\ calling external functions one or more times).
+  Normally this is an external function, but it could be a non-external function as well (e.g., calling external functions one or more times).
   The function input shall not have a default value using the constructor.
   \end{nonnormative}
 \item
diff --git a/chapters/inheritance.tex b/chapters/inheritance.tex
index 710d7efd9..eebdff8d7 100644
--- a/chapters/inheritance.tex
+++ b/chapters/inheritance.tex
@@ -197,7 +197,7 @@ \subsection{Restrictions on the Kind of Base Class}\label{restrictions-on-the-ki
 own kind and from \lstinline!class!.
 
 \begin{nonnormative}
-E.g.\ a package can only be base class for packages.
+E.g., a package can only be base class for packages.
 All other kinds of classes can use the \lstinline!import!-clause to use the contents of a package.
 \end{nonnormative}
 
@@ -231,7 +231,7 @@ \subsection{Require Transitively Non-Replaceable}\label{restrictions-on-base-cla
 For a replaceable component declaration without \lstinline[language=grammar]!constraining-clause! the class must use a class reference considered transitively non-replaceable.
 
 \begin{nonnormative}
-The requirement to use a transitively non-replaceable name excludes the long form of redeclare, i.e.\ \lstinline!redeclare model extends M $\ldots$! where \lstinline!M! must be an inherited replaceable class.
+The requirement to use a transitively non-replaceable name excludes the long form of redeclare, i.e., \lstinline!redeclare model extends M $\ldots$! where \lstinline!M! must be an inherited replaceable class.
 \end{nonnormative}
 
 \begin{nonnormative}
@@ -857,7 +857,7 @@ \subsection{The ``class extends'' Redeclaration Mechanism}\label{the-class-exten
 Here, the usual approach is used to extend (here from \lstinline!PartialMedium!) and in the modifier perform all redeclarations.
 In order to perform these redeclarations, corresponding implementations of all elements of \lstinline!PartialMedium! have to be given under a different name, such as \lstinline!MoistAir2.MoistAir_BaseProperties!, since the name \lstinline!BaseProperties! already exists due to \lstinline!extends PartialMedium!.
 Then it is possible in the modifier to redeclare \lstinline!PartialMedium.BaseProperties! to \lstinline!MoistAir2.MoistAir_BaseProperties!.
-Besides the drawback that the namespace is polluted by elements that have different names but the same implementation (e.g.\ \lstinline!MoistAir2.BaseProperties! is identical to \lstinline!MoistAir2.MoistAir_BaseProperties!) the whole construction does not work if arrays are present that depend on constants in \lstinline!PartialMedium!, such as \lstinline!X[nX]!:
+Besides the drawback that the namespace is polluted by elements that have different names but the same implementation (e.g., \lstinline!MoistAir2.BaseProperties! is identical to \lstinline!MoistAir2.MoistAir_BaseProperties!) the whole construction does not work if arrays are present that depend on constants in \lstinline!PartialMedium!, such as \lstinline!X[nX]!:
 The problem is that \lstinline!MoistAir_BaseProperties! extends from \lstinline!PartialMedium.BaseProperties! where the constant \lstinline!nX! does not yet have a value.
 This means that the dimension of array \lstinline!X! is undefined and model \lstinline!MoistAir_BaseProperties! is wrong.
 With this construction, all constant definitions have to be repeated whenever these constants shall be used, especially in \lstinline!MoistAir_BaseProperties! and \lstinline!MoistAir_dynamicViscosity!.
@@ -1001,8 +1001,8 @@ \subsection{Constraining Type}\label{constraining-type}
 replaceable T1[n] x constrainedby T2;
 \end{lstlisting}
 In these examples the number of dimensions must be the same in \lstinline!T1! and \lstinline!T2!, as well as in a redeclaration.  Normally \lstinline!T1! and \lstinline!T2! are scalar types, but both
-could also be defined as array types (with the same number of dimensions).  Thus if \lstinline!T2! is a scalar type (e.g.\ \lstinline!type T2 = Real!) then \lstinline!T1! must also be a scalar type,
-and if \lstinline!T2! is defined as vector type (e.g.\ \lstinline!type T2 = Real[3]!) then \lstinline!T1! must also be vector type.
+could also be defined as array types (with the same number of dimensions).  Thus if \lstinline!T2! is a scalar type (e.g., \lstinline!type T2 = Real!) then \lstinline!T1! must also be a scalar type,
+and if \lstinline!T2! is defined as vector type (e.g., \lstinline!type T2 = Real[3]!) then \lstinline!T1! must also be vector type.
 \end{example}
 
 \subsubsection{Constraining-Clause Annotations}\label{constraining-clause-annotations}
diff --git a/chapters/interface.tex b/chapters/interface.tex
index c45b0074c..c86d79ef5 100644
--- a/chapters/interface.tex
+++ b/chapters/interface.tex
@@ -1,7 +1,7 @@
 \chapter{Interface or Type Relationships}\label{interface-or-type-relationships}
 
-A class or component, e.g.\ denoted \lstinline!A!, can in some cases be used at a
-location designed for another class or component, e.g.\ denoted \lstinline!B!. In
+A class or component, e.g., denoted \lstinline!A!, can in some cases be used at a
+location designed for another class or component, e.g., denoted \lstinline!B!. In
 Modelica this is the case for replaceable classes (see \cref{redeclaration}) and
 for \lstinline!inner!/\lstinline!outer! elements (see \cref{instance-hierarchy-name-lookup-of-inner-declarations}).
 Replaceable classes are the
@@ -13,7 +13,7 @@ \chapter{Interface or Type Relationships}\label{interface-or-type-relationships}
 
 \section{Interface Terminology}\label{interface-terminology}
 
-In this chapter, two kinds of terminology are used for identical concepts to get better understanding (e.g.\ by both engineers and computer scientists).
+In this chapter, two kinds of terminology are used for identical concepts to get better understanding (e.g., by both engineers and computer scientists).
 A short summary of the terms is given in the following table.
 The details are defined in the rest of this chapter.
 
@@ -22,7 +22,7 @@ \section{Interface Terminology}\label{interface-terminology}
 that is needed to decide whether \lstinline!A! can be used instead of \lstinline!B!.
 \par
 \begin{nonnormative*}
-E.g.\ a declaration \lstinline!Real x! is part of the type (also called \emph{interface}), but \lstinline!import A! is not.
+E.g., a declaration \lstinline!Real x! is part of the type (also called \emph{interface}), but \lstinline!import A! is not.
 \end{nonnormative*}
 \end{definition}
 
@@ -47,7 +47,7 @@ \section{Interface Terminology}\label{interface-terminology}
 \lstinline!A! is a restricted subtype of \lstinline!B!, or equivalently, the interface of \lstinline!A! is plug compatible to the interface of \lstinline!B!, if \lstinline!A! is a subtype of
 \lstinline!B! and if connector components in \lstinline!A! that are not in \lstinline!B!, are default connectable.
 \begin{nonnormative}
-E.g.\ it is not allowed that these connectors have variables with the \lstinline!input! prefix, because then they must be connected.
+E.g., it is not allowed that these connectors have variables with the \lstinline!input! prefix, because then they must be connected.
 \end{nonnormative}
 A model or block \lstinline!A! cannot be used instead of \lstinline!B!, if the particular situation does not allow to make a connection to these additional connectors. In such a case the stricter
 \emph{plug compatible} is required for a redeclaration.
@@ -59,7 +59,7 @@ \section{Interface Terminology}\label{interface-terminology}
 \lstinline!B! is called.
 \par
 \begin{nonnormative*}
-E.g.\ an additional argument must have a default value.
+E.g., an additional argument must have a default value.
 \end{nonnormative*}
 \end{definition}
 
@@ -67,7 +67,7 @@ \section{The Concepts of Type, Interface and Subtype}\label{the-concepts-of-type
 
 A \emph{type} can conceptually be viewed as a \emph{set of values}. When
 we say that the variable \lstinline!x! has the type \lstinline!Real!, we mean that the value of
-\lstinline!x! belongs to the set of values represented by the type \lstinline!Real! i.e.,
+\lstinline!x! belongs to the set of values represented by the type \lstinline!Real!, i.e.,
 roughly the set of floating point numbers representable by \lstinline!Real!, for the
 moment ignoring the fact that \lstinline!Real! is also viewed as a class with
 certain attributes. Analogously, the variable \lstinline!b! having \lstinline!Boolean! type
@@ -92,7 +92,7 @@ \section{The Concepts of Type, Interface and Subtype}\label{the-concepts-of-type
 
 An element is characterized by its interface defined by some attributes
 (\cref{interface-or-type}). The \emph{type} of the element is the set of values
-having the same interface, i.e.\ the same attributes.
+having the same interface, i.e., the same attributes.
 
 A \emph{subtype} \lstinline!A1! in relation to another type \lstinline!A!, means that the
 elements of the set corresponding to \lstinline!A1! is a subset of the set
@@ -108,7 +108,7 @@ \section{The Concepts of Type, Interface and Subtype}\label{the-concepts-of-type
 
 An instance \lstinline!r2!: \lstinline!R2 r2;!
 
-The type \lstinline!R! of \lstinline!r! can be viewed as the set of all record values having the attributes defined by the interface of \lstinline!R!, e.g.\ the infinite set \{\lstinline!R(b=false, x=1.2)!, \lstinline!R(b=false, x=3.4)!, \lstinline!R(b=true, x=1.2)!, \lstinline!R(b=true, x=1.2, y=2)!, \lstinline!R(b=true, x=1.2, a=2)!, $\ldots$\}.
+The type \lstinline!R! of \lstinline!r! can be viewed as the set of all record values having the attributes defined by the interface of \lstinline!R!, e.g., the infinite set \{\lstinline!R(b=false, x=1.2)!, \lstinline!R(b=false, x=3.4)!, \lstinline!R(b=true, x=1.2)!, \lstinline!R(b=true, x=1.2, y=2)!, \lstinline!R(b=true, x=1.2, a=2)!, $\ldots$\}.
 The statement that \lstinline!r! has the type (or interface) \lstinline!R! means that the value of \lstinline!r! s to this infinite set.
 
 The type \lstinline!R2! is a subtype of \lstinline!R! since its instances
@@ -165,7 +165,7 @@ \section{Interface or Type}\label{interface-or-type}
     \lstinline!IntegerType!, \lstinline!StringType! or \lstinline!BooleanType!).
   \end{itemize}
 \item
-  Only for an \lstinline!operator record! class and classes derived from \lstinline!ExternalObject!: the full name of the operator record base class (i.e.\ the one containing the operations), or the derived class.
+  Only for an \lstinline!operator record! class and classes derived from \lstinline!ExternalObject!: the full name of the operator record base class (i.e., the one containing the operations), or the derived class.
   See \cref{overloaded-operators} and \cref{external-objects}.
 
   The following item does not apply for an \lstinline!operator record! class or class derived from \lstinline!ExternalObject!, since the type is already uniquely defined by the full name.
@@ -194,7 +194,7 @@ \section{Interface or Type}\label{interface-or-type}
 
 \begin{nonnormative}
 The public interface does not contain all of the information about the class or component.
-When using a class as a base class we also need protected elements, and for internal type-checking we need e.g.\ import-elements.
+When using a class as a base class we also need protected elements, and for internal type-checking we need, e.g., import-elements.
 However, the information is sufficient for checking compatibility and for using the class to flatten components.
 \end{nonnormative}
 
@@ -205,19 +205,19 @@ \subsection{Transitively Non-Replaceable}\label{transitively-non-replaceable}
 Such classes are defined as \willintroduce{transitively non-replaceable}.
 \end{nonnormative}
 
-A class reference is \firstuse{transitively non-replaceable} iff (i.e.\ \emph{if and only if}) all parts of the name satisfy the following:
+A class reference is \firstuse{transitively non-replaceable} iff (i.e., \emph{if and only if}) all parts of the name satisfy the following:
 \begin{itemize}
 \item
   If the class definition is long it is transitively non-replaceable if
   not declared replaceable.
 \item
-  If the class definition is short (i.e.\ \lstinline!class A = P.B!) it is
+  If the class definition is short (i.e., \lstinline!class A = P.B!) it is
   transitively non-replaceable if it is non-replaceable and equal to
   class reference (\lstinline!P.B!) that is transitively non-replaceable.
 \end{itemize}
 
 \begin{nonnormative}
-According to \cref{restrictions-on-base-classes-and-constraining-types-to-be-transitively-non-replaceable}, for a hierarchical name all parts of the name must be transitively non-replaceable, i.e.\ in \lstinline!extends A.B.C! this implies that \lstinline!A.B.C! must be transitively non-replaceable, as well as \lstinline!A! and \lstinline!A.B!, with the exception of the \emph{class extends redeclaration mechanism} see \cref{the-class-extends-redeclaration-mechanism}.
+According to \cref{restrictions-on-base-classes-and-constraining-types-to-be-transitively-non-replaceable}, for a hierarchical name all parts of the name must be transitively non-replaceable, i.e., in \lstinline!extends A.B.C! this implies that \lstinline!A.B.C! must be transitively non-replaceable, as well as \lstinline!A! and \lstinline!A.B!, with the exception of the \emph{class extends redeclaration mechanism} see \cref{the-class-extends-redeclaration-mechanism}.
 \end{nonnormative}
 
 \subsection{Inheritance Interface or Class Type}\label{inheritance-interface-or-class-type}
@@ -332,7 +332,7 @@ \section{Interface Compatibility or Subtyping}\label{interface-compatibility-or-
   \item
     Declared variability is ordered \lstinline!constant! \textless{} \lstinline!parameter! \textless{} \lstinline!discrete! \textless{} continuous-time (\lstinline!Real! without prefix), and \lstinline!A! is only compatible with \lstinline!B! if the declared variability in \lstinline!A! is less than or equal the variability in \lstinline!B!.
     \begin{nonnormative}
-    For a redeclaration of an element the variability prefix is as default inherited by the redeclaration (i.e.\ no need to repeat \lstinline!parameter! when redeclaring a parameter).
+    For a redeclaration of an element the variability prefix is as default inherited by the redeclaration (i.e., no need to repeat \lstinline!parameter! when redeclaring a parameter).
     \end{nonnormative}
   \item
     The \lstinline!input! and \lstinline!output! prefixes must be matched.  This ensures that the rules regarding inputs/outputs for matching connectors and (non-connector inputs) are preserved, as well as the restriction on blocks.
@@ -588,14 +588,14 @@ \section{Type Compatible Expressions}\label{type-compatible-expressions}
 Certain expressions consist of an operator applied to two or more subexpressions (\lstinline!A! and \lstinline!B!).
 This includes:
 \begin{itemize}
-\item \lstinline!if!-expressions, e.g.\ \lstinline!if x then A else B!.
-\item Array expressions, e.g.\ \lstinline!{A, B}!
-\item Binary operators if both operands are of simple types, e.g.\ \lstinline!A + B!.
+\item \lstinline!if!-expressions, e.g., \lstinline!if x then A else B!.
+\item Array expressions, e.g., \lstinline!{A, B}!
+\item Binary operators if both operands are of simple types, e.g., \lstinline!A + B!.
 Binary operators for other types are only defined for operator records, \cref{overloaded-binary-operations}, and do not necessarily require that the operands are type compatible with each other.
 \end{itemize}
 If the subexpressions satisfy the following restrictions they are called type compatible expressions.
 Otherwise the expression is illegal.
-The type of the full expression (e.g.\ \lstinline!if x then A else B!) is also defined below.
+The type of the full expression (e.g., \lstinline!if x then A else B!) is also defined below.
 \begin{itemize}
 \item
   If \lstinline!A! is a record expression, \lstinline!B! must also be a record expression with the same named elements.
@@ -628,8 +628,8 @@ \section{Type Compatible Expressions}\label{type-compatible-expressions}
   The enumeration expressions must be defined in terms of an enumeration type with the same enumeration literals in the same order.
 \item
   For array and \lstinline!if!-expressions, if \lstinline!A! has an \lstinline!operator record! base class then \lstinline!B! must also have an \lstinline!operator record! base class, and it must be the same, and otherwise neither \lstinline!A! nor \lstinline!B! may have an \lstinline!operator record! base class.
-  This is also the \lstinline!operator record! base class for the full expression e.g.\ for \lstinline!if (cond) then A else B!.
+  This is also the \lstinline!operator record! base class for the full expression, e.g., for \lstinline!if (cond) then A else B!.
 \item
   If \lstinline!A! is derived from \lstinline!ExternalObject! then \lstinline!B! must also be derived from \lstinline!ExternalObject! and they must have the same full name; and otherwise neither \lstinline!A! nor \lstinline!B! may be derived from \lstinline!ExternalObject!.
-  The common full name also defines the type of the full expression, e.g.\ for \lstinline!if (cond) then A else B!.
+  The common full name also defines the type of the full expression, e.g., for \lstinline!if (cond) then A else B!.
 \end{itemize}
diff --git a/chapters/introduction.tex b/chapters/introduction.tex
index 91cdbc4e1..e50f574de 100644
--- a/chapters/introduction.tex
+++ b/chapters/introduction.tex
@@ -52,7 +52,7 @@ \section{Scope of the Specification}\label{scope-of-the-specification}
 Therefore, a flat hybrid DAE is seen as a set of equations where some of the equations are only conditionally evaluated.
 Initial setup of the model is specified using \lstinline!start!-attributes and equations that hold only during initialization.
 
-A Modelica class may also contain annotations, i.e.\ formal comments, which specify graphical representations of the class (icon and diagram), documentation text for the class, and version information.
+A Modelica class may also contain annotations, i.e., formal comments, which specify graphical representations of the class (icon and diagram), documentation text for the class, and version information.
 
 \section{Some Definitions}\label{some-definitions}
 
diff --git a/chapters/lexicalstructure.tex b/chapters/lexicalstructure.tex
index f40a15d52..515a6ab24 100644
--- a/chapters/lexicalstructure.tex
+++ b/chapters/lexicalstructure.tex
@@ -71,7 +71,7 @@ \subsection{Identifiers}\label{identifiers}
 Modelica \firstuse[identifier]{identifiers}, used for naming classes, variables, constants, and other items, are of two forms.
 The first form always starts with a letter or underscore (`\_'), followed by any number of letters, digits, or underscores.
 Case is significant, i.e., the identifiers \lstinline!Inductor! and \lstinline!inductor! are different.
-The second form (\lstinline[language=grammar]!Q-IDENT!) starts with a single quote, followed by a sequence of any printable ASCII character, where single-quote must be preceded by backslash, and terminated by a single quote, e.g.\ \lstinline!'12H'!, \lstinline!'13\'H'!, \lstinline!'+foo'!.
+The second form (\lstinline[language=grammar]!Q-IDENT!) starts with a single quote, followed by a sequence of any printable ASCII character, where single-quote must be preceded by backslash, and terminated by a single quote, e.g., \lstinline!'12H'!, \lstinline!'13\'H'!, \lstinline!'+foo'!.
 Control characters in quoted identifiers have to use string escapes.
 The single quotes are part of the identifier, i.e., \lstinline!'x'! and \lstinline!x! are distinct identifiers.
 The redundant escapes (\lstinline!'\?'! and \lstinline!'\"'!) are the same as the corresponding non-escaped variants (\lstinline!'?'! and \lstinline!'"'!), but are only for use in Modelica source code.
@@ -171,7 +171,7 @@ \subsection{Floating Point Numbers}\label{floating-point-numbers}
 
 \subsection{Integer Literals}\label{integer-literals}
 
-Literals of type \lstinline!Integer! are sequences of decimal digits, e.g.\ as in the integer numbers \lstinline!33!,
+Literals of type \lstinline!Integer! are sequences of decimal digits, e.g., as in the integer numbers \lstinline!33!,
 % Just a '0' doesn't work in \lstinline as reported in (closed as fixed on 2021-09-07):
 % - https://github.com/brucemiller/LaTeXML/issues/1651 -- fixed on 'master'
 \ifpdf
@@ -225,7 +225,7 @@ \subsection{Strings}\label{strings}
 \end{lstlisting}
 
 Concatenation of string literals in certain situations (see the Modelica
-grammar) is denoted by the + operator in Modelica, e.g.\ \lstinline!"a"! + \lstinline!"b"!
+grammar) is denoted by the + operator in Modelica, e.g., \lstinline!"a"! + \lstinline!"b"!
 becomes \lstinline!"ab"!. This is useful for expressing long string literals that
 need to be written on several lines.
 
diff --git a/chapters/library.tex b/chapters/library.tex
index 1031ee3ce..bcc2e1a0b 100644
--- a/chapters/library.tex
+++ b/chapters/library.tex
@@ -11,7 +11,7 @@ \chapter{The Modelica Standard Library}\label{the-modelica-standard-library}
 commercial Modelica simulation environments. The Modelica Standard
 Library is tool-neutral, and relies on a small library,
 ModelicaServices, that each conformant tool must implement to handle
-tool-specific couplings e.g.\ for animation. Furthermore, other people
+tool-specific couplings, e.g., for animation. Furthermore, other people
 and organizations are developing free and commercial Modelica libraries.
 For information about these libraries and for downloading the free
 libraries see \url{https://modelica.org/libraries/}.
diff --git a/chapters/operatorsandexpressions.tex b/chapters/operatorsandexpressions.tex
index a129f4c40..21b06ef6f 100644
--- a/chapters/operatorsandexpressions.tex
+++ b/chapters/operatorsandexpressions.tex
@@ -166,7 +166,7 @@ \section{Operator Precedence and Associativity}\label{operator-precedence-and-as
 
 \section{Evaluation Order}\label{evaluation-order}
 
-A tool is free to solve equations, reorder expressions and to not evaluate expressions if their values do not influence the result (e.g.\ short-circuit evaluation of \lstinline!Boolean! expressions).
+A tool is free to solve equations, reorder expressions and to not evaluate expressions if their values do not influence the result (e.g., short-circuit evaluation of \lstinline!Boolean! expressions).
 \lstinline!if!-statements and \lstinline!if!-expressions guarantee that their branches are only evaluated if the appropriate condition is true, but relational operators generating state or time events will during continuous integration have the value from the most recent event.
 
 If a numeric operation overflows the result is undefined.
@@ -292,7 +292,7 @@ \section{Equality, Relational, and Logical Operators}\label{equality-relational-
 \item
   In relations of the form \lstinline!v1 == v2 or v1 <> v2!, \lstinline!v1! or \lstinline!v2! shall, unless used in a function, not be a subtype of \lstinline!Real!.
   \begin{nonnormative}
-  The reason for this rule is that relations with \lstinline!Real! arguments are transformed to state events (see \cref{events-and-synchronization}) and this transformation becomes unnecessarily complicated for the \lstinline!==! and \lstinline!<>! relational operators (e.g.\ two crossing functions instead of one crossing function needed, epsilon strategy needed even at event instants).
+  The reason for this rule is that relations with \lstinline!Real! arguments are transformed to state events (see \cref{events-and-synchronization}) and this transformation becomes unnecessarily complicated for the \lstinline!==! and \lstinline!<>! relational operators (e.g., two crossing functions instead of one crossing function needed, epsilon strategy needed even at event instants).
   Furthermore, testing on equality of \lstinline!Real! variables is questionable on machines where the number length in registers is different to number length in main memory.
   \end{nonnormative}
 \item
@@ -580,7 +580,7 @@ \subsection{Event Triggering Mathematical Functions}\label{event-triggering-math
 \end{center}
 
 These expression for \lstinline!div!, \lstinline!ceil!, \lstinline!floor!, and \lstinline!integer! are event generating expression.
-The event generating expression for \lstinline!mod(x,y)! is \lstinline!floor(x/y)!, and for \lstinline!rem(x,y)! it is \lstinline!div(x,y)! -- i.e.\ events are not generated when \lstinline!mod! or \lstinline!rem! changes continuously in an interval, but when they change discontinuously from one interval to the next.
+The event generating expression for \lstinline!mod(x,y)! is \lstinline!floor(x/y)!, and for \lstinline!rem(x,y)! it is \lstinline!div(x,y)! -- i.e., events are not generated when \lstinline!mod! or \lstinline!rem! changes continuously in an interval, but when they change discontinuously from one interval to the next.
 
 \begin{nonnormative}
 If this is not desired, the \lstinline!noEvent! operator can be applied to them.
@@ -1066,7 +1066,7 @@ \subsubsection{homotopy}\label{homotopy}
 \lstinline!homotopy! is, however used on a variable that is an ``input'' to the non-linear algebraic equation system, and modifies the characteristics of the non-linear algebraic equation system.
 The only useful way is to perform the homotopy iteration over $f_1$ and $f_2$ together.
 
-The suggested approach is ``conceptual'', because more efficient implementations are possible, e.g.\ by determining the smallest iteration loop, that contains the equations of the first BLT block in which \lstinline!homotopy! is present and all equations up to the last BLT block that describes a non-linear algebraic equation system.
+The suggested approach is ``conceptual'', because more efficient implementations are possible, e.g., by determining the smallest iteration loop, that contains the equations of the first BLT block in which \lstinline!homotopy! is present and all equations up to the last BLT block that describes a non-linear algebraic equation system.
 
 A trivial implementation of \lstinline!homotopy! is obtained by defining the following function in the global scope:
 \begin{lstlisting}[language=modelica]
@@ -1241,7 +1241,7 @@ \subsubsection{getInstanceName}\label{getinstancename}
 If \lstinline!MyLib.Vehicle! is simulated, the call of \lstinline!getInstanceName()! returns \lstinline!"Vehicle.engine.controller"!.
 \end{example}
 
-If this function is not called inside a model or block (e.g.\ the function is called in a function or in a constant of a package), the return value is not specified.
+If this function is not called inside a model or block (e.g., the function is called in a function or in a constant of a package), the return value is not specified.
 
 \begin{nonnormative}
 The simulation result should not depend on the return value of this function.
@@ -1311,7 +1311,7 @@ \subsection{Event-Related Operators with Function Syntax}\label{event-related-op
 smooth($p$, $\mathit{expr}$)
 \end{lstlisting}\end{synopsis}
 \begin{semantics}
-If $p \geq 0$ \lstinline!smooth($p$, $\mathit{expr}$)! returns $\mathit{expr}$ and states that $\mathit{expr}$ is $p$ times continuously differentiable, i.e.: $\mathit{expr}$ is continuous in all \lstinline!Real! variables appearing in the expression and all partial derivatives with respect to all appearing real variables exist and are continuous up to order $p$.
+If $p \geq 0$ \lstinline!smooth($p$, $\mathit{expr}$)! returns $\mathit{expr}$ and states that $\mathit{expr}$ is $p$ times continuously differentiable, i.e., $\mathit{expr}$ is continuous in all \lstinline!Real! variables appearing in the expression and all partial derivatives with respect to all appearing real variables exist and are continuous up to order $p$.
 The argument $p$ should be a scalar \lstinline!Integer! parameter expression.
 The only allowed types for $\mathit{expr}$ in \lstinline!smooth! are: \lstinline!Real! expressions, arrays of allowed expressions, and records containing only components of allowed expressions.
 
@@ -1385,7 +1385,7 @@ \subsection{Event-Related Operators with Function Syntax}\label{event-related-op
 \end{lstlisting}\end{synopsis}
 \begin{semantics}
 Expands into \lstinline!($b$ and not pre($b$))! for \lstinline!Boolean! variable $b$.
-The same restrictions as for \lstinline!pre! apply (e.g.\ not to be used in \lstinline!function! classes).
+The same restrictions as for \lstinline!pre! apply (e.g., not to be used in \lstinline!function! classes).
 \end{semantics}
 \end{operatordefinition}
 
diff --git a/chapters/overloaded.tex b/chapters/overloaded.tex
index 2e7492cfe..23a882338 100644
--- a/chapters/overloaded.tex
+++ b/chapters/overloaded.tex
@@ -46,7 +46,7 @@ \section{Overview of Overloaded Operators}\label{overview-of-overloaded-operator
 
 \section{Matching Function}\label{matching-function}
 
-All functions defined inside the \lstinline!operator! class must return one output (based on the restriction above), and may include functions with optional arguments, i.e.\ functions of the form
+All functions defined inside the \lstinline!operator! class must return one output (based on the restriction above), and may include functions with optional arguments, i.e., functions of the form
 \begin{lstlisting}[language=modelica]
 function f
   input $A_1$ $u_1$;
@@ -222,7 +222,7 @@ \section{Overloaded Binary Operations}\label{overloaded-binary-operations}
   Otherwise the expression is erroneous.
 \end{enumerate}
 
-For an element-wise operator, \lstinline!a .op b!, \cref{overloaded-binary-predefined,overloaded-binary-arrays,overloaded-binary-error} are used; e.g.\ the operator \lstinline!.+! will always be defined in terms of \lstinline!'+'!.
+For an element-wise operator, \lstinline!a .op b!, \cref{overloaded-binary-predefined,overloaded-binary-arrays,overloaded-binary-error} are used; e.g., the operator \lstinline!.+! will always be defined in terms of \lstinline!'+'!.
 
 Restrictions:
 \begin{itemize}
diff --git a/chapters/packages.tex b/chapters/packages.tex
index 616a1bdfc..9c897ccd5 100644
--- a/chapters/packages.tex
+++ b/chapters/packages.tex
@@ -121,7 +121,7 @@ \subsection{Rules for Import-Clauses}\label{summary-of-rules-for-import-clauses}
   The \emph{order} of \lstinline!import!-clauses does not matter.
 \item
   One can only import \emph{from} packages, not from other kinds of classes.
-  Both packages and classes can be imported \emph{into} i.e., they may contain \lstinline!import!-clauses.
+  Both packages and classes can be imported \emph{into}, i.e., they may contain \lstinline!import!-clauses.
 \item
   An imported package or definition should always be referred to by its fully qualified name in the \lstinline!import!-clause.
 \item
@@ -144,7 +144,7 @@ \section{The Modelica Library Path -- MODELICAPATH}\label{the-modelica-library-p
 in general not advisable for a program installation to modify global
 environment variables. The version information for a library (as defined
 in \cref{annotations-for-version-handling}) may also be used during this search to search for a
-specific version of the library (e.g.\ if Modelica library version 2.2 is
+specific version of the library (e.g., if Modelica library version 2.2 is
 needed and the first directory in \lstinline!MODELICAPATH! contain Modelica library
 version 2.1, whereas the second directory contains Modelica version 2.2,
 then Modelica library version 2.2 is loaded from the second directory.).
@@ -172,7 +172,7 @@ \section{The Modelica Library Path -- MODELICAPATH}\label{the-modelica-library-p
   \label{fig:roots}
 \end{figure}
 
-Assume that we want to access the package \lstinline!MyLib.Pack2! in \cref{fig:roots} above, e.g.\ through an \lstinline!import!-clause \lstinline!import MyLib.Pack2;!.
+Assume that we want to access the package \lstinline!MyLib.Pack2! in \cref{fig:roots} above, e.g., through an \lstinline!import!-clause \lstinline!import MyLib.Pack2;!.
 During lookup we first try to find a package \lstinline!MyLib! corresponding to the first part of the name in the import-statement.
 It is not found in the top-level scope since it has not previously been loaded into the environment.
 
@@ -244,7 +244,7 @@ \subsection{Directory Hierarchy Mapping}\label{mapping-a-package-class-hierarchy
 
 \subsection{Single File Mapping}\label{mapping-a-package-class-hierarchy-into-a-single-file-nonstructured-entity}\label{single-file-mapping}
 
-When mapping a package or class-hierarchy to a file (e.g.\ the file \filename{A.mo}), that file shall only define a single class \lstinline!A! with a
+When mapping a package or class-hierarchy to a file (e.g., the file \filename{A.mo}), that file shall only define a single class \lstinline!A! with a
 name matching the name of the nonstructured entity. In a file hierarchy the files shall have the extension \filename{.mo}.
 
 A \filename{.mo} file defining more than one class cannot be part of the mapping
@@ -296,11 +296,11 @@ \section{External Resources}\label{external-resources}
 that precedes it. The first part of the path shall not be the name of a
 class in the package given by the authority.
 
-When Modelica packages are stored hierarchically in a file-system (i.e.\ package \lstinline!A! in a directory \filename{A} containing \filename{package.mo}) the resource
+When Modelica packages are stored hierarchically in a file-system (i.e., package \lstinline!A! in a directory \filename{A} containing \filename{package.mo}) the resource
 \filename{modelica://A/Resources/C.jpg} should be stored in the file \filename{A/Resources/C.jpg}, it is not recommend to use \filename{modelica://A.B/C.jpg} for referencing
 resources; it could be stored in the file \filename{A/B/C.jpg} -- which is counter-intuitive if \lstinline!A.B! is stored together with \lstinline!A!.  When Modelica packages
 are stored in other formats a similar mapping should be defined, such that a resource with a given path should be unique for any package name that precedes it.  The first
-part of the path shall not be the name of a class in the package given by the authority.  As above for \filename{Modelica 3.2.1/package.mo} i.e.\ resources starting from
+part of the path shall not be the name of a class in the package given by the authority.  As above for \filename{Modelica 3.2.1/package.mo}, i.e., resources starting from
 \filename{Modelica 3.2.1}, and \filename{modelica://Modelica.Mechanics/C.jpg} is \filename{Modelica 3.2.1/Mechanics/C.jpg} -- regardless of whether \lstinline!Modelica.Mechanics!
 is stored in \filename{Modelica 3.2.1/package.mo}, \filename{Modelica 3.2.1/Mechanics.mo}, or \filename{Modelica 3.2.1/Mechanics/package.mo}.
 
diff --git a/chapters/revisions.tex b/chapters/revisions.tex
index c5de539e6..a9715218d 100644
--- a/chapters/revisions.tex
+++ b/chapters/revisions.tex
@@ -1559,7 +1559,7 @@ \subsection{Main Changes in Modelica 3.2}\label{main-changes-in-modelica-3-2}
 \item
   Constants can once again be modified unless declared final -- as this is already used in packages.  (See \cref{constant-expressions}).
 \item
-  Global name lookup has been introduced (e.g.
+  Global name lookup has been introduced (e.g.,
   \lstinline!.Modelica.Constants.pi!), see \cref{global-name-lookup}.
 \item
   New C functions \lstinline!ModelicaVFormatMessage! and \lstinline!ModelicaVFormatError!, to
@@ -2196,7 +2196,7 @@ \subsection{Main Changes in Modelica 3.0}\label{main-changes-in-modelica-3-0}
   New attribute \lstinline!Smooth = enumeration(None, Bezier)! for graphical objects
   and connection lines (Bezier defines a Bezier spline).\\
   New attribute \lstinline!visible! in \lstinline!record Placement! allows making a graphical
-  annotation invisible (e.g.\ after inheritance).\\
+  annotation invisible (e.g., after inheritance).\\
   New attributes \lstinline!startAngle!, \lstinline!endAngle! in record ellipse to define part
   of an ellipse.\\
   New layer specific annotations \lstinline!IconMap! and \lstinline!DiagramMap! for \lstinline!extends!.\\
@@ -2393,7 +2393,7 @@ \subsection{Main Changes in Modelica 2.1}\label{main-changes-in-modelica-2-1}
   base constraining type automatically to modifications.
 \item
   Enhanced redeclaration as needed, e.g., in the Modelica.Media library
-  under development (e.g.\ \lstinline!redeclare model name! or \lstinline!model extends name (<modifications>)!).
+  under development (e.g., \lstinline!redeclare model name! or \lstinline!model extends name (<modifications>)!).
 \item
   Handling of overdetermined connectors (needed, e.g., for multi-body
   systems and electrical power systems) including the new built-in
@@ -2415,7 +2415,7 @@ \subsection{Main Changes in Modelica 2.1}\label{main-changes-in-modelica-2-1}
   in a mathematically clean way).
 \item
   More general identifiers by having any character in single quotes,
-  e.g.\ \lstinline!'+'! or '123.456\#1' are valid identifiers. \lstinline!'x'! and \lstinline!x! are
+  e.g., \lstinline!'+'! or '123.456\#1' are valid identifiers. \lstinline!'x'! and \lstinline!x! are
   different identifiers. This is useful for a direct mapping of product
   identifiers to model names and for having the usual symbols for
   digital electrical signals as enumerations (such as \lstinline!'+'!, \lstinline!'-'!, \lstinline!'0'!,
@@ -2654,7 +2654,7 @@ \subsection{Main Changes in Modelica 1.4}\label{main-changes-in-modelica-1-4}
   automatically generated when the result value of one of these operator
   changes discontinuously.
 \item
-  Quantity attribute also for base types \lstinline!Boolean!, \lstinline!Integer!, \lstinline!String! (and not only for \lstinline!Real!), in order to allow abstracted variables to refer to physical quantities (e.g.\ \lstinline!Boolean i(quantity="Current")! is true if current is flowing and is false if no current is flowing).
+  Quantity attribute also for base types \lstinline!Boolean!, \lstinline!Integer!, \lstinline!String! (and not only for \lstinline!Real!), in order to allow abstracted variables to refer to physical quantities (e.g., \lstinline!Boolean i(quantity="Current")! is true if current is flowing and is false if no current is flowing).
 \item
   \lstinline!final! keyword also allowed in declaration, to prevent modification.
   Example:
@@ -2671,7 +2671,7 @@ \subsection{Main Changes in Modelica 1.4}\label{main-changes-in-modelica-1-4}
 \item
   Several minor enhancements, such as usage of dot-notation in
   modifications\\
-  (e.g.: \lstinline!A x(B.C=1, B.D=2)! is the same as \lstinline!A x(B(C=1, D=2))!).
+  (e.g., \lstinline!A x(B.C=1, B.D=2)! is the same as \lstinline!A x(B(C=1, D=2))!).
 \item
   Internally restructured specification.
 \end{itemize}
diff --git a/chapters/scoping.tex b/chapters/scoping.tex
index 2d2ca2c68..1044e5179 100644
--- a/chapters/scoping.tex
+++ b/chapters/scoping.tex
@@ -79,7 +79,7 @@ \subsection{Simple Name Lookup}\label{simple-name-lookup}
   It is an error if this step produces matches from several unqualified imports.
 \end{itemize}
 
-The \lstinline!import!-clauses defined in inherited classes are ignored for the lookup, i.e.\ \lstinline!import!-clauses are not inherited.
+The \lstinline!import!-clauses defined in inherited classes are ignored for the lookup, i.e., \lstinline!import!-clauses are not inherited.
 
 
 \subsection{Composite Name Lookup}\label{composite-name-lookup}
@@ -126,7 +126,7 @@ \subsection{Composite Name Lookup}\label{composite-name-lookup}
 
 \subsection{Global Name Lookup}\label{global-name-lookup}
 
-For a name starting with dot, e.g.: \lstinline!.A! (or \lstinline!.A.B!, \lstinline!.A.B.C! etc.) lookup is performed as follows:
+For a name starting with dot, e.g., \lstinline!.A! (or \lstinline!.A.B!, \lstinline!.A.B.C! etc.) lookup is performed as follows:
 \begin{itemize}
 \item
   The first identifier (\lstinline!A!) is looked up in the global scope.
@@ -135,7 +135,7 @@ \subsection{Global Name Lookup}\label{global-name-lookup}
 \item
   If the name is simple then the class \lstinline!A! is the result of lookup.
 \item
-  If the name is a composite name then the class \lstinline!A! is temporarily flattened with an empty environment (i.e.\ no modifiers, see \cref{modification-environment}) and using the enclosing classes of the denoted class.
+  If the name is a composite name then the class \lstinline!A! is temporarily flattened with an empty environment (i.e., no modifiers, see \cref{modification-environment}) and using the enclosing classes of the denoted class.
   The rest of the name (e.g., \lstinline!B! or \lstinline!B.C!) is looked up among the declared named elements of the temporary flattened class.
   If the class does not satisfy the requirements for a package, the lookup is restricted to encapsulated elements only.
   The class we look inside shall not be partial.
@@ -168,7 +168,7 @@ \section{Inner Declarations - Instance Hierarchy Name Lookup}\label{instance-hie
 \item
   If there is one (or more) \lstinline!outer! declarations of a partial class it is an error.
 \item
-  In other cases, i.e.\ if a unique non-partial class is used for all \lstinline!outer! declarations of the same name lacking a matching inner declaration, then an \lstinline!inner! declaration of that class is automatically added at the top of the model and a diagnostic is given.
+  In other cases, i.e., if a unique non-partial class is used for all \lstinline!outer! declarations of the same name lacking a matching inner declaration, then an \lstinline!inner! declaration of that class is automatically added at the top of the model and a diagnostic is given.
 \item
   The annotations defined in \cref{annotations-for-the-graphical-user-interface} does not affect this process, other than that:
   \begin{itemize}
@@ -367,7 +367,7 @@ \subsection{Instantiation}\label{instantiation}
 
 \subsubsection{The Class Tree}\label{the-class-tree}
 
-All necessary libraries including the model which is to be instantiated are loaded from e.g.\ file system and form a so called \firstuse{class tree}.
+All necessary libraries including the model which is to be instantiated are loaded (e.g., from a file system) and form a so called \firstuse{class tree}.
 This tree represents the syntactic information from the class definitions.
 It contains also all modifications at their original locations in syntactic form.
 The builtin classes are put into the unnamed root of the class tree.
@@ -440,7 +440,7 @@ \subsubsection{Steps of Instantiation}\label{steps-of-instantiation}
 
 \paragraph*{The element itself}\label{the-element-itself}
 
-A \firstuse{partially instantiated} class or component is an element that is ready to be instantiated; a partially instantiated element (i.e.\ class or component) is comprised of a reference to the original element (from the class tree) and the modifiers for that element (including a possible redeclaration).
+A \firstuse{partially instantiated} class or component is an element that is ready to be instantiated; a partially instantiated element (i.e., class or component) is comprised of a reference to the original element (from the class tree) and the modifiers for that element (including a possible redeclaration).
 
 The possible redeclaration of the element itself takes effect.
 
@@ -458,7 +458,7 @@ \subsubsection{Steps of Instantiation}\label{steps-of-instantiation}
 Equations, algorithms, and annotations of the class and the component declaration are copied to the instance without merging.
 
 \begin{nonnormative}
-The annotations can be relevant for simulations, e.g.\ annotations for symbolic processing (\cref{modelica:Evaluate}), simulation experiments (\cref{modelica:experiment}) or functions (\cref{derivatives-and-inverses-of-functions} and \cref{external-function-interface}).
+The annotations can be relevant for simulations, e.g., annotations for symbolic processing (\cref{modelica:Evaluate}), simulation experiments (\cref{modelica:experiment}) or functions (\cref{derivatives-and-inverses-of-functions} and \cref{external-function-interface}).
 \end{nonnormative}
 
 The \lstinline!extends!-clauses are not looked up, but empty \lstinline!extends!-clause nodes are created and inserted into the current instance (to be able to preserve the declaration order of components).
@@ -576,7 +576,7 @@ \subsection{Generation of the Flat Equation System}\label{generation-of-the-flat
 
 \begin{nonnormative}
 This identifier is normally constructed from the names of the instances along a path in the instance tree (and omitting the unnamed nodes of \lstinline!extends!-clauses), separated by dots.
-Either the referenced instance belongs to the model to be simulated the path starts at the model itself, or if not, it starts at the unnamed root of the instance tree, e.g.\ in case of a constant in a package.
+Either the referenced instance belongs to the model to be simulated the path starts at the model itself, or if not, it starts at the unnamed root of the instance tree, e.g., in case of a constant in a package.
 \end{nonnormative}
 
 \begin{nonnormative}
@@ -613,7 +613,7 @@ \subsection{Generation of the Flat Equation System}\label{generation-of-the-flat
     If it is of simple type (\lstinline!Boolean!, \lstinline!Integer!, enumeration, \lstinline!Real!, \lstinline!String!, \lstinline!Clock!, \lstinline!ExternalObject!):
     \begin{itemize}
     \item
-      In the modifications of \emph{non-value} attributes, e.g.\ \lstinline!start!, \lstinline!fixed! etc.\ references are resolved using the instance scope of the modification.
+      In the modifications of \emph{non-value} attributes, e.g., \lstinline!start!, \lstinline!fixed! etc.\ references are resolved using the instance scope of the modification.
       An equation is formed from a reference to the name of the instance appended by a dot and the attribute name and the resolved modification value of the instance, and included into the equation system.
     \end{itemize}
   \item
@@ -634,11 +634,11 @@ \subsection{Generation of the Flat Equation System}\label{generation-of-the-flat
 \item
   Conditional components with false condition are removed afterwards and they are not part of the simulation model.
   \begin{nonnormative}
-  Thus e.g.\ parameters don't need values in them.
+  Thus, e.g., parameters don't need values in them.
   However, type-error can be detected.
   \end{nonnormative}
 \item
-  Each reference is checked, whether it is a valid reference, e.g.\ the referenced object belongs to or is an instance, where all existing conditional declaration expressions evaluate to true or it is a constant in a package.
+  Each reference is checked, whether it is a valid reference, e.g., the referenced object belongs to or is an instance, where all existing conditional declaration expressions evaluate to true or it is a constant in a package.
   \begin{nonnormative}
   Conditional components can be used in \lstinline!connect!-equations, and if the component is conditionally disabled the \lstinline!connect!-equation is removed.
   \end{nonnormative}
@@ -646,8 +646,8 @@ \subsection{Generation of the Flat Equation System}\label{generation-of-the-flat
 
 This leads to a flattened equation system, except for \lstinline!connect!- and \lstinline!transition!-equations.
 These have to be transformed as described in \cref{connectors-and-connections} and \cref{state-machines}.
-This may lead to further changes in the instance tree (e.g.\ from expandable connectors (\cref{expandable-connectors})) and additional equations in the flattened equation system (e.g.\ connection equations (\cref{generation-of-connection-equations}), generated equations for state machine semantics (\cref{semantics-summary})).
+This may lead to further changes in the instance tree (e.g., from expandable connectors (\cref{expandable-connectors})) and additional equations in the flattened equation system (e.g., connection equations (\cref{generation-of-connection-equations}), generated equations for state machine semantics (\cref{semantics-summary})).
 
 \begin{nonnormative}
-After flattening, the resulting equation system is self contained and covers all information needed to transform it to a simulatable model, but the class and instance trees are still needed: in the transformation process, there might be the need to instantiate further functions, e.g.\ from \lstinline!derivative! annotation or from \lstinline!inverse! annotation etc., on demand.
+After flattening, the resulting equation system is self contained and covers all information needed to transform it to a simulatable model, but the class and instance trees are still needed: in the transformation process, there might be the need to instantiate further functions, e.g., from \lstinline!derivative! annotation or from \lstinline!inverse! annotation etc., on demand.
 \end{nonnormative}
diff --git a/chapters/statemachines.tex b/chapters/statemachines.tex
index 93f684e9e..c08fb4bef 100644
--- a/chapters/statemachines.tex
+++ b/chapters/statemachines.tex
@@ -90,8 +90,8 @@ \section{Transitions}\label{transitions}
 The transition fires when $\mathit{condition} = \text{\lstinline!true!}$ if $\mathit{imm} = \text{\lstinline!true!}$ (this is called an \firstuse{immediate transition}\index{transition!immediate}) or \lstinline!previous($\mathit{condition}$)! when $\mathit{imm} = \text{\lstinline!false!}$ (this is called a \firstuse{delayed transition}\index{transition!delayed}).
 Argument \lstinline!priority! defines the priority of firing when several transitions could fire.
 In this case the transition with the smallest value of \lstinline!priority! fires.
-It is required that $\mathit{prio} \geq 1$ and that for all transitions from the same state, the priorities are different. If $\mathit{reset} = \text{\lstinline!true!}$, the states of the target state are reinitialized, i.e.\ state machines are restarted in initial state and state variables are reset to their start values.
-If $\mathit{synch} = \text{\lstinline!true!}$, any transition is disabled until all state machines of the from-state have reached final states, i.e.\ states without outgoing transitions.
+It is required that $\mathit{prio} \geq 1$ and that for all transitions from the same state, the priorities are different. If $\mathit{reset} = \text{\lstinline!true!}$, the states of the target state are reinitialized, i.e., state machines are restarted in initial state and state variables are reset to their start values.
+If $\mathit{synch} = \text{\lstinline!true!}$, any transition is disabled until all state machines of the from-state have reached final states, i.e., states without outgoing transitions.
 For the precise details about firing a transition, see \cref{state-machine-semantics}.
 \end{semantics}
 \end{operatordefinition}
@@ -121,7 +121,7 @@ \section{Transitions}\label{transitions}
 ticksInState()
 \end{lstlisting}\end{synopsis}
 \begin{semantics}
-Returns the number of ticks of the clock of the state machine for which the currently active state has maintained its active state without interruption, i.e.\ without local or hierarchical transitions from this state.  In the case of a self-transition to the currently active state or to an active enclosing state, the number is reset to one.
+Returns the number of ticks of the clock of the state machine for which the currently active state has maintained its active state without interruption, i.e., without local or hierarchical transitions from this state.  In the case of a self-transition to the currently active state or to an active enclosing state, the number is reset to one.
 
 This function can only be used in state machines.
 \end{semantics}
@@ -132,7 +132,7 @@ \section{Transitions}\label{transitions}
 timeInState()
 \end{lstlisting}\end{synopsis}
 \begin{semantics}
-Returns the time duration as \lstinline!Real! in {[}s{]} for which the currently active state has maintained its active state without interruption, i.e.\ without local or hierarchical transitions from this state. In the case of a self-transition to the currently active state or to an active enclosing state, the time is reset to zero.
+Returns the time duration as \lstinline!Real! in {[}s{]} for which the currently active state has maintained its active state without interruption, i.e., without local or hierarchical transitions from this state. In the case of a self-transition to the currently active state or to an active enclosing state, the time is reset to zero.
 
 This function can only be used in state machines.
 \end{semantics}
@@ -277,7 +277,7 @@ \subsection{State Activation}\label{state-activation}
 \end{lstlisting}
 
 In a similar way, the \lstinline!Integer delayed! is calculated as the index for a
-potentially delayed transition, i.e.\ a transition taking place at the
+potentially delayed transition, i.e., a transition taking place at the
 next clock tick. In this case the from-state needs to be equal to
 \lstinline!nextState!:
 \begin{lstlisting}[language=modelica]
@@ -301,7 +301,7 @@ \subsection{State Activation}\label{state-activation}
     previous(nextState);
 \end{lstlisting}
 In order to define synchronize transitions, each state machine must
-determine which are the final states, i.e.\ states without
+determine which are the final states, i.e., states without
 from-transitions and to determine if the state machine is in a final
 state currently:
 \begin{lstlisting}[language=modelica]
@@ -467,7 +467,7 @@ \subsection{Example}\label{example}
 \item
   \lstinline!state1! is a meta state with two parallel state machines in it.
 \item
-  \lstinline!stateA! declares \lstinline!v! as \lstinline!outer output!. \lstinline!state1! is on an intermediate level and declares \lstinline!v! as \lstinline!inner outer output!, i.e.\ matches lower level \lstinline!outer v! by being \lstinline!inner! and also matches higher level \lstinline!inner v! by being \lstinline!outer!.
+  \lstinline!stateA! declares \lstinline!v! as \lstinline!outer output!. \lstinline!state1! is on an intermediate level and declares \lstinline!v! as \lstinline!inner outer output!, i.e., matches lower level \lstinline!outer v! by being \lstinline!inner! and also matches higher level \lstinline!inner v! by being \lstinline!outer!.
   The top level declares \lstinline!v! as \lstinline!inner! and gives the start value.
 \item
   \lstinline!count! is defined with a start value in \lstinline!state1!. It is reset when
diff --git a/chapters/statements.tex b/chapters/statements.tex
index 7c1b94845..ae4de4d60 100644
--- a/chapters/statements.tex
+++ b/chapters/statements.tex
@@ -246,7 +246,7 @@ \subsubsection{Implicit Iteration Ranges}\label{implicit-iteration-ranges}
 \subsubsection{Types as Iteration Ranges}\label{types-as-iteration-ranges}
 
 The iteration range can be specified as \lstinline!Boolean! or as an enumeration type.
-This means iteration over the type from min to max, i.e.\ for \lstinline!Boolean! it is the same as \lstinline!false:true! and for an enumeration \lstinline!E! it is the same as \lstinline!E.min:E.max!.
+This means iteration over the type from min to max, i.e., for \lstinline!Boolean! it is the same as \lstinline!false:true! and for an enumeration \lstinline!E! it is the same as \lstinline!E.min:E.max!.
 This can be used for \lstinline!for!-loops and reduction expressions.
 
 \begin{example}
@@ -465,7 +465,7 @@ \subsubsection{Defining When-Statements by If-Statements}\label{defining-when-st
   end if;
 \end{lstlisting}
 with \lstinline!edge(A) = A and not pre(A)! and the additional guarantee, that the statements within this special \lstinline!if!-statement are only evaluated at event instants.
-The difference compared to the when-statements is that e.g.\ \lstinline!pre! may only be used on continuous-time real variables inside the body of a \lstinline!when!-clause and not inside these if-statements.
+The difference compared to the when-statements is that, e.g., \lstinline!pre! may only be used on continuous-time real variables inside the body of a \lstinline!when!-clause and not inside these if-statements.
 
 \subsection{Special Statements}\label{special-statements}
 
diff --git a/chapters/stream.tex b/chapters/stream.tex
index 5ca41dd7a..e36682ac6 100644
--- a/chapters/stream.tex
+++ b/chapters/stream.tex
@@ -386,7 +386,7 @@ \section{actualStream}\label{stream-operator-actualstream}\label{actualstream}
 wants to avoid events entirely, he/she may enclose the right-hand side
 of (1) with \lstinline!noEvent!.
 
-Equations like (2) might be used for monitoring purposes (e.g.\ plots), in order to inspect what the actual enthalpy of the fluid flowing through a port is.
+Equations like (2) might be used for monitoring purposes (e.g., plots), in order to inspect what the actual enthalpy of the fluid flowing through a port is.
 In this case, the user will probably want to see the change due to flow reversal at the exact instant, so an event should be generated.  If the user doesn't
 bother, then he/she should enclose the right-hand side of (2) with \lstinline!noEvent!.  Since the output of \lstinline!actualStream! will be discontinuous,
 it should not be used by itself to model physical behaviour (e.g., to compute densities used in momentum balances) -- \lstinline!inStream! should be used
diff --git a/chapters/synchronous.tex b/chapters/synchronous.tex
index eba528952..6dac49dc4 100644
--- a/chapters/synchronous.tex
+++ b/chapters/synchronous.tex
@@ -119,7 +119,7 @@ \section{Rationale for Clocked Semantics}\label{rationale-for-clocked-semantics}
   For a standard \lstinline!when!-clause the condition (sampling) must be explicitly
   propagated to all blocks, which is tedious and error prone for large systems.
 \item
-  Possible to use general continuous-time models in synchronous models (e.g.\ some advanced controllers use an inverse model of a plant in the feedforward path of the controller, see \textcite{ThummelEtAl2005InverseModels}).
+  Possible to use general continuous-time models in synchronous models (e.g., some advanced controllers use an inverse model of a plant in the feedforward path of the controller, see \textcite{ThummelEtAl2005InverseModels}).
   This powerful feature of Modelica to use a nonlinear plant model in a controller would require to export the continuous-time model with an embedded integration method and then import it in an environment where the rest of the controller is defined.
   With clocked equations, clocked controllers with continuous-time models can be directly defined in Modelica.
 \item
@@ -136,7 +136,7 @@ \section{Rationale for Clocked Semantics}\label{rationale-for-clocked-semantics}
   that are only run the first event iterations.
 \item
   Clocked subsystems using arithmetic blocks are straightforward to optimize.
-  When a standard math-block (e.g.\ addition) is part of a clocked sub-system it is automatically
+  When a standard math-block (e.g., addition) is part of a clocked sub-system it is automatically
   clocked and only evaluated when the clocked equations trigger.
   For standard \lstinline!when!-clauses one either needs a separate sampled math-block for each operation, or
   it will conceptually be evaluated all the time.
@@ -665,7 +665,7 @@ \subsection{Sub-Clock Conversion Operators}\label{sub-clock-conversion-operators
 \item
   The optional input arguments \lstinline!factor! (defaults to 0, with \lstinline!min = 0!), and \lstinline!resolution! (defaults to 1, with \lstinline!min = 1!) are parameter expressions of type \lstinline!Integer!.
 \item
-  Calls of the operators can use named arguments for the multi-letter arguments (i.e.\ not for $u$) with the given names, or positional arguments.
+  Calls of the operators can use named arguments for the multi-letter arguments (i.e., not for $u$) with the given names, or positional arguments.
 \begin{nonnormative}
 Named arguments can make the calls easier to understand.
 \end{nonnormative}
@@ -1286,7 +1286,7 @@ \subsection{Solver Methods}\label{solver-methods}
 For the implicit integration methods the efficiency can be enhanced by utilizing the discretization formula during the symbolic transformation of the equations.
 For example, linear differential equations are then mapped to linear and not non-linear algebraic equation systems, and also the structure of the equations can be utilized.
 For details see \textcite{ElmqvistOtterCellier1995InlineIntegration}.
-It might be necessary to associate additional data for an implicit integration method, e.g.\ the relative tolerance to solve the non-linear algebraic equation systems, or the maximum number of iterations in case of hard realtime requirements.
+It might be necessary to associate additional data for an implicit integration method, e.g., the relative tolerance to solve the non-linear algebraic equation systems, or the maximum number of iterations in case of hard realtime requirements.
 This data is tool specific and is typically either defined with a vendor annotation or is given in the simulation environment.
 \end{nonnormative}
 
diff --git a/styleguide.md b/styleguide.md
index 856733832..44db4e73d 100644
--- a/styleguide.md
+++ b/styleguide.md
@@ -254,3 +254,8 @@ When a sentence starts with inline code,
 this may be rewritten using _The_ inserted before the inline code to avoid a lower case letter at the beginning of the sentence:
 
 > The `import`-clauses are not inherited.
+
+### Wrap punctuations around some abbreviations 
+
+Always use comma (or colon if the following text starts on new line) _after_ "e.g." and "i.e."; and use comma or some other punctuation such as "(", "--", or "." before them.
+This also avoids the need to guard the space after the dot.