Remove whitespace

Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt

@@ -165,7 +165,7 @@ concepts `Field` and `RealEmbeddable`, while
 `RingNumberType` combines `IntegralDomainWithoutDivision` and
 `RealEmbeddable`. Algebraically, the real number types do not form
 distinct structures and are therefore not listed in the concept
-hierarchy of Figure  \ref figConceptHierarchyOfAlgebraicStructures .
+hierarchy of Figure  \ref figConceptHierarchyOfAlgebraicStructures.
 
 # Interoperability #
 

Alpha_shapes_3/doc/Alpha_shapes_3/Alpha_shapes_3.txt

@@ -146,7 +146,7 @@ such that the alpha shape satisfies the following two properties
 (i) all data points are either on the boundary or in the interior 
 of the regularized version of the alpha shape (no singular faces). 
 
-(ii) The number of components is equal or less than a given number .<BR>
+(ii) The number of components is equal or less than a given number.
 
 The current implementation is static, that is after its construction
 points cannot be inserted or removed.

Apollonius_graph_2/doc/Apollonius_graph_2/Apollonius_graph_2.txt

@@ -10,9 +10,9 @@ namespace CGAL {
 
 This chapter describes the two-dimensional Apollonius graph
 of \cgal. We start with a few definitions in 
-Section \ref secapollonius2definitions .
+Section \ref secapollonius2definitions.
 The software design of the 2D Apollonius graph package is described 
-in Section \ref secapollonius2design .
+in Section \ref secapollonius2design.
 In Section \ref secapollonius2traits we discuss the geometric
 traits of the 2D Apollonius graph package and in Section
 \ref secapollonius2hierarchy the Apollonius graph hierarchy, a data

Bounding_volumes/doc/Bounding_volumes/PackageDescription.txt

@@ -18,7 +18,7 @@
 The optimization code uses infix `OPTIMISATION` in the assertions,
 e.g. defining the compiler flag
 `CGAL_OPTIMISATION_NO_PRECONDITIONS` switches precondition
-checking off, cf. Section  \ref secchecks .
+checking off, cf. Section  \ref secchecks.
 
 */
 

Box_intersection_d/doc/Box_intersection_d/Box_intersection_d.txt

@@ -289,7 +289,7 @@ otherwise the box might shrink and one might miss intersections.
 \section secboxintersparams Example Using the topology and the cutoff Parameters 
 
 Boxes can be interpreted by the box intersection algorithm as closed
-or as half-open boxes, see also Section \ref secboxintersdef . Closed
+or as half-open boxes, see also Section \ref secboxintersdef. Closed
 boxes support zero-width boxes and they can intersect at their
 boundaries, while half-open boxes always have a positive volume and
 they only intersect iff their interiors overlap. The choice between
@@ -304,7 +304,7 @@ parameter and its two values:
 The example program uses a two-dimensional box with `int`
 coordinates and `id`-numbers that are by default explicitly
 stored. We create the same boxes as in the minimal example in
-Section \ref secboxintersectminimal . We create a \f$ 3 \times 3\f$ grid
+Section \ref secboxintersectminimal. We create a \f$ 3 \times 3\f$ grid
 of `boxes`, and two boxes for the `query` sequence, namely the
 box at the center and the box from the upper-right corner of the grid.
 
@@ -379,7 +379,7 @@ box intersection is reported to an empty dummy callback.
 For each box set, a near-optimal cutoff parameter is determined using
 an adaptive approximation. The runtime required for streaming is
 compared against usual scanning. Results on a Xeon 2.4GHz with 4GB
-main memory can be seen in Figure \ref fig_benchmark . For a small
+main memory can be seen in Figure \ref fig_benchmark. For a small
 number of boxes, pure scanning is still faster than streaming with
 optimal cutoff, which would just delegate the box sets to the scanning
 algorithm. As there are more and more boxes, the overhead becomes less

Convex_decomposition_3/doc/Convex_decomposition_3/Convex_decomposition_3.txt

@@ -66,10 +66,10 @@ polyhedron and therefore selected, but in case of the open unit cube
 which allows the correct representation of Nef polyhedra, which are
 closed under Boolean and topological operations. Details can be found
 in the chapter on 3D Boolean operations on Nef
-polyhedra \ref chapterNef3 .
+polyhedra \ref chapterNef3.
 
 Usually, an instance of `Nef_polyhedron_3` does not contain any
-redundant items. However, the function `convex_decomposition_3`
+redundant items. However, the function `::convex_decomposition_3`
 subdivides selected volumes of a given `Nef_polyhedron_3` by
 selected facets. These additional facets are therefore redundant,
 i.e., their insertion alters the representation of the polyhedron, but

Convex_hull_3/doc/Convex_hull_3/CGAL/convex_hull_3.h

@@ -10,7 +10,7 @@ and the plane equations of each face are not computed.
 \pre There are at least four points in the range 
 [`first`, `last`) not all of which are collinear.
 
-The function `convex_hull_3` computes the convex hull of a given set of 
+The function `::convex_hull_3` computes the convex hull of a given set of 
 three-dimensional points 
 Two versions of this function 
 are available. The first can be used when it is known that the result 
@@ -44,7 +44,7 @@ and for the second, it is required that
 For both versions, if the kernel `R` of the points determined by `InputIterator::value_type` 
 is a kernel with exact predicates but inexact constructions 
 (in practice we check `R::Has_filtered_predicates_tag` is `Tag_true` and `R::FT` is a floating point type), 
-then the default traits class of `convex_hull_3` is `Convex_hull_traits_3<R>`, and `R` otherwise. 
+then the default traits class of `::convex_hull_3` is `Convex_hull_traits_3<R>`, and `R` otherwise. 
 
 \sa `CGAL::convex_hull_incremental_3` 
 \sa `CGAL::ch_eddy` 
@@ -62,7 +62,7 @@ Example
 The following program computes the convex hull of a set of 250 random 
 points chosen from a sphere of radius 100. It then determines if the resulting 
 hull is a segment or a polyhedron. Notice that the traits class is not 
-necessary in the call to `convex_hull_3` but is used in the definition 
+necessary in the call to `::convex_hull_3` but is used in the definition 
 of `Polyhedron_3`. 
 
 \cgalexample{Convex_hull_3/quickhull_3.cpp} 

Convex_hull_d/doc/Convex_hull_d/CGAL/Convex_hull_d.h

@@ -192,7 +192,7 @@ Convex_hull_d<R>(int d, R Kernel = R());
 /// @{
 
 /*!
-returns the dimension of ambient space
+returns the dimension of ambient space.
 */
 int dimension() ;
 

Convex_hull_d/doc/Convex_hull_d/Convex_hull_d.txt

@@ -42,7 +42,7 @@ The convex hull class is parameterized by a traits class that provides
 model <I>e.g.</I>, `Homogeneous<RT>` or `Cartesian<FT>` for use 
 with `Convex_hull_d`, where the dimension is fixed to three.
 The validity of the computed convex hull can be checked using the
-member function `is_valid`, which implements the algorithm
+member function `::is_valid`, which implements the algorithm
 of Mehlhorn <I>et al.</I>\cite mnssssu-cgpvg-96 to determine if
 the vertices of a given polytope constitute a strongly convex point
 set or not.

Generator/doc/Generator/Generator.txt

@@ -18,9 +18,9 @@ generators and second deterministic point generators. Most random
 point generators and a few deterministic point generators are provided
 as input iterators. The input iterators model an infinite sequence of
 points. The function `CGAL::cpp0x::copy_n()` can be used to copy a
-finite sequence; see Section \ref sectionCopyN . The iterator adaptor
+finite sequence; see Section \ref sectionCopyN. The iterator adaptor
 `Counting_iterator` can be used to create finite iterator
-ranges; see Section \ref sectionCountingIterator .
+ranges; see Section \ref sectionCountingIterator.
 Other generators are provided as functions that write to output
 iterators. Further functions add degeneracies or random perturbations.
 
@@ -40,7 +40,7 @@ distributed in a sphere (`Random_points_in_sphere_3`)
 or cube (`Random_points_in_cube_3`) or on the boundary of a sphere
 (`Random_points_on_sphere_3`).
 For generating 3D grid points, we provide the function 
-`points_on_cube_grid_3` that writes to
+`::points_on_cube_grid_3` that writes to
 an output iterator.
 
 For higher dimensions, input iterators are provided for random points uniformly 

Jet_fitting_3/doc/Jet_fitting_3/Jet_fitting_3.txt

@@ -224,7 +224,7 @@ In addition, the class `Monge_via_jet_fitting` stores
 
 This concept provides the types for the input sample points, together
 with \f$ 3d\f$ vectors and a number type. It is used as template for the
-class `Monge_via_jet_fitting<DataKernel, LocalKernel, SvdTraits>` . Typically, one can use
+class `Monge_via_jet_fitting<DataKernel, LocalKernel, SvdTraits>`. Typically, one can use
 `CGAL::Cartesian<double>`.
 
 ## Template parameter <TT>LocalKernel</TT> ##

Matrix_search/doc/Matrix_search/PkgDescription.txt

@@ -32,7 +32,7 @@
 The optimization code uses infix `OPTIMISATION` in the assertions,
 e.g. defining the compiler flag
 `CGAL_OPTIMISATION_NO_PRECONDITIONS` switches precondition
-checking off, cf. Section \ref secchecks .
+checking off, cf. Section \ref secchecks.
 
 # Classified References Pages #
 

Mesh_3/doc/Mesh_3/Mesh_3.txt

@@ -316,12 +316,12 @@ parameters::internal::Perturb_options perturb = parameters::perturb(),
 parameters::internal::Exude_options exude = parameters::exude()); 
 \endcode
 
-The function `make_mesh_3` generates from scratch a mesh
+The function `::make_mesh_3` generates from scratch a mesh
 of the input domain, while
-the function `refine_mesh_3` refines
+the function `::refine_mesh_3` refines
 an existing mesh of the input domain. Note that as the protection
 of 0- and 1-dimensional features does not rely on Delaunay 
-refinement, the function `refine_mesh_3` has no parameter
+refinement, the function `r::efine_mesh_3` has no parameter
 to preserve features.
 
 ## The data structure ##
@@ -499,8 +499,8 @@ appropriate values of these types:
 These parameters are optional and can be passed in any order.
 If one parameter is not passed the default value is used. By default,
 only the perturber and the exuder are activated.
-Note that whatever may be the optimization processes activated by `make_mesh_3`
+Note that whatever may be the optimization processes activated by `::make_mesh_3`
-or `refine_mesh_3`,
+or `::refine_mesh_3`,
 they are always launched in the order that is a suborder 
 of the following:
 `odt smoother`, `Lloyd smoother`, `perturber` and 
@@ -590,7 +590,7 @@ where each subdomain corresponds to a specific tissue.
 In the following example, the image is read from the file
 `liner.inr.gz` which is encoded in the format of the library Inrimage
 `http://inrimage.gforge.inria.fr/`.
-The resulting mesh is shown in Figure \ref figureliver_3d_image_mesh .
+The resulting mesh is shown in Figure \ref figureliver_3d_image_mesh.
 
 \cgalexample{Mesh_3/mesh_3D_image.cpp}
 
@@ -657,7 +657,7 @@ domain. We add by hand the intersection of the spheres as a sharp feature.
 \anchor Mesh_3_subsection_examples_optimization
 
 In the previous examples, the mesh generation is launched through a call
-`make_mesh_3(domain,criteria)` with a minimal number of parameters. In such cases, 
+`::make_mesh_3(domain,criteria)` with a minimal number of parameters. In such cases, 
 the default optimization strategy is applied: after the Delaunay refinement process
 two optimization steps are performed, a perturbation and a sliver exudation.
 The following examples show how to disable default optimization steps 
@@ -671,10 +671,10 @@ a perturbation phase which is launched with no time bound
 and an objective of 10 degrees for the minimum dihedral angle
 of the mesh.
 The example shows two ways of achieving the same result. The first way
-issues a single call to `make_mesh_3` with the required optimization 
+issues a single call to `::make_mesh_3` with the required optimization 
-process activated and tuned. In the second way, `make_mesh_3` is first called
+process activated and tuned. In the second way, `::make_mesh_3` is first called
 without any optimization process and the resulting mesh is next optimized
-through a call to `perturb_mesh_3` with tuned parameters.
+through a call to `::perturb_mesh_3` with tuned parameters.
 
 \cgalexample{Mesh_3/mesh_optimization_example.cpp}
 

Minkowski_sum_2/doc/Minkowski_sum_2/Minkowski_sum_2.txt

@@ -125,7 +125,7 @@ contains `S.number_of_holes()` holes in its interior).
 </center>
 
 The following example program constructs the Minkowski sum of two triangles,
-as depicted in Figure \ref mink_figsum_tri . The result in this case is
+as depicted in Figure \ref mink_figsum_tri. The result in this case is
 a convex hexagon. This program, as other example programs in this chapter,
 includes the auxiliary header file `ms_rational_nt.h` which defines
 `Number_type` as either `Gmpq` or `Quotient<MP_Float>`,

Miscellany/doc/Miscellany/Miscellany.txt

@@ -16,7 +16,7 @@ the class `CGAL::Real\_timer` is the version for the real time.
 Instantiations of both classes are objects with a state. The state is
 either <I>running/</I> or it is <I>stopped</I>. The state of an object
 `t` is controlled
-with `t.start()` and `t.stop()` . The timer counts the
+with `t.start()` and `t.stop()`. The timer counts the
 time elapsed since its creation or last reset. It counts only the time
 where it is in the running state. The time information is given in seconds.
 The timer counts also the number of intervals it was running, i.e. it 
@@ -80,7 +80,7 @@ of the polyhedron.
 
 The solution provided here is inspired by the strategy
 pattern \cite cgal:ghjv-dpero-95, though it serves a different intent, see
-Figure \ref figureModifierDesign . The abstract base class
+Figure \ref figureModifierDesign. The abstract base class
 `Modifier_base<R>` declares a pure virtual member function
 `operator()` that accepts a single reference parameter of the
 internal representation type. The member function `delegate()` of

STL_Extension/doc/STL_Extension/STL_Extension.txt

@@ -15,7 +15,7 @@ uses three-valued comparisons and offers additional functionality,
 generic algorithms, iterators, functor adaptors for binding and swapping
 arguments and for composition, functors for projection and creation and
 adaptor classes around iterators and circulators. See also circulators in
-Chapter \ref chapterCirculators . A class storing polymorphic objects
+Chapter \ref chapterCirculators. A class storing polymorphic objects
 is also provided, as well as a class to manage the uncertainty of some values.
 Finally, tags and policy classes to specify complexity trade-offs of data-structures,
 and a class which helps specifying that the default types in template

Straight_skeleton_2/doc/Straight_skeleton_2/Straight_skeleton_2.txt

@@ -398,7 +398,7 @@ Therefore, the `Exact_predicates_inexact_constructions_kernel` should be used.
 
 \cgalexample{Straight_skeleton_2/Low_level_API.cpp}
 
-## Exterior Skeletons and Exterior Offset contours ##
+## Exterior Skeletons and Exterior Offset Contours ##
 
 This \cgal package can only construct the straight skeleton and offset contours in the <I>interior</I> of a polygon with holes. However, constructing exterior skeletons and exterior offsets is possible: