songsenand
/
cgal
mirror of https://github.com/CGAL/cgal
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

backporting documentation changes of master@9fcc5b57 into doxy-port-pmoeller 

Conflicts:
	Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_linear_traits_2.h
	Installation/doc_tex/Installation/usage.tex
	Kernel_23/doc/Kernel_23/CGAL/Projection_traits_xy_3.h
	Mesh_2/doc/Mesh_2/Concepts/ConformingDelaunayTriangulationTraits_2.h
	Spatial_searching/doc/Spatial_searching/CGAL/Incremental_neighbor_search.h
	Spatial_searching/doc/Spatial_searching/CGAL/K_neighbor_search.h
	Spatial_searching/doc/Spatial_searching/CGAL/Orthogonal_incremental_neighbor_search.h
This commit is contained in:
Sébastien Loriot 2012-11-23 22:54:31 +01:00
parent bc7519a413 efd13bab22
commit 920eb63882
363 changed files with 2149 additions and 1360 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
AABB_tree/doc_tex/AABB_tree/performances.tex
View File

@ -119,7 +119,7 @@ The experiments described above are neither exhaustive nor conclusive as we have
\item Primitives: Although the number of input primitives plays an obvious role in the final performance, their distribution in space is at least equally important in order to obtain a well-balanced AABB tree. Ideally the primitives must be evenly distributed in space and the long primitives spanning the bounding box of the tree root node must be avoided as much as possible. It is often beneficial to split these long primitives into smaller ones before constructing the tree, e.g., through recursive longest edge bisection for triangle surface meshes.
\item Function: The type of function queried plays another important role. Obviously the "exhaustive" functions, which list all intersections, are slower than the ones stopping after the first intersection. Within each of these functions the ones which call only intersection tests (do\_intersect(), number\_of\_intersected\_primitives(), any\_intersected\_primitive(), all\_intersected\_primitives()) are faster than the ones which explicitly construct the intersections (any\_intersection() and all\_intersections()).
\item Function: The type of function queried plays another important role. Obviously the ``exhaustive'' functions, which list all intersections, are slower than the ones stopping after the first intersection. Within each of these functions the ones which call only intersection tests (do\_intersect(), number\_of\_intersected\_primitives(), any\_intersected\_primitive(), all\_intersected\_primitives()) are faster than the ones which explicitly construct the intersections (any\_intersection() and all\_intersections()).
\item Query: The type of query (e.g., line, ray, segment or plane used above) plays another role, strongly correlated with the type of function (exhaustive or not, and whether or not it constructs the intersections). When all intersection constructions are needed, the final execution times highly depend on the complexity of the general intersection object. For example a plane query generally intersects a surface triangle mesh into many segments while a segment query generally intersects a surface triangle mesh into few points. Finally, the location of the query in space also plays an obvious role in the performances, especially for the distance queries. Assuming the internal KD-tree constructed through the function \ccc{tree.accelerate_distance_queries()}, it is preferable to specify a query point already close to the surface triangle mesh so that the query traverses only few AABBs of the tree. For a large number of primitive data (greater than 2M faces in our experiments) however we noticed that it is not necessary (and sometimes even slower) to use all reference points when constructing the KD-tree. In these cases we recommend to specify trough the function \ccc{tree.accelerate_distance_queries(begin,end)} fewer reference points (typically not more than 100K) evenly distributed over the input primitives.

2
Algebraic_foundations/doc/Algebraic_foundations/Concepts/Field.h
View File

@ -15,7 +15,7 @@ Moreover, `CGAL::Algebraic_structure_traits< Field >` is a model of
- `CGAL::Algebraic_structure_traits< Field >::Algebraic_type` derived from `Field_tag`
- `CGAL::Algebraic_structure_traits< FieldWithSqrt >::Inverse`
- `CGAL::Algebraic_structure_traits< FieldWithSqrt >::Inverse` which is a model of `AlgebraicStructureTraits::Inverse`
\cgalRefines `IntegralDomain`

2
Algebraic_foundations/doc/Algebraic_foundations/Concepts/FieldWithKthRoot.h
View File

@ -9,7 +9,7 @@ Moreover, `CGAL::Algebraic_structure_traits< FieldWithKthRoot >` is a model of `
- `CGAL::Algebraic_structure_traits< FieldWithKthRoot >::Algebraic_type` derived from `Field_with_kth_root_tag`
- `CGAL::Algebraic_structure_traits< FieldWithKthRoot >::Kth_root`
- `CGAL::Algebraic_structure_traits< FieldWithKthRoot >::Kth_root` which is a model of `AlgebraicStructureTraits::KthRoot`
\cgalRefines `FieldWithSqrt`

16
Algebraic_foundations/doc/Algebraic_foundations/Concepts/RealEmbeddable.h
View File

@ -16,21 +16,21 @@ with:
and functors :
- `CGAL::Real_embeddable_traits< RealEmbeddable >::Is_zero`
- `CGAL::Real_embeddable_traits< RealEmbeddable >::Is_zero` which is a model of `AlgebraicStructureTraits::IsZero`
- `CGAL::Real_embeddable_traits< RealEmbeddable >::Abs`
- `CGAL::Real_embeddable_traits< RealEmbeddable >::Abs` which is a model of `AlgebraicStructureTraits::Abs`
- `CGAL::Real_embeddable_traits< RealEmbeddable >::Sgn`
- `CGAL::Real_embeddable_traits< RealEmbeddable >::Sgn` which is a model of `AlgebraicStructureTraits::Sgn`
- `CGAL::Real_embeddable_traits< RealEmbeddable >::Is_positive`
- `CGAL::Real_embeddable_traits< RealEmbeddable >::Is_positive` which is a model of `AlgebraicStructureTraits::IsPositive`
- `CGAL::Real_embeddable_traits< RealEmbeddable >::Is_negative`
- `CGAL::Real_embeddable_traits< RealEmbeddable >::Is_negative` which is a model of `AlgebraicStructureTraits::IsNegative`
- `CGAL::Real_embeddable_traits< RealEmbeddable >::Compare`
- `CGAL::Real_embeddable_traits< RealEmbeddable >::Compare` which is a model of `AlgebraicStructureTraits::Compare`
- `CGAL::Real_embeddable_traits< RealEmbeddable >::To_double`
- `CGAL::Real_embeddable_traits< RealEmbeddable >::To_double` which is a model of `AlgebraicStructureTraits::ToDouble`
- `CGAL::Real_embeddable_traits< RealEmbeddable >::To_interval`
- `CGAL::Real_embeddable_traits< RealEmbeddable >::To_interval` which is a model of `AlgebraicStructureTraits::ToInterval`
Remark:

2
Algebraic_foundations/doc_tex/Algebraic_foundations_ref/AlgebraicStructureTraits_Inverse.tex
View File

@ -20,7 +20,7 @@ respect to multiplication of a \ccc{Field}.
\ccCreationVariable{inverse}
\ccMethod{result_type operator()(argument_type x) const;}
{ returns the inverse element of $x$ with respect to multiplication.
\ccPrecond{$x \neq 0$.}
\ccPrecond $x \neq 0$
}
%\ccHasModels

2
Algebraic_foundations/doc_tex/Algebraic_foundations_ref/AlgebraicStructureTraits_IsSquare.tex
View File

@ -35,7 +35,7 @@ $y$ is uniquely defined up to multiplication by units. \\
\ccMethod{result_type operator()(first_argument_type x,
second_argument_type y);}
{ returns {\tt true} in case $x$ is a square, i.e. $x = y*y$.
\ccPostcond{$unit\_part(y) == 1$. }
\ccPostcond $unit\_part(y) == 1$.
}
\ccMethod{result_type operator()(first_argument_type x);}
{ returns {\tt true} in case $x$ is a square.

8
Algebraic_foundations/doc_tex/Algebraic_foundations_ref/AlgebraicStructureTraits_RootOf.tex
View File

@ -23,8 +23,8 @@ result_type operator() (int k, InputIterator begin, InputIterator end);}
{returns the k-th real root of the univariate polynomial,
which is defined by the iterator range,
where begin refers to the constant term.
\ccPrecond{The polynomial is square-free.}
\ccPrecond{The value type of the InputIterator is \ccc{AlgebraicStructureTraits::Type}.} }
\ccPrecond The polynomial is square-free.
\ccPrecond The value type of the InputIterator is \ccc{AlgebraicStructureTraits::Type}\\ }
%\begin{ccAdvanced}
%\ccMethod{
@ -36,8 +36,8 @@ result_type operator() (int k, InputIterator begin, InputIterator end);}
% {returns the only real root within the interval [lower,upper]
% of the univariate polynomial, which is defined by the iterator
% range, where begin refers to the constant term.
% \ccPrecond{The polynomial is square-free.}
% \ccPrecond{The value type of the InputIterator is \ccc{AlgebraicStructureTraits::Type}.}
% \ccPrecond The polynomial is square-free.
% \ccPrecond The value type of the InputIterator is \ccc{AlgebraicStructureTraits::Type}\\
%}
%\end{ccAdvanced}

2
Algebraic_foundations/doc_tex/Algebraic_foundations_ref/inverse.tex
View File

@ -10,7 +10,7 @@ is a model of the \ccc{Field} concept.
\ccInclude{CGAL/number_utils.h}
\ccFunction{template <class NT> NT inverse(const NT& x);}
{\ccPrecond{$x \neq 0$.}}
{\ccPrecond $x \neq 0$}

2
Algebraic_foundations/doc_tex/Algebraic_foundations_ref/root_of.tex
View File

@ -16,7 +16,7 @@ of the iterator range is a model of the \ccc{FieldWithRootOf} concept.
returns the k-th real root of the univariate polynomial,
which is defined by the iterator range,
where begin refers to the constant term.
\ccPrecond{The polynomial is square-free.}
\ccPrecond The polynomial is square-free.
}

4
Algebraic_kernel_for_circles/doc_tex/Algebraic_kernel_for_circles_ref/intro.tex
View File

@ -3,10 +3,10 @@
\textbf{Submission - Monique - with Sylvain's help...}
\begin{ccAdvanced}
As in Curved-kernel, I use the "Advanced" environment in this
As in Curved-kernel, I use the ``Advanced'' environment in this
document to distinguish between my current submission to the \cgal\
editorial board and plans for the future, related to ACS. The
"Advanced" parts will disappear if/when this is released.
``Advanced'' parts will disappear if/when this is released.
\end{ccAdvanced}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

8
Alpha_shapes_2/doc_tex/Alpha_shapes_2/alpha2.tex
View File

@ -11,7 +11,7 @@
Assume we are given a set $S$ of points in 2D or 3D and we'd like to
have something like "the shape formed by these points." This is
have something like ``the shape formed by these points.'' This is
quite a vague notion and there are probably many possible
interpretations, the $\alpha$-shape being one of them. Alpha shapes
can be used for shape reconstruction from a dense unorganized set of
@ -21,13 +21,13 @@ which is a linear approximation of the original shape \cite{bb-srmua-97t}.
As mentioned in Edelsbrunner's and M\"ucke's paper \cite{em-tdas-94},
one can intuitively think of an $\alpha$-shape as the
following. Imagine a huge mass of ice-cream making up the space $\R^3$
and containing the points as "hard" chocolate pieces. Using one of
and containing the points as ``hard'' chocolate pieces. Using one of
these sphere-formed ice-cream spoons we carve out all parts of the
ice-cream block we can reach without bumping into chocolate pieces,
thereby even carving out holes in the inside (e.g. parts not reachable
by simply moving the spoon from the outside). We will eventually end
up with a (not necessarily convex) object bounded by caps, arcs and
points. If we now straighten all "round" faces to triangles and line
points. If we now straighten all ``round'' faces to triangles and line
segments, we have an intuitive description of what is called the
$\alpha$-shape of $S$. Here's an example for this process in 2D (where
our ice-cream spoon is simply a circle):
@ -42,7 +42,7 @@ it's way too large. So we will never spoon up ice-cream lying in the
inside of the convex hull of $S$, and hence the $\alpha$-shape for
$\alpha \rightarrow \infty$ is the convex hull of $S$.\footnote{ice cream, ice cream!!!
The wording of this introductory paragraphs is borrowed from Kaspar Fischer's
" Introduction to Alpha Shapes" which can be found at
`` Introduction to Alpha Shapes'' which can be found at
http://people.inf.ethz.ch/fischerk/pubs/as.pdf.
The picture has been taken from Walter Luh's homepage at
http://www.stanford.edu/\~wluh/cs448b/alphashapes.html.}

2
Alpha_shapes_2/doc_tex/Alpha_shapes_2_ref/AlphaShapeTraits_2.tex
View File

@ -74,7 +74,7 @@ The type must provide a copy constructor, assignment, comparison
operators, negation, multiplication, division and allow the
declaration and initialization with a small integer constant
(cf. requirements for number types).
\ccPrecond{An obvious choice would be coordinate type of the point class.}}
\ccPrecond An obvious choice would be coordinate type of the point class.}
\ccCreation

24
Alpha_shapes_2/doc_tex/Alpha_shapes_2_ref/Alpha_shape_2.tex
View File

@ -101,15 +101,15 @@ For example \ccc{Dt::Point} is a Point class.
\ccNestedType{Alpha_iterator}{A bidirectional and non-mutable iterator that allow to traverse
the increasing sequence of different $\alpha$-values.
\ccPrecond{Its \ccc{value_type} is \ccc{FT}.}}
\ccPrecond Its \ccc{value_type} is \ccc{FT}}
\ccNestedType{Alpha_shape_vertices_iterator}{A bidirectional and non-mutable iterator that allow to traverse
the vertices which belongs to the $\alpha$-shape for the current $\alpha$.
\ccPrecond{Its \ccc{value_type} is \ccc{Dt::Vertex_handle}.}}
\ccPrecond Its \ccc{value_type} is \ccc{Dt::Vertex_handle}}
\ccNestedType{Alpha_shape_edges_iterator}{A bidirectional and non-mutable iterator that allow to traverse
the edges which belongs to the $\alpha$-shape for the current $\alpha$.
\ccPrecond{Its \ccc{value_type} is \ccc{Dt::Edge}.}}
\ccPrecond Its \ccc{value_type} is \ccc{Dt::Edge}.}
\ccEnum{enum Classification_type {EXTERIOR, SINGULAR, REGULAR, INTERIOR};}
{Distinguishes the different cases for classifying a $k$-dimensional face
@ -134,7 +134,7 @@ and their vertices.}
Mode m = GENERAL);}
{Introduces an empty $\alpha$-shape \ccVar\ for a positive $\alpha$-value
\ccc{alpha}.
\ccPrecond{\ccc{alpha}~$\geq~0$.}}
\ccPrecond \ccc{alpha}~$\geq~0$.}
\ccConstructor{Alpha_shape_2(
Dt& dt,
@ -143,7 +143,7 @@ and their vertices.}
{Builds an alpha shape of mode \ccc{m} from the triangulation \ccc{dt}
for a positive $\alpha$-value \ccc{alpha}.
Be careful that this operation destroys the triangulation.
\ccPrecond{\ccc{alpha}~$\geq~0$.}}
\ccPrecond \ccc{alpha}~$\geq~0$.}
\ccConstructor{template < class InputIterator >
Alpha_shape_2(
@ -155,9 +155,9 @@ Be careful that this operation destroys the triangulation.
$\left[\right.$\ccc{first}, \ccc{last}$\left.\right)$ and
introduces an $\alpha$-shape \ccVar\ for a positive $\alpha$-value
\ccc{alpha}.
\ccPrecond{The \ccc{value_type} of \ccc{first} and
\ccPrecond The \ccc{value_type} of \ccc{first} and
\ccc{last} is \ccc{Point}.\\
\ccc{alpha} $\geq 0$.}}
\ccc{alpha} $\geq 0$.}
\ccOperations
@ -170,8 +170,8 @@ $\left[\right.$\ccc{first}, \ccc{last}$\left.\right)$. Returns the number of
inserted points. \\
If the function is applied to an non-empty family of alpha-shape, it is cleared
before initialization.
\ccPrecond{The \ccc{value_type} of \ccc{first} and
\ccc{last} is \ccc{Point}.}}
\ccPrecond The \ccc{value_type} of \ccc{first} and
\ccc{last} is \ccc{Point}.}
\ccMethod{void
clear();}
@ -181,7 +181,7 @@ before initialization.
set_alpha(const FT& alpha);}
{Sets the $\alpha$-value to \ccc{alpha}.
Returns the previous $\alpha$-value.
\ccPrecond{\ccc{alpha} $\geq 0$.}}
\ccPrecond \ccc{alpha} $\geq 0$.}
\ccMethod{const FT&
get_alpha(void) const;}
@ -189,7 +189,7 @@ before initialization.
\ccMethod{const FT& get_nth_alpha(size_type n) const;}
{Returns the $n$-th alpha-value, sorted in an increasing order.
\ccPrecond{\ccc{n} $<$ number of alphas.}}
\ccPrecond \ccc{n} $<$ number of alphas.}
\ccMethod{size_type number_of_alphas() const;}
{Returns the number of different alpha-values.}
@ -323,7 +323,7 @@ is an internal format.
\ccFunction{ostream& operator<<(ostream& os,
const Alpha_shape_2<Dt>& A);}
{Inserts the alpha shape \ccVar\ for the current $\alpha$-value into the stream \ccc{os}.
\ccPrecond{The insert operator must be defined for \ccc{Point}.}}
\ccPrecond The insert operator must be defined for \ccc{Point}.}
\ccImplementation

10
Alpha_shapes_3/doc_tex/Alpha_shapes_3/alpha3.tex
View File

@ -10,7 +10,7 @@
\end{ccHtmlOnly}
Assume we are given a set $S$ of points in 2D or 3D and we'd like to
have something like "the shape formed by these points." This is
have something like ``the shape formed by these points.'' This is
quite a vague notion and there are probably many possible
interpretations, the alpha shape being one of them. Alpha shapes
can be used for shape reconstruction from a dense unorganized set of
@ -20,13 +20,13 @@ which is a linear approximation of the original shape \cite{bb-srmua-97t}.
As mentioned in Edelsbrunner's and M\"ucke's paper \cite{em-tdas-94},
one can intuitively think of an alpha shape as the
following. Imagine a huge mass of ice-cream making up the space $\R^3$
and containing the points as "hard" chocolate pieces. Using one of
and containing the points as ``hard'' chocolate pieces. Using one of
those sphere-formed ice-cream spoons we carve out all parts of the
ice-cream block we can reach without bumping into chocolate pieces,
thereby even carving out holes in the inside (e.g. parts not reachable
by simply moving the spoon from the outside). We will eventually end
up with a (not necessarily convex) object bounded by caps, arcs and
points. If we now straighten all "round" faces to triangles and line
points. If we now straighten all ``round'' faces to triangles and line
segments, we have an intuitive description of what is called the
alpha shape of $S$. Here's an example for this process in 2D (where
our ice-cream spoon is simply a circle):
@ -43,7 +43,7 @@ it's way too large. So we will never spoon up ice-cream lying in the
inside of the convex hull of $S$, and hence the alpha shape for
$\alpha \rightarrow \infty$ is the convex hull of $S$.\footnote{ice cream, ice cream!!!
The wording of this introductory paragraphs is borrowed from Kaspar Fischer's
" Introduction to Alpha Shapes" which can be found at
`` Introduction to Alpha Shapes'' which can be found at
http://people.inf.ethz.ch/fischerk/pubs/as.pdf.
The picture has been taken from Walter Luh's homepage at
http://www.stanford.edu/\~wluh/cs448b/alphashapes.html.}
@ -73,7 +73,7 @@ of the Delaunay triangulation.
For a given value of $\alpha$, the alpha complex includes
all the simplices in the Delaunay triangulation which have
an empty circumscribing sphere with squared radius equal or smaller than $\alpha$.
Here "empty" means that the open sphere
Here ``empty'' means that the open sphere
do not include any points of $S$.
The alpha shape is then simply the domain covered by the simplices
of the alpha complex (see \cite{em-tdas-94}).

22
Alpha_shapes_3/doc_tex/Alpha_shapes_3_ref/Alpha_shape_3.tex
View File

@ -104,15 +104,15 @@ For convenience, classical comparison operators are provided for the type \ccc{F
\ccNestedType{Alpha_iterator}{A bidirectional and non-mutable iterator that allow to traverse
the increasing sequence of different alpha values.
\ccPrecond{Its \ccc{value_type} is \ccc{FT}.}}
\ccPrecond Its \ccc{value_type} is \ccc{FT}}
%\ccNestedType{Alpha_shape_vertices_iterator}{A bidirectional and non-mutable iterator that allow to traverse
%the vertices which belongs to the alpha shape for a fixed $\alpha$.
%\ccPrecond{Its \ccc{value_type} is \ccc{Dt::Vertex_handle}}}
%\ccPrecond Its \ccc{value_type} is \ccc{Dt::Vertex_handle}}
%\ccNestedType{Alpha_shape_facets_iterator}{A bidirectional and non-mutable iterator that allow to traverse
%the facets which belongs to the alpha shape for a fixed $\alpha$.
%\ccPrecond{Its \ccc{value_type} is \ccc{Dt::Facet}}}
%\ccPrecond Its \ccc{value_type} is \ccc{Dt::Facet}}
\ccEnum{enum Mode {GENERAL, REGULARIZED};}
@ -171,9 +171,9 @@ Be careful that this operation destroys the triangulation.}
for the points in the range
$\left[\right.$\ccc{first}, \ccc{last}$\left.\right)$ and
set the current alpha value to \ccc{alpha}.
\ccPrecond{The \ccc{value_type} of \ccc{first} and
\ccPrecond The \ccc{value_type} of \ccc{first} and
\ccc{last} is \ccc{Point} (the type point of the underlying
triangulation.)}}
triangulation.)}
\ccModifiers
@ -189,8 +189,8 @@ Returns the number of data points inserted in the underlying
triangulation. \\
If the function is applied to an non-empty alpha shape data structure, it is cleared
before initialization.
\ccPrecond{The \ccc{value_type} of \ccc{first} and
\ccc{last} is \ccc{Point}.}}
\ccPrecond The \ccc{value_type} of \ccc{first} and
\ccc{last} is \ccc{Point}.}
\ccMethod{void
clear();}
@ -200,7 +200,7 @@ before initialization.
set_alpha(const FT& alpha);}
{Sets the $\alpha$-value to \ccc{alpha}.
Returns the previous $\alpha$-value.
\ccPrecond{\ccc{alpha} $\geq 0$.}}
\ccPrecond \ccc{alpha} $\geq 0$.}
\ccMethod{Mode
set_mode(Mode m = REGULARIZED );}
@ -257,7 +257,7 @@ entails a partial re-computation of the data structure.}
\ccMethod{const FT& get_nth_alpha(int n) const;}
{Returns the $n$-th alpha-value, sorted in an increasing order.
\ccPrecond{\ccc{n} < number of alphas.}}
\ccPrecond \ccc{n} < number of alphas.}
\ccMethod{size_type number_of_alphas() const;}
{Returns the number of different alpha-values.}
@ -391,7 +391,7 @@ is an internal format.
\ccFunction{ostream& operator<<(ostream& os,
const Alpha_shape_3<Dt,ExactAlphaComparisonTag>& A);}
{Inserts the alpha shape \ccVar\ for the current alpha value into the stream \ccc{os}.
\ccPrecond{The insert operator must be defined for \ccc{Point}.}}
\ccPrecond The insert operator must be defined for \ccc{Point}.}
\ccInclude{CGAL/IO/Geomview_stream.h}
@ -400,7 +400,7 @@ is an internal format.
\ccFunction{Geomview_stream& operator<<(Geomview_stream& W,
const Alpha_shape_3<Dt,ExactAlphaComparisonTag>& A);}
{Inserts the alpha shape \ccVar\ for the current alpha value into the Geomview stream \ccc{W}.
\ccPrecond{The insert operator must be defined for \ccc{GT::Point} and \ccc{GT::Triangle}.}}
\ccPrecond The insert operator must be defined for \ccc{GT::Point} and \ccc{GT::Triangle}.}
\ccImplementation

4
Alpha_shapes_3/doc_tex/Alpha_shapes_3_ref/Alpha_status.tex
View File

@ -65,13 +65,13 @@ The class \ccRefName\ is parameterized by a number type \ccc{NT}.
\ccGlue
\ccMethod{ NT alpha_min() const;}
{ Returns the \ccc{alpha_min}
\ccPrecond{\ccc{is_Gabriel()} returns false;}}
\ccPrecond \ccc{is_Gabriel()} returns false;}
\ccGlue
\ccMethod{ NT alpha_mid() const;} { Returns the \ccc{alpha_mid};}
\ccGlue
\ccMethod{ NT alpha_max() const; }
{ Returns \ccc{alpha_max}.
\ccPrecond{\ccc{is_on_chull()} returns false.}}
\ccPrecond \ccc{is_on_chull()} returns false.}
\ccSeeAlso
\ccc{AlphaShapeCellBase_3} \\

10
Alpha_shapes_3/doc_tex/Alpha_shapes_3_ref/Fixed_alpha_shape_3.tex
View File

@ -39,11 +39,11 @@ For example \ccc{Dt::Point} is a Point class.
%\ccNestedType{Alpha_shape_vertices_iterator}{A bidirectional and non-mutable iterator that allow to traverse
%the vertices which belongs to the alpha shape for a fixed $\alpha$.
%\ccPrecond{Its \ccc{value_type} is \ccc{Dt::Vertex_handle}}}
%\ccPrecond Its \ccc{value_type} is \ccc{Dt::Vertex_handle}}
%\ccNestedType{Alpha_shape_facets_iterator}{A bidirectional and non-mutable iterator that allow to traverse
%the facets which belongs to the alpha shape for a fixed $\alpha$.
%\ccPrecond{Its \ccc{value_type} is \ccc{Dt::Facet}}}
%\ccPrecond Its \ccc{value_type} is \ccc{Dt::Facet}}
\ccEnum{enum Classification_type {EXTERIOR, SINGULAR, REGULAR, INTERIOR};}
{Enum to classify the simplices of the underlying
@ -80,9 +80,9 @@ Be careful that this operation destroys the triangulation.}
for the points in the range
$\left[\right.$\ccc{first}, \ccc{last}$\left.\right)$ and
set the alpha value to \ccc{alpha}.
\ccRequire{ The \ccc{value_type} of \ccc{first} and
\ccRequire The \ccc{value_type} of \ccc{first} and
\ccc{last} is \ccc{Point} (the type point of the underlying
triangulation.)}}
triangulation.)}
\ccModifiers
@ -173,7 +173,7 @@ is an internal format.
\ccFunction{ostream& operator<<(ostream& os,
const Fixed_alpha_shape_3<Dt>& A);}
{Inserts the alpha shape \ccVar\ into the stream \ccc{os}.
\ccRequire{ The insert operator must be defined for \ccc{GT::Point}.}}
\ccRequire The insert operator must be defined for \ccc{GT::Point}.}

2
Alpha_shapes_3/doc_tex/Alpha_shapes_3_ref/intro.tex
View File

@ -68,7 +68,7 @@ of the Delaunay triangulation.
For a given value of $\alpha$, the alpha complex includes
all the simplices in the Delaunay triangulation which have
an empty circumscribing sphere with squared radius equal or smaller than $\alpha$.
Here "empty" means that the open sphere
Here ``empty'' means that the open sphere
do not include any points of $S$.
The alpha shape is then simply the domain covered by the simplices
of the alpha complex (see \cite{em-tdas-94}).

2
Apollonius_graph_2/doc_tex/Apollonius_graph_2_ref/ApolloniusGraphVertexBase_2.tex
View File

@ -56,7 +56,7 @@ define the type \ccc{Site_2}.}}
\ccNestedType{Hidden_sites_iterator}{An iterator that
iterates over the hidden sites in the hidden sites
container of the vertex.
\ccPrecond{Must be a model of \ccc{Iterator}.}}
\ccPrecond Must be a model of \ccc{Iterator}.}
\ccCreation

6
Apollonius_graph_2/doc_tex/Apollonius_graph_2_ref/Apollonius_graph_2.tex
View File

@ -353,7 +353,7 @@ to \ccc{v}.}
\ccGlue
\ccMethod{Face_circulator incident_faces(Vertex_handle v, Face_handle f);}
{Starts at face \ccc{f}.
\ccPrecond{Face \ccc{f} is incident to vertex \ccc{v}.}}
\ccPrecond Face \ccc{f} is incident to vertex \ccc{v}.}
\ccGlue
\ccMethod{Edge_circulator incident_edges(Vertex_handle v);}
{Starts at an arbitrary edge incident
@ -362,7 +362,7 @@ to \ccc{v}.}
\ccMethod{Edge_circulator incident_edges(Vertex_handle v, Face_handle f);}
{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}.}}
\ccPrecond Face \ccc{f} is incident to vertex \ccc{v}.}
\ccGlue
\ccMethod{Vertex_circulator incident_vertices(Vertex_handle v);}
{Starts at an arbitrary vertex incident
@ -371,7 +371,7 @@ to \ccc{v}.}
\ccMethod{Vertex_circulator incident_vertices(Vertex_handle v, Face_handle f);}
{Starts at the first vertex of \ccc{f} adjacent to \ccc{v}
in counterclockwise order around \ccc{v}.
\ccPrecond{Face \ccc{f} is incident to vertex \ccc{v}.}}
\ccPrecond Face \ccc{f} is incident to vertex \ccc{v}.}

8
Apollonius_graph_2/doc_tex/Apollonius_graph_2_ref/Apollonius_site_2.tex
View File

@ -48,15 +48,15 @@ The I/O operators are defined for \ccc{iostream}.
\ccFunction{std::ostream& operator<<(std::ostream& os,
const Apollonius_site_2<K>& s);}{Inserts the
Apollonius site \ccVar\ into the stream \ccc{os}.
\ccPrecond{The insert operator must be defined for \ccc{Point_2} and
\ccc{Weight}.}}
\ccPrecond The insert operator must be defined for \ccc{Point_2} and
\ccc{Weight}.}
\ccFunction{std::istream& operator>>(std::istream& is,
const Apollonius_site_2<K>& s);}
{Reads an Apollonius site from the stream \ccc{is} and assigns it
to \ccVar.
\ccPrecond{The extract operator must be defined for \ccc{Point_2} and
\ccc{Weight}.}}
\ccPrecond The extract operator must be defined for \ccc{Point_2} and
\ccc{Weight}.}
The information output in the \ccc{iostream} is: the point of the
Apollonius site and its weight.

32
Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt
View File

@ -951,7 +951,7 @@ selected point-location strategy.
\subsection arr_sssecpl_ex An Example
\cgalFigureBegin{arr_figex_8,ex_5.gif}
The arrangement of line segments, as constructed in `point_location.cpp`, `vertical_ray_shooting.cpp`, and `batched_point_location.cpp`. The arrangement vertices are drawn as small discs, while the query points \f$ q_1, \ldots, q_6\f$ are marked with crosses.
The arrangement of line segments, as constructed in `point_location_example.cpp`, `vertical_ray_shooting.cpp`, and `batched_point_location.cpp`. The arrangement vertices are drawn as small discs, while the query points \f$ q_1, \ldots, q_6\f$ are marked with crosses.
\cgalFigureEnd
The following program constructs a simple arrangement of five line
@ -963,7 +963,7 @@ can be found in `point_location_utils.h`).
It then employs the naive and the landmark strategies to issue
several point-location queries on this arrangement:
\cgalExample{Arrangement_on_surface_2/point_location.cpp}
\cgalExample{Arrangement_on_surface_2/point_location_example.cpp}
Note that the program uses the auxiliary
`point_location_query()` function template to nicely print the
@ -1039,7 +1039,7 @@ void vertical_ray_shooting_query
The following program uses the auxiliary function listed above to
perform vertical ray-shooting queries on an arrangement.
The arrangement and the query points are exactly the same as in
`point_location.cpp` (see \cgalFigureRef{arr_figex_5}):
`point_location_example.cpp` (see \cgalFigureRef{arr_figex_5}):
\cgalExample{Arrangement_on_surface_2/vertical_ray_shooting.cpp}
@ -1082,7 +1082,7 @@ additional data structures.
The following program issues a batched point-location query, which
is essentially equivalent to the six separate queries performed in
`point_location.cpp` (see Section \ref arr_ssecpl):
`point_location_example.cpp` (see Section \ref arr_ssecpl):
\cgalExample{Arrangement_on_surface_2/batched_point_location.cpp}
@ -3500,10 +3500,12 @@ For example, when we compute the shortest paths from a given source vertex
\f$ s\f$ to all other vertices we can obtain a map of distances and a map of
predecessors - namely for each \f$ v\f$ vertex we have its distance from \f$ s\f$
and a descriptor of the vertex that precedes \f$ v\f$ in the shortest path from \f$ s\f$.
If the vertex descriptors are simply indices, one can use vectors to
efficiently represent the property maps. As this is not the case with the
arrangement graph, we offer the `Arr_vertex_property_map<Arrangement,Type>`
template allows for an efficient mapping of `Vertex_handle` objects to
If the vertex descriptors are simply indices, boost supplies tools to
easily represent property maps using vectors.
\ccc{Arr_vertex_index_map<Arrangement>} class allows create such
indices, and together with `boost::vector_property_map<Type, IndexMap>`
allows for an efficient mapping of `Vertex_handle` objects to
properties of type `Type`. Note however that unlike the
`Arr_vertex_index_map` class, the vertex property-map class is not
kept synchronized with the number of vertices in the arrangement, so it
@ -3518,7 +3520,7 @@ In the following example we construct an arrangement of 7 line segments,
as shown in \cgalFigureRef{arr_figex_bgl},
then use Dijkstra's shortest-paths algorithm from the <span class="textsc">bgl</span> to compute
the graph distance of all vertices from the leftmost vertex in the
arrangement \f$ v_0\f$. Note the usage of the `Arr_vertex_index_map` and
arrangement \f$ v_0\f$. Note the usage of the `boost::vector_property_map<Type, IndexMap>` and
the `Arr_vertex_property_map` classes. The latter one, instantiated by
the type `double` is used to map vertices to their distances from \f$ v_0\f$.
@ -3547,17 +3549,17 @@ arrangement graph is also a model of the concepts `VertexListGraph`,
Since we use `Face_handle` objects as the vertex descriptors, we define
the `Arr_face_index_map<Arrangement>` class-template, which maintains an
efficient mapping of face handles to indices. We also provide the template
`Arr_face_property_map<Arrangement,Type>` for associating arbitrary
data with the arrangement faces.
efficient mapping of face handles to indices.
Like vertices, `boost::vector_property_map<Type, IndexMap>` can be
used for associating arbitrary data with the arrangement faces.
In the following example we construct the same arrangement as in
example `bgl_primal_adapter.cpp` (see \cgalFigureRef{arr_figex_bgl}),
and perform breadth-first search on the graph faces, starting from the
unbounded face. We extend the \sc{Dcel} faces
with an unsigned integer, marking the discover time of the face and use a
breadth-first-search visitor to obtain these times and update the faces
accordingly:
with an unsigned integer, marking the discover time of the face
using `boost` visitors and a property-map class that directly accesses
the extended data of the faces:
\cgalExample{Arrangement_on_surface_2/bgl_dual_adapter.cpp}

80
Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_face_index_map.h Normal file
View File

@ -0,0 +1,80 @@
namespace CGAL {
/*!
\ingroup PkgArrangement2
`Arr_face_index_map` maintains a mapping of face handles of an
attached arrangement object to indices (of type `unsigned int`).
This class template is a model of the `boost` concept
`ReadablePropertyMap`. A mapping between face handles and indices
enables convenient usage of property-map classes supplied by `boost`.
For example, the property-map class templates
`boost::vector_property_map`, which is based on `std::vector`,
and `boost::iterator_property_map`, which can be used to implement
a property map based on a native \CC array, require the
user to supply a mapping such as `Arr_face_index_map`.
As new faces might be inserted into the attached arrangement, and
existing faces might be removed, the notification mechanism is used
to dynamically maintain the mapping of face handles to indices.
\cgalModels DefaultConstructible
\cgalModels CopyConstructible
\cgalModels Assignable
\cgalModels `boost::ReadablePropertyMap`
\sa `Arr_observer<Arrangement>`
\sa `Arr_vertex_index_map<Arrangement>`
*/
template< typename Arrangement >
class Arr_face_index_map: public Arr_observer<Arrangement> {
public:
/// \name Types
/// @{
/*!
the type of the attached arrangement.
*/
typedef Arrangement Arrangement_2;
typedef boost::readable_property_map_tag;
typedef unsigned int value_type;
typedef unsigned int reference;
typedef Face_handle key_type;
/*!
The face handle type.
*/
typedef typename Arrangement_2::Face_handle Face_handle;
/*!
The type of mapping of faces to indices.
*/
typedef Unique_hash_map<Face_handle, value_type> Index_map;
/// @}
/// \name Creation
/// @{
/*!
constructs a map that is unattached to any arrangement instance.
*/
Arr_face_index_map();
/*!
constructs a map and attaches it to the given arrangement `arr`.
*/
Arr_face_index_map(Arrangement_2& arr);
/// @}
}; /* end Arr_accessor */
} /* end namespace CGAL */

8
Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_linear_traits_2.h
View File

@ -5,9 +5,10 @@ namespace CGAL {
\ingroup PkgArrangement2TraitsClasses
The traits class `Arr_linear_traits_2` is a model of the
`ArrangementTraits_2` concept that allows for the construction and
maintenance of arrangements of linear objects which may be bounded
(line segments) or unbounded (rays and lines). The traits class is
`ArrangementTraits_2` concept, which enables the construction and maintenance of arrangements of
linear objects. The linear objects may be bounded (line segments) or
unbounded (rays and lines). Thus, it is also a model of the concept
`ArrangementOpenBoundaryTraits_2`. The traits class is parameterized
parameterized with a \cgal-kernel model; see the reference page of
`Arr_segment_traits_2<Kernel>` for further explanations and
recommendations on choosing a kernel.
@ -24,6 +25,7 @@ namespace CGAL {
\cgalModels `ArrangementTraits_2`
\cgalModels `ArrangementLandmarkTraits_2`
\cgalModels `ArrangementOpenBoundaryTraits_2`
*/
template< typename Kernel >
class Arr_linear_traits_2 {

8
Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_rational_function_traits_2.h
View File

@ -6,9 +6,11 @@ namespace CGAL {
The traits class `Arr_rational_function_traits_2` is a model of the `ArrangementTraits_2`
concept. It handles bounded and unbounded arcs of rational functions,
referred to as <I>rational arcs</I> (in particular, such an arc may
correspond to the entire graph of a rational function), and enables the
construction and maintenance of arrangements of such arcs.
referred to as <i>rational arcs</i> (in particular, such an arc may correspond to the
entire graph of a rational function). It supports bounded and
unbounded arcs. Thus, it is also a model of the concept
`ArrangementOpenBoundaryTraits_2`. The traits class enables
the construction and maintenance of arrangements of such arcs.
A rational function \f$ y = \frac{P(x)}{Q(x)}\f$ is defined by two polynomials
\f$ P\f$ and \f$ Q\f$ of arbitrary degrees.

85
Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_vertex_index_map.h Normal file
View File

@ -0,0 +1,85 @@
namespace CGAL {
/*!
\ingroup PkgArrangement2
`Arr_vertex_index_map` maintains a mapping of vertex handles of an
attached arrangement object to indices (of type `unsigned int`).
This class template is a model of the `boost` concept
`ReadablePropertyMap`. A mapping between vertex handles and indices
enables convenient usage of property-map classes supplied by `boost`.
For example, the property-map class templates
`boost::vector_property_map`, which is based on `std::vector`,
and `boost::iterator_property_map`, which can be used to implement
a property map based on a native \CC array, require the
user to supply a mapping such as `Arr_vertex_index_map`.
As new vertices might be inserted into the attached arrangement, and
existing vertices might be removed, the notification mechanism is used
to dynamically maintain the mapping of vertex handles to indices.
\cgalModels DefaultConstructible
\cgalModels CopyConstructible
\cgalModels Assignable
\cgalModels `boost::ReadablePropertyMap`
\sa `Arr_observer<Arrangement>`
\sa `Arr_face_index_map<Arrangement>`
*/
template< typename Arrangement >
class Arr_vertex_index_map: public Arr_observer<Arrangement> {
public:
/// \name Types
/// @{
/*!
the type of the attached arrangement.
*/
typedef Arrangement Arrangement_2;
typedef boost::readable_property_map_tag;
typedef unsigned int value_type;
typedef unsigned int reference;
typedef Vertex_handle key_type;
/*!
The vertex handle type.
*/
typedef typename Arrangement_2::Vertex_handle Vertex_handle;
/*!
The type of mapping of vertices to indices.
*/
typedef Unique_hash_map<Vertex_handle, value_type> Index_map;
/// @}
/// \name Creation
/// @{
/*!
constructs a map that is unattached to any arrangement instance.
*/
Arr_vertex_index_map();
/*!
constructs a map and attaches it to the given arrangement `arr`.
*/
Arr_vertex_index_map(Arrangement_2& arr);
/// @}
}; /* end Arr_accessor */
} /* end namespace CGAL */

2
Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arrangement_2.h
View File

@ -172,7 +172,7 @@ public:
An object \f$ e\f$ of the class `Halfedge` represents a halfedge in the
arrangement. A halfedge is directed from its <I>source</I> vertex
to its <I>target</I> vertex, and has an <I>incident face</I> lying to
its right. Each halfedge has a <I>twin</I> halfedge directed in the
its left. Each halfedge has a <I>twin</I> halfedge directed in the
opposite direction, where the pair of twin halfedges form together
an arrangement edge, that is - a \f$ 1\f$-dimensional cell, associated
with planar \f$ x\f$-monotone curve.

2
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2/arr_class.tex
View File

@ -432,7 +432,7 @@ vertex (we distinguish between a vertex that corresponds to the left
endpoint of the inserted curve and a vertex corresponding to its right
endpoint), we have to create a new vertex that corresponds to the other
endpoint of the curve and to connect the two vertices by a pair of
twin halfedges that form an "antenna" emanating from the boundary
twin halfedges that form an ``antenna'' emanating from the boundary
of an existing connected component (note that if the existing vertex
used to be isolated, this operation is actually equivalent to forming
a new hole inside the face that contains this vertex).

4
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2/arr_free.tex
View File

@ -218,7 +218,7 @@ zone computation terminates when an intersection with an arrangement's
edge/vertex is found or when the right endpoint is reached.
A given point-location object is used for locating the left endpoint
of the given curve in the existing arrangement. By default, the function
uses the "walk along line" point-location strategy --- namely an
uses the ``walk along line'' point-location strategy --- namely an
instance of the class
\ccc{Arr_walk_along_line_point_location}.
If the given curve is $x$-monotone then the traits
@ -233,7 +233,7 @@ intersects in the order that they are
discovered when traversing the $x$-monotone curve from left to right.
The function uses a given point-location object to locate the left
endpoint of the given $x$-monotone curve. By default, the function
uses the "walk along line" point-location strategy.
uses the ``walk along line'' point-location strategy.
The function requires that the traits class will model the
\ccc{ArrangementXMonotoneTraits_2} concept.

2
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2/arr_intro.tex
View File

@ -7,7 +7,7 @@ one-dimensional and two-dimensional cells, called {\em vertices}, {\em
edges} and {\em faces}, respectively induced by the curves in $\calC$.
Arrangements are ubiquitous in the computational-geometry
literature and have many applications;
see, e.g.,~\cite{as-aa-00}, \cite{cgal:h-a-04}.
see, e.g.,~\cite{as-aa-00,cgal:h-a-04}.
The curves in $\calC$ can intersect each other (a single curve may also
be self-intersecting or may be comprised of several disconnected branches)

2
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2/arr_notif.tex
View File

@ -39,7 +39,7 @@ topological structure. Most notifier functions belong to this
category. The relevant local changes include:
\begin{itemize}
\item A new vertex is constructed and associated with a point.
\item An edge\footnote{The term "edge" refers here to a pair of twin
\item An edge\footnote{The term ``edge'' refers here to a pair of twin
half-edges.} is constructed and associated with an $x$-monotone
curve.
\item An edge is split into two edges.

4
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2/arr_queries.tex
View File

@ -111,7 +111,7 @@ arrangement and moves downward toward the query point until
locating the arrangement cell containing it.
%
\item \ccc{Arr_landmarks_point_location<Arrangement,Generator>}
uses a set of "landmark" points whose location in the
uses a set of ``landmark'' points whose location in the
arrangement is known. Given a query point, it uses a \kdtree\ to
find the nearest landmark and then traverses the straight line
segment connecting this landmark to the query point.
@ -142,7 +142,7 @@ pointer to an arrangement object and operate directly on it.
Attaching such point-location objects to an existing arrangement
has virtually no running-time cost at all, but the query time is
linear in the size of the arrangement (the performance of the
"walk" strategy is much better in practice, but its worst-case
``walk'' strategy is much better in practice, but its worst-case
performance is linear). Using these strategies is therefore
recommended only when a relatively small number of point-location
queries are issued by the application, or when the arrangement is

10
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2/arr_traits.tex
View File

@ -438,7 +438,7 @@ segment-traits class. This kernel use interval arithmetic to filter the
exact computations. The program reads a set of line segments with integer
coordinates from a file and computes their arrangement. By default it
opens the \ccc{fan_grids.dat} input-file, located in the examples folder,
which contains $104$ line segments that form four "fan-like" grids and
which contains $104$ line segments that form four ``fan-like'' grids and
induce a dense arrangement, as illustrated in
Figure~\ref{arr_fig:predef_kernels}(a):
@ -953,9 +953,9 @@ The following example demonstrates the construction of an
arrangement of six rational arcs---four unbounded arcs and two
bounded ones---as depicted in Figure~\ref{arr_fig:ex_unb_rat}. Note
the usage of the constructors of an entire rational function and of
an infinite "ray" of such a function. Also observe that the hyperbolas
an infinite ``ray'' of such a function. Also observe that the hyperbolas
$y = \pm\frac{1}{x}$ and $y = \pm\frac{1}{2x}$ never intersect, although
they have common vertical and horizontal asymptotes, so very "thin"
they have common vertical and horizontal asymptotes, so very ``thin''
unbounded faces are created between them:
\ccIncludeExampleCode{Arrangement_on_surface_2/unbounded_rational_functions.cpp}
@ -1043,7 +1043,7 @@ of a polynomial $f(x,y)$ in two variables. The curve is uniquely defined
by $f$ (although several polynomials might define the same curve).
We call $f$ a \emph{defining polynomial} of $C$.
% When talking about algebraic curves, we use the term "segment" for a
% When talking about algebraic curves, we use the term ``segment'' for a
% closed continuous subset of an algebraic curve
% such that each interior point can be parameterized uniquely, as a function in
% $x$ or $y$. In other words, there is no self-intersection in the interior
@ -1054,7 +1054,7 @@ or by (weakly) $x$-monotone segments for algebraic curves
(Such a segment is not necessarily the maximal possible
(weakly) x-monotone segment; see below.)
When talking about algebraic curves,
we use the term "segment" for a continuous, possibly non-linear subset
we use the term ``segment'' for a continuous, possibly non-linear subset
of an algebraic curve~-- see the definition below.
There are no restrictions on the algebraic curve, that means,
we support unbounded curves, vertical curves or segments, and isolated points.

4
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2/arr_unbounded.tex
View File

@ -151,7 +151,7 @@ Halfedges are drawn as thin arrows. The vertices $v_1, \ldots, v_8$
lie at infinity, and are not associated with valid points. The
halfedges that connect them are fictitious, and are not associated
with concrete curves. The face denoted $f_0$ (lightly shaded)
is the fictitious "unbounded face" which lies outside the bounding
is the fictitious ``unbounded face'' which lies outside the bounding
rectangle (dashed) that bounds the actual arrangement. The four
fictitious vertices $v_{\rm bl}, v_{\rm tl}, v_{\rm br}$ and
$v_{\rm tr}$ represent the four corners of the bounding
@ -211,7 +211,7 @@ bounding bounding rectangle:
general the curve end also goes to $y = \pm\infty$ (see for instance
the vertices $v_1$, $v_3$, $v_6$ and $v_8$ in
Figure~\ref{arr_fig:unb_dcel}). For our convenience, we will always
take a "tall" enough bounding rectangle and treat such vertices as
take a ``tall'' enough bounding rectangle and treat such vertices as
lying on either the left or right rectangle edges (that is, if a curve
is defined at $x = -\infty$, its left end will be represented by
a vertex on the left edge of the bounding rectangle, and if it is

4
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2_ref/Arr_landmarks_point_location.tex
View File

@ -12,11 +12,11 @@
\label{arr_ref:lm_pl}
The \ccRefName\ class implements a Jump \& Walk algorithm, where special
points, referred to as "landmarks", are chosen in a preprocessing stage,
points, referred to as ``landmarks'', are chosen in a preprocessing stage,
their place in the arrangement is found, and they are inserted into a
data-structure that enables efficient nearest-neighbor search (a
{\sc Kd}-tree). Given a query point, the nearest landmark is located and a
"walk" strategy is applied from the landmark to the query point.
``walk'' strategy is applied from the landmark to the query point.
There are various strategies to select the landmark set in the
arrangement, where the strategy is determined by the

2
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2_ref/Arr_rational_function_traits.tex
View File

@ -46,7 +46,7 @@ using \ccc{Make_x_monotone_2}.
%does not have any real roots in this interval (thus the arc does not
%contain any vertical asymptotes). Our traits class is also capable of
%representing functions defined over an unbounded $x$-range, namely
%a "ray" defined over $(-\infty, x_{\rm max}]$ or over $[x_{\rm min}, \infty)$,
%a ``ray'' defined over $(-\infty, x_{\rm max}]$ or over $[x_{\rm min}, \infty)$,
%or a function defined over the entire real $x$-range. Note that a
%rational arc may be unbounded even if it is defined over some bounded interval.
%In these cases $Q$ has zeros in this interval. That is, the user is able to construct

2
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2_ref/Arr_vertical_ray_shoot.tex
View File

@ -17,7 +17,7 @@ A model of the \ccRefName\ concept can be attached to an \ccc{Arrangement_2}
instance and answer vertical ray-shooting queries on this arrangement.
Namely, given a \ccc{Arrangement_2::Point_2} object, representing a point in
the plane, it returns the arrangement feature (edge or vertex) that lies
strictly above it (or below it). By "strictly" we mean that if the
strictly above it (or below it). By ``strictly'' we mean that if the
query point lies on an arrangement edge (or on an arrangement vertex) this
edge will {\em not} be the query result, but the feature lying above or
below it. (An exception to this rule is the degenerate situation where the

2
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2_ref/Arr_walk_along_a_line_point_location.tex
View File

@ -27,7 +27,7 @@ The walk-along-a-line point-location object (just like the na\"{i}ve one)
does not use any auxiliary data structures. Thus, attaching it to an
existing arrangement takes constant time, and any ongoing updates to
this arrangement do not affect the point-location object.
It is therefore recommended to use the "walk" point-location strategy
It is therefore recommended to use the ``walk'' point-location strategy
for arrangements that are constantly changing, especially if the number
of issued queries is not large.

2
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2_ref/Arrangement_2.tex
View File

@ -259,7 +259,7 @@ a mutable handle. For example, the result of a point-location query is
a non-mutable handle for the arrangement cell containing the query point.
Assume that the query point lies on a edge, so we obtain a
\ccc{Halfedge_const_handle}; if we wish to use this handle and remove the
edge, we first need to cast away its "constness".
edge, we first need to cast away its ``constness''.
\ccMethod{Vertex_handle non_const_handle (Vertex_const_handle v);}
{casts the given constant vertex handle to an equivalent mutable handle.}

2
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2_ref/arr_do_intersect.tex
View File

@ -18,7 +18,7 @@ edge/vertex is found or when the right endpoint is reached.
A given point-location object is used for locating the left endpoint
of the given curve in the existing arrangement. By default, the function
uses the "walk along line" point-location strategy --- namely an
uses the ``walk along line'' point-location strategy --- namely an
instance of the class
\ccc{Arr_walk_along_line_point_location<Arrangement_2<Traits,Dcel> >}.

4
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2_ref/arr_insert.tex
View File

@ -26,7 +26,7 @@ its left endpoint and computing its zone until reaching the right endpoint.
The given point-location object \ccc{pl} is used to locate the left
endpoints of the $x$-monotone curves. By default, the function uses the
"walk along line" point-location strategy --- namely an instance of
``walk along line'' point-location strategy --- namely an instance of
the class \ccc{Arr_walk_along_line_point_location<Arrangement_2<Traits,Dcel> >}.
\ccPrecond{If provided, \ccc{pl} must be attached to the given arrangement
@ -74,7 +74,7 @@ computing its zone until reaching the right endpoint.
The given point-location object \ccc{pl} is used to locate the left
endpoints of the $x$-monotone curves. By default, the function uses the
"walk along line" point-location strategy --- namely an instance of
``walk along line'' point-location strategy --- namely an instance of
the class \ccc{Arr_walk_along_line_point_location<Arrangement_2<Traits,Dcel> >}.
\ccPrecond{If provided, \ccc{pl} is attached to the given arrangement

2
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2_ref/arr_insert_non_intersecting.tex
View File

@ -16,7 +16,7 @@ left to right).
A given point-location object is used for answering the two point-location
queries on the given curve endpoints. By default, the function uses the
"walk along line" point-location strategy --- namely, an instance of the
``walk along line'' point-location strategy --- namely, an instance of the
class \ccc{Arr_walk_along_line_point_location<Arrangement_2<Traits,Dcel> >}.
\ccInclude{CGAL/Arrangement_2.h}

2
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2_ref/arr_insert_vertex.tex
View File

@ -10,7 +10,7 @@ point in the given arrangement. If the point conincides with an existing
vertex, there is nothing left to do; if it lies on an edge, the edge is
split at the point. Otherwise, the point is contained inside a face, and is
inserted as an isolated vertex inside this face.
By default, the function uses the "walk along line" point-location
By default, the function uses the ``walk along line'' point-location
strategy --- namely, an instance of the class
\ccc{Arr_walk_along_line_point_location<Arrangement_2<Traits,Dcel> >}.
In either case, the function returns a handle for the vertex associated

8
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2_ref/arr_overlay.tex
View File

@ -30,7 +30,7 @@ construct the overlaid \dcel{} that represents the resulting arrangement.
Computes the overlay of two arrangements \ccc{arr1} and \ccc{arr2}, and sets
the output arrangement \ccc{res} to represent the overlaid arrangement.
\ccPrecond{\ccc{res} does not refer to either \ccc{arr1} or \ccc{arr2}
(that is, "self overlay" is not supported).}
(that is, ``self overlay'' is not supported).}
\ccGlobalFunction{template <class GeomTraitsA, class GeomTraitsB,
class GeomTraitsRes, class TopTraitsA,
@ -43,7 +43,7 @@ and sets the output arrangement \ccc{res} to represent the overlaid
arrangement. It employs the default overlay-traits, which practically does
nothing.
\ccPrecond{\ccc{res} does not refer to either \ccc{arr1} or \ccc{arr2}
(that is, "self overlay" is not supported).}
(that is, ``self overlay'' is not supported).}
%%%%
@ -62,7 +62,7 @@ Computes the overlay of two arrangements with history \ccc{arr1} and
represent the overlaid arrangement. The function also constructs a
consolidated set of curves that induce \ccc{res}.
\ccPrecond{\ccc{res} does not refer to either \ccc{arr1} or \ccc{arr2}
(that is, "self overlay" is not supported).}
(that is, ``self overlay'' is not supported).}
\ccGlobalFunction{template<typename Traits, typename Dcel1, typename Dcel2,
typename ResDcel>
@ -75,7 +75,7 @@ represent the overlaid arrangement. The function also constructs a
consolidated set of curves that induce \ccc{res}. It employs the default
overlay-traits, which practically does nothing.
\ccPrecond{\ccc{res} does not refer to either \ccc{arr1} or \ccc{arr2}
(that is, "self overlay" is not supported).}
(that is, ``self overlay'' is not supported).}
\ccRequirements
\begin{itemize}

2
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2_ref/arr_vert_decomp.tex
View File

@ -14,7 +14,7 @@ and physically decomposing the arrangement into pseudo-trapezoids. To do
this, it is convenient to process the vertices in an ascending
$xy$-lexicographic order. The visible objects are therefore returned through
an output iterator, which pairs each finite arrangement vertex with the two
features it "sees", such that the vertices are given in ascending
features it ``sees'', such that the vertices are given in ascending
$xy$-lexicographic order.
\ccInclude{CGAL/Arr_vertical_decomposition_2.h}

2
Arrangement_on_surface_2/doc_tex/Arrangement_on_surface_2_ref/arr_zone.tex
View File

@ -12,7 +12,7 @@ discovered when traversing the $x$-monotone curve from left to right.
A given point-location object is used for answering point-location queries
during the insertion process. By default, the function uses the
"walk along line" point-location strategy --- namely an instance of the
``walk along line'' point-location strategy --- namely an instance of the
class \ccc{Arr_walk_along_line_point_location<Arrangement_2<Traits,Dcel> >}.
%%%%

2
Arrangement_on_surface_2/doc_tex/Sweep_line_2_ref/Basic_sweep_line_2.tex
View File

@ -71,7 +71,7 @@
{Run the sweep-line algorithm on a given range of x-monotone curves.
\ccc{curves_begin} is an iterator for the first curve in the range.
\ccc{curves_end} is a past-the-end iterator for the range.
\ccPrecond{The value-type of CurveInputIterator is X_monotone_curve_2.}}
\ccPrecond {The value-type of CurveInputIterator is X_monotone_curve_2.}}
\ccMethod{template<class CurveInputIterator, class PointInputIterator>

2
BGL/doc_tex/BGL/BGL.tex
View File

@ -88,7 +88,7 @@ property map.
The data themselves may be stored in the vertex or edge, or they may
be stored in an external data structure, or they may be computed on
the fly. This is an "implementation detail" of the particular property map.
the fly. This is an ``implementation detail'' of the particular property map.
\smallskip
Property maps in the Boost manuals: \path|http://www.boost.org/libs/property_map/doc/property_map.html|

2
BGL/doc_tex/BGL_ref/graph_traits_Triangulation_2.tex
View File

@ -27,7 +27,7 @@ the edge weight is not well defined for infinite edges. For algorithms
that make use of the edge weight the user must therefore
define a \ccAnchor{http://www.boost.org/libs/graph/doc/filtered_graph.html}
{\ccc{boost::filtered_graph}} or pass a property map to the
algorithm that returns "infinity" for infinite edges.
algorithm that returns ``infinity'' for infinite edges.
Note also that when you derive from the class \ccc{CGAL::Triangulation_2}

16
Box_intersection_d/doc_tex/Box_intersection_d_ref/Box_d.tex
View File

@ -87,13 +87,13 @@ and also automatically with\\
\ccConstructor{Box_d(NT lo[D], NT hi[D]);}{initializes the box
intervals to [\ccc{lo[i]},\ccc{hi[i]}], $0 \leq i < D$.
\ccPrecond{\ccc{lo[i]} $<$ \ccc{hi[i]} for $0 \leq i < D$.}}
\ccPrecond \ccc{lo[i]} $<$ \ccc{hi[i]} for $0 \leq i < D$.}
\ccConstructor{Box_d( const Bbox_2& bbox);}{constructs from bbox
\ccRequire{ $D=2$ and \ccc{NT}$ \equiv $\ccc{double}.}}
\ccRequire $D=2$ and \ccc{NT}$ \equiv $\ccc{double}.}
\ccGlue
\ccConstructor{Box_d( const Bbox_3& bbox);}{constructs from bbox
\ccRequire{ $D=3$ and \ccc{NT}$ \equiv $\ccc{double}.}}
\ccRequire $D=3$ and \ccc{NT}$ \equiv $\ccc{double}.}
\ccModifiers
@ -113,21 +113,21 @@ and also automatically with\\
\ccMethod{std::size_t id();} {returns a unique box id, see the
\ccc{IdPolicy} template parameter above for the different
choices.
\ccRequire{ \ccc{IdPolicy}$ \neq $\ccc{ID_NONE}}}
\ccRequire \ccc{IdPolicy}$ \neq $\ccc{ID_NONE}}
\ccMethod{NT min_coord(int d) const;}{%
returns the lower boundary in dimension \ccc{d}
\ccPrecond{$0 \leq $\ccc{d}$ < D$}.}
\ccPrecond $0 \leq $\ccc{d}$ < D$}
\ccMethod{NT max_coord(int d) const;}{%
returns the upper boundary in dimension \ccc{d}
\ccPrecond{$0 \leq $\ccc{d}$ < D$}.}
\ccPrecond $0 \leq $\ccc{d}$ < D$}
\ccMethod{const Bbox_2& bbox() const;}{returns the bounding box
\ccRequire{ $D=2$ and \ccc{NT}$ \equiv $\ccc{double}}}
\ccRequire $D=2$ and \ccc{NT}$ \equiv $\ccc{double}}
\ccGlue
\ccMethod{const Bbox_3& bbox() const;}{returns the bounding box
\ccRequire{ $D=3$ and \ccc{NT}$ \equiv $\ccc{double}}}
\ccRequire $D=3$ and \ccc{NT}$ \equiv $\ccc{double}}
\ccMethod{void extend(NT p[N]);}{extends \ccVar\ to the smallest
box that additionally contains the point represented by coordinates in \ccc{p}.}

2
Box_intersection_d/doc_tex/Box_intersection_d_ref/Box_with_handle_d.tex
View File

@ -104,7 +104,7 @@ and also automatically with\\
\ccConstructor{Box_with_handle_d(NT lo[D], NT hi[D], Handle h);}{initializes
the box intervals to [\ccc{lo[i]},\ccc{hi[i]}], $0 \leq i < D$ and
sets the handle to $h$.
\ccPrecond{\ccc{lo[i]} $<$ \ccc{hi[i]} for $0 \leq i < D$.}}
\ccPrecond \ccc{lo[i]} $<$ \ccc{hi[i]} for $0 \leq i < D$.}
\ccConstructor{Box_with_handle_d( const Bbox_2& bbox, Handle h);}{constructs
from bbox and sets the handle to $h$, exists iff $D=2$ and \ccc{NT}$

2
Circular_kernel_2/doc_tex/Circular_kernel_2/CK.tex
View File

@ -82,7 +82,7 @@ numbers of degree~2, written by Olivier Devillers
\cite{cgal:dfmt-amafe-00,cgal:dfmt-amafe-02}, and that are still used
in the current implementation of \ccc{CGAL::Root_of_2}.
Some work was then done in the direction of a "kernel" for
Some work was then done in the direction of a ``kernel'' for
\cgal.\footnote{Monique Teillaud, First Prototype of a
\cgal\ Geometric Kernel with Circular Arcs, Technical Report
ECG-TR-182203-01, 2002\\Sylvain Pion and Monique Teillaud,

2
Circular_kernel_2/doc_tex/Circular_kernel_2_ref/intro.tex
View File

@ -24,7 +24,7 @@
\ccRefConceptPage{CircularKernel::ConstructCircularTargetVertex_2}
%\footnote{technical remark: the previous functors have a different name
%"Circular" because the operators() don't have the same return type
%``Circular'' because the operators() don't have the same return type
%as the existing CGAL functors... it would be nice to find a way to avoid
%this, but I don't know any technique for this.}

4
Circulator/doc_tex/Circulator_ref/Circulator_from_container.tex
View File

@ -57,8 +57,8 @@ All types required for circulators are provided.
\ccConstructor{Circulator_from_container(C* container, C::iterator i);}{%
a circulator \ccVar\ initialized to refer to the element \ccStyle{*i} in
\ccStyle{container}. \ccPrecond{\ccStyle{*i} is dereferenceable and refers
to \ccStyle{container}.}
\ccStyle{container}. \ccPrecond \ccStyle{*i} is dereferenceable and refers
to \ccStyle{container}.
}
\ccOperations

4
Circulator/doc_tex/Circulator_ref/is_empty_range.tex
View File

@ -31,8 +31,8 @@ the range is empty or not.
bool is_empty_range( const IC& i, const IC& j);}{%
is \ccc{true} if the range [\ccc{i, j}) is empty,
\ccc{false} otherwise.
\ccPrecond{\ccc{IC} is either a circulator or an iterator
type. The range [\ccc{i, j}) is valid.}
\ccPrecond \ccc{IC} is either a circulator or an iterator
type. The range [\ccc{i, j}) is valid.
}
\ccExample

6
Combinatorial_map/doc_tex/Combinatorial_map/Combinatorial_map.tex
View File

@ -402,7 +402,7 @@ of the combinatorial map.
% the set of \cells{i} form a partition of the set of darts D, i.e.
%
% Je le dis ici a titre d'exemple, c'est a dire je recommende
% que tu fasse un passe pour obtenir plus de "phrases sans $..$"
% que tu fasse un passe pour obtenir plus de ``phrases sans $..$''
A last important property of cells is that for all dimensions \emph{i} the
set of \cells{i} forms a partition of the set of darts \emph{D}, i.e. for
@ -1605,9 +1605,9 @@ four 2-attributes having respectively 2, 2, 5 and 10 as values.
\section{Mathematical Definitions}\label{sec_definition}
The initial definition of combinatorial map in any dimension is given
in \cite{cgal:l-tmbrc-91}, \cite{l-ndgcm-94}. But it allows only to represent
in \cite{cgal:l-tmbrc-91,l-ndgcm-94}. But it allows only to represent
objects without boundaries. This definition was extended
\cite{cgal:pabl-cco-07}, \cite{cgal:d-ccccg-10} in order to allow to represent
\cite{cgal:pabl-cco-07,cgal:d-ccccg-10} in order to allow to represent
objects with boundaries, based on the notions of partial permutations
and partial involutions.

4
Convex_hull_2/doc_tex/Convex_hull_2_ref/ch_akl_toussaint.tex
View File

@ -30,9 +30,9 @@ points from a given set of input points.
\ccc{result}, and the past-the-end iterator for the resulting
sequence is returned. It is not specified at which point the
cyclic sequence of extreme points is cut into a linear sequence.
\ccPrecond{ %\ccIndexSubitem[C]{ch_akl_toussaint}{preconditions}
\ccPrecond %\ccIndexSubitem[C]{ch_akl_toussaint}{preconditions}
The source range [\ccc{first},\ccc{beyond}) does not contain
\ccc{result}.}}
\ccc{result}.}
The default traits class \ccc{Default_traits} is the kernel in which the

4
Convex_hull_2/doc_tex/Convex_hull_2_ref/ch_bykat.tex
View File

@ -31,9 +31,9 @@ points from a given set of input points.
\ccc{result}, and the past-the-end iterator for the resulting
sequence is returned. It is not specified at which point the
cyclic sequence of extreme points is cut into a linear sequence.
\ccPrecond{ %\ccIndexSubitem[C]{ch_bykat}{preconditions}
\ccPrecond %\ccIndexSubitem[C]{ch_bykat}{preconditions}
The source range [\ccc{first},\ccc{beyond}) does not contain
\ccc{result}.}}
\ccc{result}.}
The default traits class \ccc{Default_traits} is the kernel in which the
type \ccc{ForwardIterator::value_type} is defined.

4
Convex_hull_2/doc_tex/Convex_hull_2_ref/ch_eddy.tex
View File

@ -31,9 +31,9 @@ points from a given set of input points.
\ccc{result}, and the past-the-end iterator for the resulting
sequence is returned. It is not specified at which point the
cyclic sequence of extreme points is cut into a linear sequence.
\ccPrecond{ %\ccIndexSubitem[C]{ch_eddy}{preconditions}
\ccPrecond %\ccIndexSubitem[C]{ch_eddy}{preconditions}
The source range [\ccc{first},\ccc{beyond}) does not contain
\ccc{result}.}}
\ccc{result}.}
The default traits class \ccc{Default_traits} is the kernel in which the
type \ccc{ForwardIterator::value_type} is defined.

4
Convex_hull_2/doc_tex/Convex_hull_2_ref/ch_graham_andrew.tex
View File

@ -31,9 +31,9 @@ points from a given set of input points.
\ccc{result}, and the past-the-end iterator for the resulting
sequence is returned. It is not specified at which point the
cyclic sequence of extreme points is cut into a linear sequence.
\ccPrecond{ %\ccIndexSubitem[C]{ch_graham_andrew}{preconditions}
\ccPrecond %\ccIndexSubitem[C]{ch_graham_andrew}{preconditions}
The source range [\ccc{first},\ccc{beyond}) does not contain
\ccc{result}.}}
\ccc{result}.}
The default traits class \ccc{Default_traits} is the kernel in which the
type \ccc{InputIterator::value_type} is defined.

6
Convex_hull_2/doc_tex/Convex_hull_2_ref/ch_graham_andrew_scan.tex
View File

@ -32,13 +32,13 @@ by the first and last points in this sequence.
the value of \ccc{beyond} $-1$. The resulting sequence is placed
starting at \ccc{result} with $p$; point $q$ is omitted. The
past-the-end iterator for the sequence is returned.
\ccPrecond{ %\ccIndexSubitem[C]{ch_graham_andrew_scan}{preconditions}
\ccPrecond %\ccIndexSubitem[C]{ch_graham_andrew_scan}{preconditions}
The range [\ccc{first},\ccc{beyond}) contains at least
two different points.
The points in [\ccc{first},\ccc{beyond}) are "sorted" with respect
The points in [\ccc{first},\ccc{beyond}) are ``sorted'' with respect
to $pq$, {\it i.e.}, the sequence of points in
[\ccc{first},\ccc{beyond}) define a counterclockwise polygon,
for which the Graham-Sklansky-procedure \cite{s-mcrm-72} works.}}
for which the Graham-Sklansky-procedure \cite{s-mcrm-72} works.}
The default traits class \ccc{Default_traits} is the kernel in which the
type \ccc{BidirectionalIterator::value_type} is defined.

4
Convex_hull_2/doc_tex/Convex_hull_2_ref/ch_jarvis.tex
View File

@ -32,9 +32,9 @@ points from a given set of input points.
\ccc{result}, and the past-the-end iterator for the resulting
sequence is returned. It is not specified at which point the
cyclic sequence of extreme points is cut into a linear sequence.
\ccPrecond{ %\ccIndexSubitem[C]{ch_jarvis}{preconditions}
\ccPrecond %\ccIndexSubitem[C]{ch_jarvis}{preconditions}
The source range [\ccc{first},\ccc{beyond}) does not contain
\ccc{result}.}}
\ccc{result}.}
The default traits class \ccc{Default_traits} is the kernel in which the
type \ccc{InputIterator::value_type} is defined.

4
Convex_hull_2/doc_tex/Convex_hull_2_ref/ch_melkman.tex
View File

@ -28,10 +28,10 @@ extreme points of a sequence of points that forms a simple polyline or polygon.
The resulting sequence is placed starting at
position \ccc{result}, and the past-the-end iterator for
the resulting sequence is returned.
\ccPrecond{ %\ccIndexSubitem[C]{ch_melkman}{preconditions}
\ccPrecond %\ccIndexSubitem[C]{ch_melkman}{preconditions}
The source range [\ccc{first},\ccc{beyond}) corresponds
to a simple polyline.
[\ccc{first},\ccc{beyond}) does not contain \ccc{result}}.}
[\ccc{first},\ccc{beyond}) does not contain \ccc{result}}.
The default traits class \ccc{Default_traits} is the kernel in which the
type \ccc{InputIterator::value_type} is defined.

4
Convex_hull_2/doc_tex/Convex_hull_2_ref/convex_hull_2.tex
View File

@ -28,9 +28,9 @@ points from a given set of input points.
\ccc{result}, and the past-the-end iterator for the resulting
sequence is returned. It is not specified at which point the
cyclic sequence of extreme points is cut into a linear sequence.
\ccPrecond{ %\ccIndexSubitem[C]{convex_hull_2}{preconditions}
\ccPrecond %\ccIndexSubitem[C]{convex_hull_2}{preconditions}
The source range [\ccc{first},\ccc{beyond}) does not contain
\ccc{result}.}}
\ccc{result}.}
The default traits class \ccc{Default_traits} is the kernel in which
the type \ccc{InputIterator::value_type} is defined.

30
Convex_hull_d/doc_tex/Convex_hull_d_ref/Convex_hull_d.tex
View File

@ -124,20 +124,20 @@ returns the point associated with vertex $v$.}
\ccMethod{Vertex_handle vertex_of_simplex(Simplex_handle s, int i)
;}{returns the vertex corresponding to the $i$-th vertex of $s$.\\
\ccPrecond{$0 \leq i \leq \ccc{dcur}$. }}
\ccPrecond $0 \leq i \leq \ccc{dcur}$. }
\ccMethod{Point_d point_of_simplex(Simplex_handle s,int i) ;}{same as
\ccc{C.associated_point(C.vertex_of_simplex(s,i))}. }
\ccMethod{Simplex_handle opposite_simplex(Simplex_handle s,int i)
;}{returns the simplex opposite to the $i$-th vertex of $s$
(\ccc{Simplex_handle()} if there is no such simplex). \ccPrecond{ $0
\leq i \leq \ccc{dcur}$.} }
(\ccc{Simplex_handle()} if there is no such simplex). \ccPrecond $0
\leq i \leq \ccc{dcur}$. }
\ccMethod{int index_of_vertex_in_opposite_simplex(Simplex_handle s,int
i) ;}{returns the index of the vertex opposite to the $i$-th vertex of
$s$. \ccPrecond{$0 \leq i \leq \ccc{dcur}$ and there is a simplex
opposite to the $i$-th vertex of $s$.} }
$s$. \ccPrecond $0 \leq i \leq \ccc{dcur}$ and there is a simplex
opposite to the $i$-th vertex of $s$. }
\ccMethod{Simplex_handle simplex(Vertex_handle v) ;}{returns a simplex
of which $v$ is a node. Note that this simplex is not unique. }
@ -147,24 +147,24 @@ of which $v$ is a node. Note that this simplex is not unique. }
\ccMethod{Vertex_handle vertex_of_facet(Facet_handle f, int i)
;}{returns the vertex corresponding to the $i$-th vertex of $f$.
\ccPrecond{$0 \leq i < \ccc{dcur}$.} }
\ccPrecond $0 \leq i < \ccc{dcur}$. }
\ccMethod{Point_d point_of_facet(Facet_handle f, int i) ;}{same as
\ccc{C.associated_point(C.vertex_of_facet(f,i))}. }
\ccMethod{Facet_handle opposite_facet(Facet_handle f, int i)
;}{returns the facet opposite to the $i$-th vertex of $f$
(\ccc{Facet_handle()} if there is no such facet). \ccPrecond{$0 \leq i
< \ccc{dcur}$ and \ccc{dcur > 1}.} }
(\ccc{Facet_handle()} if there is no such facet). \ccPrecond $0 \leq i
< \ccc{dcur}$ and \ccc{dcur > 1}. }
\ccMethod{int index_of_vertex_in_opposite_facet(Facet_handle f, int i)
;}{returns the index of the vertex opposite to the $i$-th vertex of
$f$. \ccPrecond{$0 \leq i < \ccc{dcur}$ and \ccc{dcur > 1}.} }
$f$. \ccPrecond $0 \leq i < \ccc{dcur}$ and \ccc{dcur > 1}. }
\ccMethod{Hyperplane_d hyperplane_supporting(Facet_handle f)
;}{returns a hyperplane supporting facet \ccc{f}. The hyperplane is
oriented such that the interior of \ccc{C} is on the negative side of
it. \ccPrecond{\ccc{f} is a facet of \ccc{C} and \ccc{dcur > 1}.} }
it. \ccPrecond \ccc{f} is a facet of \ccc{C} and \ccc{dcur > 1}. }
\ccMethod{Vertex_handle insert(const Point_d& x);}{adds point \ccc{x}
to the underlying set of points. If $x$ is equal to (the point
@ -188,13 +188,13 @@ $x$ is not contained in the affine hull of \ccc{S}. }
\ccMethod{std::list<Facet_handle> facets_visible_from(const Point_d&
x);}{returns the list of all facets that are visible from \ccc{x}.\\
\ccPrecond{\ccc{x} is contained in the affine hull of \ccc{S}.} }
\ccPrecond \ccc{x} is contained in the affine hull of \ccc{S}. }
\ccMethod{Bounded_side bounded_side(const Point_d& x);}{returns
\ccc{ON_BOUNDED_SIDE} (\ccc{ON_BOUNDARY},\ccc{ON_UNBOUNDED_SIDE}) if
\ccc{x} is contained in the interior (lies on the boundary, is
contained in the exterior) of \ccc{C}. \ccPrecond{\ccc{x} is contained
in the affine hull of \ccc{S}.} }
contained in the exterior) of \ccc{C}. \ccPrecond \ccc{x} is contained
in the affine hull of \ccc{S}. }
\ccMethod{void clear(int d) ;}{re-initializes \ccc{C} to an empty hull
in $d$-dimensional space. }
@ -323,7 +323,7 @@ include \ccc{<CGAL/Convex_hull_d_to_polyhedron_3.h>}
\ccFunction{template <class R, class T, class HDS>
void convex_hull_d_to_polyhedron_3( const Convex_hull_d<R>& C, Polyhedron_3<T,HDS>& P) ;}{converts the convex hull \ccc{C} to polyhedral surface stored in
\ccc{P}.\\ \ccPrecond{\ccc{dim == 3} and \ccc{dcur == 3}.}
\ccc{P}.\\ \ccPrecond \ccc{dim == 3} and \ccc{dcur == 3}.
}
\ccHeading{Low Dimensional Output Routines}
@ -331,7 +331,7 @@ void convex_hull_d_to_polyhedron_3( const Convex_hull_d<R>& C, Polyhedron_3<T,
\ccFunction{template <class R>
void d3_surface_map(const Convex_hull_d<R>& C, GRAPH< typename Convex_hull_d<R>::Point_d ,int>& G);}{constructs the representation of the surface of \ccc{C} as a
bidirected LEDA graph \ccc{G}.\\ \ccPrecond{\ccc{dim == 3}. }
bidirected LEDA graph \ccc{G}.\\ \ccPrecond \ccc{dim == 3}.
}
\end{ccRefClass}

14
Convex_hull_d/doc_tex/Convex_hull_d_ref/Delaunay_d.tex
View File

@ -144,23 +144,23 @@ triangulation.
}
\ccMethod{ Vertex_handle vertex_of_simplex(Simplex_handle s, int i) ;}{returns the vertex associated with the $i$-th node of $s$.
\ccPrecond{$0 \leq i \leq \ccc{dcur}$.}
\ccPrecond $0 \leq i \leq \ccc{dcur}$.
}
\ccMethod{Point_d associated_point(Vertex_handle v) ;}{returns the point associated with vertex $v$.
}
\ccMethod{Point_d point_of_simplex(Simplex_handle s,int i) ;}{returns the point associated with the $i$-th vertex of $s$.
\ccPrecond{$0 \leq i \leq \ccc{dcur}$.}
\ccPrecond $0 \leq i \leq \ccc{dcur}$.
}
\ccMethod{Simplex_handle opposite_simplex(Simplex_handle s, int i) ;}{returns the simplex opposite to the $i$-th vertex of $s$
(\ccc{Simplex_handle()} if there is no such simplex).
\ccPrecond{$0 \leq i \leq \ccc{dcur}$.}
\ccPrecond $0 \leq i \leq \ccc{dcur}$.
}
\ccMethod{int index_of_vertex_in_opposite_simplex(Simplex_handle s,int i) ;}{returns the index of the vertex opposite to the $i$-th vertex
of $s$. \ccPrecond{$0 \leq i \leq \ccc{dcur}$.}
of $s$. \ccPrecond $0 \leq i \leq \ccc{dcur}$.
}
\ccMethod{Simplex_handle simplex(Vertex_handle v) ;}{returns a simplex of the nearest site triangulation incident
@ -209,8 +209,8 @@ sphere $C$.
\ccMethod{std::list<Vertex_handle> range_search(const std::vector<Point_d>& A) ;}{returns the list of all vertices contained in the closure of
the simplex whose corners are given by \ccc{A}.
\ccPrecond{\ccc{A} must consist of $d+1$ affinely independent points
in base space.}
\ccPrecond \ccc{A} must consist of $d+1$ affinely independent points
in base space.
}
\ccMethod{std::list<Simplex_handle> all_simplices(Delaunay_voronoi_kind k = NEAREST) ;}{returns a list of all simplices of either the nearest or the
@ -327,7 +327,7 @@ and uses the following function objects from the kernel traits \ccc{R}:
\ccFunction{template <typename R, typename Lifted_R>
template <typename R, typename Lifted_R> void d2_map(const Delaunay_d<R,Lifted_R>& D, GRAPH< typename Delaunay_d<R,Lifted_R>::Point_d, int >& DTG, typename Delaunay_d<R,Lifted_R>::Delaunay_voronoi_kind k = Delaunay_d<R,Lifted_R>::NEAREST) ;}{constructs a LEDA graph representation of the nearest
(\ccc{kind = NEAREST} or the furthest (\ccc{kind = FURTHEST}) site
Delaunay triangulation. \ccPrecond{\ccc{dim() == 2}.}
Delaunay triangulation.\\ \ccPrecond \ccc{dim() == 2}.
}
\ccIndexMainItemEnd{Delaunay triangulation, dD}

2
Developers_manual/doc_tex/Developers_manual/checks.tex
View File

@ -81,7 +81,7 @@ attributes:
\begin{itemize}
\item \textbf{Expensive}\ccIndexSubitemDef{checks}{expensive}
checks take considerable time to compute.
"Considerable" is an imprecise phrase. Checks that add less than 10
``Considerable'' is an imprecise phrase. Checks that add less than 10
percent to the execution time of their routine are not expensive.
Checks that can double the execution time are. Somewhere in between
lies the border line.

16
Developers_manual/doc_tex/Developers_manual/code_format.tex
View File

@ -59,13 +59,13 @@ there are \emph{convincing} reasons.
\ccIndexSubitem{naming scheme}{abbreviations}
({\em e.g.}, use
\ccc{Triangulation} instead of \ccc{Tri}). The only exceptions
might be standard geometric abbreviations (such as "CH" for "convex
hull") and standard data structure abbreviations (such as "DS" for
"data structure"). Unfortunately, the long names that result from
might be standard geometric abbreviations (such as ``CH'' for ``convex
hull'') and standard data structure abbreviations (such as ``DS'' for
``data structure''). Unfortunately, the long names that result from
the absence of abbreviations are known to cause problems with some
compilers.\ccIndexMainItem{long-name problem}
% See Section~\ref{sec:long_name_problem}
% for further information about the so-called "long-name problem."
% for further information about the so-called ``long-name problem.''
\ccIndexSubitemBegin{naming scheme}{capitalization}
\item Names of constants are uppercase ({\em e.g.}, \ccc{ORIGIN}).
\ccModifierCrossRefOff
@ -112,7 +112,7 @@ there are \emph{convincing} reasons.
\ccIndexSubitemBegin{data structures}{naming}
\begin{itemize}
\item Names for geometric data structures and algorithms should follow
the "spirit" of the rules given so far, \eg~a data structure for
the ``spirit'' of the rules given so far, \eg~a data structure for
triangulations in the plane is named \ccc{Triangulation_2}, and a
convex hull algorithm in 3-space is named \ccc{convex_hull_3}.
\item Member functions realizing predicates should start with \ccc{is_} or
@ -186,7 +186,7 @@ Here are the naming rules:
objects like \ccc{Has_on_bounded_side_2}, \ccc{Is_degenerate_2},
and \ccc{Is_horizontal_2}. According to the current kernel we
also have \ccc{Left_turn_2}. For reasons of consistency with
\stl, all "less-than"-objects start with \ccc{Less_},
\stl, all ``less-than''-objects start with \ccc{Less_},
\eg,~\ccc{Less_xy_2}. Further examples are
\ccc{Less_distance_to_point_2} and
\ccc{Less_distance_to_line_2}. However, we have \ccc{Equal_2},
@ -250,7 +250,7 @@ For example, the function that returns an instance of the
\ccIndexSubitemBegin{source files}{naming scheme}
\begin{itemize}
\item File names should be chosen in the "spirit" of the naming rules given
\item File names should be chosen in the ``spirit'' of the naming rules given
above.
\item If a single geometric object, data structure, or algorithm is provided
in a single file, its name (and its capitalization) should be used for
@ -266,7 +266,7 @@ For example, the function that returns an instance of the
rejected by the submission script.
\item The names of files should not contain any characters not allowed by
all the platforms the library supports. In particular, it should not
contain the characters ':', '*', or '\ '.
contain the characters `:', `*', or `\ '.
\item Internal header files -- which are not documented to the user -- should
have {\tt /internal/} as a directory higher up in their hierarchy.
For example {\tt CGAL/internal/foo.h} or

2
Developers_manual/doc_tex/Developers_manual/handles.tex
View File

@ -146,7 +146,7 @@ class My_geo_object : public Handle
\end{verbatim}
The class \ccc{My_geo_object} is responsible for allocating and constructing
the \ccc{My_rep} object "on the heap".
the \ccc{My_rep} object ``on the heap''.
Typically, a constructor call is forwarded to a
corresponding constructor of \ccc{My_rep}. The address of the new \ccc{My_rep} is assigned to \ccc{PTR} inherited from \ccc{Handle}, e.g.:

14
Developers_manual/doc_tex/Developers_manual/portability.tex
View File

@ -35,9 +35,9 @@ assume. Especially you may assume that the compiler
\item supports member templates
\item support for \texttt{std::iterator\_traits}.
\end{itemize}
Still, there are many bugs (sometimes known as "features") left in the
Still, there are many bugs (sometimes known as ``features'') left in the
compilers. Have a look at the list of (non-obsolete) workarounds in
Section~\ref{sec:workaround_flags} to get an idea of which "features" are
Section~\ref{sec:workaround_flags} to get an idea of which ``features'' are
still present.
\ccIndexMainItemBegin{configuration}
@ -167,11 +167,11 @@ operating system and compiler that is defined as follows.
\begin{description}
\item[$<$arch$>$] is the system architecture as defined by ``{\tt
uname -p}" or "\texttt{uname -m}",
uname -p}'' or ``\texttt{uname -m}'',
\item[$<$os$>$] is the operating system as defined by ``\texttt{uname
-s}'',
\item[$<$os-version$>$] is the operating system version as defined by
"\texttt{uname -r}",
``\texttt{uname -r}'',
\item[$<$comp$>$] is the basename of the compiler executable (if it
contains spaces, these are replaced by "-"), and
\item[$<$comp-version$>$] is the compiler's version number (which
@ -196,12 +196,12 @@ These test programs reside in the directory
where \verb|$(CGAL_ROOT)| represents the installation directory for the library.
The names of all testfiles, which correspond to the names of the flags,
\ccIndexSubitem{workaround flags}{names}
start with "\texttt{CGAL\_CFG\_}" followed by
start with ``\texttt{CGAL\_CFG\_}'' followed by
\begin{itemize}
\item \textit{either} a description of a bug ending with
"\texttt{\_BUG}"
``\texttt{\_BUG}''
\item \textit{or} a description of a feature starting with
"\texttt{NO\_}".
``\texttt{NO\_}''.
\end{itemize}
For any of these files a corresponding flag is set in the
platform-specific configuration file, iff either compilation or execution

10
Developers_manual/doc_tex/Developers_manual/robustness.tex
View File

@ -34,9 +34,9 @@ Nevertheless, the generic implementation of the kernel primitives that are
parameterized by the arithmetic (more precisely, by a number type)
assumes that the arithmetic plugged in does behave as real arithmetic.
The generic code does not and should not (otherwise it would slow down
"exact" number types) deal with any potential imprecision. There are
a number of (third-party provided) "exact" number types available for use
with \cgal, where "exact" means
``exact'' number types) deal with any potential imprecision. There are
a number of (third-party provided) ``exact'' number types available for use
with \cgal, where ``exact'' means
that all decisions (comparison operations) are correct and that the
representation of the numbers allows for refinement to an arbitrary precision,
if needed.
@ -48,7 +48,7 @@ If roots of polynomials are needed, then the solution is to use
% Most notably, \ccc{leda_real}s provide easy-to-use adaptive
% "exact" arithmetic for the basic operations and $\sqrt[k]{\ }$ operations.
% ``exact'' arithmetic for the basic operations and $\sqrt[k]{\ }$ operations.
% \lcTex{
% \begin{center}
% \includegraphics[width=8cm]{Developers_manual/fig/use_real}
@ -79,7 +79,7 @@ in the constructed objects was already part of the input. An example is
computing the lexicographically smaller point for two given points.
\cgal\ provides generic implementations of geometric primitives. These assume
"exact computation". This may or may not work, depending on the actual
``exact computation''. This may or may not work, depending on the actual
numerical input data. \cgal\ also provides\footnote{at present, for the
dimension 2/3 Cartesian kernel(s) only.}
% The homogeneous counterpart still needs revision.}

12
Developers_manual/doc_tex/Developers_manual/specification.tex
View File

@ -867,15 +867,15 @@ regarding the organization are provided:
that the entire description was contained in the introduction.
\item The section describing software design should be labeled (you guessed
it) "Software Design."
it) ``Software Design.''
\item Example programs should have entries in the table of contents and
the user should be able to figure out quite easily what this example
illustrated from the table of contents. This means, examples should
be in sections of their own and the sections should have descriptive
names (\textit{i.e.}, "Example Constructing a Vanilla Cone" instead
of just "Example", unless this is a subsection of a section
entitled "Vanilla Cone").
names (\textit{i.e.}, ``Example Constructing a Vanilla Cone'' instead
of just ``Example'', unless this is a subsection of a section
entitled ``Vanilla Cone'').
\item The examples should appear near the things of which they are
examples. So for chapters describing more than one class (such as
@ -1140,7 +1140,7 @@ The name of the concept is provided as the argument to this environment.
Under the \verb|\ccDefinition| heading, the concept should be described
followed by the set of required functions (one or more
\ccc{operator()} methods). Under the heading \verb|\ccRefines|
you should list concepts that this one "inherits" from and
you should list concepts that this one ``inherits'' from and
under \verb|\ccHasModels| list the classes that are models of this
concept.
\ccIndexSubitemEnd{reference manual}{function object concepts}
@ -1367,7 +1367,7 @@ any problems.
\subsection*{Problem --- Unresolved figure references in HTML}
\ccIndexSubsubitemBegin{manuals}{HTML}{figure references}
%Figure references in the HTML manual appear as "[ref:fig:xxx]"
%Figure references in the HTML manual appear as ``[ref:fig:xxx]''
%instead of as a link to the figure.
\begin{description}

2
Developers_manual/doc_tex/Developers_manual/traits_classes.tex
View File

@ -250,7 +250,7 @@ have to observe when you design a traits class yourself.
\ccc{Less_xy_2}, there is no reason to require \ccc{Greater_xy_2},
because the latter can be constructed from the former. In general,
designing a good traits class requires a deep understanding of the
algorithm it is made for. Finding the "right" set of geometric
algorithm it is made for. Finding the ``right'' set of geometric
primitives required by the algorithm can be a nontrivial task.
However, spending effort on that task decreases the effort needed
later to implement traits classes and increases the ease of use of

88
Documentation/doc/Installation.txt
View File

@ -117,7 +117,7 @@ contains the following subdirectories:
<TD ALIGN=LEFT NOWRAP>
`auxiliary`
<TD ALIGN=LEFT NOWRAP>
precompiled \sc{Gmp}, \sc{Mpfr} and \sc{Taucs} for Windows
precompiled \sc{Gmp} and \sc{Mpfr} for Windows
<TR>
<TD ALIGN=LEFT NOWRAP>
`cmake/modules`
@ -553,9 +553,11 @@ your own demos you might need these \cgal-libraries.
\section secoptional3rdpartysoftware Optional Third Party Libraries
Optional 3rd party software is only required to build examples and
demos shipped with \cgal or to build your own project using \cgal. In order
to simplify these builds, various libraries can be <I>prepared to be
Optional 3rd party software can be used by \cgal for various reasons:
Usually certain optional libraries are required to build examples and
demos shipped with \cgal\ or to build your own project using \cgal.
Another reason is to speed up basic tasks.
In order to support these goals, all optional libraries can be <i>prepared to be
used with \cgal</I> while configuring \cgal, just in the same way as
essential libraries are configured. Whenever building an example or a
demo (or your own executable), these <I>preconfigured</I> libraries
@ -602,8 +604,8 @@ Mainly parts in \cgal's algebraic kernel require Rs3.
\sc{Ntl} provides data structures and algorithms for signed, arbitrary
length integers, and for vectors, matrices, and polynomials over the
integers and over finite fields. In \cgal \sc{Ntl} is used to speed up
polynomial operations such as GCDs. It is recommended to install \sc{Ntl} with support from \sc{Gmp}.
integers and over finite fields. The optional library \sc{Ntl} is used by \cgal
to speed up operations of the Polynomial package, such as GCDs. It is recommended to install \sc{Ntl} with support from \sc{Gmp}.
\sc{Ntl} can be downloaded from <A HREF="http://www.shoup.net/ntl/">`http://www.shoup.net/ntl/`</A>. Version 5.1 or higher is recommended.
@ -614,14 +616,10 @@ matrix sizes, various matrix decomposition methods and sparse linear solvers.
In \cgal, \sc{Eigen} provides sparse linear solvers in the \ref PkgSurfaceReconstructionFromPointSets
and the \ref PkgSurfaceParameterization packages.
Since \cgal version 4.0, \sc{Eigen} is recommended over \sc{Taucs} that is not longer maintained.
In addition, \sc{Eigen} also provides singular value decomposition for the \ref PkgJet_fitting_3
and the \ref PkgRidges_3 packages.
The usage of \sc{Eigen} allows to remove \sc{lapack}, \sc{blas} and \sc{Taucs} from the list of third party libraries
required by some \cgal packages. Note that the version 3.1 (or greater) of \sc{Eigen} is required.
The \sc{Eigen} web site is <A HREF="http://eigen.tuxfamily.org">`http://eigen.tuxfamily.org`</A>.
\subsection thirdpartylibQGLViewer libQGLViewer
@ -1068,8 +1066,7 @@ source file</B>.
"com2") of \cgal to which the executable(s) should be linked. Valid components are \cgal's
libraries (i.e. "Core", "ImageIO", "Qt3" and "Qt4"; note
that it only make sense to either pick "Qt3" or "Qt4") and all
preconfigured 3rd party software, such as "MPFI", "RS3",
or "LAPACK"). An example is `-c Core:GMP:RS3:MPFI`
preconfigured 3rd party software, such as "MPFI", "RS3"). An example is `-c Core:GMP:RS3:MPFI`
<DT><B>`-b boost1:boost2:...`</B><DD> Lists components ("boost1",
"boost2") of \sc{Boost} to which the executable(s) should be
@ -1103,8 +1100,8 @@ link with \cgal and essential third party libraries. Beyond,
`find_package` can demand for `COMPONENTS` of \cgal,
that is, all \cgal libraries libCGAL_Core (``Core''),
libCGAL_ImageIO (``ImageIO'') , libCGAL_Qt3 (``Qt3'') and libCGAL_Qt4
(``Qt4'') or optional 3rd party software such as ``MPFI'', ``RS3'' or
``LAPACK''. A user is free to create the `CMakeLists.txt`
(``Qt4'') or optional 3rd party software such as ``MPFI'', ``RS3''.
A user is free to create the `CMakeLists.txt`
without calling the script (manual creation).
\subsection installation_custom Custom flags in the programs using CGAL
@ -1503,6 +1500,13 @@ Indicates whether to search and use \sc{Gmp}/\sc{Mpfr} or not
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`GMP_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{Gmp} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`GMP_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `gmp.h` file
@ -1588,6 +1592,13 @@ Under Linux, the \sc{Gmpxx} is also searched for, and you may specify the follow
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`GMPXX_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{gmpxx} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`GMPXX_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `gmpxx.h` file
@ -1764,6 +1775,13 @@ Indicates whether to search and use \leda or not
CMake
<TR>
<TD ALIGN=LEFT NOWRAP>
`LEDA_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{LEDA} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`LEDA_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the file `LEDA/system/basic.h`
@ -1849,6 +1867,13 @@ and library files must be specified by using environment variables.
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`MPFI_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{MPFI} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`MPFI_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `mpfi.h` file
@ -1910,6 +1935,13 @@ related to the latter library may also need to be defined.
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{RS} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `rs_exports.h` file
@ -1960,6 +1992,13 @@ Similar variables exist for Rs3.
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS3_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{RS3} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`RS3_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `rs_exports.h` file
@ -2019,6 +2058,13 @@ headers and library files must be specified using environment variables.
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`NTL_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{NTL} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`NTL_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `NTL/ZZX.h` file
@ -2072,6 +2118,13 @@ Only the <I>directory</I> containing the header files of \sc{Eigen} 3.1 (or grea
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`EIGEN3_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{EIGEN} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`EIGEN3_INCLUDE_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the file `signature_of_eigen3_matrix_library`
@ -2155,6 +2208,13 @@ environment variable is sufficient.
<B>Type</B>
<TR>
<TD ALIGN=LEFT NOWRAP>
`ESBTL_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory of \sc{ESBTL} default installation
<TD ALIGN=LEFT NOWRAP>
Environment
<TR>
<TD ALIGN=LEFT NOWRAP>
`ESBTL_INC_DIR`
<TD ALIGN=LEFT NOWRAP>
Directory containing the `ESBTL/default.h` file

7
Documentation/doc/Preliminaries.txt
View File

@ -139,13 +139,14 @@ to force its definition on the command line, and it is possible to prevent its d
definition by setting `CGAL_HAS_NO_THREADS` from the command line.
\section Preliminaries_cc0x C++0x Support
\section Preliminaries_cc0x \cpp11 Support
\cgal is based on the \CC standard released in 1998 (and later refined in 2003).
A new major version of this standard is being prepared, and is refered to as C++0x.
A new major version of this standard has been released, and is refered to as \cpp11.
Some compilers and standard library implementations already provide some of the
functionality of this new standard, as a preview. For example, \gcc provides
a command-line switch `-std=c++0x` which enables some of those features.
a command-line switch (`-std=c++0x` or or `-std=c++11` depending on the compiler version)
which enables some of those features.
\cgal attempts to support this mode progressively, and already makes use of
some of these features if they are available, although no extensive support has

4
Envelope_3/doc_tex/Envelope_3_ref/EnvelopeTraits_3.tex
View File

@ -134,7 +134,7 @@ Note however, that these operations usually involve the projection of
is in the $x$-range of $c$, and lies to its left when the curve is
traversed from its $xy$-lexicographically smaller endpoint to its
larger endpoint). We have the precondition that both surfaces are
defined "above" $c$, and their relative $z$-order is the same for
defined ``above'' $c$, and their relative $z$-order is the same for
some small enough neighborhood of points above $c$.
\end{itemize}}
@ -150,7 +150,7 @@ Note however, that these operations usually involve the projection of
is in the $x$-range of $c$, and lies to its right when the curve is
traversed from its $xy$-lexicographically smaller endpoint to its
larger endpoint). We have the precondition that both surfaces are
defined "below" $c$, and their relative $z$-order is the same for
defined ``below'' $c$, and their relative $z$-order is the same for
some small enough neighborhood of points below $c$.
\end{itemize}}

108
Generator/doc/Generator/CGAL/Combination_enumerator.h Normal file
View File

@ -0,0 +1,108 @@
namespace CGAL {
/// \addtogroup PkgGenerators
/// @{
/*!
The class `Combination_enumerator` is used to enumerate all fixed-size combinations
(subsets) of a <i>source range</i> of elements. For example, it can
enumerate all the combinations of 2 elements from the source range `[3,7)`
(`7` excluded) which gives the enumeration `{3,4}, {3,5}, {3,6}, {4,5},
{4,6}, {5,6}`. The source range consists of elements of type
`CombinationElement` and is specified by its first element and the element
just beyond its last one.
\tparam CombinationElement should be a model of the concept `CombinationElement`.
Each combination is uniquely represented as an increasing sequence of elements.
Thus, the combinations can be lexicographically ordered. They are enumerated in
that order, so that we can talk about the first or last combination.
*/
template <class CombinationElement>
class Combination_enumerator{
public:
/// \name Creation
/// @{
/*!
This constructor initializes the object to
enumerate the combinations of `k` elements from the source range
`[first, beyond)`. The current combination is set to the first combination
of the enumeration.
\pre `1 <= k <= beyond - first`
*/
Combination_enumerator(int k, const CombinationElement & first, const CombinationElement & beyond);
/*!
The copy constructor.
*/
Combination_enumerator(const Combination_enumerator & combi);
/// @}
/// \name Access to the current combination
/// @{
/*!
Returns the `i`-th element of the current combination.
\pre `0 <= i < number_of_elements()`
*/
const CombinationElement & operator[](int i);
/// @}
/// \name Access to the enumeration
///@{
/*!
Returns the size of the enumerated combinations (the parameter `k` from the class' constructor).
*/
int number_of_elements();
/*!
Returns the smallest element of the source range. (the parameter `first` of the
constructor of the class).
*/
const CombinationElement & min_element();
/*!
Returns the successor to the largest element of the source range (the parameter `beyond` of
the constructor of the class).
*/
const CombinationElement & beyond_element();
/*!
Returns `true` if and only if all combinations have been enumerated.
*/
bool finished();
/// @}
/// /name Operations
/// @{
/*!
Resets the enumerator. The current combination is set to the first one of the enumeration.
*/
void reset();
/*!
Moves *this to the next combination.
*/
void operator++();
/*!
Post-incrementation. Same as the pre-incrementation above, but returns the original value of `*this`.
*/
Combination_enumerator operator++(int);
/// @}
}; /*end of class Combination_enumerator*/
} /* end namespace CGAL */
/// @}

83
Generator/doc/Generator/Concepts/CombinationElement.h Normal file
View File

@ -0,0 +1,83 @@
/*!
\cgalConcept
A CombinationElement can be used as template parameter for the class
`Combination_enumerator<CombinationElement>`.
\cgalHasModel Any integer type (`char`, `short`, `int`, `long`, etc.)
\cgalHasModel Pointers
\cgalHasModel Random access iterators
\sa `Combination_enumerator<CombinationElement>`
*/
class CombinationElement {
public:
/// \name Creation
/// @{
/*!
Copy constructor
*/
CombinationElement(const CombinationElement & e2);
/// @}
/// \name Types
/// @{
/*!
the type of point being generated.
*/
typedef Hidden_type value_type;
/// @}
/// \name Operations
/// @{
/*!
Incrementation
*/
void operator++();
/*!
Decrementation
*/
void operator--();
/*!
Total order comparison
*/
bool operator<(const CombinationElement & e2);
/*!
Equality test
*/
bool operator==(const CombinationElement & e2);
/*!
Equivalent to calling `++(*this)` `i` times if i is positive.
Equivalent to calling `--(*this)` `-i` times if i is negative.
*/
CombinationElement operator+(int i);
/*!
Equivalent to calling ++(*this) `i` times if i is positive.
Equivalent to calling --(*this) `-i` times if i is negative.
*/
int operator-(const CombinationElement & e2);
/// @}
}; /* end CombinationElement */

31
Generator/doc/Generator/Generator.txt
View File

@ -80,6 +80,11 @@ The function `random_selection()` chooses `n` items at random from a random
access iterator range which is useful to produce degenerate input data
sets with multiple entries of identical items.
The class `Combination_enumerator<CombinationElement>` is used to enumerate
all fixed-size combinations (subsets) of a range of elements. It is useful
in the context of high-dimensional triangulations, e.g., for enumerating the
faces of a simplex.
\section GeneratorExample_1 Example Generating Degenerate Point Sets
We want to generate a test set of 1000 points, where 60% are chosen
@ -200,6 +205,32 @@ Generating 20 grid points in 4D
\image html hypergrid.gif
\section GeneratorExGenCombi Example Generating Combinations
\subsection GeneratorFromRangeInt From a Range of Integers
The following example enumerates and outputs all subsets of 3 elements from the
range \f$ [10, 15]\f$. Accordingly, it outputs \f$ \frac{6!}{3! 3!}=20\f$
triples.
\cgalExample{Generator/combination_enumerator.cpp}
The output of this example is:
\verbatim
Taking 3 distinct integers in the range [10, 15]: {10 11 12} {10 11 13} {10 11 14}
{10 11 15} {10 12 13} {10 12 14} {10 12 15} {10 13 14} {10 13 15} {10 14 15}
{11 12 13} {11 12 14} {11 12 15} {11 13 14} {11 13 15} {11 14 15} {12 13 14}
{12 13 15} {12 14 15} {13 14 15}
Enumerated 20 combinations.
\endverbatim
\subsection GeneratorFromArrayStr From an Array of Strings
The following example generates all pairs of names from a set of names stored
in an array of strings.
\cgalExample{Generator/name_pairs.cpp}
\section GeneratorDesign Design and Implementation History
Lutz Kettner coded generators in 2D and 3D

2
Generator/doc_tex/Generator/generators.tex
View File

@ -280,7 +280,7 @@ generated points have the same last coordinate $-5$.
\ccIncludeExampleCode{Generator/grid_d.cpp}
The output of previous example corresponds to the points of this
figure depicted in red or pink (pink points are "inside" the cube).
figure depicted in red or pink (pink points are ``inside'' the cube).
The output is:
\begin{verbatim}
Generating 20 grid points in 4D

4
Generator/doc_tex/Generator_ref/Points_on_segment_2_functor.tex
View File

@ -36,10 +36,10 @@ spaced
segment defined by $p$ and $q$. Values of the index parameter $i$ larger
than 0 indicate starting points for the sequence further from $p$.
Point $p$ has index value 0 and $q$ has index value $n-1$.
\ccRequire{ The expressions \ccc{to_double(p.x())} and
\ccRequire The expressions \ccc{to_double(p.x())} and
\ccc{to_double(p.y())} must result in the respective
\ccc{double} representation of the coordinates of $p$, and similarly
for $q$.}}
for $q$.}
\ccOperations

4
Generator/doc_tex/Generator_ref/Random_points_on_segment_2.tex
View File

@ -35,10 +35,10 @@ InputIterator \\
distributed on the segment from $p$ to $q$ (excluding $q$),
i.e.~$\ccc{*g} == (1-\lambda)\, p + \lambda q$ where $0 \le \lambda < 1$~.
A single random number is needed from \ccc{rnd} for each point.
\ccRequire{ The expressions \ccc{to_double(p.x())} and
\ccRequire The expressions \ccc{to_double(p.x())} and
\ccc{to_double(p.y())} must result in the respective
\ccc{double} representation of the coordinates of $p$,
and similarly for $q$.}}
and similarly for $q$.}
\ccSeeAlso

2
Generator/doc_tex/Generator_ref/random_convex_set.tex
View File

@ -33,7 +33,7 @@ computes a random convex \ccc{n}-gon by writing its vertices (oriented
counterclockwise) to \ccc{o}. The resulting polygon is scaled such
that it fits into the bounding box as specified by \ccc{pg}. Therefore
we cannot easily describe the resulting distribution.
\ccPrecond{$n \ge 3$.}
\ccPrecond $n \ge 3$.
}
\ccHeading{Requirements}

2
Generator/doc_tex/Generator_ref/random_polygon.tex
View File

@ -49,7 +49,7 @@ The default traits class \ccc{Default_traits} is the kernel in which
\ccImplementation
The implementation is based on the method of eliminating self-intersections in
a polygon by using so-called "2-opt" moves. Such a move eliminates an
a polygon by using so-called ``2-opt'' moves. Such a move eliminates an
intersection between two edges by reversing the order of the vertices between
the edges. No more than $O(n^3)$ such moves are required to simplify a polygon
defined on $n$ points \cite{ls-utstp-82}.

4
Generator/doc_tex/Generator_ref/random_selection.tex
View File

@ -19,8 +19,8 @@ sets with multiple entries of identical items.
\ccc{result}.
A single random number is needed from \ccc{rnd} for each item.
Returns the value of \ccc{result} after inserting the $n$ items.
\ccPrecond{\ccc{Random} is a random number generator type as provided
by the STL or by \ccc{Random}.}
\ccPrecond \ccc{Random} is a random number generator type as provided
by the STL or by \ccc{Random}.
}
\ccSeeAlso

2
Geomview/doc_tex/Geomview_ref/Geomview_stream.tex
View File

@ -247,7 +247,7 @@ from Geomview and to read data sent back by Geomview.
\ccMethod{Geomview_stream& operator>>(char* s);}
{Extracts a string \ccc{s} from the stream.
\ccPrecond{You have to allocate enough memory.}}
\ccPrecond You have to allocate enough memory.}
\ccMethod{Geomview_stream& operator<<(int i);}
{Inserts \ccc{i} into the stream. Puts whitespace around if the

22
GraphicsView/doc/GraphicsView/GraphicsView.txt
View File

@ -8,17 +8,17 @@ namespace CGAL {
\cgalAutoToc
\authors Andreas Fabri and Laurent Rineau
<A HREF="http://qt.nokia.com/">Qt</A> is a <span class="textsc">Gui</span> toolkit for
<A HREF="http://qt.digia.com/">Qt</A> is a <span class="textsc">Gui</span> toolkit for
cross-platform application development.
\section GraphicsViewIntroduction Introduction
This chapter describes classes that help to visualize two dimensional \cgal objects
with the <A HREF="http://doc.qt.nokia.com/latest/graphicsview.html">Qt Graphics View Framework</A>.
with the <A HREF="http://doc.qt.digia.com/latest/graphicsview.html">Qt Graphics View Framework</A>.
This framework uses the model view paradigm. <A HREF="http://doc.qt.nokia.com/latest/qgraphicsitem.html">`QGraphicsItem`</A>s are stored in a
<A HREF="http://doc.qt.nokia.com/latest/qgraphicsscene.html">`QGraphicsScene`</A>
and are displayed in a <A HREF="http://doc.qt.nokia.com/latest/qgraphicsview.html">`QGraphicsView`</A>. The items
This framework uses the model view paradigm. <A HREF="http://doc.qt.digia.com/latest/qgraphicsitem.html">`QGraphicsItem`</A>s are stored in a
<A HREF="http://doc.qt.digia.com/latest/qgraphicsscene.html">`QGraphicsScene`</A>
and are displayed in a <A HREF="http://doc.qt.digia.com/latest/qgraphicsview.html">`QGraphicsView`</A>. The items
have a paint method which is called when an item is in the visible area of a view.
The framework is also responsible for dispatching events from the view
via the scene to the items. The framework is extensible in the sense
@ -50,14 +50,14 @@ classes that have to override member functions adhering to this naming scheme.
\section GraphicsViewOverall Overall Design
In \cgalFigureRef{graphicsviewuml} you see four classes depicted in grey,
that come from the Qt Graphics View Framework. The <A HREF="http://doc.qt.nokia.com/latest/qgraphicsscene.html">`QGraphicsScene`</A>
contains <A HREF="http://doc.qt.nokia.com/latest/qgraphicsitem.html">`QGraphicsItem`</A>s, which get displayed in any number
of <A HREF="http://doc.qt.nokia.com/latest/qgraphicsview.html">`QGraphicsView`</A>s. The views are widgets, that is they take screen space
that come from the Qt Graphics View Framework. The <A HREF="http://doc.qt.digia.com/latest/qgraphicsscene.html">`QGraphicsScene`</A>
contains <A HREF="http://doc.qt.digia.com/latest/qgraphicsitem.html">`QGraphicsItem`</A>s, which get displayed in any number
of <A HREF="http://doc.qt.digia.com/latest/qgraphicsview.html">`QGraphicsView`</A>s. The views are widgets, that is they take screen space
in an application.
The fourth class is the <A HREF="http://doc.qt.nokia.com/latest/qobject.html">`QObject`</A>. It plays an important role in Qt for
event handling and memory management. First, it allows to add <A HREF="http://doc.qt.nokia.com/latest/signalsandslots.html">signals and
slots</A>, and to connect them. Second, it allows to install <A HREF="http://doc.qt.nokia.com/latest/eventsandfilters.html">event filters</A>.
The fourth class is the <A HREF="http://doc.qt.digia.com/latest/qobject.html">`QObject`</A>. It plays an important role in Qt for
event handling and memory management. First, it allows to add <A HREF="http://doc.qt.digia.com/latest/signalsandslots.html">signals and
slots</A>, and to connect them. Second, it allows to install <A HREF="http://doc.qt.digia.com/latest/eventsandfilters.html">event filters</A>.
\cgalFigureBegin{graphicsviewuml,uml-design.png}
UML Class Diagram with the Qt classes (blue), CGAL classes for using the framework (yellow), CGAL data structures (red), and application classes (green).

4
GraphicsView/doc/GraphicsView/PackageDescription.txt
View File

@ -8,7 +8,7 @@
\cgalPkgPicture{detail.png}
\cgalPkgSummaryBegin
\cgalPkgAuthors{Andreas Fabri and Laurent Rineau}
\cgalPkgDesc{This package provides classes for displaying \cgal objects and data structures in the <A HREF="http://doc.qt.nokia.com/latest/graphicsview.html">Qt 4 Graphics View Framework</A>.}
\cgalPkgDesc{This package provides classes for displaying \cgal objects and data structures in the <A HREF="http://doc.qt.digia.com/latest/graphicsview.html">Qt 4 Graphics View Framework</A>.}
\cgalPkgManuals{Chapter_CGAL_and_the_Qt_Graphics_View_Framework,PkgGraphicsView}
\cgalPkgSummaryEnd
\cgalPkgShortInfoBegin
@ -21,7 +21,7 @@
This package provides some classes which allow to use \cgal classes in
<I>Qt</I> applications which make use of the <A
HREF="http://doc.qt.nokia.com/latest/graphicsview.html">Qt Graphics
HREF="http://doc.qt.digia.com/latest/graphicsview.html">Qt Graphics
View Framework</A>.
*/

22
HalfedgeDS/doc_tex/HalfedgeDS_ref/HalfedgeDS.tex
View File

@ -266,18 +266,18 @@ arises.
\ccTagDefaults
\ccConstructor{HalfedgeDS( const HalfedgeDS<Traits,Items,Alloc>& hds2);}
{copy constructor. \ccPrecond{\ccc{hds2} contains no dangling handles.}}
{copy constructor. \ccPrecond \ccc{hds2} contains no dangling handles.}
\ccMethod{HalfedgeDS<Traits,Items,Alloc>&
operator=( const HalfedgeDS<Traits,Items,Alloc>& hds2);}
{assignment operator. \ccPrecond{\ccc{hds2} contains no dangling handles.}}
{assignment operator. \ccPrecond \ccc{hds2} contains no dangling handles.}
\ccMethod{void reserve( size_type v, size_type h, size_type f);}
{reserves storage for $v$ vertices, $h$ halfedges, and $f$ faces.
If all capacities are already greater or equal than the requested sizes
nothing happens. Otherwise, \ccVar\ will be resized and all handles,
iterators and circulators invalidate. \ccPrecond{If resizing is
necessary \ccVar\ contains no dangling handles.}}
iterators and circulators invalidate. \ccPrecond If resizing is
necessary \ccVar\ contains no dangling handles.}
% +-----------------------------------+
@ -336,7 +336,7 @@ faces respectively.
\ccMethod{Halfedge_handle edges_push_back( const Halfedge& h);}
{appends a copy of $h$ and a copy of $h->opposite()$ to \ccc{hds} and
makes them opposite to each other. Returns a handle of the copy of $h$.
\ccPrecond{\ccc{h->opposite()} denotes a halfedge.}}
\ccPrecond \ccc{h->opposite()} denotes a halfedge.}
\ccMethod{Face_handle faces_push_back( const Face& f);}
{appends a copy of $f$ to \ccc{hds}. Returns a handle of the new face.}
@ -445,17 +445,17 @@ a halfedge. There is no automatic update required.
\ccMethod{Size size_of_border_halfedges() const;}
{number of border halfedges. An edge with no incident face
counts as two border halfedges.
\ccPrecond{\ccc{normalize_border()} has been called and no
\ccPrecond \ccc{normalize_border()} has been called and no
halfedge insertion or removal and no change in border
status of the halfedges have occurred since then.}}
status of the halfedges have occurred since then.}
\ccMethod{Size size_of_border_edges() const;}
{number of border edges. If \ccc{size_of_border_edges()} is equal
to \ccc{size_of_border_halfedges()} all border edges are incident to
a face on one side and to an open region on the other side.
\ccPrecond{\ccc{normalize_border()} has been called and no
\ccPrecond \ccc{normalize_border()} has been called and no
halfedge insertion or removal and no change in border
status of the halfedges have occurred since then.}}
status of the halfedges have occurred since then.}
\ccMethod{Halfedge_iterator border_halfedges_begin();}
{halfedge iterator starting with the border edges. The range
@ -463,9 +463,9 @@ a halfedge. There is no automatic update required.
all non-border edges. The range
[\ccStyle{border_halfedges_begin(), halfedges_end()}) denotes all
border edges.
\ccPrecond{\ccc{normalize_border()} has been called and no
\ccPrecond \ccc{normalize_border()} has been called and no
halfedge insertion or removal and no change in border
status of the halfedges have occurred since then.}}
status of the halfedges have occurred since then.}
\vspace*{-4mm}
\end{ccAdvanced}

36
HalfedgeDS/doc_tex/HalfedgeDS_ref/HalfedgeDS_decorator.tex
View File

@ -130,14 +130,14 @@ incidence relations except if mentioned otherwise.
halfedge data structure if they were already border edges. If this
creates isolated vertices they get removed as well. See
\ccc{make_hole(h)} for a more specialized variant.
\ccPrecond{\ccc{h->is_border() == false}.}
\ccPrecond \ccc{h->is_border() == false}.
\ccCommentHeading{Requirement} If faces are supported,
\ccc{Supports_removal} $\equiv$ \ccc{CGAL::Tag_true}.}
\ccMethod{void erase_connected_component( Halfedge_handle h);}
{removes the vertices, halfedges, and faces that belong to the
connected component of $h$. \ccPrecond{For all halfedges $g$ in the
connected component \ccc{g.next() != Halfedge_handle()}.}
connected component of $h$. \ccPrecond For all halfedges $g$ in the
connected component \ccc{g.next() != Halfedge_handle()}.
\ccCommentHeading{Requirement} \ccc{Supports_removal} $\equiv$
\ccc{CGAL::Tag_true}.}
@ -154,19 +154,19 @@ incidence relations except if mentioned otherwise.
\ccMethod{void make_hole( Halfedge_handle h);}
{removes the face incident to \ccc{h} from \ccc{hds} and creates a hole.
\ccPrecond{\ccc{h != Halfedge_handle()} and \ccc{!(h->is_border())}.}
\ccPrecond \ccc{h != Halfedge_handle()} and \ccc{!(h->is_border())}.
\ccCommentHeading{Requirement} If faces are supported,
\ccc{Supports_removal} $\equiv$ \ccc{CGAL::Tag_true}.}
\ccMethod{Halfedge_handle fill_hole( Halfedge_handle h);}
{fills the hole incident to \ccc{h} with a new face from \ccc{hds}.
Returns \ccc{h}.
\ccPrecond{\ccc{h != Halfedge_handle()} and \ccc{h->is_border()}.}}
\ccPrecond \ccc{h != Halfedge_handle()} and \ccc{h->is_border()}.}
\ccMethod{Halfedge_handle fill_hole( Halfedge_handle h, const Face& f);}
{fills the hole incident to \ccc{h} with a copy of face $f$.
Returns \ccc{h}.
\ccPrecond{\ccc{h != Halfedge_handle()} and \ccc{h->is_border()}.}}
\ccPrecond \ccc{h != Halfedge_handle()} and \ccc{h->is_border()}.}
\ccMethod{Halfedge_handle add_face_to_border( Halfedge_handle h,
Halfedge_handle g);}
@ -175,9 +175,9 @@ incidence relations except if mentioned otherwise.
denoted by $g$ with the vertex denoted by $h$ and fills this separated
part of the hole with a new face, such that the new face is incident
to $g$. Returns the new halfedge that is incident to the new face.
\ccPrecond{\ccc{h != Halfedge_handle()}, \ccc{g != Halfedge_handle()},
\ccPrecond \ccc{h != Halfedge_handle()}, \ccc{g != Halfedge_handle()},
\ccc{h->is_border()}, \ccc{g->is_border()} and $g$ can be reached
along the hole starting with $h$.}}
along the hole starting with $h$.}
\ccMethod{Halfedge_handle add_face_to_border( Halfedge_handle h,
Halfedge_handle g,
@ -187,9 +187,9 @@ incidence relations except if mentioned otherwise.
$g$ with the tip of $h$ and fills this separated part of the hole with a
copy of face $f$, such that the new face is incident to $g$. Returns
the new halfedge that is incident to the new face.
\ccPrecond{\ccc{h != Halfedge_handle()}, \ccc{g != Halfedge_handle()},
\ccPrecond \ccc{h != Halfedge_handle()}, \ccc{g != Halfedge_handle()},
\ccc{h->is_border()}, \ccc{g->is_border()} and $g$ can be reached
along the hole starting with $h$.}}
along the hole starting with $h$.}
% -----------------------------------------
\ccHeading{Modifying Functions (Euler Operators)}
@ -293,7 +293,7 @@ the halfedge \ccc{h->next} with a new face in-between.
are copies of this face. Returns the halfedge \ccc{h->next()}
after the operation, i.e., a halfedge pointing to the new vertex.
The time is proportional to the size of the face.
\ccPrecond{\ccc{h} is not a border halfedge.}}
\ccPrecond \ccc{h} is not a border halfedge.}
\ccMethod{Halfedge_handle erase_center_vertex( Halfedge_handle g);}
{reverses \ccc{create_center_vertex}. Erases the
@ -304,12 +304,12 @@ the halfedge \ccc{h->next} with a new face in-between.
Thus, the invariant \ccc{h == erase_center_vertex(
create_center_vertex(h))} holds if \ccc{h} is not a border halfedge.
The time is proportional to the sum of the size of all incident faces.
\ccPrecond{None of the incident faces of \ccc{g->vertex()} is
\ccPrecond None of the incident faces of \ccc{g->vertex()} is
a hole. There are at least two distinct faces incident
to the faces that are incident to \ccc{g->vertex()}. (This
prevents the operation from collapsing a volume into two faces
glued together with opposite orientations, such as would
happen with any vertex of a tetrahedron.)}
happen with any vertex of a tetrahedron.)
\ccCommentHeading{Requirement} \ccc{Supports_removal} $\equiv$
\ccc{CGAL::Tag_true}.}
@ -339,10 +339,10 @@ the halfedge \ccc{h->next} with a new face in-between.
triangles are created. $h,i,j$ will be incident to the first new triangle.
The return value will be the halfedge incident to the second new triangle
which is the copy of \ccc{h-opposite()}.
\ccPrecond{$h,i,j$ denote distinct, consecutive vertices of the
\ccPrecond $h,i,j$ denote distinct, consecutive vertices of the
halfedge data structure and form a cycle: i.e., \ccc{h->vertex() ==
i->opposite()->vertex()}, \ldots, \ccc{j->vertex() ==
h->opposite()->vertex()}.}}
h->opposite()->vertex()}.}
\ccMethod{Halfedge_handle join_loop( Halfedge_handle h, Halfedge_handle g);}
{glues the boundary of the two faces denoted by $h$ and $g$ together
@ -350,8 +350,8 @@ the halfedge \ccc{h->next} with a new face in-between.
by $g$ gets removed. Both faces may be holes. The invariant
\ccc{join_loop( h, split_loop( h, i, j))} returns $h$ and keeps the
data structure unchanged.
\ccPrecond{The faces denoted by $h$ and $g$ are different and have
equal degree (i.e., number of edges).}
\ccPrecond The faces denoted by $h$ and $g$ are different and have
equal degree (i.e., number of edges).
\ccCommentHeading{Requirement} \ccc{Supports_removal} $\equiv$
\ccc{CGAL::Tag_true}.}
@ -374,7 +374,7 @@ These operations are the same as for
\ccHeading{Miscellaneous}
\ccMethod{void inside_out();}
{reverses face orientations. \ccPrecond{\ccc{is_valid()} of level three.}}
{reverses face orientations. \ccPrecond \ccc{is_valid()} of level three.}
% -----------------------------------------

8
HalfedgeDS/doc_tex/HalfedgeDS_ref/HalfedgeDS_items_decorator.tex
View File

@ -163,18 +163,18 @@ Corresponding member functions for \ccc{const_handle}'s are provided as well.
\ccMethod{void set_vertex_in_vertex_loop( Halfedge_handle h,
Vertex_handle v) const;}
{loops around the vertex incident to $h$ and sets all vertex
pointers to $v$. \ccPrecond{\ccc{h != Halfedge_handle()}.}}
pointers to $v$. \ccPrecond \ccc{h != Halfedge_handle()}.}
\vspace*{-1mm}
\ccMethod{void set_face_in_face_loop( Halfedge_handle h, Face_handle f) const;}
{loops around the face incident to $h$ and sets all face
pointers to $f$. \ccPrecond{\ccc{h != Halfedge_handle()}.}}
pointers to $f$. \ccPrecond \ccc{h != Halfedge_handle()}.}
\ccMethod{Halfedge_handle flip_edge( Halfedge_handle h) const;}
{performs an edge flip. It returns $h$ after rotating the edge $h$ one
vertex in the direction of the face orientation.
\ccPrecond{\ccc{h != Halfedge_handle()} and both incident faces
of $h$ are triangles.}}
\ccPrecond \ccc{h != Halfedge_handle()} and both incident faces
of $h$ are triangles.}
% -----------------------------------------
\vspace*{-2mm}

12
HalfedgeDS/doc_tex/HalfedgeDS_ref/HalfedgeDS_list.tex
View File

@ -50,27 +50,27 @@ additionally:
{inserts elements in the range [\ccc{first, last}) before position
\ccc{target} and removes the elements from \ccc{source}. It takes
constant time if \ccc{&source == &}\ccVar; otherwise, it takes linear
time in the size of the range. \ccPrecond{[\ccc{first, last}) is a
time in the size of the range. \ccPrecond [\ccc{first, last}) is a
valid range in \ccc{source}. \ccc{target} is not in the range
[\ccc{first, last}).}}
[\ccc{first, last}).}
\ccMethod{void halfedges_splice( Halfedge_iterator target, Self &source,
Halfedge_iterator first, Halfedge_iterator last);}
{inserts elements in the range [\ccc{first, last}) before position
\ccc{target} and removes the elements from \ccc{source}. It takes
constant time if \ccc{&source == &}\ccVar; otherwise, it takes linear
time in the size of the range. \ccPrecond{[\ccc{first, last}) is a
time in the size of the range. \ccPrecond [\ccc{first, last}) is a
valid range in \ccc{source}. \ccc{target} is not in the range
[\ccc{first, last}).}}
[\ccc{first, last}).}
\ccMethod{void faces_splice( Face_iterator target, Self &source,
Face_iterator first, Face_iterator last);}
{inserts elements in the range [\ccc{first, last}) before position
\ccc{target} and removes the elements from \ccc{source}. It takes
constant time if \ccc{&source == &}\ccVar; otherwise, it takes linear
time in the size of the range. \ccPrecond{[\ccc{first, last}) is a
time in the size of the range. \ccPrecond [\ccc{first, last}) is a
valid range in \ccc{source}. \ccc{target} is not in the range
[\ccc{first, last}).}}
[\ccc{first, last}).}

4
Installation/doc_tex/Installation/installation.tex
View File

@ -215,7 +215,7 @@ In order to build the \cgal\ libraries, you need a \CC\ compiler.
\section{Configuring \cgal\ with CMake\label{sec:configwithcmake}}
In order to configure, build, and install the \cgal\ libraries, examples and
demos, you need \cmake, a cross-platform "makefile generator".
demos, you need \cmake, a cross-platform ``makefile generator''.
If \cmake\ is not installed already you can obtain it from \cmakepage.
\cmake\ version~2.6.2 or higher is required. On Windows, \cmake{}
version~2.8.6 or higher is required, for a proper support of DLL's
@ -820,7 +820,7 @@ make install # install
}
If you use a generator that produces IDE files (for Visual Studio for instance) there will be an optional
\texttt{INSTALL} project, which you will be able to \emph{"build"} to execute the installation step.
\texttt{INSTALL} project, which you will be able to \emph{``build''} to execute the installation step.
\begin{ccAdvanced}

2
Interpolation/doc_tex/Interpolation/coordinates.tex
View File

@ -6,7 +6,7 @@ a set of data points $\mathcal{P}$, the natural neighbor coordinates
associated to $\mathcal{P}$ are defined from the Voronoi diagram of
$\mathcal{P}$. When simulating the insertion of a query point
$\mathbf{x}$ into the Voronoi diagram of $\mathcal{P}$, the potential
Voronoi cell of $\mathbf{x}$ "steals" some parts from the existing
Voronoi cell of $\mathbf{x}$ ``steals'' some parts from the existing
cells.
\begin{figure}[ht!]

12
Interval_skip_list/doc_tex/Interval_skip_list_ref/Interval_skip_list.tex
View File

@ -71,8 +71,8 @@ allows to find all members of a set of intervals that overlap a point.
InputIterator first,
InputIterator last);}
{Constructor that inserts the iterator range \ccc{[first, last)} in the interval skip list.
\ccPrecond{The \ccc{value_type} of \ccc{first} and
\ccc{last} is \ccc{Interval}.}}
\ccPrecond The \ccc{value_type} of \ccc{first} and
\ccc{last} is \ccc{Interval}.}
\ccOperations
@ -82,8 +82,8 @@ allows to find all members of a set of intervals that overlap a point.
InputIterator last);}
{Inserts the iterator range \ccc{[first, last)} in the interval skip list, and returns
the number of inserted intervals.
\ccPrecond{The \ccc{value_type} of \ccc{first} and
\ccc{last} is \ccc{Interval}.}}
\ccPrecond The \ccc{value_type} of \ccc{first} and
\ccc{last} is \ccc{Interval}.}
@ -102,7 +102,7 @@ the number of inserted intervals.
OutputIterator out);}
{Writes the intervals \ccc{i} with \ccc{i.inf()} $\leq$ \ccc{v} $\leq$ \ccc{i.sup} to the
output iterator \ccc{out}.
\ccPrecond{The \ccc{value_type} of \ccc{out} is \ccc{Interval}.}}
\ccPrecond The \ccc{value_type} of \ccc{out} is \ccc{Interval}.}
\ccMethod{void
@ -124,7 +124,7 @@ output iterator \ccc{out}.
\ccFunction{ostream& operator<<(ostream& os,
const Interval_skip_list<Interval>& isl);}
{Inserts the interval skip list \ccc{isl} into the stream \ccc{os}.
\ccPrecond{The output operator must be defined for \ccc{Interval}.}}
\ccPrecond The output operator must be defined for \ccc{Interval}.}
\ccImplementation

2
Interval_skip_list/doc_tex/Interval_skip_list_ref/Interval_skip_list_interval.tex
View File

@ -85,7 +85,7 @@ The output operator is defined for \ccc{std::ostream}.
\ccFunction{ostream& operator<<(ostream& os,
const Interval_skip_list_interval<V>& i);}
{Inserts the interval \ccc{i} into the stream \ccc{os}.\\
\ccPrecond{The output operator for \ccc{Value} is defined.}}
\ccPrecond The output operator for \ccc{Value} is defined.}
\ccIsModel

2
Interval_skip_list/doc_tex/Interval_skip_list_ref/Level_interval.tex
View File

@ -88,7 +88,7 @@ stored in the vertices of the face \ccc{fh} points to.}
\ccFunction{ostream& operator<<(ostream& os,
const Level_interval<FaceHandle>& i);}
{Inserts the interval \ccc{i} into the stream \ccc{os}.
\ccPrecond{The output operator for \ccc{*Face_handle} is defined.}}
\ccPrecond The output operator for \ccc{*Face_handle} is defined.}
\ccIsModel
\ccc{Interval}

5
Jet_fitting_3/doc/Jet_fitting_3/CGAL/Monge_via_jet_fitting.h
View File

@ -12,9 +12,8 @@ The results are stored in an instance of the nested class `Monge_form`,
the particular information returned depending on the degrees specified
for the polynomial fitting and for the Monge form.
The default for the template `LocalKernel` is
`Cartesian<double>` and the default for `SvdTraits` is `Eigen_svd` if `CGAL_EIGEN3_ENABLED`
is defined.
If `CGAL_EIGEN3_ENABLED` is defined, `LocalKernel` and `SvdTraits`
template parameters have defaults, `Cartesian<double>` and `Eigen_svd` respectively.
\tparam DataKernel provides the geometric classes and tools
corresponding to the input points, and also members of the

6
Jet_fitting_3/doc_tex/Jet_fitting_3_ref/Monge_via_jet_fitting.tex
View File

@ -69,15 +69,15 @@ algebra algorithm required by the fitting method.
given by the \ccc{InputIterator} parameters which value-type are
\ccc{Data_kernel::Point_3}, \ccc{d} is the degree of the fitted
polynomial, \ccc{d'} is the degree of the expected Monge
coefficients. \ccPrecond{$N \geq N_{d}:=(d+1)(d+2)/2$, $1 \leq d'
\leq \min(d,4) $.} }
coefficients. \ccPrecond $N \geq N_{d}:=(d+1)(d+2)/2$, $1 \leq d'
\leq \min(d,4) $. }
\ccMethod{FT condition_number();}{condition number of the linear fitting system.}
\ccGlue
\ccMethod{std::pair<FT, Vector_3> pca_basis(size_t i);}
{pca eigenvalues and eigenvectors, the pca\_basis has always 3 such pairs.
\ccPrecond{$i$ ranges from 0 to 2.}}
Precondition : $i$ ranges from 0 to 2.}
% {\bf NESTED CLASS : Monge\_form}
% \ccDefinition

1
Kernel_23/doc/Kernel_23/CGAL/Projection_traits_xy_3.h
View File

@ -29,6 +29,7 @@ and predicates defined in `K`.
\cgalModels `DelaunayTriangulationTraits_2`
\cgalModels `ConstrainedTriangulationTraits_2`
\cgalModels `ConvexHullTraits_2`
\cgalModels `DelaunayMeshTraits_2`
*/
template< typename K >

Some files were not shown because too many files have changed in this diff Show More