fixed some typos

.gitattributes

@@ -16,7 +16,7 @@
 *.py text
 *.xml text
 *.js text
-*.hmtl text
+*.html text
 *.bib text
 *.css text
 *.ui text

AABB_tree/doc/AABB_tree/aabb_tree.txt

@@ -106,7 +106,7 @@ it is used only for distance computations.
 \warning Having degenerate primitives in the AABB-tree is not recommended as the underlying
 predicates and constructions of the traits class might not be able to handle them.
 For example if one is using `CGAL::AABB_traits` with a Kernel from \cgal,
-having degenerate triangles or segments in the AABB-tree will results in an undefined
+having degenerate triangles or segments in the AABB-tree will result in an undefined
 behavior or a crash.
 
 \section aabb_tree_examples Examples
@@ -197,9 +197,9 @@ The AABB tree example folder contains three examples of trees
 constructed with custom primitives. In \ref AABB_tree/AABB_custom_example.cpp "AABB_custom_example.cpp"
 the primitive contains triangles which are defined by three pointers
 to custom points. In \ref AABB_tree/AABB_custom_triangle_soup_example.cpp "AABB_custom_triangle_soup_example.cpp" all input
-triangles are stored into a single array so as to form a triangle
-soup. The primitive internally uses a `boost::iterator_adaptor` so as
-to provide the three functions `AABBPrimitive::id()`, `AABBPrimitive::datum()`,
+triangles are stored into a single array as to form a triangle
+soup. The primitive internally uses a `boost::iterator_adaptor`
+as to provide the three functions `AABBPrimitive::id()`, `AABBPrimitive::datum()`,
 and `AABBPrimitive::reference_point()`) required by the primitive concept. In
 \ref AABB_tree/AABB_custom_indexed_triangle_set_example.cpp "AABB_custom_indexed_triangle_set_example.cpp" the input is an indexed
 triangle set stored through two arrays: one array of points and one
@@ -213,7 +213,7 @@ contains a set of polyhedron triangle facets. We measure the tree
 construction time, the memory occupancy and the number of queries per
 second for a variety of intersection and distance queries. The machine
 used is a PC running Windows XP64 with an Intel CPU Core2 Extreme
-clocked at 3.06 GHz with 4GB of RAM. By default the kernel used is
+clocked at 3.06 GHz with 4GB of RAM. By default, the kernel used is
 `Simple_cartesian<double>` (the fastest in our experiments). The
 program has been compiled with Visual C++ 2005 compiler with the O2
 option which maximizes speed.
@@ -244,7 +244,7 @@ internal KD-tree). It increases to approximately 150 bytes per
 primitive when constructing the internal KD-tree with one reference
 point per primitive (the default mode when calling the function
 `AABB_tree::accelerate_distance_queries()`). Note that the polyhedron
-facet primitive primitive stores only one facet handle as primitive id
+facet primitive stores only one facet handle as primitive id
 and computes on the fly a 3D triangle from the facet handle stored
 internally. When explicitly storing a 3D triangle in the primitive the
 tree occupies approximately 140 bytes per primitive instead of 60
@@ -340,7 +340,7 @@ inside the bounding box.
 
 The experiments described above are neither exhaustive nor conclusive
 as we have chosen one specific case where the input primitives are the
-facets of a triangle surface polyhedron. Nevertheless we now provide
+facets of a triangle surface polyhedron. Nevertheless, we now provide
 some general observations and advises about how to put the AABB tree
 to use with satisfactory performances. While the tree construction
 times and memory occupancy do not fluctuate much in our experiments

Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt

@@ -15,7 +15,7 @@ As a consequence types representing polynomials, algebraic extensions and
 finite fields play a more important role in related implementations.
 This package has been introduced to stay abreast of these changes.
 Since in particular polynomials must be supported by the introduced framework
-the package avoids the term <I>number type</I>. Instead the package distinguishes
+the package avoids the term <I>number type</I>. Instead, the package distinguishes
 between the <I>algebraic structure</I> of a type and whether a type is embeddable on
 the real axis, or <I>real embeddable</I> for short.
 Moreover, the package introduces the notion of <I>interoperable</I> types which
@@ -45,11 +45,11 @@ the operations 'sqrt', 'k-th root' and 'real root of a polynomial',
 respectively. The concept `IntegralDomainWithoutDivision` also
 corresponds to integral domains in the algebraic sense, the
 distinction results from the fact that some implementations of
-integral domains lack the (algebraically always well defined) integral
+integral domains lack the (algebraically always well-defined) integral
 division.
 Note that `Field` refines `IntegralDomain`. This is because
 most ring-theoretic notions like greatest common divisors become trivial for
-`Field`s. Hence we see `Field` as a refinement of
+`Field`s. Hence, we see `Field` as a refinement of
 `IntegralDomain` and not as a
 refinement of one of the more advanced ring concepts.
 If an algorithm wants to rely on gcd or remainder computation, it is trying
@@ -119,7 +119,7 @@ Conversely, types as `leda_real` or `CORE::Expr` are exact but sensitive
 to numerical issues due to the internal use of multi precision floating point
 arithmetic. We expect that `Is_numerical_sensitive` is used for dispatching
 of algorithms, while `Is_exact` is useful to enable assertions that can be
-check for exact types only.
+checked for exact types only.
 
 Tags are very useful to dispatch between alternative implementations.
 The following example illustrates a dispatch for `Field`s using overloaded
@@ -134,7 +134,7 @@ category tags reflect the algebraic structure hierarchy.
 
 Most number types represent some subset of the real numbers. From those types
 we expect functionality to compute the sign, absolute value or double
-approximations. In particular we can expect an order on such a type that
+approximations. In particular, we can expect an order on such a type that
 reflects the order along the real axis.
 All these properties are gathered in the concept `::RealEmbeddable`.
 The concept is orthogonal to the algebraic structure concepts,
@@ -190,12 +190,12 @@ In general mixed operations are provided by overloaded operators and
 functions or just via implicit constructor calls.
 This level of interoperability is reflected by the concept
 `ImplicitInteroperable`. However, within template code the result type,
-or so called coercion type, of a mixed arithmetic operation may be unclear.
+or so-called coercion type, of a mixed arithmetic operation may be unclear.
 Therefore, the package introduces `Coercion_traits`
 giving access to the coercion type via \link Coercion_traits::Type `Coercion_traits<A,B>::Type` \endlink
 for two interoperable types `A` and `B`.
 
-Some trivial example are `int` and `double` with coercion type double
+Some trivial examples are `int` and `double` with coercion type double
 or `Gmpz` and `Gmpq` with coercion type `Gmpq`.
 However, the coercion type is not necessarily one of the input types,
 e.g. the coercion type of a polynomial
@@ -269,7 +269,7 @@ The package is part of \cgal since release 3.3. Of course the package is based
 on the former Number type support of CGAL. This goes back to Stefan Schirra and Andreas Fabri. But on the other hand the package is to a large extend influenced
 by the experience with the number type support in \exacus \cgalCite{beh-eeeafcs-05},
 which in the main goes back to
-Lutz Kettner, Susan Hert, Arno Eigenwillig and Michael Hemmer.
+Lutz Kettner, Susan Hert, Arno Eigenwillig, and Michael Hemmer.
 However, the package abstracts from the pure support for
 number types that are embedded on the real axis which allows the support of
 polynomials, finite fields, and algebraic extensions as well. See also related

Algebraic_kernel_d/doc/Algebraic_kernel_d/Algebraic_kernel_d.txt

@@ -146,8 +146,8 @@ polynomial is not computed yet.
 This is in particular relevant in relation to the `AlgebraicKernel_d_2`,
 where `AlgebraicKernel_d_1::Algebraic_real_1` is used to represent coordinates of solutions of bivariate systems.
 Hence, the design does
-not allow a direct access to any, seemingly obvious, members of an
-`AlgebraicKernel_d_1::Algebraic_real_1`. Instead there is, e.g.,
+not allow direct access to any, seemingly obvious, members of an
+`AlgebraicKernel_d_1::Algebraic_real_1`. Instead, there is, e.g.,
 `AlgebraicKernel_d_1::Compute_polynomial_1` which emphasizes
 that the requested polynomial may not be computed yet. Similarly,
 there is no way to directly ask for the refinement of the current

Alpha_shapes_2/doc/Alpha_shapes_2/Alpha_shapes_2.txt

@@ -35,8 +35,8 @@ of this process in 2D (where our ice-cream spoon is simply a circle).
 
 Alpha shapes depend on a parameter \f$ \alpha\f$ after which they are named.
 In the ice-cream analogy above, \f$ \alpha\f$ is the squared radius of the
-carving spoon. A very small value will allow us to eat up all of the
-ice-cream except the chocolate points themselves. Thus we already see
+carving spoon. A very small value will allow us to eat up all the
+ice-cream except the chocolate points themselves. Thus, we already see
 that the \f$ \alpha\f$-shape degenerates to the point-set \f$ S\f$ for
 \f$ \alpha \rightarrow 0\f$. On the other hand, a huge value of \f$ \alpha\f$
 will prevent us even from moving the spoon between two points since
@@ -53,7 +53,7 @@ We distinguish two versions of alpha shapes. <I>Basic alpha shapes</I>
 are based on the Delaunay triangulation. <I>Weighted alpha shapes</I>
 are based on its generalization, the regular triangulation
 (cf. Section \ref Section_2D_Triangulations_Regular "Regular Triangulations"),
-replacing the euclidean distance by the power to weighted points.
+replacing the Euclidean distance by the power to weighted points.
 
 There is a close connection between alpha shapes and the underlying
 triangulations. More precisely, the \f$ \alpha\f$-complex of \f$ S\f$ is a
@@ -100,7 +100,7 @@ It provides iterators to enumerate the vertices and edges that are in
 the \f$ \alpha\f$-shape, and functions that allow to classify vertices,
 edges and faces with respect to the \f$ \alpha\f$-shape. They can be in
 the interior of a face that belongs or does not belong to the \f$ \alpha\f$-shape.
-They can be singular/regular, that is be on the boundary of the \f$ \alpha\f$-shape,
+They can be singular/regular, that is, they can be on the boundary of the \f$ \alpha\f$-shape,
 but not incident/incident to a triangle of the \f$ \alpha\f$-complex.
 
 Finally, it provides a function to determine the \f$ \alpha\f$-value
@@ -213,7 +213,7 @@ cube will be chosen and no optimizations will be used.
 It is also recommended to switch the triangulation to 1-sheeted
 covering if possible. Note that a periodic triangulation in 9-sheeted
 covering space is degenerate. In this case, an exact constructions
-kernel needs to be used to compute the alpha shapes. Otherwise the
+kernel needs to be used to compute the alpha shapes. Otherwise, the
 results will suffer from round-off problems.
 
 \cgalExample{Alpha_shapes_2/ex_periodic_alpha_shapes_2.cpp}

Alpha_shapes_3/doc/Alpha_shapes_3/Alpha_shapes_3.txt

@@ -34,8 +34,8 @@ of this process in 2D (where our ice-cream spoon is simply a circle).
 
 Alpha shapes depend on a parameter \f$ \alpha\f$ after which they are named.
 In the ice-cream analogy above, \f$ \alpha\f$ is the squared radius of the
-carving spoon. A very small value will allow us to eat up all of the
-ice-cream except the chocolate points themselves. Thus we already see
+carving spoon. A very small value will allow us to eat up all the
+ice-cream except the chocolate points themselves. Thus, we already see
 that the alpha shape degenerates to the point-set \f$ S\f$ for
 \f$ \alpha \rightarrow 0\f$. On the other hand, a huge value of \f$ \alpha\f$
 will prevent us even from moving the spoon between two points since
@@ -53,7 +53,7 @@ We distinguish two versions of alpha shapes. <I>Basic alpha shapes</I>
 are based on the Delaunay triangulation. <I>Weighted alpha shapes</I>
 are based on its generalization, the regular triangulation
 (cf. Section \ref Triangulation3secclassRegulartriangulation "Regular Triangulations"),
-replacing the euclidean distance by the power to weighted points.
+replacing the Euclidean distance by the power to weighted points.
 
 Let us consider the basic case with a Delaunay triangulation.
 We first define the alpha complex of the set of points \f$ S\f$.
@@ -79,7 +79,7 @@ of the alpha complex where singular faces are removed
 (See \cgalFigureRef{figgenregex} for an example).
 
 \cgalFigureBegin{figgenregex,gen-reg-ex.png}
-Comparison of general and regularized alpha-shape. <B>Left:</B> Some points are taken on the surface of a torus, three points being taken relatively far from the surface of the torus; <B>Middle:</B> The general alpha-shape (for a large enough alpha value) contains the singular triangle facet of the three isolated points; <B>Right:</B> The regularized version (for the same value of alpha) does not contains any singular facet.
+Comparison of general and regularized alpha-shape. <B>Left:</B> Some points are taken on the surface of a torus, three points being taken relatively far from the surface of the torus; <B>Middle:</B> The general alpha-shape (for a large enough alpha value) contains the singular triangle facet of the three isolated points; <B>Right:</B> The regularized version (for the same value of alpha) does not contain any singular facet.
 \cgalFigureEnd
 
 The alpha shapes of a set of points
@@ -112,11 +112,11 @@ and radii \f$ r_1, r_2 \f$ are said to be orthogonal iff
 iff \f$ C_1C_2 ^2 < r_1^2 + r_2^2\f$.
 For a given value of \f$ \alpha\f$,
 the weighted alpha complex is formed with the simplices of the
-regular triangulation triangulation
-such that there is a sphere orthogonal to the weighted points associated
+regular triangulation such that there is a sphere
+orthogonal to the weighted points associated
 with the vertices of the simplex and suborthogonal to all the other
 input weighted points. Once again the alpha shape is then defined as
-the domain covered by a the alpha complex and comes in general and
+the domain covered by the alpha complex and comes in general and
 regularized versions.
 
 \section Alpha_Shape_3Functionality Functionality
@@ -273,7 +273,7 @@ alpha-shape, using the `Alpha_shape_3<Dt,ExactAlphaComparisonTag>` requires a ke
 with exact predicates and exact constructions (or setting `ExactAlphaComparisonTag` to `Tag_true`)
 while using a kernel with exact predicates is sufficient for the class `Fixed_alpha_shape_3<Dt>`.
 This makes the class `Fixed_alpha_shape_3<Dt>` even more efficient in this setting.
-In addition, note that the `Fixed` version is the only of the
+In addition, note that the `Fixed` version is the only one of the
 two that supports incremental insertion and removal of points.
 
 We give the time spent while computing the alpha shape of a protein (considered
@@ -345,7 +345,7 @@ cube will be chosen and no optimizations will be used.
 It is also recommended to switch the triangulation to 1-sheeted
 covering if possible. Note that a periodic triangulation in 27-sheeted
 covering space is degenerate. In this case, an exact constructions
-kernel needs to be used to compute the alpha shapes. Otherwise the
+kernel needs to be used to compute the alpha shapes. Otherwise, the
 results will suffer from round-off problems.
 
 \cgalExample{Alpha_shapes_3/ex_periodic_alpha_shapes_3.cpp}

Alpha_wrap_3/doc/Alpha_wrap_3/alpha_wrap_3.txt

@@ -264,7 +264,7 @@ Secondly, the farther the isosurface is from the input, the more new points are
 through the first criterion (i.e., through intersection with dual Voronoi edge, see Section \ref aw3_algorithm);
 thus, the quality of the output improves in terms of angles of the triangle elements.
 Finally, and depending on the value of the alpha parameter, a large offset can also offer defeaturing capabilities.
-However using a small offset parameter will tend to better preserve sharp features as projection
+However, using a small offset parameter will tend to better preserve sharp features as projection
 Steiner points tend to project onto convex sharp features.
 
 \cgalFigureAnchor{6}
@@ -278,7 +278,7 @@ Impact of the offset parameter on the output.
 The offset parameter is decreasing from left to right, to respectively 1/50, 1/200 and 1/1000 of the longest diagonal of the input bounding box.
 The alpha parameter is equal to 1/50 of the longest diagonal of the input bounding box for all level of details.
 A larger offset will produce an output less complex with better triangle quality.
-However the sharp features (red edges) are well preserved when the offset parameter is small.
+However, the sharp features (red edges) are well-preserved when the offset parameter is small.
 \cgalFigureCaptionEnd
 
 \cgalFigureAnchor{7}
@@ -346,15 +346,15 @@ The charts below plots the computation times of the wrapping algorithm on the Th
 \cgalFigureCaptionBegin{9}
 Execution times and output complexity for different values of alpha on the Thingi10k data set.
 Alpha increases from 1/20 to 1/200 of the length of bounding box diagonal.
-The x axis represents the complexity of the output wrap mesh in number of triangle facets.
-The y axis represents the total computation time, in seconds.
+The x-axis represents the complexity of the output wrap mesh in number of triangle facets.
+The y-axis represents the total computation time, in seconds.
 The color and diameter of the dots represent the number of faces in the input triangle soup,
 ranging from 10 (green) to 3154000 (blue).
 \cgalFigureCaptionEnd
 
 \section aw3_examples Examples
 
-Here is an example with an input triangle mesh, with alpha set to 1/20 of the bounding box longest diagonal edge length,
+Here is an example with an input triangle mesh, with alpha set to 1/20 of the bounding box's longest diagonal edge length,
 and offset set to 1/30 of alpha (i.e., 1/600 of the bounding box diagonal edge length).
 
 \cgalExample{Alpha_wrap_3/triangle_mesh_wrap.cpp}