- Fix for universal brain damage: "the the" -> "the".

Arrangement_2/doc_tex/Arrangement_2/arr_intro.tex

@@ -41,7 +41,7 @@ maintains the incidence relations among these objects.
 
 The main idea behind the \dcel\ data-structure is to represent
 each edge using a pair of directed {\em halfedges}, one going from
-the the $xy$-lexicographically smaller (left) endpoint of the curve toward
+the $xy$-lexicographically smaller (left) endpoint of the curve toward
 its the $xy$-lexicographically larger (right) endpoint, and the other,
 known as its {\em twin} halfedge, going in the opposite direction. As each
 halfedge is directed, we say it has a {\em source} vertex and a {\em target}

Arrangement_2/doc_tex/Arrangement_2/arr_traits.tex

@@ -220,7 +220,7 @@ class-template with the predefined
 \ccc{Exact_predicates_inexact_constructions_kernel}. Note that we use
 the \ccc{insert_non_intersecting_curves()} function to construct the
 arrangement.
-By default, the example opens the the \ccc{Europe.dat} input-file,
+By default, the example opens the \ccc{Europe.dat} input-file,
 located in the examples folder, which contains more than $3000$ line segments
 with floating-point coordinates that form the map of Europe, as depicted in
 Figure~\ref{arr_fig:predef_kernels}(b):

Arrangement_2/doc_tex/Arrangement_2_ref/Arr_halfedge.tex

@@ -46,7 +46,7 @@ that return constant handles, iterators or circulators:
     {returns a handle for the source vertex of \ccVar{}.}
 \ccGlue
 \ccMethod{Vertex_handle target();}
-    {returns a handle for the the target vertex of \ccVar{}.}
+    {returns a handle for the target vertex of \ccVar{}.}
 
 \ccMethod{Comparison_result direction() const;}
     {returns the direction of the halfedge: \ccc{SMALLER} if \ccVar{}'s

Kernel_d/doc_tex/Convex_hull_d_ref/Convex_hull_d.tex

@@ -75,7 +75,7 @@ Note that each iterator fits the handle concept, i.e. iterators can be
 used as handles. Note also that all iterator and handle types come
 also in a const flavor, e.g., \ccc{Vertex_const_iterator} is the
 constant version of \ccc{Vertex_iterator}. Const correctness requires
-to use the const version whenever the the convex hull object is
+to use the const version whenever the convex hull object is
 referenced as constant. The \ccc{Hull_vertex_iterator} is convertible
 to \ccc{Vertex_iterator} and \ccc{Vertex_handle}.
 

Kernel_d/doc_tex/Kernel_d/kernel_representation_d.tex

@@ -214,7 +214,7 @@ due to accumulated rounding errors.
 
 \subsection{Inclusion of Header Files}
 
-You need just to include a representation class to obtain the the
+You need just to include a representation class to obtain the
 geometric objects of the kernel that you would like to use with the
 representation class, i.e., \ccc{CGAL/Cartesian_d.h} or
 \ccc{CGAL/Homogeneous_d.h}

Kinetic_data_structures/doc_tex/Kinetic_data_structures/sorted_impl_example.tex

@@ -180,7 +180,7 @@ a notification. Validation consists of using the
 ordered correctly.
 
 The remaining two methods, \ccc{set} and \ccc{erase} are only
-necessary if the the kinetic data structure wishes to support dynamic
+necessary if the kinetic data structure wishes to support dynamic
 trajectory changes and removals. These methods are called by the
 \ccc{mot_listener_} helper when appropriate.
 

Kinetic_data_structures/doc_tex/Kinetic_data_structures/trivial_kds_example.tex

@@ -10,7 +10,7 @@ kinetic data structure so that the \ccc{operator<<} can be defined for
 them. 
 
 The kinetic data structure maintains one event containing a list of
-the trajectories of all objects in the the simulation. This
+the trajectories of all objects in the simulation. This
 event must updated whenever any objects change, in addition, it is
 always created to fail one time unit in the future, so it must be
 recreated when it fails. As a result, the kinetic data structure has

Nef_3/doc_tex/Nef_3_ref/Nef_polyhedron_3_Halfedge.tex

@@ -44,7 +44,7 @@ function \ccc{twin()} returns the opposite halfedge.
 
 Looking at the incidence structure on a sphere map, the member function 
 \ccc{out_sedge} returns the first outgoing shalfedge, and \ccc{incident_sface}
-returns the the incident sface.
+returns the incident sface.
 
 \ccInclude{CGAL/Nef_polyhedron_3.h}
 

Nef_S2/doc_tex/Nef_S2_ref/Nef_polyhedron_S2_SVertex.tex

@@ -27,7 +27,7 @@ The figure on page
 
 The member function 
 \ccc{out_sedge} returns the first outgoing shalfedge, and \ccc{incident_sface}
-returns the the incident sface.
+returns the incident sface.
 
 \ccInclude{CGAL/Nef_polyhedron_S2.h}
 

Partition_2/doc_tex/Partition_2_ref/greene_approx_convex_partition_2.tex

@@ -63,7 +63,7 @@ with the representation type determined by \ccc{InputIterator::value_type}.
 \ccRefIdfierPage{CGAL::y_monotone_partition_2} 
 
 \ccImplementation
-This function implements the the approximation algorithm of 
+This function implements the approximation algorithm of 
 Greene \cite{g-dpcp-83} and requires $O(n \log n)$ time and $O(n)$ space
 to produce a convex partitioning given a $y$-monotone partitioning of a
 polygon with $n$ vertices.  The function \ccc{y_monotone_partition_2} 

Polygon/doc_tex/Polygon_ref/right_vertex_2.tex

@@ -37,7 +37,7 @@ with the largest \ccStyle{y}-coordinate is taken.
 \begin{enumerate}
     \item \ccc{Traits} is a model of the concept 
 	  PolygonTraits\_2\ccIndexMainItem[c]{PolygonTraits_2}.
-	  In fact, only the the members \ccc{Less_xy_2} and
+	  In fact, only the members \ccc{Less_xy_2} and
 	  \ccc{less_xy_2_object} are used.
     \item \ccc{ForwardIterator::value_type} should be \ccc{Traits::Point_2},
 \end{enumerate}

Polygon/doc_tex/Polygon_ref/top_vertex_2.tex

@@ -37,7 +37,7 @@ with the largest \ccStyle{x}-coordinate is taken.
 \begin{enumerate}
     \item \ccc{Traits} is a model of the concept 
 	  PolygonTraits\_2\ccIndexMainItem[c]{PolygonTraits_2}.
-	  In fact, only the the members \ccc{Less_yx_2} and
+	  In fact, only the members \ccc{Less_yx_2} and
 	  \ccc{less_yx_2_object} are used.
     \item \ccc{ForwardIterator::value_type} should be \ccc{Traits::Point_2},
 \end{enumerate}

Polygonal_approximation_d/doc_tex/Polygonal_approximation_d/main.tex

@@ -29,7 +29,7 @@ polyline and the simplified polyline, or as the sum of all
 these distances.
 
 Although the interface is generic, this package implements faster algorithms
-for the the Euclidean distance, namely the incremental algorithm \cite{[cgal:pv-opadc-94]},
+for the Euclidean distance, namely the incremental algorithm \cite{[cgal:pv-opadc-94]},
 and the algorithm based on the path hull structure \cite{[hs-sudpl-92]}.
 
 Finally, another group of algorithms, optimal polyline simplification methods

QP_solver/doc_tex/Optimisation_ref/QP_pricing_strategy.tex

@@ -46,7 +46,7 @@ internals.}
 %the bounds themselves can be evaluated with floating point arithmetic. 
 
 User provided pricing strategies may use \ccRefName\ as a base class directly
-or inherit from the the class \ccc{QP__filtered_base} or from the class
+or inherit from the class \ccc{QP__filtered_base} or from the class
 \ccc{QP__partial_base} or both.   
    
 

QP_solver/doc_tex/Optimisation_ref/QP_solver.tex

@@ -265,7 +265,7 @@ solution, see \ccc{variables_value_begin()} below.}
 %KKT
 %\ccNestedType{Lambda_value_iterator}{a STL random access iterator with value type}
 
-%The following enum type is provided by the the class \ccRefName\ :
+%The following enum type is provided by the class \ccRefName\ :
 
 \ccEnum{enum Strategy { FULL_EXACT_PRICING, FULL_FILTERED_PRICING,
 PARTIAL_EXACT_PRICING, PARTIAL_FILTERED_PRICING };}{enumeration used

Segment_Delaunay_graph_2/doc_tex/Segment_Delaunay_graph_2_ref/SegmentDelaunayGraphTraits_2.tex

@@ -229,7 +229,7 @@ and has as endpoints the Voronoi vertices $v_{\infty{}12}$ and
 $v_{\infty{}31}$ defined by the triplets
 $s_\infty$, \ccc{s1}, \ccc{s2} and $s_\infty$, \ccc{s3} and
 \ccc{s1}. The sign \ccc{sgn} is the common sign of the distances of
-\ccc{q} from the Voronoi circles centered at the the vertices
+\ccc{q} from the Voronoi circles centered at the vertices
 $v_{\infty{}12}$ and $v_{\infty{}31}$. If \ccc{sgn} is \ccc{NEGATIVE},
 the predicate returns \ccc{true} if and only if the entire Voronoi
 edge is in conflict with \ccc{q}. If \ccc{sgn} is \ccc{POSITIVE} or

Segment_Delaunay_graph_2/doc_tex/Segment_Delaunay_graph_2_ref/Segment_Delaunay_graph_2.tex

@@ -222,7 +222,7 @@ Gt gt=Gt());}
 {Returns the number of finite vertices of the segment Delaunay graph.}
 \ccGlue
 \ccMethod{size_type number_of_faces();}
-{Returns the number of faces (both finite and infinite) of the the
+{Returns the number of faces (both finite and infinite) of the
   segment Delaunay graph.}
 \ccGlue
 \ccMethod{size_type number_of_input_sites();}

Spatial_searching/doc_tex/Spatial_searching/intro.tex

@@ -129,7 +129,7 @@ browsing for queries defined by points or spatial objects.
 supported using exact or fuzzy $d$-dimensional objects enclosing a
 region.  The fuzziness of the query object is specified by a parameter
 $\epsilon$ denoting a maximal allowed distance to the boundary of a
-query object.  If the distance to the the boundary is at least
+query object.  If the distance to the boundary is at least
 $\epsilon$, points inside the object are always reported and points
 outside the object are never reported. Points within distance
 $\epsilon$ to the boundary may be or may be not reported.  For exact

Triangulation_2/doc_tex/TDS_2/tds_user.tex

@@ -117,7 +117,7 @@ The triangulation data structure
 is required to provide :
 \begin{itemize}
 \item
-the types \ccc{Vertex} and \ccc{Face} for the the vertices
+the types \ccc{Vertex} and \ccc{Face} for the vertices
 and faces of the triangulations
 \item the type \ccc{Vertex_handle} and \ccc{Face_handle}
 which are models of the concept \ccc{Handle} and 

Triangulation_2/doc_tex/Triangulation_2_ref/Regular_triangulation_2.tex

@@ -267,7 +267,7 @@ located in  \ccc{lt,loc,li}.}
   get_boundary_of_conflicts_and_hidden_vertices(const Weighted_point
   &p, OutputItBoundaryEdges eit,
   OutputItHiddenVertices vit, Face_handle start) const;} 
-{ same as above except that only the the vertices that would be hidden
+{ same as above except that only the vertices that would be hidden
   by \ccc{p} and the boundary of the zone in conflict with \ccc{p} are
   output via the corresponding output iterators. The boundary edges of
   the conflict zone are ouput in counterclockwise order and each edge

Triangulation_2/doc_tex/Triangulation_2_ref/Triangulation_2.tex

@@ -809,7 +809,7 @@ to \ccc{v}.}
 to \ccc{v}.}
 \ccGlue
 \ccMethod{Edge_circulator incident_edges(Vertex_handle v, Face_handle f) const;}
-{Starts at the the first edge of \ccc{f} incident to 
+{Starts at the first edge of \ccc{f} incident to 
 \ccc{v}, in counterclockwise order around \ccc{v}.
 \ccPrecond Face \ccc{f} is incident to vertex \ccc{v}.}
 \ccGlue

Viewer_3/doc_tex/Viewer_3/viewer.tex

@@ -162,7 +162,7 @@ on the left of the browser.
 \subsection{The user panel}
 
 Users can define their own buttons and actions in a special panel
-activated by the the ``User Panel'' button. By default, there is nothing 
+activated by the ``User Panel'' button. By default, there is nothing 
 but a ``Close'' button in this panel.
 
 \section{The drawable objects}

Visibility_complex/doc_tex/Visibility_complex/main.tex

@@ -471,7 +471,7 @@ The shortest path is computed as follows:
     \item Perform a Dijsktra algorithm to find the shortest path between $p$ and
     $q$.
 \end{enumerate}
-The value type of the output iterator is the vertex type of the the visibility
+The value type of the output iterator is the vertex type of the visibility
 complex computed in the second step above. In other words we only give access to
 the bitangent segments of the shortest path (recall that the vertices of the
 visibility complex correspond to free bitangents).