From d282ade623e00c0e0c2b82b53fe43b5562cbf76f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Loriot?= Date: Mon, 5 Aug 2013 18:25:26 +0200 Subject: [PATCH] use \cgalCite instead of \cite using perl -i -pe 's/\\cite\s*{?([a-zA-Z0-9:-]+)}?/\\cgalCite{$1}/g' --- AABB_tree/doc/AABB_tree/aabb_tree.txt | 2 +- .../Algebraic_foundations.txt | 2 +- .../Algebraic_kernel_d/Algebraic_kernel_d.txt | 30 +++++++------- .../CGAL/Algebraic_kernel_d_1.h | 4 +- .../CGAL/Algebraic_kernel_d_2.h | 8 ++-- .../doc/Alpha_shapes_2/Alpha_shapes_2.txt | 6 +-- .../doc/Alpha_shapes_2/PackageDescription.txt | 2 +- .../doc/Alpha_shapes_3/Alpha_shapes_3.txt | 6 +-- .../doc/Alpha_shapes_3/PackageDescription.txt | 2 +- .../Apollonius_graph_2/Apollonius_graph_2.txt | 6 +-- .../CGAL/Apollonius_graph_filtered_traits_2.h | 4 +- .../CGAL/Apollonius_graph_hierarchy_2.h | 2 +- .../CGAL/Apollonius_graph_traits_2.h | 2 +- .../Arrangement_on_surface_2.txt | 18 ++++----- .../CGAL/Arr_trapezoid_ric_point_location.h | 6 +-- .../CGAL/Arrangement_2.h | 2 +- .../doc/Sweep_line_2/Sweep_line_2.txt | 2 +- BGL/doc/BGL/BGL.txt | 2 +- .../graph/graph_traits_Triangulation_2.h | 2 +- .../Boolean_set_operations_2.txt | 2 +- .../CGAL/Approximate_min_ellipsoid_d.h | 2 +- .../doc/Bounding_volumes/CGAL/Min_annulus_d.h | 2 +- .../doc/Bounding_volumes/CGAL/Min_circle_2.h | 4 +- .../doc/Bounding_volumes/CGAL/Min_ellipse_2.h | 6 +-- .../doc/Bounding_volumes/CGAL/Min_sphere_d.h | 4 +- .../CGAL/Min_sphere_of_spheres_d.h | 2 +- .../CGAL/min_quadrilateral_2.h | 6 +-- .../CGAL/rectangular_p_center_2.h | 6 +-- .../Concepts/MinSphereOfSpheresTraits.h | 2 +- .../Box_intersection_d/Box_intersection_d.txt | 14 +++---- .../CGAL/box_intersection_d.h | 6 +-- .../doc/CGAL_ipelets/CGAL_ipelets.txt | 2 +- .../Circular_kernel_2/Circular_kernel_2.txt | 4 +- .../Circular_kernel_3/Circular_kernel_3.txt | 2 +- Circulator/doc/Circulator/Circulator.txt | 2 +- .../doc/Circulator/Concepts/Circulator.h | 2 +- .../Combinatorial_map/Combinatorial_map.txt | 4 +- .../Convex_decomposition_3.txt | 4 +- .../doc/Convex_hull_2/CGAL/ch_akl_toussaint.h | 2 +- .../doc/Convex_hull_2/CGAL/ch_bykat.h | 2 +- .../doc/Convex_hull_2/CGAL/ch_eddy.h | 4 +- .../doc/Convex_hull_2/CGAL/ch_graham_andrew.h | 12 +++--- .../doc/Convex_hull_2/CGAL/ch_jarvis.h | 4 +- .../doc/Convex_hull_2/CGAL/ch_melkman.h | 2 +- .../doc/Convex_hull_2/CGAL/convex_hull_2.h | 8 ++-- .../doc/Convex_hull_2/Convex_hull_2.txt | 12 +++--- .../doc/Convex_hull_3/CGAL/convex_hull_3.h | 2 +- .../CGAL/convex_hull_incremental_3.h | 4 +- .../Convex_hull_3/CGAL/convexity_check_3.h | 2 +- .../doc/Convex_hull_3/Convex_hull_3.txt | 6 +-- .../doc/Convex_hull_d/CGAL/Convex_hull_d.h | 2 +- .../doc/Convex_hull_d/Convex_hull_d.txt | 6 +-- Convex_hull_d/include/CGAL/Convex_hull_d.h | 2 +- .../Developer_manual/Chapter_checks.txt | 4 +- .../Developer_manual/Chapter_code_format.txt | 2 +- .../Chapter_information_sources.txt | 12 +++--- .../Developer_manual/Chapter_intro.txt | 8 ++-- .../Chapter_iterators_and_circulators.txt | 6 +-- .../Developer_manual/Chapter_kernels.txt | 6 +-- .../Chapter_memory_management.txt | 2 +- .../Developer_manual/Chapter_portability.txt | 2 +- .../Chapter_traits_classes.txt | 4 +- Envelope_2/doc/Envelope_2/Envelope_2.txt | 2 +- Envelope_3/doc/Envelope_3/Envelope_3.txt | 2 +- .../doc/Generator/CGAL/random_convex_set_2.h | 2 +- .../doc/Generator/CGAL/random_polygon_2.h | 2 +- .../doc/HalfedgeDS/Concepts/HalfedgeDS.h | 12 +++--- HalfedgeDS/doc/HalfedgeDS/HalfedgeDS.txt | 20 +++++----- .../doc/HalfedgeDS/PackageDescription.txt | 12 +++--- .../CGAL/Largest_empty_iso_rectangle_2.h | 2 +- .../Inscribed_areas/CGAL/extremal_polygon_2.h | 6 +-- .../CGAL/interpolation_functions.h | 2 +- .../CGAL/sibson_gradient_fitting.h | 4 +- .../CGAL/surface_neighbor_coordinates_3.h | 2 +- .../Interpolation/CGAL/surface_neighbors_3.h | 2 +- .../doc/Interpolation/Interpolation.txt | 26 ++++++------ .../doc/Interpolation/PackageDescription.txt | 2 +- .../Interval_skip_list/Interval_skip_list.txt | 4 +- .../Interval_skip_list/PackageDescription.txt | 4 +- .../doc/Jet_fitting_3/Jet_fitting_3.txt | 12 +++--- .../doc/Kernel_23/CGAL/Filtered_kernel.h | 6 +-- Kernel_23/doc/Kernel_23/Kernel_23.txt | 8 ++-- Kernel_d/doc/Kernel_d/Kernel_d.txt | 8 ++-- .../Kinetic_data_structures.txt | 2 +- .../Kinetic_framework/Kinetic_framework.txt | 2 +- .../CGAL/monotone_matrix_search.h | 2 +- .../Matrix_search/CGAL/sorted_matrix_search.h | 2 +- Mesh_2/doc/Mesh_2/Mesh_2.txt | 4 +- Mesh_3/doc/Mesh_3/Mesh_3.txt | 40 +++++++++---------- .../CGAL/Polygon_convex_decomposition_2.h | 6 +-- ...mall_side_angle_bisector_decomposition_2.h | 2 +- .../doc/Minkowski_sum_2/Minkowski_sum_2.txt | 12 +++--- .../doc/Minkowski_sum_3/Minkowski_sum_3.txt | 6 +-- .../doc/Miscellany/CGAL/Unique_hash_map.h | 2 +- Miscellany/doc/Miscellany/Miscellany.txt | 2 +- .../Modular_arithmetic/Modular_arithmetic.txt | 4 +- Nef_3/doc/Nef_3/Nef_3.txt | 10 ++--- .../doc/Number_types/CGAL/CORE_BigFloat.h | 2 +- .../doc/Number_types/CGAL/CORE_BigInt.h | 2 +- .../doc/Number_types/CGAL/CORE_BigRat.h | 2 +- .../doc/Number_types/CGAL/CORE_Expr.h | 2 +- .../doc/Number_types/CGAL/Interval_nt.h | 2 +- .../doc/Number_types/CGAL/leda_bigfloat.h | 2 +- .../doc/Number_types/CGAL/leda_integer.h | 2 +- .../doc/Number_types/CGAL/leda_rational.h | 2 +- .../doc/Number_types/CGAL/leda_real.h | 2 +- .../doc/Number_types/NumberTypeSupport.txt | 8 ++-- .../doc/Partition_2/CGAL/partition_2.h | 8 ++-- .../doc/Partition_2/PackageDescription.txt | 8 ++-- Partition_2/doc/Partition_2/Partition_2.txt | 8 ++-- .../Periodic_2_Delaunay_triangulation_2.h | 2 +- .../CGAL/Periodic_2_triangulation_2.h | 4 +- .../Periodic_2_triangulation_2.txt | 8 ++-- .../Periodic_3_Delaunay_triangulation_3.h | 4 +- .../CGAL/Periodic_3_triangulation_3.h | 4 +- .../Periodic_3_triangulation_3.txt | 8 ++-- Point_set_2/doc/Point_set_2/Point_set_2.txt | 4 +- .../Point_set_processing_3.txt | 4 +- .../Polyhedron/CGAL/IO/Polyhedron_iostream.h | 4 +- Polyhedron/doc/Polyhedron/CGAL/Polyhedron_3.h | 2 +- .../CGAL/Polyhedron_incremental_builder_3.h | 6 +-- .../doc/Polyhedron/PackageDescription.txt | 2 +- Polyhedron/doc/Polyhedron/Polyhedron.txt | 16 ++++---- .../Concepts/PolynomialTraits_d--Resultant.h | 2 +- Polynomial/doc/Polynomial/Polynomial.txt | 2 +- .../CGAL/Polytope_distance_d.h | 2 +- .../CGAL/all_furthest_neighbors_2.h | 2 +- QP_solver/doc/QP_solver/QP_solver.txt | 2 +- Ridges_3/doc/Ridges_3/Ridges_3.txt | 20 +++++----- .../doc/STL_Extension/CGAL/Multiset.h | 8 ++-- .../doc/STL_Extension/STL_Extension.txt | 4 +- .../doc/SearchStructures/SearchStructures.txt | 6 +-- ...Segment_Delaunay_graph_filtered_traits_2.h | 8 ++-- .../CGAL/Segment_Delaunay_graph_hierarchy_2.h | 4 +- .../CGAL/Segment_Delaunay_graph_traits_2.h | 4 +- .../Segment_Delaunay_graph_2.txt | 12 +++--- .../CGAL/make_skin_surface_mesh_3.h | 2 +- .../Skin_surface_3/CGAL/mesh_skin_surface_3.h | 2 +- .../doc/Skin_surface_3/Skin_surface_3.txt | 8 ++-- .../Snap_rounding_2/CGAL/Snap_rounding_2.h | 10 ++--- .../doc/Snap_rounding_2/Snap_rounding_2.txt | 10 ++--- .../Spatial_searching/Spatial_searching.txt | 10 ++--- .../doc/Spatial_sorting/Spatial_sorting.txt | 6 +-- .../CGAL/Straight_skeleton_builder_2.h | 2 +- .../Straight_skeleton_2.txt | 6 +-- .../doc/Stream_lines_2/Stream_lines_2.txt | 6 +-- .../Subdivision_method_3.txt | 8 ++-- .../Concepts/BorderParameterizer_3.h | 2 +- .../Concepts/ParameterizationMesh_3.h | 2 +- .../ParameterizationPatchableMesh_3.h | 2 +- .../Concepts/ParameterizerTraits_3.h | 2 +- .../PackageDescription.txt | 20 +++++----- .../Surface_mesh_parameterization.txt | 24 +++++------ .../Barycentric_mapping_parameterizer_3.h | 2 +- .../CGAL/Discrete_authalic_parameterizer_3.h | 4 +- .../Discrete_conformal_map_parameterizer_3.h | 2 +- .../include/CGAL/LSCM_parameterizer_3.h | 2 +- .../Mean_value_coordinates_parameterizer_3.h | 2 +- .../Concepts/EdgeCollapsableMesh.h | 4 +- .../Surface_mesh_simplification.txt | 16 ++++---- .../doc/Surface_mesher/Surface_mesher.txt | 8 ++-- .../Surface_reconstruction_points_3.txt | 10 ++--- .../CGAL/Poisson_reconstruction_function.h | 2 +- .../CGAL/Delaunay_triangulation_2.h | 2 +- .../CGAL/Triangulation_hierarchy_2.h | 2 +- .../doc/Triangulation_2/Triangulation_2.txt | 6 +-- .../doc/TDS_3/TriangulationDS_3.txt | 4 +- .../CGAL/Delaunay_triangulation_3.h | 4 +- .../Triangulation_3/PackageDescription.txt | 2 +- .../doc/Triangulation_3/Triangulation_3.txt | 32 +++++++-------- .../Voronoi_diagram_2/Voronoi_diagram_2.txt | 2 +- 171 files changed, 479 insertions(+), 479 deletions(-) diff --git a/AABB_tree/doc/AABB_tree/aabb_tree.txt b/AABB_tree/doc/AABB_tree/aabb_tree.txt index 50f14198300..5413fdb7ac3 100644 --- a/AABB_tree/doc/AABB_tree/aabb_tree.txt +++ b/AABB_tree/doc/AABB_tree/aabb_tree.txt @@ -377,7 +377,7 @@ whole set of input primitives. All primitives are then sorted along the longest coordinate axis of this box, and the primitives are separated into two equal size sets. This procedure is applied recursively until an AABB contains a single primitive. The tree is -leafless as presented in `OPCODE` \cite cgal:t-ocdl-05\. An +leafless as presented in `OPCODE` \cgalCite{cgal:t-ocdl-05}\. An intersection query traverses the tree by computing intersection tests only with respect to the AABBs during traversal, and with respect to the input primitives at the end of traversal (in the leafs of the diff --git a/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt b/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt index 273cbb75383..f6275d95704 100644 --- a/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt +++ b/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt @@ -267,7 +267,7 @@ compute the least common multiple of the denominators. The package is part of \cgal since release 3.3. Of course the package is based on the former Number type support of CGAL. This goes back to Stefan Schirra and Andreas Fabri. But on the other hand the package is to a large extend influenced -by the experience with the number type support in Exacus \cite beh-eeeafcs-05, +by the experience with the number type support in Exacus \cgalCite{beh-eeeafcs-05}, which in the main goes back to Lutz Kettner, Susan Hert, Arno Eigenwillig and Michael Hemmer. However, the package abstracts from the pure support for diff --git a/Algebraic_kernel_d/doc/Algebraic_kernel_d/Algebraic_kernel_d.txt b/Algebraic_kernel_d/doc/Algebraic_kernel_d/Algebraic_kernel_d.txt index 48d74af8d75..d62c9ba9462 100644 --- a/Algebraic_kernel_d/doc/Algebraic_kernel_d/Algebraic_kernel_d.txt +++ b/Algebraic_kernel_d/doc/Algebraic_kernel_d/Algebraic_kernel_d.txt @@ -248,22 +248,22 @@ of LEDA and CORE. The `Algebraic_kernel_d_1` represents an algebraic real root by a square free polynomial and an isolating interval that uniquely defines the root. The current method to isolate roots is the Bitstream Descartes -method \cite eigenwillig-phd-08. +method \cgalCite{eigenwillig-phd-08}. The used method to refine the approximation of an algebraic real root is a -slightly modified (filtered) version of the one presented in \cite abbott-qir-06. +slightly modified (filtered) version of the one presented in \cgalCite{abbott-qir-06}. The method has quadratic convergence. `Algebraic_kernel_d_2` is based on an algorithm computing a -geometric-topological analysis of a single curve \cite ekw-fast-07 and of a -pair of curves \cite ek-exact-08. +geometric-topological analysis of a single curve \cgalCite{ekw-fast-07} and of a +pair of curves \cgalCite{ek-exact-08}. The main idea behind both analyses is to compute the critical x-coordinates of curves and curve pairs by projection (resultants), and compute additional information about the critical fibers using subresultants -and Sturm-Habicht sequences \cite grlr-sturm-habicht-98. +and Sturm-Habicht sequences \cgalCite{grlr-sturm-habicht-98}. With that information, the fiber at critical x-coordinates is computed by a variant of the Bitstream Descartes method. -See also \cite kerber-phd-09 for a comprehensive description of +See also \cgalCite{kerber-phd-09} for a comprehensive description of these techniques. Almost all functors in the class that take a `Polynomial_2` object as argument trigger such an analysis as a main computation @@ -286,9 +286,9 @@ time-consuming step, and should be avoided for efficiency reasons if possible. \subsection Algebraic_kernel_dAlgebraicKernelsBasedon Algebraic Kernels Based on RS The package offers two univariate algebraic kernels that are based on -the library RS \cite cgal:r-rs, namely `Algebraic_kernel_rs_gmpz_d_1` +the library RS \cgalCite{cgal:r-rs}, namely `Algebraic_kernel_rs_gmpz_d_1` and `Algebraic_kernel_rs_gmpq_d_1`. As the names indicate, -the kernels are based on the library RS \cite cgal:r-rs and support univariate +the kernels are based on the library RS \cgalCite{cgal:r-rs} and support univariate polynomials over `Gmpz` or `Gmpq`, respectively. In general we encourage to use `Algebraic_kernel_rs_gmpz_d_1` @@ -302,7 +302,7 @@ not always be a major issue, the `Algebraic_kernel_rs_gmpq_d_1` is provided for convenience. The core of both kernels is the implementation of the interval Descartes -algorithm \cite cgal:rz-jcam-04 of the library RS \cite cgal:r-rs, +algorithm \cgalCite{cgal:rz-jcam-04} of the library RS \cgalCite{cgal:r-rs}, which is used to isolate the roots of the polynomial. The RS library restricts its attention to univariate integer polynomials and some substantial gain of efficiency can be made by using a kernel @@ -310,11 +310,11 @@ that does not follow the generic programming paradigm, by avoiding interfaces between layers. Specifically, working with only one number type allows to optimize some polynomial operations as well as memory handling. The implementation of these kernels -make heavy use of the Mpfr \cite cgal:mt-mpfr and Mpfi \cite cgal:r-mpfi +make heavy use of the Mpfr \cgalCite{cgal:mt-mpfr} and Mpfi \cgalCite{cgal:r-mpfi} libraries, and of their \cgal interfaces, `Gmpfr` and `Gmpfi`. The algebraic numbers (roots of the polynomials) are represented in the two RS kernels by a `Gmpfi` interval and a pointer to -the polynomial of which they are roots. See \cite cgal:lpt-wea-09 +the polynomial of which they are roots. See \cgalCite{cgal:lpt-wea-09} for more details on the implementation, tests of these kernels, comparisons with other algebraic kernels and discussions about the efficiency. @@ -358,7 +358,7 @@ were written by Eric Berberich, Michael Hemmer, and Monique Teillaud. The design history of the package is fairly old and several ideas that influenced this package can already be found -in \cite cgal:bhkt-risak-07. Since then, the initial design underwent +in \cgalCite{cgal:bhkt-risak-07}. Since then, the initial design underwent considerable changes. For instance, it was decided that the algebraic numbers should be under the control of the algebraic kernel. On the other hand the initial support for polynomials was extended to a separate @@ -368,7 +368,7 @@ ideas that was brought to them throughout the last years. In particular, they want to thank Menelaos Karavelas and Elias Tsigaridas for their initial contributions. -The two generic models where initially developed as part of the Exacus \cite beh+-eeeafcs-05 project. +The two generic models where initially developed as part of the Exacus \cgalCite{beh}+-eeeafcs-05 project. However, the models are now fully integrated into the \cgal library, since also the relevant layers of Exacus are now part of \cgal. The main authors for `Algebraic_kernel_d_1` and `Algebraic_kernel_d_2` are @@ -376,9 +376,9 @@ Michael Hemmer and Michael Kerber, respectively. Notwithstanding, the authors al contribution of all authors of the Exacus project, particularly the contribution of Arno Eigenwillig, Sebastian Limbach and Pavel Emeliyanenko. -The two univariate kernels that interface the library RS \cite cgal:r-rs were +The two univariate kernels that interface the library RS \cgalCite{cgal:r-rs} were written by Luis Peñaranda and Sylvain Lazard. -Both models interface the library RS \cite cgal:r-rs by Fabrice Rouillier. +Both models interface the library RS \cgalCite{cgal:r-rs} by Fabrice Rouillier. The authors want to thank Fabrice Rouillier and Elias Tsigaridas for strong support and many useful discussions that lead to the integration of RS. diff --git a/Algebraic_kernel_d/doc/Algebraic_kernel_d/CGAL/Algebraic_kernel_d_1.h b/Algebraic_kernel_d/doc/Algebraic_kernel_d/CGAL/Algebraic_kernel_d_1.h index d89652397d5..d03587b18bb 100644 --- a/Algebraic_kernel_d/doc/Algebraic_kernel_d/CGAL/Algebraic_kernel_d_1.h +++ b/Algebraic_kernel_d/doc/Algebraic_kernel_d/CGAL/Algebraic_kernel_d_1.h @@ -24,9 +24,9 @@ See also the documentation of `Sqrt_extension`. \cgalAdvancedEnd The current method to isolate roots is the bitstream Descartes method -presented in \cite eigenwillig-phd-08. The used method to refine the +presented in \cgalCite{eigenwillig-phd-08}. The used method to refine the approximation of an algebraic real root is a slightly modified -(filtered) version of the one presented in \cite abbott-qir-06. The +(filtered) version of the one presented in \cgalCite{abbott-qir-06}. The method has quadratic convergence. \cgalModels `AlgebraicKernel_d_1` diff --git a/Algebraic_kernel_d/doc/Algebraic_kernel_d/CGAL/Algebraic_kernel_d_2.h b/Algebraic_kernel_d/doc/Algebraic_kernel_d/CGAL/Algebraic_kernel_d_2.h index 78b0e054ba0..22ad1ea49a6 100644 --- a/Algebraic_kernel_d/doc/Algebraic_kernel_d/CGAL/Algebraic_kernel_d_2.h +++ b/Algebraic_kernel_d/doc/Algebraic_kernel_d/CGAL/Algebraic_kernel_d_2.h @@ -5,16 +5,16 @@ namespace CGAL { \ingroup PkgAlgebraicKerneldModels This class is based on an algorithm computing a -geometric-topological analysis of a single curve \cite ekw-fast-07 and of a -pair of curves \cite ek-exact-08. +geometric-topological analysis of a single curve \cgalCite{ekw-fast-07} and of a +pair of curves \cgalCite{ek-exact-08}. The main idea behind both analyses is to compute the critical x-coordinates of curves and curve pairs by projection (resultants), and compute additional information about the critical fibers using subresultants -and Sturm-Habicht sequences \cite grlr-sturm-habicht-98. +and Sturm-Habicht sequences \cgalCite{grlr-sturm-habicht-98}. With that information, the fiber at critical x-coordinates is computed by a variant of the Bitstream Descartes method. -See also \cite kerber-phd-09 for a comprehensive description of +See also \cgalCite{kerber-phd-09} for a comprehensive description of these techniques. A point \f$ p\f$ of type `Algebraic_real_2` is represented diff --git a/Alpha_shapes_2/doc/Alpha_shapes_2/Alpha_shapes_2.txt b/Alpha_shapes_2/doc/Alpha_shapes_2/Alpha_shapes_2.txt index 33a1908049d..5c32996e240 100644 --- a/Alpha_shapes_2/doc/Alpha_shapes_2/Alpha_shapes_2.txt +++ b/Alpha_shapes_2/doc/Alpha_shapes_2/Alpha_shapes_2.txt @@ -17,9 +17,9 @@ quite a vague notion and there are probably many possible interpretations, the \f$ \alpha\f$-shape being one of them. Alpha shapes can be used for shape reconstruction from a dense unorganized set of data points. Indeed, an \f$ \alpha\f$-shape is demarcated by a frontier, -which is a linear approximation of the original shape \cite bb-srmua-97t. +which is a linear approximation of the original shape \cgalCite{bb-srmua-97t}. -As mentioned in Edelsbrunner's and Mücke's paper \cite em-tdas-94, +As mentioned in Edelsbrunner's and Mücke's paper \cgalCite{em-tdas-94}, one can intuitively think of an \f$ \alpha\f$-shape as the following. Imagine a huge mass of ice-cream making up the space \f$ \mathbb{R}^3\f$ and containing the points as "hard" chocolate pieces. Using one of @@ -58,7 +58,7 @@ open disk (resp. ball) of radius \f$ \sqrt{\alpha}\f$ through the vertices of th simplex that does not contain any other point of \f$ S\f$, for the metric used in the computation of the underlying triangulation. The corresponding \f$ \alpha\f$-shape is defined as the underlying interior space of the -\f$ \alpha\f$-complex (see \cite em-tdas-94). +\f$ \alpha\f$-complex (see \cgalCite{em-tdas-94}). In general, an \f$ \alpha\f$-complex is a non-connected and non-pure polytope, it means, that one \f$ k\f$-simplex, \f$ 0 \leq k \leq d-1\f$ is not necessary adjacent to diff --git a/Alpha_shapes_2/doc/Alpha_shapes_2/PackageDescription.txt b/Alpha_shapes_2/doc/Alpha_shapes_2/PackageDescription.txt index ac5f95bba0a..36c55e6c59c 100644 --- a/Alpha_shapes_2/doc/Alpha_shapes_2/PackageDescription.txt +++ b/Alpha_shapes_2/doc/Alpha_shapes_2/PackageDescription.txt @@ -22,7 +22,7 @@ \cgalPkgDescriptionEnd This chapter presents a framework for alpha shapes. The description is based on -the articles \cite em-tdas-94, \cite e-was-92. Alpha shapes are +the articles \cgalCite{em-tdas-94}, \cgalCite{e-was-92}. Alpha shapes are the generalization of the convex hull of a point set. Let \f$ S\f$ be a finite set of points in \f$ \mathbb{R}^d\f$, \f$ d = 2,3\f$ and \f$ \alpha\f$ a parameter with \f$ 0 \leq \alpha \leq \infty\f$. For \f$ \alpha = \infty\f$, the \f$ \alpha\f$-shape is the convex hull of \f$ S\f$. As diff --git a/Alpha_shapes_3/doc/Alpha_shapes_3/Alpha_shapes_3.txt b/Alpha_shapes_3/doc/Alpha_shapes_3/Alpha_shapes_3.txt index ba0a98bdf94..76662c17399 100644 --- a/Alpha_shapes_3/doc/Alpha_shapes_3/Alpha_shapes_3.txt +++ b/Alpha_shapes_3/doc/Alpha_shapes_3/Alpha_shapes_3.txt @@ -16,9 +16,9 @@ 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 data points. Indeed, an alpha shape is demarcated by a frontier, -which is a linear approximation of the original shape \cite bb-srmua-97t. +which is a linear approximation of the original shape \cgalCite{bb-srmua-97t}. -As mentioned in Edelsbrunner's and Mücke's paper \cite em-tdas-94, +As mentioned in Edelsbrunner's and Mücke's paper \cgalCite{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 \f$ \mathbb{R}^3\f$ and containing the points as "hard" chocolate pieces. Using one of @@ -63,7 +63,7 @@ an empty circumscribing sphere with squared radius equal or smaller than \f$ \al Here "empty" means that the open sphere do not include any points of \f$ S\f$. The alpha shape is then simply the domain covered by the simplices -of the alpha complex (see \cite em-tdas-94). +of the alpha complex (see \cgalCite{em-tdas-94}). In general, an alpha complex is a disconnected and non-pure complex: This means in particular that the alpha complex may have diff --git a/Alpha_shapes_3/doc/Alpha_shapes_3/PackageDescription.txt b/Alpha_shapes_3/doc/Alpha_shapes_3/PackageDescription.txt index 720428461de..d04ffc7d40b 100644 --- a/Alpha_shapes_3/doc/Alpha_shapes_3/PackageDescription.txt +++ b/Alpha_shapes_3/doc/Alpha_shapes_3/PackageDescription.txt @@ -35,7 +35,7 @@ an empty circumscribing sphere with squared radius equal or smaller than \f$ \a Here "empty" means that the open sphere do not include any points of \f$ S\f$. The alpha shape is then simply the domain covered by the simplices -of the alpha complex (see \cite em-tdas-94). +of the alpha complex (see \cgalCite{em-tdas-94}). In general, an alpha complex is a non-connected and non-pure complex. This means in particular that the alpha complex may have diff --git a/Apollonius_graph_2/doc/Apollonius_graph_2/Apollonius_graph_2.txt b/Apollonius_graph_2/doc/Apollonius_graph_2/Apollonius_graph_2.txt index f6c04754486..8f29331cbfb 100644 --- a/Apollonius_graph_2/doc/Apollonius_graph_2/Apollonius_graph_2.txt +++ b/Apollonius_graph_2/doc/Apollonius_graph_2/Apollonius_graph_2.txt @@ -32,7 +32,7 @@ deletions on line. The corresponding \cgal class is called `Apollonius_graph_2` and will be discussed in more detail in the sequel. The interested reader may want to refer to the paper by Karavelas and Yvinec -\cite cgal:ky-dawvd-02 for the general idea as well as the details of the +\cgalCite{cgal:ky-dawvd-02} for the general idea as well as the details of the algorithm implemented. Before describing the details of the implementation we make a brief @@ -240,7 +240,7 @@ The predicates required for the computation of the Apollonius graph are rather complicated. It is not the purpose of this document to discuss them in detail. The interested reader may refer to the papers by Karavelas and Emiris for the details -\cite cgal:ke-ppawv-02, \cite cgal:ke-rctac-03. However, we would like to give a brief +\cgalCite{cgal:ke-ppawv-02}, \cgalCite{cgal:ke-rctac-03}. However, we would like to give a brief overview of what they compute. There are several predicates needed by this algorithm. We will discuss the most important/complicated ones. It turns out that @@ -414,7 +414,7 @@ manual. The `Apollonius_graph_hierarchy_2` class is nothing but the equivalent of the `Triangulation_hierarchy_2` class, applied to the Apollonius graph. It consists of a series of Apollonius graphs constructed in a manner analogous to the Delaunay -hierarchy by Devillers \cite d-iirdt-98. The class +hierarchy by Devillers \cgalCite{d-iirdt-98}. The class `Apollonius_graph_hierarchy_2` has exactly the same interface and functionality as the `Apollonius_graph_2` diff --git a/Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_filtered_traits_2.h b/Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_filtered_traits_2.h index 8ece98dc24b..8f972d24d33 100644 --- a/Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_filtered_traits_2.h +++ b/Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_filtered_traits_2.h @@ -7,7 +7,7 @@ namespace CGAL { The class `Apollonius_graph_filtered_traits_2` provides a model for the `ApolloniusGraphTraits_2` concept. -The class `Apollonius_graph_filtered_traits_2` uses the filtering technique \cite cgal:bbp-iayed-01 +The class `Apollonius_graph_filtered_traits_2` uses the filtering technique \cgalCite{cgal:bbp-iayed-01} to achieve traits for the `Apollonius_graph_2` class with efficient and exact predicates given an exact kernel `EK` and a filtering kernel `FK`. The geometric @@ -28,7 +28,7 @@ whereas the second one requires the exact evaluation of signs of ring-type expressions, i.e., expressions involving only additions, subtractions and multiplications. The way the predicates are evaluated is discussed in -\cite cgal:ke-ppawv-02, \cite cgal:ke-rctac-03. +\cgalCite{cgal:ke-ppawv-02}, \cgalCite{cgal:ke-rctac-03}. The default values for the template parameters are as follows: `CM = CGAL::Ring_tag`, diff --git a/Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_hierarchy_2.h b/Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_hierarchy_2.h index 073d13ade6e..863167f6e3b 100644 --- a/Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_hierarchy_2.h +++ b/Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_hierarchy_2.h @@ -18,7 +18,7 @@ find the nearest neighbor of \f$ p\f$ as in the `Apollonius_graph_2` class. At every subsequent level \f$ i\f$ we use the nearest neighbor found at level \f$ i+1\f$ to find the nearest neighbor at level \f$ i\f$. This is a variant of the corresponding -hierarchy for points found in \cite d-iirdt-98. +hierarchy for points found in \cgalCite{d-iirdt-98}. The class has two template parameters which have essentially the same meaning as in the `Apollonius_graph_2` class. The first template parameter must be a model of the diff --git a/Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_traits_2.h b/Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_traits_2.h index b351b44498a..bdd1cc2b503 100644 --- a/Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_traits_2.h +++ b/Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_traits_2.h @@ -18,7 +18,7 @@ evaluation of signs of ring-type expressions, i.e., expressions involving only additions, subtractions and multiplications. The default value for `Method_tag` is `CGAL::Ring_tag`. The way the predicates are evaluated is discussed in -\cite cgal:ke-ppawv-02, \cite cgal:ke-rctac-03. +\cgalCite{cgal:ke-ppawv-02}, \cgalCite{cgal:ke-rctac-03}. \cgalModels `ApolloniusGraphTraits_2` diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt index 3934d248e27..847493c246f 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt @@ -15,7 +15,7 @@ Given a set \f$ \cal C\f$ of planar curves, the arrangement one-dimensional and two-dimensional cells, called vertices, edges and faces, respectively induced by the curves in \f$ \cal C\f$. 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., \cgalCite{as-aa-00}, \cgalCite{cgal:h-a-04}. The curves in \f$ \cal C\f$ can intersect each other (a single curve may also be self-intersecting or may be comprised of several disconnected branches) @@ -76,7 +76,7 @@ connected faces. Every face can have several holes contained in its interior (or no holes at all). In addition, every face may contain isolated vertices in its interior. See \cgalFigureRef{arr_figseg_dcel} for an illustration of the various \sc{Dcel} features. For more details -on the \sc{Dcel} data structure see \cite bkos-cgaa-00 Chapter 2. +on the \sc{Dcel} data structure see \cgalCite{bkos-cgaa-00} Chapter 2. \cgalFigureBegin{arr_figseg_dcel,arr_segs.png} An arrangement of interior-disjoint line segments with some of the \sc{Dcel} records that represent it. The unbounded face \f$ f_0\f$ has a single connected component that forms a hole inside it, and this hole is comprised if several faces. The half-edge \f$ e\f$ is directed from its source vertex \f$ v_1\f$ to its target vertex \f$ v_2\f$. This edge, together with its twin \f$ e'\f$, correspond to a line segment that connects the points associated with \f$ v_1\f$ and \f$ v_2\f$ and separates the face \f$ f_1\f$ from \f$ f_2\f$. The predecessor \f$ e_{\rm prev}\f$ and successor \f$ e_{\rm next}\f$ of \f$ e\f$ are part of the chain that form the outer boundary of the face \f$ f_2\f$. The face \f$ f_1\f$ has a more complicated structure as it contains two holes in its interior: One hole consists of two adjacent faces \f$ f_3\f$ and \f$ f_4\f$, while the other hole is comprised of two edges. \f$ f_1\f$ also contains two isolated vertices \f$ u_1\f$ and \f$ u_2\f$ in its interior. @@ -871,7 +871,7 @@ print_point_location Each of the various point-location class templates employs a different algorithm or strategy\cgalFootnote{We use the term strategy -is borrowed from the design-pattern taxonomy \cite cgal:ghjv-dpero-95, Chapter 5.} +is borrowed from the design-pattern taxonomy \cgalCite{cgal:ghjv-dpero-95}, Chapter 5.} for answering queries:
  • `Arr_naive_point_location` employes the @@ -911,8 +911,8 @@ for answering queries: classes included in the 2D Arrangement package are models of this refined concept.
  • `Arr_trapezoid_ric_point_location` implements - Mulmuley's point-location algorithm \cite m-fppa-90; see - also \cite bkos-cgaa-00, Chapter 6. The arrangement faces are + Mulmuley's point-location algorithm \cgalCite{m-fppa-90}; see + also \cgalCite{bkos-cgaa-00}, Chapter 6. The arrangement faces are decomposed into simpler cells each of constant complexity, known as pseudo-trapezoids, and a search structure (a directed acyclic graph) is constructed on top of these cells, facilitating the search @@ -950,7 +950,7 @@ The trapezoidal map RIC algorithm has expected logarithmic query time, while the query time for the landmark strategy may be as large as linear. In practice however, the query times of both strategies are competitive. For a detailed experimental comparison -see \cite hh-eplca-05 +see \cgalCite{hh-eplca-05} Updating the auxiliary data structures of the trapezoidal map RIC algorithm is done very efficiently. On the other hand, updating the @@ -2406,7 +2406,7 @@ maintenance of arrangements of such arcs. Rational functions, and polynomial functions in particular, are not only interesting in their own right, they are also very useful for approximating or interpolating more complicated curves; see, -e.g., [\cite cgal:ptvf-nrcpp-02 Chapter 3. +e.g., [\cgalCite{cgal:ptvf-nrcpp-02} Chapter 3. `Arr_rational_function_traits_2` is a model of the concepts `ArrangementTraits_2`, @@ -2822,7 +2822,7 @@ require auxiliary data-structures (see Section \ref arr_ssecpl), which must be notified on various local changes in the arrangement, in order to keep their data structures up-to-date. The arrangement package offers a mechanism that uses observers -(see \cite cgal:ghjv-dpero-95) that can be +(see \cgalCite{cgal:ghjv-dpero-95}) that can be attached to an arrangement instance and receive notifications about the changes this arrangement goes through. @@ -3038,7 +3038,7 @@ the annual precipitation is between 1000mm and 1500mm. Computing the overlay of two planar arrangement is also useful for supporting Boolean set operations on polygons (or generalized polygons, -see, e.g., \cite cgal:behhms-cbcab-02). +see, e.g., \cgalCite{cgal:behhms-cbcab-02}). The function `overlay (arr_a, arr_b, ovl_arr, ovl_traits)` accepts two input arrangement instances `arr_a` and `arr_b`, and constructs diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_trapezoid_ric_point_location.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_trapezoid_ric_point_location.h index 2056a6211bf..00ad02c72e4 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_trapezoid_ric_point_location.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_trapezoid_ric_point_location.h @@ -7,15 +7,15 @@ namespace CGAL { \anchor arr_reftrap_pl The `Arr_trapezoid_ric_point_location` class implements the incremental randomized algorithm -introduced by Mulmuley \cite m-fppa-90 as presented by -Seidel \cite s-sfira-91 (see also [\cite bkos-cgaa-00 Chapter 6). +introduced by Mulmuley \cgalCite{m-fppa-90} as presented by +Seidel \cgalCite{s-sfira-91} (see also [\cgalCite{bkos-cgaa-00} Chapter 6). It subdivides each arrangement face to pseudo-trapezoidal cells, each of constant complexity, and constructs and maintains a linear-size search structure on top of these cells, such that each query can be answered in \f$ O(\log n)\f$ time, where \f$ n\f$ is the complexity of the arrangement. Constructing the search structures takes \f$ O(n \log n)\f$ expected time -and may require a small number of rebuilds \cite hkh-iiplgtds-12. Therefore +and may require a small number of rebuilds \cgalCite{hkh-iiplgtds-12}. Therefore attaching a trapezoidal point-location object to an existing arrangement may incur some overhead in running times. In addition, the point-location object needs to keep its auxiliary data structures up-to-date as the diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arrangement_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arrangement_2.h index 38bacb7bb42..d5e9f459829 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arrangement_2.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arrangement_2.h @@ -361,7 +361,7 @@ public: The following handles, iterators, and circulators all have respective constant counterparts (for example, in addition to `Vertex_iterator` -the type `Vertex_const_iterator` is also defined). See \cite cgal:ms-strg-96 +the type `Vertex_const_iterator` is also defined). See \cgalCite{cgal:ms-strg-96} for a discussion of constant versus mutable iterator types. The mutable types are assignable to their constant counterparts. `Vertex_iterator`, `Halfedge_iterator`, and diff --git a/Arrangement_on_surface_2/doc/Sweep_line_2/Sweep_line_2.txt b/Arrangement_on_surface_2/doc/Sweep_line_2/Sweep_line_2.txt index c136d7fde91..b13e8e527c6 100644 --- a/Arrangement_on_surface_2/doc/Sweep_line_2/Sweep_line_2.txt +++ b/Arrangement_on_surface_2/doc/Sweep_line_2/Sweep_line_2.txt @@ -19,7 +19,7 @@ the plane, we keep track of the order of curves intersecting it. This order changes at a finite number of event points, such that we only have to calculate the intersection points between two curves when they become contiguous. For more details on the -sweep-line algorithm see, for example, \cite bkos-cgaa-00, Chapter 2. +sweep-line algorithm see, for example, \cgalCite{bkos-cgaa-00}, Chapter 2. This chapter describes three functions implemented using the sweep-line algorithm: given a collection of input curves, compute all intersection points, diff --git a/BGL/doc/BGL/BGL.txt b/BGL/doc/BGL/BGL.txt index 07e339e9e60..688fe55019f 100644 --- a/BGL/doc/BGL/BGL.txt +++ b/BGL/doc/BGL/BGL.txt @@ -15,7 +15,7 @@ faces as edges of the dual graph. As the scope of \cgal is geometry and not graph algorithms, we provide the necessary classes and functions that allow to use the -algorithms of the Boost Graph Library (BGL) \cite cgal:sll-bgl-02 for \cgal data structures. +algorithms of the Boost Graph Library (BGL) \cgalCite{cgal:sll-bgl-02} for \cgal data structures. \section BGLA A Short Introduction to the Boost Graph Library diff --git a/BGL/doc/BGL/CGAL/boost/graph/graph_traits_Triangulation_2.h b/BGL/doc/BGL/CGAL/boost/graph/graph_traits_Triangulation_2.h index 3f9b977b929..21c7c23b6bb 100644 --- a/BGL/doc/BGL/CGAL/boost/graph/graph_traits_Triangulation_2.h +++ b/BGL/doc/BGL/CGAL/boost/graph/graph_traits_Triangulation_2.h @@ -9,7 +9,7 @@ for the 2D triangulation classes. The triangulations of \cgal are all models of the concepts `BidirectionalGraph` and `VertexAndEdgeListGraph` of the Boost Graph -Library \cite cgal:sll-bgl-02. +Library \cgalCite{cgal:sll-bgl-02}. The mapping between vertices and edges of the triangulation and the diff --git a/Boolean_set_operations_2/doc/Boolean_set_operations_2/Boolean_set_operations_2.txt b/Boolean_set_operations_2/doc/Boolean_set_operations_2/Boolean_set_operations_2.txt index 32425c767ec..87c69bb56e4 100644 --- a/Boolean_set_operations_2/doc/Boolean_set_operations_2/Boolean_set_operations_2.txt +++ b/Boolean_set_operations_2/doc/Boolean_set_operations_2/Boolean_set_operations_2.txt @@ -97,7 +97,7 @@ of the boundary.
  • A regularized Boolean set-operation \f$ \mbox{op}^*\f$ can be obtained by first taking the interior of the resultant point set of an ordinary Boolean set-operation \f$ (P\ \mbox{op}\ Q)\f$ and then by taking the -closure \cite cgal:h-sm-04. That is, +closure \cgalCite{cgal:h-sm-04}. That is, \f$ P\ \mbox{op}^*\ Q = \mbox{closure}(\mbox{interior} (P\ \mbox{op}\ Q))\f$. Regularized Boolean set-operations appear in Constructive Solid Geometry (CSG), because regular sets are closed under regularized diff --git a/Bounding_volumes/doc/Bounding_volumes/CGAL/Approximate_min_ellipsoid_d.h b/Bounding_volumes/doc/Bounding_volumes/CGAL/Approximate_min_ellipsoid_d.h index b230e906799..91bee658513 100644 --- a/Bounding_volumes/doc/Bounding_volumes/CGAL/Approximate_min_ellipsoid_d.h +++ b/Bounding_volumes/doc/Bounding_volumes/CGAL/Approximate_min_ellipsoid_d.h @@ -116,7 +116,7 @@ using the \f$ d\f$-dimensional \cgal kernel; the models \cgalHeading{Implementation} We implement Khachyian's algorithm for rounding -polytopes \cite cgal:k-rprnm-96. Internally, we use +polytopes \cgalCite{cgal:k-rprnm-96}. Internally, we use `double`-arithmetic and (initially a single) Cholesky-decomposition. The algorithm's running time is \f$ {\cal O}(nd^2(\epsilon^{-1}+\ln d + \ln\ln(n)))\f$, where \f$ n=|P|\f$ and diff --git a/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_annulus_d.h b/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_annulus_d.h index 6be9ff955af..b3a9ee69bb0 100644 --- a/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_annulus_d.h +++ b/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_annulus_d.h @@ -43,7 +43,7 @@ can be formulated as an optimization problem with linear constraints and a linear objective function. The solution is obtained using our exact -solver for linear and quadratic programs \cite gs-eegqp-00. +solver for linear and quadratic programs \cgalCite{gs-eegqp-00}. The creation time is almost always linear in the number of points. Access functions and predicates take constant time, inserting a point takes almost diff --git a/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_circle_2.h b/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_circle_2.h index a5e6ef69fd3..62ca61ccf2b 100644 --- a/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_circle_2.h +++ b/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_circle_2.h @@ -53,8 +53,8 @@ two-dimensional \cgal kernel. \cgalHeading{Implementation} We implement the incremental algorithm of Welzl, with move-to-front -heuristic \cite w-sedbe-91a. The whole implementation is described -in \cite cgal:gs-seceg-98. +heuristic \cgalCite{w-sedbe-91a}. The whole implementation is described +in \cgalCite{cgal:gs-seceg-98}. If randomization is chosen, the creation time is almost always linear in the number of points. diff --git a/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_ellipse_2.h b/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_ellipse_2.h index 8e21d7e4a0c..7741156ace4 100644 --- a/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_ellipse_2.h +++ b/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_ellipse_2.h @@ -35,9 +35,9 @@ two-dimensional \cgal kernel. \cgalHeading{Implementation} We implement the incremental algorithm of Welzl, with move-to-front -heuristic \cite w-sedbe-91a, using the primitives as described -in \cite gs-epsee-97, \cite cgal:gs-seefe-97a. The whole implementation is described -in \cite cgal:gs-seeeg-98. +heuristic \cgalCite{w-sedbe-91a}, using the primitives as described +in \cgalCite{gs-epsee-97}, \cgalCite{cgal:gs-seefe-97a}. The whole implementation is described +in \cgalCite{cgal:gs-seeeg-98}. If randomization is chosen, the creation time is almost always linear in the number of points. diff --git a/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_sphere_d.h b/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_sphere_d.h index ae9c71826df..992270414de 100644 --- a/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_sphere_d.h +++ b/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_sphere_d.h @@ -56,9 +56,9 @@ for two-, three-, and \f$ d\f$-dimensional points respectively. \cgalHeading{Implementation} We implement the algorithm of Welzl with move-to-front -heuristic \cite w-sedbe-91a for small point sets, combined with a new +heuristic \cgalCite{w-sedbe-91a} for small point sets, combined with a new efficient method for large sets, which is particularly tuned for -moderately large dimension (\f$ d \leq 20\f$) \cite cgal:g-frseb-99. +moderately large dimension (\f$ d \leq 20\f$) \cgalCite{cgal:g-frseb-99}. The creation time is almost always linear in the number of points. Access functions and predicates take constant time, inserting a point might take up to linear time, diff --git a/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_sphere_of_spheres_d.h b/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_sphere_of_spheres_d.h index df2e7ef860d..cd93275d46e 100644 --- a/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_sphere_of_spheres_d.h +++ b/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_sphere_of_spheres_d.h @@ -73,7 +73,7 @@ might still be an option in case your input number type cannot \cgalHeading{Implementation} We implement two algorithms, the LP-algorithm and a -heuristic \cite msw-sblp-92. As described in the documentation of +heuristic \cgalCite{msw-sblp-92}. As described in the documentation of concept `MinSphereOfSpheresTraits`, each has its advantages and disadvantages: Our implementation of the LP-algorithm has maximal expected running time \f$ O(2^d n)\f$, while the heuristic comes without diff --git a/Bounding_volumes/doc/Bounding_volumes/CGAL/min_quadrilateral_2.h b/Bounding_volumes/doc/Bounding_volumes/CGAL/min_quadrilateral_2.h index 87a4d53136b..68e98dc3908 100644 --- a/Bounding_volumes/doc/Bounding_volumes/CGAL/min_quadrilateral_2.h +++ b/Bounding_volumes/doc/Bounding_volumes/CGAL/min_quadrilateral_2.h @@ -46,7 +46,7 @@ type from one the \cgal kernels. In this case, a default traits class We use a rotating caliper algorithm -\cite stvwe-mepa-95, \cite v-fmep-90 with worst case running time linear +\cgalCite{stvwe-mepa-95}, \cgalCite{v-fmep-90} with worst case running time linear in the number of input points. \cgalHeading{Example} @@ -115,7 +115,7 @@ is `CGAL::Point_2` for some kernel `K`. \cgalHeading{Implementation} We use a rotating caliper -algorithm \cite t-sgprc-83 +algorithm \cgalCite{t-sgprc-83} with worst case running time linear in the number of input points. \cgalHeading{Example} @@ -183,7 +183,7 @@ is `CGAL::Point_2` for some kernel `K`. \cgalHeading{Implementation} We use a rotating caliper -algorithm \cite t-sgprc-83 +algorithm \cgalCite{t-sgprc-83} with worst case running time linear in the number of input points. \cgalHeading{Example} diff --git a/Bounding_volumes/doc/Bounding_volumes/CGAL/rectangular_p_center_2.h b/Bounding_volumes/doc/Bounding_volumes/CGAL/rectangular_p_center_2.h index e58749a4dea..b5170ab4e4f 100644 --- a/Bounding_volumes/doc/Bounding_volumes/CGAL/rectangular_p_center_2.h +++ b/Bounding_volumes/doc/Bounding_volumes/CGAL/rectangular_p_center_2.h @@ -248,9 +248,9 @@ The runtime is linear for \f$ p \in \{2,\,3\}\f$ and \f$ \mathcal{O}(n \cdot \log n)\f$ for \f$ p = 4\f$ where \f$ n\f$ is the number of input points. These runtimes are worst case optimal. The \f$ 3\f$-center algorithm uses a prune-and-search technique described in -\cite cgal:h-slacr-99. The \f$ 4\f$-center implementation uses sorted matrix -search \cite fj-fkppc-83, \cite fj-gsrsm-84 and fast algorithms for -piercing rectangles \cite sw-rpppp-96. +\cgalCite{cgal:h-slacr-99}. The \f$ 4\f$-center implementation uses sorted matrix +search \cgalCite{fj-fkppc-83}, \cgalCite{fj-gsrsm-84} and fast algorithms for +piercing rectangles \cgalCite{sw-rpppp-96}. \cgalHeading{Example} diff --git a/Bounding_volumes/doc/Bounding_volumes/Concepts/MinSphereOfSpheresTraits.h b/Bounding_volumes/doc/Bounding_volumes/Concepts/MinSphereOfSpheresTraits.h index be843a34c9d..7d67a373b35 100644 --- a/Bounding_volumes/doc/Bounding_volumes/Concepts/MinSphereOfSpheresTraits.h +++ b/Bounding_volumes/doc/Bounding_volumes/Concepts/MinSphereOfSpheresTraits.h @@ -75,7 +75,7 @@ with. It must typedef to either `CGAL::Default_algorithm`, The recommended choice is the first, which is a synonym to the one of the other two methods which we consider "the best in practice." In case of `CGAL::LP_algorithm`, the minsphere will be computed -using the LP-algorithm \cite msw-sblp-92, which in our +using the LP-algorithm \cgalCite{msw-sblp-92}, which in our implementation has maximal expected running time \f$ O(2^d n)\f$ (in the number of operations on the number type `FT`). In case of `CGAL::Farthest_first_heuristic`, a simple heuristic will be diff --git a/Box_intersection_d/doc/Box_intersection_d/Box_intersection_d.txt b/Box_intersection_d/doc/Box_intersection_d/Box_intersection_d.txt index 44917117805..74a05dbb35a 100644 --- a/Box_intersection_d/doc/Box_intersection_d/Box_intersection_d.txt +++ b/Box_intersection_d/doc/Box_intersection_d/Box_intersection_d.txt @@ -27,7 +27,7 @@ complicated geometric primitives contained in the boxes. \image html box_inters.png \image latex box_inters.png -We provide an efficient algorithm \cite cgal:ze-fsbi-02 for finding all +We provide an efficient algorithm \cgalCite{cgal:ze-fsbi-02} for finding all intersecting pairs for large numbers of iso-oriented boxes, i.e., typically these will be such bounding boxes of more complicated geometries. One immediate application of this algorithm is the detection of all @@ -36,7 +36,7 @@ applying the algorithm on a large set of triangles in space, we give an example program later in this chapter. Not so obvious applications are proximity queries and distance computations among such surfaces, see Section \ref secbox_inters_example_proximity for an example -and \cite cgal:ze-fsbi-02 for more details. +and \cgalCite{cgal:ze-fsbi-02} for more details. \section secboxintersdef Definition @@ -138,7 +138,7 @@ Two implementations of iso-oriented boxes are provided; handle that can be used to point to the full geometry that is approximated by the box. Both implementations have template parameters for the number type used for the interval bounds, for the fixed -dimension of the box, and for a policy class \cite cgal:a-mcdgp-01 +dimension of the box, and for a policy class \cgalCite{cgal:a-mcdgp-01} selecting among several solutions for providing the `id`-number. The function signatures for the bipartite case look as follows. The @@ -343,11 +343,11 @@ discussion. \section secboxintersperformance Runtime Performance -The implemented algorithm is described in \cite cgal:ze-fsbi-02 as +The implemented algorithm is described in \cgalCite{cgal:ze-fsbi-02} as version two. Its performance depends on a `cutoff` parameter. When the size of both iterator ranges drops below the `cutoff` parameter the function switches from the streamed segment-tree -algorithm to the two-way-scan algorithm, see \cite cgal:ze-fsbi-02 +algorithm to the two-way-scan algorithm, see \cgalCite{cgal:ze-fsbi-02} for the details. The streamed segment-tree algorithm needs \f$ O(n \log^d (n) + k)\f$ @@ -368,7 +368,7 @@ of course the number of boxes to be checked and their distribution. In cases where the callback runtime is dominant, it may be best to make the threshold parameter small. Otherwise a `cutoff`\f$ =\sqrt{n}\f$ can lead to acceptable results. For well distributed boxes the original -paper \cite cgal:ze-fsbi-02 gives optimal cutoffs in the thousands. +paper \cgalCite{cgal:ze-fsbi-02} gives optimal cutoffs in the thousands. Anyway, for optimal runtime some experiments to compare different cutoff parameters are recommended. @@ -462,7 +462,7 @@ stored in the `boxes` so far. \section Box_intersection_dDesign Design and Implementation History Lutz Kettner and Andreas Meyer implemented the algorithms starting -from the publication \cite cgal:ze-fsbi-02. We had access to the +from the publication \cgalCite{cgal:ze-fsbi-02}. We had access to the original C implementation of Afra Zomorodian, which helped clarifying some questions, and we are grateful to the help of Afra Zomorodian in answering our questions during his visit. We thank Steve Robbins for diff --git a/Box_intersection_d/doc/Box_intersection_d/CGAL/box_intersection_d.h b/Box_intersection_d/doc/Box_intersection_d/CGAL/box_intersection_d.h index f11dfdb58ca..31d1d959647 100644 --- a/Box_intersection_d/doc/Box_intersection_d/CGAL/box_intersection_d.h +++ b/Box_intersection_d/doc/Box_intersection_d/CGAL/box_intersection_d.h @@ -156,11 +156,11 @@ namespace CGAL { \cgalHeading{Implementation} - The implemented algorithm is described in \cite cgal:ze-fsbi-02 as + The implemented algorithm is described in \cgalCite{cgal:ze-fsbi-02} as version two. Its performance depends on a `cutoff` parameter. When the size of both iterator ranges drops below the `cutoff` parameter the function switches from the streamed segment-tree - algorithm to the two-way-scan algorithm, see \cite cgal:ze-fsbi-02 + algorithm to the two-way-scan algorithm, see \cgalCite{cgal:ze-fsbi-02} for the details. The streamed segment-tree algorithm needs \f$ O(n \log^d (n) + k)\f$ @@ -181,7 +181,7 @@ namespace CGAL { cases where the callback runtime is dominant, it may be best to make the threshold parameter small. Otherwise a `cutoff`\f$ =\sqrt{n}\f$ can lead to acceptable results. For well distributed boxes the original - paper \cite cgal:ze-fsbi-02 gives optimal cutoffs in the thousands. + paper \cgalCite{cgal:ze-fsbi-02} gives optimal cutoffs in the thousands. Anyway, for optimal runtime some experiments to compare different cutoff parameters are recommended. See also Section \ref secboxintersperformance . diff --git a/CGAL_ipelets/doc/CGAL_ipelets/CGAL_ipelets.txt b/CGAL_ipelets/doc/CGAL_ipelets/CGAL_ipelets.txt index 2f9c0ae32ae..5e35a500bd6 100644 --- a/CGAL_ipelets/doc/CGAL_ipelets/CGAL_ipelets.txt +++ b/CGAL_ipelets/doc/CGAL_ipelets/CGAL_ipelets.txt @@ -9,7 +9,7 @@ namespace CGAL { \section CGAL_ipeletsIntroduction Introduction -The Ipe extensible drawing editor (http://tclab.kaist.ac.kr/ipe/) \cite schwarzkopf1995ede, \cite ipe:man-09 +The Ipe extensible drawing editor (http://tclab.kaist.ac.kr/ipe/) \cgalCite{schwarzkopf1995ede}, \cgalCite{ipe:man-09} is a tool used by computational geometry researchers to produce 2D figures for inclusion in articles or presentations. The extensible adjective sheds a light on an important feature: the possibility for users to write small extensions (called ipelets) diff --git a/Circular_kernel_2/doc/Circular_kernel_2/Circular_kernel_2.txt b/Circular_kernel_2/doc/Circular_kernel_2/Circular_kernel_2.txt index 33749ad952f..04074b621fa 100644 --- a/Circular_kernel_2/doc/Circular_kernel_2/Circular_kernel_2.txt +++ b/Circular_kernel_2/doc/Circular_kernel_2/Circular_kernel_2.txt @@ -73,12 +73,12 @@ The following example shows how to use a functor of the kernel. The first pieces of prototype code were comparisons of algebraic numbers of degree 2, written by Olivier Devillers -\cite cgal:dfmt-amafe-00,cgal:dfmt-amafe-02. +\cgalCite{cgal:dfmt-amafe-00},cgal:dfmt-amafe-02. Some work was then done in the direction of a "kernel" for \cgal.\cgalFootnote{Monique Teillaud, First Prototype of a \cgal Geometric Kernel with Circular Arcs, Technical Report ECG-TR-182203-01, 2002 Sylvain Pion and Monique Teillaud, Towards a \cgal-like kernel for curves, Technical Report ECG-TR-302206-01, 2003} and the first design emerged in -\cite cgal:ekptt-tock-04. +\cgalCite{cgal:ekptt-tock-04}. The code of this package was initially written by Sylvain Pion and Monique Teillaud who also wrote the manual. Athanasios Kakargias had diff --git a/Circular_kernel_3/doc/Circular_kernel_3/Circular_kernel_3.txt b/Circular_kernel_3/doc/Circular_kernel_3/Circular_kernel_3.txt index 1def9009ccc..15ebcf1461f 100644 --- a/Circular_kernel_3/doc/Circular_kernel_3/Circular_kernel_3.txt +++ b/Circular_kernel_3/doc/Circular_kernel_3/Circular_kernel_3.txt @@ -193,7 +193,7 @@ The first version of the package was co-authored by Pedro Machado Manhães de Castro and Monique Teillaud, and integrated in CGAL 3.4. Frédéric Cazals and Sébastien Loriot extended the package by providing functionalities restricted on a given sphere -\cite cclt-dc3sk-08. +\cgalCite{cclt-dc3sk-08}. Sylvain Pion is acknowledged for helpful discussions. diff --git a/Circulator/doc/Circulator/Circulator.txt b/Circulator/doc/Circulator/Circulator.txt index a01b19ae6cb..7c84203be63 100644 --- a/Circulator/doc/Circulator/Circulator.txt +++ b/Circulator/doc/Circulator/Circulator.txt @@ -43,7 +43,7 @@ reference pages. Note that circulators are not part of \stl, but of \cgal. \subsection sectionIntroduction Introduction The concept of iterators in \stl is tailored for linear -sequences \cite cgal:ansi-is14882-98, \cite cgal:ms-strg-96. In contrast, circular +sequences \cgalCite{cgal:ansi-is14882-98}, \cgalCite{cgal:ms-strg-96}. In contrast, circular sequences occur naturally in many combinatorial and geometric structures. Examples are polyhedral surfaces and planar maps, where the edges emanating from a vertex or the edges around a facet form a diff --git a/Circulator/doc/Circulator/Concepts/Circulator.h b/Circulator/doc/Circulator/Concepts/Circulator.h index db658fe07f4..4f84c9db7c1 100644 --- a/Circulator/doc/Circulator/Concepts/Circulator.h +++ b/Circulator/doc/Circulator/Concepts/Circulator.h @@ -33,7 +33,7 @@ circulators are a contradiction, since any circulator is supposed to return once to itself. Output circulators are not supported since they would be indistinguishable from output iterators.}. Most requirements for circulators are equal to those for iterators. We present the -changes, please refer to [\cite cgal:ms-strg-96, chapter 18 or \cite cgal:ansi-is14882-98] +changes, please refer to [\cgalCite{cgal:ms-strg-96}, chapter 18 or \cgalCite{cgal:ansi-is14882-98}] for the iterator requirements. Past-the-end value: There is no past-the-end value for circulators. diff --git a/Combinatorial_map/doc/Combinatorial_map/Combinatorial_map.txt b/Combinatorial_map/doc/Combinatorial_map/Combinatorial_map.txt index 3c1fb4b45fc..efe54fd6eb6 100644 --- a/Combinatorial_map/doc/Combinatorial_map/Combinatorial_map.txt +++ b/Combinatorial_map/doc/Combinatorial_map/Combinatorial_map.txt @@ -1423,9 +1423,9 @@ Lastly we remove the dynamic onmerge functor (step 8). This is done by initializ \section sec_definition Mathematical Definitions 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 +in \cgalCite{cgal:l-tmbrc-91}, \cgalCite{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 +\cgalCite{cgal:pabl-cco-07}, \cgalCite{cgal:d-ccccg-10} in order to allow to represent objects with boundaries, based on the notions of partial permutations and partial involutions. diff --git a/Convex_decomposition_3/doc/Convex_decomposition_3/Convex_decomposition_3.txt b/Convex_decomposition_3/doc/Convex_decomposition_3/Convex_decomposition_3.txt index 1dd59b3c0d8..ba0b9ff781b 100644 --- a/Convex_decomposition_3/doc/Convex_decomposition_3/Convex_decomposition_3.txt +++ b/Convex_decomposition_3/doc/Convex_decomposition_3/Convex_decomposition_3.txt @@ -17,13 +17,13 @@ decomposing both polyhedra into convex pieces, compute pair-wise Minkowski sums of the convex pieces, and unite the pair-wise sums. While it is desirable to have a decomposition into a minimum number of -pieces, this problem is known to be NP-hard \cite c-cpplb-84. Our +pieces, this problem is known to be NP-hard \cgalCite{c-cpplb-84}. Our implementation decomposes a Nef polyhedron \f$ N\f$ into \f$ O(r^2)\f$ convex pieces, where \f$ r\f$ is the number of edges that have two adjacent facets that span an angle of more than 180 degrees with respect to the interior of the polyhedron. Those edges are also called reflex edges. The bound of \f$ O(r^2)\f$ convex pieces is worst-case -optimal \cite c-cpplb-84. +optimal \cgalCite{c-cpplb-84}. \cgalFigureBegin{figverticalDecomposition,two_cubes_all_in_one.png} Vertical decomposition based on the insertion of vertical facets (viewed from the top). Left: Non-convex polyhedron. Middle: Non-vertical reflex edges have been resolved. Right: Vertical reflex edges have been resolved. The sub-volumes are convex. diff --git a/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_akl_toussaint.h b/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_akl_toussaint.h index 0f0677bca39..50631e75cb1 100644 --- a/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_akl_toussaint.h +++ b/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_akl_toussaint.h @@ -40,7 +40,7 @@ functions that return instances of these types: \cgalHeading{Implementation} This function uses the algorithm of Akl and -Toussaint \cite at-fcha-78 that requires \f$ O(n \log n)\f$ time for \f$ n\f$ input +Toussaint \cgalCite{at-fcha-78} that requires \f$ O(n \log n)\f$ time for \f$ n\f$ input points. diff --git a/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_bykat.h b/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_bykat.h index 10e8bc9833b..d290e484341 100644 --- a/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_bykat.h +++ b/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_bykat.h @@ -41,7 +41,7 @@ functions that return instances of these types: \cgalHeading{Implementation} This function implements the non-recursive variation of -Eddy's algorithm \cite e-nchap-77 described in \cite b-chfsp-78. +Eddy's algorithm \cgalCite{e-nchap-77} described in \cgalCite{b-chfsp-78}. This algorithm requires \f$ O(n h)\f$ time in the worst case for \f$ n\f$ input points with \f$ h\f$ extreme points. diff --git a/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_eddy.h b/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_eddy.h index 10595945d2a..36cf947028b 100644 --- a/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_eddy.h +++ b/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_eddy.h @@ -41,8 +41,8 @@ functions that return instances of these types: \cgalHeading{Implementation} This function implements Eddy's algorithm -\cite e-nchap-77, which is the two-dimensional version of the quickhull -algorithm \cite bdh-qach-96. +\cgalCite{e-nchap-77}, which is the two-dimensional version of the quickhull +algorithm \cgalCite{bdh-qach-96}. This algorithm requires \f$ O(n h)\f$ time in the worst case for \f$ n\f$ input points with \f$ h\f$ extreme points. diff --git a/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_graham_andrew.h b/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_graham_andrew.h index 967fde1c0d2..01e203423d8 100644 --- a/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_graham_andrew.h +++ b/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_graham_andrew.h @@ -44,8 +44,8 @@ functions that return instances of these types: \cgalHeading{Implementation} This function implements Andrew's variant of the Graham -scan algorithm \cite a-aeach-79 and follows the presentation of Mehlhorn -\cite m-mdscg-84. This algorithm requires \f$ O(n \log n)\f$ time +scan algorithm \cgalCite{a-aeach-79} and follows the presentation of Mehlhorn +\cgalCite{m-mdscg-84}. This algorithm requires \f$ O(n \log n)\f$ time in the worst case for \f$ n\f$ input points. @@ -93,14 +93,14 @@ functions that return instances of these types: \cgalHeading{Implementation} The function uses Andrew's -variant of the Graham scan algorithm \cite a-aeach-79. This algorithm +variant of the Graham scan algorithm \cgalCite{a-aeach-79}. This algorithm requires \f$ O(n \log n)\f$ time in the worst case for \f$ n\f$ input points. \cgalHeading{Example} In the following example `ch_graham_andrew_scan()` is used to -realize Anderson's variant \cite a-readc-78 of the Graham Scan -\cite g-eadch-72. The points are sorted counterclockwise around the leftmost +realize Anderson's variant \cgalCite{a-readc-78} of the Graham Scan +\cgalCite{g-eadch-72}. The points are sorted counterclockwise around the leftmost point using the `Less_rotate_ccw_2` predicate, as defined in the concept `ConvexHullTraits_2`. According to the definition of `Less_rotate_ccw_2`, the leftmost point is the last point in the sorted @@ -140,7 +140,7 @@ not left of \f$ pq\f$, where \f$ p\f$ is the value of `first` and \f$ q\f$ is the value of `beyond` \f$ -1\f$. The resulting sequence is placed starting at `result` with \f$ p\f$; point \f$ q\f$ is omitted. The past-the-end iterator for the sequence is returned. -\pre The range [`first`,`beyond`) contains at least two different points. The points in [`first`,`beyond`) are sorted with respect to \f$ pq\f$, i.e., the sequence of points in [`first`,`beyond`) define a counterclockwise polygon, for which the Graham-Sklansky-procedure \cite s-mcrm-72 works. +\pre The range [`first`,`beyond`) contains at least two different points. The points in [`first`,`beyond`) are sorted with respect to \f$ pq\f$, i.e., the sequence of points in [`first`,`beyond`) define a counterclockwise polygon, for which the Graham-Sklansky-procedure \cgalCite{s-mcrm-72} works. */ template diff --git a/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_jarvis.h b/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_jarvis.h index 919495fd2cf..9d6a951af7e 100644 --- a/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_jarvis.h +++ b/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_jarvis.h @@ -41,7 +41,7 @@ functions that return instances of these types: \cgalHeading{Implementation} This function uses the Jarvis march (gift-wrapping) -algorithm \cite j-ichfs-73. This algorithm requires \f$ O(n h)\f$ time +algorithm \cgalCite{j-ichfs-73}. This algorithm requires \f$ O(n h)\f$ time in the worst case for \f$ n\f$ input points with \f$ h\f$ extreme points. @@ -88,7 +88,7 @@ functions that return instances of these types: \cgalHeading{Implementation} -The function uses the Jarvis march (gift-wrapping) algorithm \cite j-ichfs-73. +The function uses the Jarvis march (gift-wrapping) algorithm \cgalCite{j-ichfs-73}. This algorithm requires \f$ O(n h)\f$ time in the worst case for \f$ n\f$ input points with \f$ h\f$ extreme points. diff --git a/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_melkman.h b/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_melkman.h index 36514113fbe..6d240d93420 100644 --- a/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_melkman.h +++ b/Convex_hull_2/doc/Convex_hull_2/CGAL/ch_melkman.h @@ -39,7 +39,7 @@ functions that return instances of these types: \cgalHeading{Implementation} -It uses an implementation of Melkman's algorithm \cite m-olcch-87. +It uses an implementation of Melkman's algorithm \cgalCite{m-olcch-87}. Running time of this is linear. diff --git a/Convex_hull_2/doc/Convex_hull_2/CGAL/convex_hull_2.h b/Convex_hull_2/doc/Convex_hull_2/CGAL/convex_hull_2.h index 95290848121..4a012656269 100644 --- a/Convex_hull_2/doc/Convex_hull_2/CGAL/convex_hull_2.h +++ b/Convex_hull_2/doc/Convex_hull_2/CGAL/convex_hull_2.h @@ -46,11 +46,11 @@ functions that return instances of these types: One of two algorithms is used, depending on the type of iterator used to specify the input points. For -input iterators, the algorithm used is that of Bykat \cite b-chfsp-78, which +input iterators, the algorithm used is that of Bykat \cgalCite{b-chfsp-78}, which has a worst-case running time of \f$ O(n h)\f$, where \f$ n\f$ is the number of input points and \f$ h\f$ is the number of extreme points. For all other types of iterators, the \f$ O(n \log n)\f$ algorithm of of Akl and Toussaint -\cite at-fcha-78 is used. +\cgalCite{at-fcha-78} is used. */ @@ -127,7 +127,7 @@ functions that return instances of these types: \cgalHeading{Implementation} This function uses Andrew's variant of Graham's scan algorithm -\cite a-aeach-79, \cite m-mdscg-84. The algorithm has worst-case running time +\cgalCite{a-aeach-79}, \cgalCite{m-mdscg-84}. The algorithm has worst-case running time of \f$ O(n \log n)\f$ for \f$ n\f$ input points. @@ -191,7 +191,7 @@ functions that return instances of these types: \cgalHeading{Implementation} This function uses Andrew's -variant of Graham's scan algorithm \cite a-aeach-79, \cite m-mdscg-84. The algorithm +variant of Graham's scan algorithm \cgalCite{a-aeach-79}, \cgalCite{m-mdscg-84}. The algorithm has worst-case running time of \f$ O(n \log n)\f$ for \f$ n\f$ input points. diff --git a/Convex_hull_2/doc/Convex_hull_2/Convex_hull_2.txt b/Convex_hull_2/doc/Convex_hull_2/Convex_hull_2.txt index 9d963ea2421..7bfe36c6639 100644 --- a/Convex_hull_2/doc/Convex_hull_2/Convex_hull_2.txt +++ b/Convex_hull_2/doc/Convex_hull_2/Convex_hull_2.txt @@ -52,17 +52,17 @@ class need not be specified and defaults to types and operations defined in the kernel in which the input point type is defined. Given a sequence of \f$ n\f$ input points with \f$ h\f$ extreme points, -the function `convex_hull_2()` uses either the output-sensitive \f$ O(n h)\f$ algorithm of Bykat \cite b-chfsp-78 -(a non-recursive version of the quickhull \cite bdh-qach-96 algorithm) or the algorithm of Akl and Toussaint, which requires \f$ O(n \log n)\f$ time +the function `convex_hull_2()` uses either the output-sensitive \f$ O(n h)\f$ algorithm of Bykat \cgalCite{b-chfsp-78} +(a non-recursive version of the quickhull \cgalCite{bdh-qach-96} algorithm) or the algorithm of Akl and Toussaint, which requires \f$ O(n \log n)\f$ time in the worst case. The algorithm chosen depends on the kind of iterator used to specify the input points. These two algorithms are also available via the functions `ch_bykat()` and `ch_akl_toussaint()`, respectively. Also available are -the \f$ O(n \log n)\f$ Graham-Andrew scan algorithm \cite a-aeach-79, \cite m-mdscg-84 +the \f$ O(n \log n)\f$ Graham-Andrew scan algorithm \cgalCite{a-aeach-79}, \cgalCite{m-mdscg-84} (`ch_graham_andrew()`), -the \f$ O(n h)\f$ Jarvis march algorithm \cite j-ichfs-73 +the \f$ O(n h)\f$ Jarvis march algorithm \cgalCite{j-ichfs-73} (`ch_jarvis()`), -and Eddy's \f$ O(n h)\f$ algorithm \cite e-nchap-77 +and Eddy's \f$ O(n h)\f$ algorithm \cgalCite{e-nchap-77} (`ch_eddy()`), which corresponds to the two-dimensional version of the quickhull algorithm. The linear-time algorithm of Melkman for producing the convex hull of @@ -89,7 +89,7 @@ The functions `lower_hull_points_2()` and `upper_hull_points_2()` provide the computation of the counterclockwise sequence of extreme points on the lower hull and upper hull, respectively. The algorithm used in these functions is -Andrew's variant of Graham's scan algorithm \cite a-aeach-79, \cite m-mdscg-84, +Andrew's variant of Graham's scan algorithm \cgalCite{a-aeach-79}, \cgalCite{m-mdscg-84}, which has worst-case running time of \f$ O(n \log n)\f$. There are also functions available for computing certain subsequences diff --git a/Convex_hull_3/doc/Convex_hull_3/CGAL/convex_hull_3.h b/Convex_hull_3/doc/Convex_hull_3/CGAL/convex_hull_3.h index c47e752b87c..a0f97a733ad 100644 --- a/Convex_hull_3/doc/Convex_hull_3/CGAL/convex_hull_3.h +++ b/Convex_hull_3/doc/Convex_hull_3/CGAL/convex_hull_3.h @@ -31,7 +31,7 @@ then the default traits class of `::convex_hull_3()` is `Convex_hull_traits_3 \cgalHeading{Implementation} The algorithm implemented by these functions is the quickhull algorithm of -Barnard et al. \cite bdh-qach-96. +Barnard et al. \cgalCite{bdh-qach-96}. */ diff --git a/Convex_hull_3/doc/Convex_hull_3/CGAL/convex_hull_incremental_3.h b/Convex_hull_3/doc/Convex_hull_3/CGAL/convex_hull_incremental_3.h index 9c7ef487ed4..cf703cf44c9 100644 --- a/Convex_hull_3/doc/Convex_hull_3/CGAL/convex_hull_incremental_3.h +++ b/Convex_hull_3/doc/Convex_hull_3/CGAL/convex_hull_incremental_3.h @@ -6,7 +6,7 @@ namespace CGAL { computes the convex hull polyhedron of the three-dimensional points in the range [`first`,`beyond`) and assigns it to `P`. If `test_correctness` is set to -`true`, the tests described in \cite mnssssu-cgpvg-96 are +`true`, the tests described in \cgalCite{mnssssu-cgpvg-96} are used to determine the correctness of the resulting polyhedron. @@ -32,7 +32,7 @@ the representation class `R` required by \cgalHeading{Implementation} This function uses the `d`-dimensional convex hull incremental construction -algorithm \cite cms-frric-93 +algorithm \cgalCite{cms-frric-93} with `d` fixed to 3. The algorithm requires \f$ O(n^2)\f$ time in the worst case and \f$ O(n \log n)\f$ expected time. diff --git a/Convex_hull_3/doc/Convex_hull_3/CGAL/convexity_check_3.h b/Convex_hull_3/doc/Convex_hull_3/CGAL/convexity_check_3.h index dea22442de3..dced5d70dd1 100644 --- a/Convex_hull_3/doc/Convex_hull_3/CGAL/convexity_check_3.h +++ b/Convex_hull_3/doc/Convex_hull_3/CGAL/convexity_check_3.h @@ -36,7 +36,7 @@ the facet type must be `ConvexHullPolyhedronFacet_3`. \cgalHeading{Implementation} -This function implements the tests described in \cite mnssssu-cgpvg-96 to +This function implements the tests described in \cgalCite{mnssssu-cgpvg-96} to determine convexity and requires \f$ O(e + f)\f$ time for a polyhedron with \f$ e\f$ edges and \f$ f\f$ faces. diff --git a/Convex_hull_3/doc/Convex_hull_3/Convex_hull_3.txt b/Convex_hull_3/doc/Convex_hull_3/Convex_hull_3.txt index cde0f1a55c1..2b3796b9bbc 100644 --- a/Convex_hull_3/doc/Convex_hull_3/Convex_hull_3.txt +++ b/Convex_hull_3/doc/Convex_hull_3/Convex_hull_3.txt @@ -35,7 +35,7 @@ triangulation to get a fully dynamic computation. The function `convex_hull_3()` provides an -implementation of the quickhull algorithm \cite bdh-qach-96 for three +implementation of the quickhull algorithm \cgalCite{bdh-qach-96} for three dimensionsquickhull, 3D. There are two versions of this function available, one that can be used when it is known that the output will be a polyhedron (i.e., there are more than three points and @@ -59,7 +59,7 @@ account. \subsection Convex_hull_3ConvexityChecking Convexity Checking The function `is_strongly_convex_3()` -implements the algorithm of Mehlhorn et al. \cite mnssssu-cgpvg-96 +implements the algorithm of Mehlhorn et al. \cgalCite{mnssssu-cgpvg-96} to determine if the vertices of a given polytope constitute a strongly convex point set or not. This function is used in postcondition testing for `convex_hull_3()`. @@ -79,7 +79,7 @@ of the convex hull. The function `convex_hull_incremental_3()` provides an interface similar to `convex_hull_3()` for the `d`-dimensional -incremental construction algorithm \cite cms-frric-93 +incremental construction algorithm \cgalCite{cms-frric-93} implemented by the class `Convex_hull_d` that is specialized to three dimensions. This function accepts an iterator range over a set of input points and returns a polyhedron, but it does not have a traits class diff --git a/Convex_hull_d/doc/Convex_hull_d/CGAL/Convex_hull_d.h b/Convex_hull_d/doc/Convex_hull_d/CGAL/Convex_hull_d.h index 5fdc3d79c0c..6cf41a4195a 100644 --- a/Convex_hull_d/doc/Convex_hull_d/CGAL/Convex_hull_d.h +++ b/Convex_hull_d/doc/Convex_hull_d/CGAL/Convex_hull_d.h @@ -58,7 +58,7 @@ successively assigned to \f$ f\f$ \f$ \}\f$ \cgalHeading{Implementation} The implementation of type `Convex_hull_d` is based on -\cite cms-frric-93 and \cite bms-dgc-94. The details +\cgalCite{cms-frric-93} and \cgalCite{bms-dgc-94}. The details of the implementation can be found in the implementation document available at the download site of this package. diff --git a/Convex_hull_d/doc/Convex_hull_d/Convex_hull_d.txt b/Convex_hull_d/doc/Convex_hull_d/Convex_hull_d.txt index f9a62c750c9..8b085bbd7da 100644 --- a/Convex_hull_d/doc/Convex_hull_d/Convex_hull_d.txt +++ b/Convex_hull_d/doc/Convex_hull_d/Convex_hull_d.txt @@ -43,12 +43,12 @@ model e.g., `Homogeneous` or `Cartesian` for use with `Convex_hull_d`, where the dimension is fixed to three. The validity of the computed convex hull can be checked using the member function `Convex_hull_d::is_valid`, which implements the algorithm -of Mehlhorn et al.\cite mnssssu-cgpvg-96 to determine if +of Mehlhorn et al.\cgalCite{mnssssu-cgpvg-96} to determine if the vertices of a given polytope constitute a strongly convex point set or not. -The implementation follows the papers \cite cms-frric-93 and -\cite bms-dgc-94. +The implementation follows the papers \cgalCite{cms-frric-93} and +\cgalCite{bms-dgc-94}. \section Convex_hull_dDelaunay Delaunay Triangulation diff --git a/Convex_hull_d/include/CGAL/Convex_hull_d.h b/Convex_hull_d/include/CGAL/Convex_hull_d.h index 19ea6620885..fcac23bdd19 100644 --- a/Convex_hull_d/include/CGAL/Convex_hull_d.h +++ b/Convex_hull_d/include/CGAL/Convex_hull_d.h @@ -981,7 +981,7 @@ public: /*{\Mimplementation The implementation of type |\Mtype| is based on - \cite{cms:fourresults} and \cite{BMS:degeneracy}. The details of the + \cgalCite{cms:fourresults} and \cgalCite{BMS:degeneracy}. The details of the implementation can be found in the implementation document available at the download site of this package. diff --git a/Documentation/doc/Documentation/Developer_manual/Chapter_checks.txt b/Documentation/doc/Documentation/Developer_manual/Chapter_checks.txt index 0f24aed7517..bab88c41eaa 100644 --- a/Documentation/doc/Documentation/Developer_manual/Chapter_checks.txt +++ b/Documentation/doc/Documentation/Developer_manual/Chapter_checks.txt @@ -203,9 +203,9 @@ package you can find a sentence similar to the following. Some parts of the library use exceptions, but there is no general specific policy concerning exception handling in \cgal. It is nevertheless good to target exception safety, as much as possible. Good references on exception -safety are: Appendix E of \cite cgal:s-cpl-97 (also available at +safety are: Appendix E of \cgalCite{cgal:s-cpl-97} (also available at http://www.research.att.com/~bs/3rd_safe0.html), -and \cite cgal:a-esgc-98 (also available at +and \cgalCite{cgal:a-esgc-98} (also available at http://www.boost.org/more/generic_exception_safety.html). \section secchecks_req_and_rec Requirements and recommendations diff --git a/Documentation/doc/Documentation/Developer_manual/Chapter_code_format.txt b/Documentation/doc/Documentation/Developer_manual/Chapter_code_format.txt index 127a1b1b903..6f7760021df 100644 --- a/Documentation/doc/Documentation/Developer_manual/Chapter_code_format.txt +++ b/Documentation/doc/Documentation/Developer_manual/Chapter_code_format.txt @@ -249,7 +249,7 @@ The first list of items are meant as rules, i.e., you should follow them. that are declared `m`utable. An example is the caching of results from expensive computations. For more information about conceptually `c`onst functions and mutable data - members see \cite cgal:m-ec-97. + members see \cgalCite{cgal:m-ec-97}. - Prefer \cpp-style to C-style casts, e.g., use `static_cast( i)` instead of `(`double)i. - Protect header files against multiple inclusion, e.g. the file This_is_an_example.h should begin/end with \code{.cpp} diff --git a/Documentation/doc/Documentation/Developer_manual/Chapter_information_sources.txt b/Documentation/doc/Documentation/Developer_manual/Chapter_information_sources.txt index 3cc09a24fef..e01f641cf11 100644 --- a/Documentation/doc/Documentation/Developer_manual/Chapter_information_sources.txt +++ b/Documentation/doc/Documentation/Developer_manual/Chapter_information_sources.txt @@ -4,18 +4,18 @@ The following books and papers are recommended as references: -- \cite cgal:a-gps-98 - Mathew Austern's introduction to the \stl +- \cgalCite{cgal:a-gps-98} - Mathew Austern's introduction to the \stl using the concept/model style of presentation. Austern wrote the WWW \stl documentation at SGI. -- \cite cgal:s-cpl-97 - Bjarne Stroustrup's introduction to +- \cgalCite{cgal:s-cpl-97} - Bjarne Stroustrup's introduction to \cpp and the \stl for those who already know some \cpp. Stroustrup is the designer and original implementer of \cpp. -- \cite cgal:ll-cp-98 - Stanley Lippman and Josee Lajoie's +- \cgalCite{cgal:ll-cp-98} - Stanley Lippman and Josee Lajoie's \cpp primer. -- \cite cgal:m-ec-97 - Scott Meyers's book on ways to improve +- \cgalCite{cgal:m-ec-97} - Scott Meyers's book on ways to improve your \cpp programs. Items 21 and 29 discuss the concept of const-correctness. -- \cite fgkss-dccga-00 - The \cgal design paper. -- \cite hhkps-aegk-01 - The new \cgal kernel design paper. +- \cgalCite{fgkss-dccga-00} - The \cgal design paper. +- \cgalCite{hhkps-aegk-01} - The new \cgal kernel design paper. */ diff --git a/Documentation/doc/Documentation/Developer_manual/Chapter_intro.txt b/Documentation/doc/Documentation/Developer_manual/Chapter_intro.txt index b143f282428..96e24eee6da 100644 --- a/Documentation/doc/Documentation/Developer_manual/Chapter_intro.txt +++ b/Documentation/doc/Documentation/Developer_manual/Chapter_intro.txt @@ -27,7 +27,7 @@ projects 21957 (CGAL) and 28155 (GALIA). \section secdesign_goals Primary design goals -The primary design goals of \cgal are described in \cite fgkss-dccga-00: +The primary design goals of \cgal are described in \cgalCite{fgkss-dccga-00:} \subsection Developer_manualCorrectness Correctness @@ -84,7 +84,7 @@ integrate new classes and algorithms into \cgal. \cgal should be open to coexist with other libraries, or better, to work together with other libraries and programs. The \cpp -Standard \cite cgal:ansi-is14882-98 +Standard \cgalCite{cgal:ansi-is14882-98} defines with the \cpp Standard Library a common foundation for all \cpp platforms. @@ -132,7 +132,7 @@ maps library. A goal with similar implications as uniformity is a design with complete and minimal interfaces, see for example Item 18 -in Ref. \cite cgal:m-ec-97. +in Ref. \cgalCite{cgal:m-ec-97}. An object or module should be complete in its functionality, but should not provide additional decorating functionality. Even if a certain @@ -167,7 +167,7 @@ clearly documented which degeneracies are handled and which are not. For most geometric algorithms theoretical results for the time and space complexity are known. Also, the theoretic interest in efficiency for realistic inputs, as opposed to worst-case situations, is -growing \cite v-ffrim-97. +growing \cgalCite{v-ffrim-97}. For practical purposes, insight into the constant factors hidden in the \f$ O\f$-notation is necessary, especially if there are several competing algorithms. diff --git a/Documentation/doc/Documentation/Developer_manual/Chapter_iterators_and_circulators.txt b/Documentation/doc/Documentation/Developer_manual/Chapter_iterators_and_circulators.txt index 0b770e68f8a..dbae5d6bda0 100644 --- a/Documentation/doc/Documentation/Developer_manual/Chapter_iterators_and_circulators.txt +++ b/Documentation/doc/Documentation/Developer_manual/Chapter_iterators_and_circulators.txt @@ -36,8 +36,8 @@ Section \ref sechandle_vs_it_vs_circ below discusses when handles should be used in your code. The concepts of iterators is relatively well described in textbooks such as -Stroustrup's book (The C++ Programming Language \cite cgal:s-cpl-97) -and Austern's book (Generic Programming and the \stl \cite cgal:a-gps-98) +Stroustrup's book (The C++ Programming Language \cgalCite{cgal:s-cpl-97}) +and Austern's book (Generic Programming and the \stl \cgalCite{cgal:a-gps-98}) and in chapter Handles and Circulators of the Support Library part of the \cgal manual. which also presents the concepts of handles and circulators. @@ -343,7 +343,7 @@ for more information and examples. Every container class in \cgal should strive to be a model for the \stl concept of a container. As for all concepts, this means that certain types and functions are provided, as detailed, for example -in \cite cgal:a-gps-98. For the purposes of this discussion, the relevant +in \cgalCite{cgal:a-gps-98}. For the purposes of this discussion, the relevant types are: ` is templated by a parameter diff --git a/Triangulation_3/doc/TDS_3/TriangulationDS_3.txt b/Triangulation_3/doc/TDS_3/TriangulationDS_3.txt index 75f1da77c95..4b7c4e283a2 100644 --- a/Triangulation_3/doc/TDS_3/TriangulationDS_3.txt +++ b/Triangulation_3/doc/TDS_3/TriangulationDS_3.txt @@ -175,7 +175,7 @@ the local validity of a given triangulation data structure. The 3D-triangulation data structure class of \cgal, `Triangulation_data_structure_3`, is designed to be used as a combinatorial -layer upon which a geometric layer can be built \cite k-ddsps-98. This +layer upon which a geometric layer can be built \cgalCite{k-ddsps-98}. This geometric layer is typically one of the 3D-triangulation classes of \cgal: `Triangulation_3`, `Delaunay_triangulation_3` and `Regular_triangulation_3`. This relation is described in more details in @@ -321,7 +321,7 @@ structures whose vertices respectively store vertex handles of the other one. Monique Teillaud introduced the triangulation of the topological sphere \f$ S^d\f$ in \f$ \mathbb{R}^{d+1}\f$ to manage the underlying graph of geometric -triangulations and handle degenerate dimensions \cite t-tdtc-99. +triangulations and handle degenerate dimensions \cgalCite{t-tdtc-99}. Sylvain Pion improved the software in several ways, in particular regarding the memory management. diff --git a/Triangulation_3/doc/Triangulation_3/CGAL/Delaunay_triangulation_3.h b/Triangulation_3/doc/Triangulation_3/CGAL/Delaunay_triangulation_3.h index 22338a6e021..1c0d329d91a 100644 --- a/Triangulation_3/doc/Triangulation_3/CGAL/Delaunay_triangulation_3.h +++ b/Triangulation_3/doc/Triangulation_3/CGAL/Delaunay_triangulation_3.h @@ -18,7 +18,7 @@ either `Fast_location` or `Compact_location`. location, which can be beneficial when performing point locations or random point insertions (with no good location hint) in large data sets. It is currently implemented using an additional triangulation -hierarchy data structure \cite cgal:d-dh-02. +hierarchy data structure \cgalCite{cgal:d-dh-02}. The default is `Compact_location`, which saves memory (3-5%) by avoiding the need for this separate data structure, and point location is then performed roughly in \f$ O(n^{1/3})\f$ time. @@ -196,7 +196,7 @@ re-triangulated. So, the problem reduces to triangulating a polyhedral region, while preserving its boundary, or to compute a *constrained* triangulation. This is known to be sometimes impossible: the Schönhardt polyhedron cannot be triangulated -\cite cgal:s-cgehd-98. However, when dealing with Delaunay +\cgalCite{cgal:s-cgehd-98}. However, when dealing with Delaunay triangulations, the case of such polyhedra that cannot be re-triangulated cannot happen, so \cgal proposes a vertex removal. diff --git a/Triangulation_3/doc/Triangulation_3/PackageDescription.txt b/Triangulation_3/doc/Triangulation_3/PackageDescription.txt index 308e172df91..7e9c0117c31 100644 --- a/Triangulation_3/doc/Triangulation_3/PackageDescription.txt +++ b/Triangulation_3/doc/Triangulation_3/PackageDescription.txt @@ -34,7 +34,7 @@ A three-dimensional triangulation is a three-dimensional simplicial -complex, pure connected and without singularities \cite by-ag-98. Its +complex, pure connected and without singularities \cgalCite{by-ag-98}. Its cells (`3`-faces) are such that two cells either do not intersect or share a common facet (`2`-face), edge (`1`-face) or vertex (`0`-face). diff --git a/Triangulation_3/doc/Triangulation_3/Triangulation_3.txt b/Triangulation_3/doc/Triangulation_3/Triangulation_3.txt index 8a951ac392c..a5d623a24f8 100644 --- a/Triangulation_3/doc/Triangulation_3/Triangulation_3.txt +++ b/Triangulation_3/doc/Triangulation_3/Triangulation_3.txt @@ -120,7 +120,7 @@ When all the points are collinear, this condition becomes: The method `Triangulation_3::is_valid()` checks the local validity of a given triangulation. This does not always -ensure global validity \cite mnssssu-cgpvg-96, \cite dlpt-ccpps-98 but it is +ensure global validity \cgalCite{mnssssu-cgpvg-96}, \cgalCite{dlpt-ccpps-98} but it is sufficient for practical cases. \section Triangulation_3Delaunay Delaunay Triangulation @@ -182,7 +182,7 @@ of the four-dimensional points \f$ (p,\|p-O\|^2-w_p),\f$ for Note that all points of \f$ {S}^{(w)}\f$ do not necessarily appear as vertices of the regular triangulation. To know more about regular triangulations, see for -example \cite es-itfwr-96. +example \cgalCite{es-itfwr-96}. When all weights are 0, power spheres are nothing more than circumscribing spheres, and the regular triangulation is exactly the @@ -204,8 +204,8 @@ Derivation diagram of the 3D triangulation classes. The three main classes (`Triangulation_3`, `Delaunay_triangulation_3` and `Regular_triangulation_3`) provide high-level geometric functionality -such as location of a point in the triangulation \cite cgal:dpt-wt-02, insertion -and possibly removal of a point \cite cgal:dt-pvr3d-03, and are responsible for the +such as location of a point in the triangulation \cgalCite{cgal:dpt-wt-02}, insertion +and possibly removal of a point \cgalCite{cgal:dt-pvr3d-03}, and are responsible for the geometric validity. They are built as layers on top of a triangulation data structure, which stores their combinatorial structure. This separation between the geometry and the combinatorics is reflected in the software design by the @@ -326,7 +326,7 @@ geometric traits.\cgalFootnote{The mechanism used behind the scenes to allow thi The `Fast_location` policy is implemented using a hierarchy of triangulations; it changes the behavior of functions `locate`, `insert`, `move`, and `remove`. -As proved in \cite cgal:d-dh-02, this structure has an +As proved in \cgalCite{cgal:d-dh-02}, this structure has an optimal behavior when it is built for Delaunay triangulations. In this setting, if you build a triangulation by iteratively inserting points, @@ -505,7 +505,7 @@ of points. For Delaunay triangulations, this bound is reached in cases such as points equally distributed on two non-coplanar lines. However, the good news is that, in many cases, the complexity of a Delaunay triangulation is linear or close to linear in the number of points. Several -articles \cite d-hdvdl-89, \cite e-dpssdt-02, \cite geometrica-5986i, \cite prisme-4453a, \cite prisme-abl-03 +articles \cgalCite{d-hdvdl-89}, \cgalCite{e-dpssdt-02}, \cgalCite{geometrica-5986i}, \cgalCite{prisme-4453a}, \cgalCite{prisme-abl-03} have proved such good complexity bounds for specific point distributions, such as points distributed on surfaces under some conditions. @@ -727,7 +727,7 @@ Running times in seconds for algorithms on 3D triangulations. \cgalFigureCaptionEnd More benchmarks comparing \cgal to other software can be found -in \cite msri52:liu-snoeyink-05. +in \cgalCite{msri52:liu-snoeyink-05}. \subsection Triangulation_3MemoryUsage Memory Usage @@ -856,8 +856,8 @@ and data with many degenerate cases. This last data set exhibits an infinite loop with an inexact kernel, and of course we are not sure whether what is computed for the other data sets with this inexact kernel is a Delaunay triangulation. General introductory information about these robustness issues -can be found in \cite cgta-kmpsy-08. More benchmarks around this issue can -also be found in \cite cgal:dp-eegpd-03. +can be found in \cgalCite{cgta-kmpsy-08}. More benchmarks around this issue can +also be found in \cgalCite{cgal:dp-eegpd-03}. \cgalFigureAnchor{Triangulation3figkernelsanddatasets}
    @@ -975,7 +975,7 @@ Data sets used in the benchmark of \cgalFigureRef{Triangulation3figkernelsanddat Monique Teillaud started to work on the 3D triangulation packages in 1997, following the design of the 2D triangulation packages. The notions of degenerate dimensions and infinite vertex were formalized -\cite t-tdtc-99 and induced changes in the 2D triangulation +\cgalCite{t-tdtc-99} and induced changes in the 2D triangulation packages. The packages were first released in \cgal 2.1. They contained basic functionalities on triangulations, Delaunay triangulations, regular triangulations. @@ -983,7 +983,7 @@ regular triangulations. A first version of removal of a vertex from a Delaunay triangulation was released in \cgal 2.2. However, this removal became really robust only in \cgal 2.3, after some research that allowed to deal with -degenerate cases quite easily \cite cgal:dt-pvr3d-03. Andreas Fabri +degenerate cases quite easily \cgalCite{cgal:dt-pvr3d-03}. Andreas Fabri implemented this revised version of the removal, and a faster removal algorithm for \cgal 3.0. @@ -994,10 +994,10 @@ she also wrote the traits classes for regular triangulations. In 2000, Sylvain Pion started working on these packages. He improved the efficiency of triangulations in \cgal 2.3 and 2.4 in several ways -\cite cgal:bdpty-tc-02: he implemented the Delaunay hierarchy -\cite cgal:d-dh-02 in 2.3, he improved the memory footprint in 2.4 +\cgalCite{cgal:bdpty-tc-02:} he implemented the Delaunay hierarchy +\cgalCite{cgal:d-dh-02} in 2.3, he improved the memory footprint in 2.4 and 3.0, he also performed work on arithmetic filters -\cite cgal:dp-eegpd-03 (see `Filtered_kernel`) to improve +\cgalCite{cgal:dp-eegpd-03} (see `Filtered_kernel`) to improve the speed of triangulations. He changed the design in \cgal 3.0, allowing users to add handles in their own vertices and cells. @@ -1008,7 +1008,7 @@ Delaunay hierarchy. In 2005, Christophe Delage implemented the vertex removal function for regular triangulations, using the symbolic perturbation proposed -in \cite cgal:dt-pvrdr-06, which allowed to release this +in \cgalCite{cgal:dt-pvrdr-06}, which allowed to release this functionality in \cgal 3.2. In 2006, Nico Kruithof wrote the `Triangulation_simplex_3` class @@ -1037,7 +1037,7 @@ Teillaud in the framework of the Google Summer of Code, 2010. The authors wish to thank Lutz Kettner for inspiring discussions about the design of \cgal. Jean-Daniel Boissonnat is also acknowledged -\cite bdty-tcgal-00. +\cgalCite{bdty-tcgal-00}. */ } /* namespace CGAL */ diff --git a/Voronoi_diagram_2/doc/Voronoi_diagram_2/Voronoi_diagram_2.txt b/Voronoi_diagram_2/doc/Voronoi_diagram_2/Voronoi_diagram_2.txt index 9a8477c7d7e..163719da3aa 100644 --- a/Voronoi_diagram_2/doc/Voronoi_diagram_2/Voronoi_diagram_2.txt +++ b/Voronoi_diagram_2/doc/Voronoi_diagram_2/Voronoi_diagram_2.txt @@ -73,7 +73,7 @@ points, the Euclidean Voronoi diagram of a set of disks on the plane (i.e., the Apollonius diagram), the Euclidean Voronoi diagram of a set of disjoint convex objects on the plane, or the power or (Laguerre) diagram for a set of circles on the plane. In fact every instance of -an abstract Voronoi diagram in the sense of Klein \cite k-cavd-89 +an abstract Voronoi diagram in the sense of Klein \cgalCite{k-cavd-89} is a simple Voronoi diagram in our setting. In the sequel when we refer to Voronoi diagrams we will refer to simple Voronoi diagrams.
    diff --git a/Documentation/doc/Documentation/Developer_manual/Chapter_kernels.txt b/Documentation/doc/Documentation/Developer_manual/Chapter_kernels.txt index 4df5643ed14..59bd99f63a1 100644 --- a/Documentation/doc/Documentation/Developer_manual/Chapter_kernels.txt +++ b/Documentation/doc/Documentation/Developer_manual/Chapter_kernels.txt @@ -13,7 +13,7 @@ stand-alone class, which is parameterized by a kernel class, and as a type in the kernel class. Each operation in the kernel is provided via a functor class\cgalFootnote{A class which defines a member `operator()`.} in the kernel class and also as either a member function or a global function. -See \cite hhkps-aegk-01 for more details about this design. +See \cgalCite{hhkps-aegk-01} for more details about this design. Ideally, if the kernel provides all the primitives required, you can use any kernel as a traits class directly with your algorithm or data structure; see also Chapter \ref chaptraits_classes . If you need @@ -58,14 +58,14 @@ Each kernel object is provided as both a stand-alone class, which is parameterized by a kernel class (`Geo_object_D`), and as a type in the kernel class (`K::Geo_object_D`). While the former use may be more natural for users not interested in the flexibility of the kernel -(and is compatible with the original kernel design \cite fgkss-dccga-00), the +(and is compatible with the original kernel design \cgalCite{fgkss-dccga-00}), the latter syntax should be used in all code distributed with the library as it allows types in the kernel to be easily exchanged and modified. Similarly, each operation and construction in the kernel is provided via a function object class in the kernel class and also as either a member function or a global function; developers should use the function object classes to gain access to the -functionality. See \cite hhkps-aegk-01 for more details about this +functionality. See \cgalCite{hhkps-aegk-01} for more details about this design and how it is accomplished. The classes for the geometric objects in the kernel have a diff --git a/Documentation/doc/Documentation/Developer_manual/Chapter_memory_management.txt b/Documentation/doc/Documentation/Developer_manual/Chapter_memory_management.txt index e86bceebcf1..4a2e20c4bb2 100644 --- a/Documentation/doc/Documentation/Developer_manual/Chapter_memory_management.txt +++ b/Documentation/doc/Documentation/Developer_manual/Chapter_memory_management.txt @@ -17,7 +17,7 @@ describe one way to address this using allocators. An allocator encapsulates the information about an allocation model. We adopted the definition of the Standard \cpp -allocator \cite cgal:ansi-is14882-98. The `std::allocator` is the +allocator \cgalCite{cgal:ansi-is14882-98}. The `std::allocator` is the only predefined and required allocator imposed by [\cpp] on all \cpp compiler implementations. The exact specification can also be found at http://en.wikipedia.org/wiki/Allocator_(C++). diff --git a/Documentation/doc/Documentation/Developer_manual/Chapter_portability.txt b/Documentation/doc/Documentation/Developer_manual/Chapter_portability.txt index 952da2d6b3e..ddffd53c325 100644 --- a/Documentation/doc/Documentation/Developer_manual/Chapter_portability.txt +++ b/Documentation/doc/Documentation/Developer_manual/Chapter_portability.txt @@ -185,7 +185,7 @@ Linux For (good) reasons that will not be discussed here, it was decided to use \cpp for the development of \cgal. An international standard for -\cpp has been sanctioned in 1998 \cite cgal:ansi-is14882-98 and the +\cpp has been sanctioned in 1998 \cgalCite{cgal:ansi-is14882-98} and the level of compliance varies widely between different compilers, let alone bugs. diff --git a/Documentation/doc/Documentation/Developer_manual/Chapter_traits_classes.txt b/Documentation/doc/Documentation/Developer_manual/Chapter_traits_classes.txt index 3a77bd5f952..f8e9f6021b1 100644 --- a/Documentation/doc/Documentation/Developer_manual/Chapter_traits_classes.txt +++ b/Documentation/doc/Documentation/Developer_manual/Chapter_traits_classes.txt @@ -5,7 +5,7 @@ The concept of a traits class is central to %CGAL. The name traits class comes from a standard \cpp design pattern -\cite cgal:m-tnutt-95; you may have heard about iterator traits which +\cgalCite{cgal:m-tnutt-95}; you may have heard about iterator traits which follow this design pattern. The traits class is used in template code to reflect properties (traits) of the actual template argument. @@ -126,7 +126,7 @@ the actual functors. Reasons for this are the following. carry data. For example, repeated calls to a function with only slightly different parameters might be handled efficiently by storing intermediate results. Functors are the natural framework - here. See \cite hhkps-aegk-01 for more exposition. + here. See \cgalCite{hhkps-aegk-01} for more exposition. If you really look up the documentation of the diff --git a/Envelope_2/doc/Envelope_2/Envelope_2.txt b/Envelope_2/doc/Envelope_2/Envelope_2.txt index 288a884f026..0863bb354a2 100644 --- a/Envelope_2/doc/Envelope_2/Envelope_2.txt +++ b/Envelope_2/doc/Envelope_2/Envelope_2.txt @@ -174,7 +174,7 @@ the lines that form the lower envelope of \f$ {\cal P}^{*}\f$ are dual to the points along the upper part of \f$ {\cal P}\f$'s convex hull, and the lines that form the upper envelope of \f$ {\cal P}^{*}\f$ are dual to the points along the lower part of the convex hull; see, -e.g., [\cite Section 11.4 for more details. +e.g., [\cgalCite{Section} 11.4 for more details. Note that the leftmost edge of the minimization diagram is associated with the same line as the rightmost edge of the maximization diagram, and vice-verse. We can therefore skip the rightmost edges of both diff --git a/Envelope_3/doc/Envelope_3/Envelope_3.txt b/Envelope_3/doc/Envelope_3/Envelope_3.txt index 2500b2d4d55..ceeba66eb74 100644 --- a/Envelope_3/doc/Envelope_3/Envelope_3.txt +++ b/Envelope_3/doc/Envelope_3/Envelope_3.txt @@ -79,7 +79,7 @@ compute their envelope diagrams recursively. Finally, we merge the diagrams, and we do this by overlaying them and then applying some post-processing on the resulting diagram. The post-processing stage is non-trivial and involves the projection of intersection curves onto -the \f$ xy\f$-plane - see \cite cgal:m-rgece-06 for more details. +the \f$ xy\f$-plane - see \cgalCite{cgal:m-rgece-06} for more details. \section Envelope_3The The Envelope-Traits Concept diff --git a/Generator/doc/Generator/CGAL/random_convex_set_2.h b/Generator/doc/Generator/CGAL/random_convex_set_2.h index a474f5ceaf6..750bc06592d 100644 --- a/Generator/doc/Generator/CGAL/random_convex_set_2.h +++ b/Generator/doc/Generator/CGAL/random_convex_set_2.h @@ -31,7 +31,7 @@ R >` for some representation class `R`, \cgalHeading{Implementation} The implementation uses the centroid method -described in \cite cgal:s-zkm-96 and has a worst case running time of \f$ O(r +described in \cgalCite{cgal:s-zkm-96} and has a worst case running time of \f$ O(r \cdot n + n \cdot \log n)\f$, where \f$ r\f$ is the time needed by `pg` to generate a random point. diff --git a/Generator/doc/Generator/CGAL/random_polygon_2.h b/Generator/doc/Generator/CGAL/random_polygon_2.h index fc9aed019f1..2f397d27726 100644 --- a/Generator/doc/Generator/CGAL/random_polygon_2.h +++ b/Generator/doc/Generator/CGAL/random_polygon_2.h @@ -34,7 +34,7 @@ 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 intersection between two edges by reversing the order of the vertices between the edges. No more than \f$ O(n^3)\f$ such moves are required to simplify a polygon -defined on \f$ n\f$ points \cite ls-utstp-82. +defined on \f$ n\f$ points \cgalCite{ls-utstp-82}. Intersecting edges are detected using a simple sweep through the vertices and then one intersection is chosen at random to eliminate after each sweep. The worse-case running time is therefore \f$ O(n^4 \log n)\f$. diff --git a/HalfedgeDS/doc/HalfedgeDS/Concepts/HalfedgeDS.h b/HalfedgeDS/doc/HalfedgeDS/Concepts/HalfedgeDS.h index 89c9077986a..5fbf2ea1f56 100644 --- a/HalfedgeDS/doc/HalfedgeDS/Concepts/HalfedgeDS.h +++ b/HalfedgeDS/doc/HalfedgeDS/Concepts/HalfedgeDS.h @@ -10,17 +10,17 @@ combinatorial data structure, geometric interpretation is added by classes built on top of the halfedge data structure. The data structure defined here is known as the -FE-structure \cite w-ebdss-85, as -halfedges \cite m-ism-88, \cite cgal:bfh-mgedm-95 or as the doubly connected edge -list (DCEL) \cite bkos-cgaa-97, although the original reference for -the DCEL \cite mp-fitcp-78 describes a different data structure. The +FE-structure \cgalCite{w-ebdss-85}, as +halfedges \cgalCite{m-ism-88}, \cgalCite{cgal:bfh-mgedm-95} or as the doubly connected edge +list (DCEL) \cgalCite{bkos-cgaa-97}, although the original reference for +the DCEL \cgalCite{mp-fitcp-78} describes a different data structure. The halfedge data structure can also be seen as one of the variants of the -quad-edge data structure \cite gs-pmgsc-85. In general, the quad-edge +quad-edge data structure \cgalCite{gs-pmgsc-85}. In general, the quad-edge data can represent non-orientable 2-manifolds, but the variant here is restricted to orientable 2-manifolds only. An overview and comparison of these different data structures together with a thorough description of the design implemented here can be found -in \cite k-ugpdd-99. +in \cgalCite{k-ugpdd-99}. Each edge is represented by two halfedges with opposite orientations. Each halfedge can store a reference to an incident face and an diff --git a/HalfedgeDS/doc/HalfedgeDS/HalfedgeDS.txt b/HalfedgeDS/doc/HalfedgeDS/HalfedgeDS.txt index 8ddfa44e55e..b0ace46d1f9 100644 --- a/HalfedgeDS/doc/HalfedgeDS/HalfedgeDS.txt +++ b/HalfedgeDS/doc/HalfedgeDS/HalfedgeDS.txt @@ -33,17 +33,17 @@ structure is meant as an implementation layer. See for example the `Polyhedron_3` class in Chapter \ref chapterPolyhedron "Polyhedral Surface". The data structure provided here is also known as the -FE-structure \cite w-ebdss-85, as -halfedges \cite m-ism-88, \cite cgal:bfh-mgedm-95 or as the doubly connected edge -list (DCEL) \cite bkos-cgaa-97, although the original reference for -the DCEL \cite mp-fitcp-78 describes a different data structure. The +FE-structure \cgalCite{w-ebdss-85}, as +halfedges \cgalCite{m-ism-88}, \cgalCite{cgal:bfh-mgedm-95} or as the doubly connected edge +list (DCEL) \cgalCite{bkos-cgaa-97}, although the original reference for +the DCEL \cgalCite{mp-fitcp-78} describes a different data structure. The halfedge data structure can also be seen as one of the variants of the -quad-edge data structure \cite gs-pmgsc-85. In general, the quad-edge +quad-edge data structure \cgalCite{gs-pmgsc-85}. In general, the quad-edge data can represent non-orientable 2-manifolds, but the variant here is restricted to orientable 2-manifolds only. An overview and comparison of these different data structures together with a thorough description of the design implemented here can be found -in \cite k-ugpdd-99. +in \cgalCite{k-ugpdd-99}. @@ -110,7 +110,7 @@ class searches in the positive direction along the face for the previous halfedge. But if the `HalfedgeDSHalfedge::prev()` member function is provided, the `HalfedgeDS_items_decorator::find_prev()` member function simply calls it. This distinction is resolved at compile time with a technique called compile-time -tags, similar to iterator tags in \cite cgal:sl-stl-95. +tags, similar to iterator tags in \cgalCite{cgal:sl-stl-95}. The `Polyhedron_3` as an example for the third layer adds the geometric interpretation, provides an easy-to-use interface of @@ -181,10 +181,10 @@ member variable `color`. The halfedge data structure as presented here is slightly less space efficient as, for example, the winged-edge data -structure \cite b-prcv-75, the DCEL \cite mp-fitcp-78 or variants of -the quad-edge data structure \cite gs-pmgsc-85. On the other hand, +structure \cgalCite{b-prcv-75}, the DCEL \cgalCite{mp-fitcp-78} or variants of +the quad-edge data structure \cgalCite{gs-pmgsc-85}. On the other hand, it does not require any search operations during traversals. A -comparison can be found in \cite k-ugpdd-99. +comparison can be found in \cgalCite{k-ugpdd-99}. The following example trades traversal time for a compact storage representation using traditional C techniques (i.e., type casting and diff --git a/HalfedgeDS/doc/HalfedgeDS/PackageDescription.txt b/HalfedgeDS/doc/HalfedgeDS/PackageDescription.txt index 753f4e24f77..bca353bfb67 100644 --- a/HalfedgeDS/doc/HalfedgeDS/PackageDescription.txt +++ b/HalfedgeDS/doc/HalfedgeDS/PackageDescription.txt @@ -46,17 +46,17 @@ implementation layer.See for example the `Polyhedron_3` class in the package \ref Chapter_3D_Polyhedral_Surfaces "3D Polyhedral Surface". The data structure provided here is known as the -FE-structure \cite w-ebdss-85, as -halfedges \cite m-ism-88, \cite cgal:bfh-mgedm-95 or as the doubly connected edge -list (DCEL) \cite bkos-cgaa-97, although the original reference for -the DCEL \cite mp-fitcp-78 describes a related but different data +FE-structure \cgalCite{w-ebdss-85}, as +halfedges \cgalCite{m-ism-88}, \cgalCite{cgal:bfh-mgedm-95} or as the doubly connected edge +list (DCEL) \cgalCite{bkos-cgaa-97}, although the original reference for +the DCEL \cgalCite{mp-fitcp-78} describes a related but different data structure. The halfedge data structure can also be seen as one of the -variants of the quad-edge data structure \cite gs-pmgsc-85. In +variants of the quad-edge data structure \cgalCite{gs-pmgsc-85}. In general, the quad-edge data can represent non-orientable 2-manifolds, but the variant here is restricted to orientable 2-manifolds only. An overview and comparison of these different data structures together with a thorough description of the design implemented here can be -found in \cite k-ugpdd-99. +found in \cgalCite{k-ugpdd-99}. \cgalClassifedRefPages diff --git a/Inscribed_areas/doc/Inscribed_areas/CGAL/Largest_empty_iso_rectangle_2.h b/Inscribed_areas/doc/Inscribed_areas/CGAL/Largest_empty_iso_rectangle_2.h index 5f15072ce24..716236ecf76 100644 --- a/Inscribed_areas/doc/Inscribed_areas/CGAL/Largest_empty_iso_rectangle_2.h +++ b/Inscribed_areas/doc/Inscribed_areas/CGAL/Largest_empty_iso_rectangle_2.h @@ -13,7 +13,7 @@ that do not contain any point of the point set. \cgalHeading{Implementation} -The algorithm is an implementation of \cite o-naler-90. The runtime of an +The algorithm is an implementation of \cgalCite{o-naler-90}. The runtime of an insertion or a removal is \f$ O(\log n)\f$. A query takes \f$ O(n^2)\f$ worst case time and \f$ O(n \log n)\f$ expected time. The working storage is \f$ O(n)\f$. diff --git a/Inscribed_areas/doc/Inscribed_areas/CGAL/extremal_polygon_2.h b/Inscribed_areas/doc/Inscribed_areas/CGAL/extremal_polygon_2.h index ccae22f62c2..fbebf68f1d4 100644 --- a/Inscribed_areas/doc/Inscribed_areas/CGAL/extremal_polygon_2.h +++ b/Inscribed_areas/doc/Inscribed_areas/CGAL/extremal_polygon_2.h @@ -32,7 +32,7 @@ convex polygon (oriented clock- or counterclockwise). \cgalHeading{Implementation} The implementation uses monotone matrix search -\cite akmsw-gamsa-87 and has a worst case running time of \f$ O(k +\cgalCite{akmsw-gamsa-87} and has a worst case running time of \f$ O(k \cdot n + n \cdot \log n)\f$, where \f$ n\f$ is the number of vertices in \f$ P\f$. @@ -89,7 +89,7 @@ where `K` is a model of `Kernel`. \cgalHeading{Implementation} The implementation uses monotone matrix search -\cite akmsw-gamsa-87 and has a worst case running time of \f$ O(k +\cgalCite{akmsw-gamsa-87} and has a worst case running time of \f$ O(k \cdot n + n \cdot \log n)\f$, where \f$ n\f$ is the number of vertices in \f$ P\f$. @@ -158,7 +158,7 @@ defined that computes the squareroot of a number. \cgalHeading{Implementation} The implementation uses monotone matrix search -\cite akmsw-gamsa-87 and has a worst case running time of \f$ O(k +\cgalCite{akmsw-gamsa-87} and has a worst case running time of \f$ O(k \cdot n + n \cdot \log n)\f$, where \f$ n\f$ is the number of vertices in \f$ P\f$. diff --git a/Interpolation/doc/Interpolation/CGAL/interpolation_functions.h b/Interpolation/doc/Interpolation/CGAL/interpolation_functions.h index 73aad73f06c..9b6915fd478 100644 --- a/Interpolation/doc/Interpolation/CGAL/interpolation_functions.h +++ b/Interpolation/doc/Interpolation/CGAL/interpolation_functions.h @@ -67,7 +67,7 @@ generates the interpolated function value computed by Farin's interpolant. \pre `norm` \f$ \neq0\f$. `function_value(p).second == true` for all points `p` of the point/coordinate pairs in the range `[first, beyond)`. \pre The range `[first, beyond)` contains either one or more than three elements. The function `farin_c1_interpolation()` interpolates the function values and the -gradients that are provided by functors using the method described in \cite f-sodt-90. +gradients that are provided by functors using the method described in \cgalCite{f-sodt-90}. \cgalHeading{Parameters} diff --git a/Interpolation/doc/Interpolation/CGAL/sibson_gradient_fitting.h b/Interpolation/doc/Interpolation/CGAL/sibson_gradient_fitting.h index 8a83d3df5fc..2ac00d622e0 100644 --- a/Interpolation/doc/Interpolation/CGAL/sibson_gradient_fitting.h +++ b/Interpolation/doc/Interpolation/CGAL/sibson_gradient_fitting.h @@ -7,7 +7,7 @@ namespace CGAL { These functions approximate the gradient of a function at a point `p` given natural neighbor coordinates for `p` and its neighbors' function values. The approximation method is described -in \cite s-bdnni-81. Further functions are provided to fit the +in \cgalCite{s-bdnni-81}. Further functions are provided to fit the gradient for all data points that lie inside the convex hull of the data points. One function exists for each type of natural neighbor coordinates. @@ -42,7 +42,7 @@ provide a multiplication and addition operation with the type This function implements Sibson's gradient estimation method based on natural neighbor coordinates -\cite s-bdnni-81. +\cgalCite{s-bdnni-81}. */ /// @{ diff --git a/Interpolation/doc/Interpolation/CGAL/surface_neighbor_coordinates_3.h b/Interpolation/doc/Interpolation/CGAL/surface_neighbor_coordinates_3.h index 94ba0120d00..40fddc7b39d 100644 --- a/Interpolation/doc/Interpolation/CGAL/surface_neighbor_coordinates_3.h +++ b/Interpolation/doc/Interpolation/CGAL/surface_neighbor_coordinates_3.h @@ -10,7 +10,7 @@ the surface. The coordinates are computed from the intersection of the Voronoi cell of the query point `p` with the tangent plane to the surface at `p`. If the sampling is sufficiently dense, the coordinate system meets the properties described in the manual pages -and in \cite bf-lcss-02,\cite cgal:f-csapc-03. The query +and in \cgalCite{bf-lcss-02},\cgalCite{cgal:f-csapc-03}. The query point `p` needs to lie inside the convex hull of the projection of the sample points onto the tangent plane at `p`. diff --git a/Interpolation/doc/Interpolation/CGAL/surface_neighbors_3.h b/Interpolation/doc/Interpolation/CGAL/surface_neighbors_3.h index fa69d67ead2..1b57660427d 100644 --- a/Interpolation/doc/Interpolation/CGAL/surface_neighbors_3.h +++ b/Interpolation/doc/Interpolation/CGAL/surface_neighbors_3.h @@ -9,7 +9,7 @@ Given a set of sample points issued from a surface and a query point the surface within the sample points. If the sampling is sufficiently dense, the neighbors are provably close to the point `p` on the surface (cf. the manual pages and -\cite bf-lcss-02,\cite cgal:f-csapc-03). They are defined to +\cgalCite{bf-lcss-02},\cgalCite{cgal:f-csapc-03}). They are defined to be the neighbors of `p` in the regular triangulation dual to the power diagram which is equivalent to the intersection of the Voronoi cell of the query point `p` with the tangent plane to the diff --git a/Interpolation/doc/Interpolation/Interpolation.txt b/Interpolation/doc/Interpolation/Interpolation.txt index 27dc07b94cf..51fe4510492 100644 --- a/Interpolation/doc/Interpolation/Interpolation.txt +++ b/Interpolation/doc/Interpolation/Interpolation.txt @@ -37,7 +37,7 @@ at \f$ \mathbf{p_i}\f$. It is denoted \f$ \mathbf{g_i}= \nabla \subsection InterpolationIntroduction Introduction Natural neighbor interpolation has been introduced by Sibson -\cite s-bdnni-81 to interpolate multivariate scattered data. Given +\cgalCite{s-bdnni-81} to interpolate multivariate scattered data. Given a set of data points \f$ \mathcal{P}\f$, the natural neighbor coordinates associated to \f$ \mathcal{P}\f$ are defined from the Voronoi diagram of \f$ \mathcal{P}\f$. When simulating the insertion of a query point @@ -60,8 +60,8 @@ with respect to the data point \f$ \mathbf{p_i}\in \mathcal{P}\f$ is defined by A two-dimensional example is depicted in \cgalFigureRef{fignn_coords}. -Various papers (\cite s-vidt-80, \cite f-sodt-90, -\cite cgal:p-plcbd-93, \cite b-scaps-97, \cite hs-vbihc-00) show that +Various papers (\cgalCite{s-vidt-80}, \cgalCite{f-sodt-90}, +\cgalCite{cgal:p-plcbd-93}, \cgalCite{b-scaps-97}, \cgalCite{hs-vbihc-00}) show that the natural neighbor coordinates have the following properties:
    1. \f$ \mathbf{x} = \sum_{i=1}^n \lambda_i(\mathbf{x}) \mathbf{p_i}\f$ @@ -84,7 +84,7 @@ The natural neighbor coordinate of \f$ \mathbf{x}\f$ with respect to these endpo \f$ \lambda_q(\mathbf{x}) = \frac{\|\mathbf{x} - \mathbf{p}\| }{ \|\mathbf{q} - \mathbf{p}\|} \f$ -Furthermore, Piper \cite cgal:p-plcbd-93 shows that the coordinate +Furthermore, Piper \cgalCite{cgal:p-plcbd-93} shows that the coordinate functions are continuous in the convex hull of \f$ \mathcal{P}\f$ and continuously differentiable except on the data points \f$ \mathcal{P}\f$.
      @@ -137,9 +137,9 @@ issued from a surface \f$ \mathcal{S}\f$ and given a query point \f$ \mathbf{x}\f$ on \f$ \mathcal{S}\f$. We suppose that \f$ \mathcal{S}\f$ is a closed and compact surface of \f$ \mathbb{R}^3\f$, and let \f$ \mathcal{P}= \{\mathbf{p_1}, \ldots,\mathbf{p_n}\}\f$ be an \f$ \epsilon\f$-sample of -\f$ \mathcal{S}\f$ (refer to Amenta and Bern \cite ab-srvf-99). The +\f$ \mathcal{S}\f$ (refer to Amenta and Bern \cgalCite{ab-srvf-99}). The concepts are based on the definition of Boissonnat and Flötotto -\cite bf-lcss-02, \cite cgal:f-csapc-03. Both references +\cgalCite{bf-lcss-02}, \cgalCite{cgal:f-csapc-03}. Both references contain a thorough description of the requirements and the mathematical properties. @@ -149,7 +149,7 @@ Two observations lead to the definition of surface neighbors and surface neighbor coordinates: First, it is clear that the tangent plane \f$ \mathcal{T}_x\f$ of the surface \f$ \mathcal{S}\f$ at the point \f$ \mathbf{x} \in \mathcal{S}\f$ approximates \f$ \mathcal{S}\f$ in the -neighborhood of \f$ \mathbf{x}\f$. It has been shown in \cite bf-lcss-02 +neighborhood of \f$ \mathbf{x}\f$. It has been shown in \cgalCite{bf-lcss-02} that, if the surface \f$ \mathcal{S}\f$ is well sampled with respect to the curvature and the local thickness of \f$ \mathcal{S}\f$, i.e.\ it is an \f$ \epsilon\f$-sample, the intersection of the tangent plane \f$ \mathcal{T}_x\f$ with the Voronoi cell of @@ -237,7 +237,7 @@ provided. \subsubsection InterpolationLinearPrecisionInterpolation Linear Precision Interpolation -Sibson \cite s-bdnni-81 defines a very simple interpolant that +Sibson \cgalCite{s-bdnni-81} defines a very simple interpolant that re-produces linear functions exactly. The interpolation of \f$ \Phi(\mathbf{x})\f$ is given as the linear combination of the neighbors' function values weighted by the coordinates: @@ -253,7 +253,7 @@ called. \subsubsection InterpolationSibson Sibson's C^1 Continuous Interpolant -In \cite s-bdnni-81, Sibson describes a second interpolation method +In \cgalCite{s-bdnni-81}, Sibson describes a second interpolation method that relies also on the function gradient \f$ \mathbf{g_i}\f$ for all \f$ \mathbf{p_i} \in \mathcal{P}\f$. It is \f$ C^1\f$ continuous with gradient \f$ \mathbf{g_i}\f$ at \f$ \mathbf{p_i}\f$. Spherical quadrics of the form \f$ \Phi(\mathbf{x}) =a + \mathbf{b}^t \mathbf{x} +\gamma\ \mathbf{x}^t\mathbf{x}\f$ are reproduced @@ -261,7 +261,7 @@ exactly. The proof relies on the barycentric coordinate property of the natural neighbor coordinates and assumes that the gradient of \f$ \Phi\f$ at the data points is known or approximated from the function values as -described in \cite s-bdnni-81 (see Section \ref sgradient_fitting). +described in \cgalCite{s-bdnni-81} (see Section \ref sgradient_fitting). Sibson's \f$ Z^1\f$ interpolant is a combination of the linear interpolant \f$ Z^0\f$ and an interpolant \f$ \xi\f$ which is the weighted sum of the first @@ -289,19 +289,19 @@ where in Sibson's original work, demanding on the number type because it avoids the square-root computation needed to compute the distance \f$ \|\mathbf{x} - \mathbf{p_i}\|\f$. The theoretical guarantees are the same (see -\cite cgal:f-csapc-03). Simply, the smaller the slope of \f$ f\f$ +\cgalCite{cgal:f-csapc-03}). Simply, the smaller the slope of \f$ f\f$ around \f$ f(0)\f$, the faster the interpolant approaches \f$ \xi_i\f$ as \f$ \mathbf{x} \rightarrow \mathbf{p_i}\f$. \subsubsection InterpolationFarin Farin's C^1 Continuous Interpolant -Farin \cite f-sodt-90 extended Sibson's work and realizes a \f$ C^1\f$ +Farin \cgalCite{f-sodt-90} extended Sibson's work and realizes a \f$ C^1\f$ continuous interpolant by embedding natural neighbor coordinates in the Bernstein-Bézier representation of a cubic simplex. If the gradient of \f$ \Phi\f$ at the data points is known, this interpolant reproduces quadratic functions exactly. The function gradient can be approximated from the function values by Sibson's method -\cite s-bdnni-81 (see Section \ref sgradient_fitting) which is exact only +\cgalCite{s-bdnni-81} (see Section \ref sgradient_fitting) which is exact only for spherical quadrics. \subsubsection InterpolationQuadraticPrecisionInterpolants Quadratic Precision Interpolants diff --git a/Interpolation/doc/Interpolation/PackageDescription.txt b/Interpolation/doc/Interpolation/PackageDescription.txt index b0631c2a206..4decaefe06d 100644 --- a/Interpolation/doc/Interpolation/PackageDescription.txt +++ b/Interpolation/doc/Interpolation/PackageDescription.txt @@ -69,7 +69,7 @@ two-dimensional power diagram for weighted points (i. e., from their regular triangulation). Natural neighbor coordinates on closed and well-sampled surfaces can also be computed if the normal to the surface at the query point is known. The latter coordinates are only -approximately barycentric, see \cite bf-lcss-02. +approximately barycentric, see \cgalCite{bf-lcss-02}. For a more thorough introduction see the user manual. diff --git a/Interval_skip_list/doc/Interval_skip_list/Interval_skip_list.txt b/Interval_skip_list/doc/Interval_skip_list/Interval_skip_list.txt index 76dfaff4f0c..73abc345924 100644 --- a/Interval_skip_list/doc/Interval_skip_list/Interval_skip_list.txt +++ b/Interval_skip_list/doc/Interval_skip_list/Interval_skip_list.txt @@ -19,9 +19,9 @@ mix calls to the methods `insert(..)`, `remove(..)`, The interval skip list class is parameterized with an interval class. -The data structure was introduced by Hanson \cite h-islds-91, and it is called +The data structure was introduced by Hanson \cgalCite{h-islds-91}, and it is called interval skip list, because it is an extension of the randomized list -structure known as skip list \cite p-slpab-90. +structure known as skip list \cgalCite{p-slpab-90}. \section Interval_skip_listExample Example Programs diff --git a/Interval_skip_list/doc/Interval_skip_list/PackageDescription.txt b/Interval_skip_list/doc/Interval_skip_list/PackageDescription.txt index 63f5811a664..30af0633afc 100644 --- a/Interval_skip_list/doc/Interval_skip_list/PackageDescription.txt +++ b/Interval_skip_list/doc/Interval_skip_list/PackageDescription.txt @@ -18,8 +18,8 @@ \cgalPkgShortInfoEnd \cgalPkgDescriptionEnd -This chapter presents the interval skip list introduced by Hanson \cite h-islds-91, -and derived from the skip list data structure \cite p-slpab-90. +This chapter presents the interval skip list introduced by Hanson \cgalCite{h-islds-91}, +and derived from the skip list data structure \cgalCite{p-slpab-90}. The data structure stores intervals and allows to perform stabbing queries, that is to test whether a point is covered by any of the intervals. diff --git a/Jet_fitting_3/doc/Jet_fitting_3/Jet_fitting_3.txt b/Jet_fitting_3/doc/Jet_fitting_3/Jet_fitting_3.txt index 05711fd6122..20760ae2745 100644 --- a/Jet_fitting_3/doc/Jet_fitting_3/Jet_fitting_3.txt +++ b/Jet_fitting_3/doc/Jet_fitting_3/Jet_fitting_3.txt @@ -34,7 +34,7 @@ estimating first and second order differential quantities is sufficient. However, some applications involving shape analysis require estimating third and fourth order differential quantities. Many different estimators have been proposed in the vast literature of -applied geometry \cite cgal:p-smrqt-01 (section 3, page 7), and all +applied geometry \cgalCite{cgal:p-smrqt-01} (section 3, page 7), and all of them need to define a neighborhood around the point at which the estimation is computed. Our method relies on smooth differential geometry calculations, carried out on smooth objects fitted from @@ -52,7 +52,7 @@ properties, so that any estimation method must come with an asymptotic convergence analysis of the results returned. For the method developed in this \cgal package, the interested will find such an analysis in -\cite cgal:cp-edqpf-05, (Theorem 3) - it should be stressed +\cgalCite{cgal:cp-edqpf-05}, (Theorem 3) - it should be stressed the error bounds proved therein are optimal. On the other hand, any estimation method may be applied to arbitrarily @@ -140,7 +140,7 @@ approximation reduces to linear algebra operations.
    Further details can be found in section \ref Jet_fitting_3Mathematical and in -\cite cgal:cp-edqpf-05 (section 6). +\cgalCite{cgal:cp-edqpf-05} (section 6). \subsection secdegcases Degenerate Cases @@ -151,7 +151,7 @@ cases: vector may not be good. The nearer this direction to the tangent plane the worse the estimation. -
  • As observed in \cite cgal:cp-edqpf-05 (section 3.1), the +
  • As observed in \cgalCite{cgal:cp-edqpf-05} (section 3.1), the interpolating problem is not well posed if the points project, into the fitting frame, onto an algebraic curve of degree \f$ d\f$. More generally, the problem is ill posed if the condition number is too @@ -429,7 +429,7 @@ definite positive when \f$ M\f$ has full rank. The advantages of the \f$ SVD\f$ is that it works directly on the rectangular system and gives the condition number of the system. For more on these alternatives, see -\cite gl-mc-83 (Chap. 5). +\cgalCite{gl-mc-83} (Chap. 5). \subsection Jet_fitting_3PrincipalCurvatureDirections Principal Curvature / Directions @@ -458,7 +458,7 @@ estimation is performed, is \f$ (0,0,A_{0,0})\f$.
  • The normal is \f$ n=(-A_{1,0},-A_{0,1},1)/\sqrt{A_{1,0}^2+A_{0,1}^2+1}\f$.
  • Curvature related properties are retrieved resorting to -standard differential calculus \cite c-dgcs-76 (Chap. 3). More precisely, the +standard differential calculus \cgalCite{c-dgcs-76} (Chap. 3). More precisely, the Weingarten operator \f$ W=-I^{-1}II\f$ is first computed in the basis of the tangent plane \f$ \{ (1,0,A_{1,0}), (0,1,A_{0,1}) \}\f$. We compute an orthonormal basis of the tangent plane using the Gram-Schmidt diff --git a/Kernel_23/doc/Kernel_23/CGAL/Filtered_kernel.h b/Kernel_23/doc/Kernel_23/CGAL/Filtered_kernel.h index 3824706ee10..3beb683606c 100644 --- a/Kernel_23/doc/Kernel_23/CGAL/Filtered_kernel.h +++ b/Kernel_23/doc/Kernel_23/CGAL/Filtered_kernel.h @@ -4,7 +4,7 @@ namespace CGAL { /*! \ingroup kernel_classes -\brief `Filtered_kernel_adaptor` is a kernel that uses the filtering technique from \cite cgal:bbp-iayed-01 to obtain a kernel with exact and efficient predicate functors. +\brief `Filtered_kernel_adaptor` is a kernel that uses the filtering technique from \cgalCite{cgal:bbp-iayed-01} to obtain a kernel with exact and efficient predicate functors. \details The geometric constructions are exactly those @@ -53,10 +53,10 @@ namespace CGAL { \ingroup kernel_classes `Filtered_kernel` is a kernel that uses the filtering technique based -on interval arithmetic from \cite cgal:bbp-iayed-01 to achieve +on interval arithmetic from \cgalCite{cgal:bbp-iayed-01} to achieve exact and efficient predicates. In addition, a few selected important predicates are implemented using the formally proved, semi-static, filtering -techniques from \cite cgal:mp-fcafg-05. +techniques from \cgalCite{cgal:mp-fcafg-05}. The geometric constructions are exactly those of the kernel `CK`, which means that they are not necessarily exact. diff --git a/Kernel_23/doc/Kernel_23/Kernel_23.txt b/Kernel_23/doc/Kernel_23/Kernel_23.txt index f7557ff538b..747b58b6288 100644 --- a/Kernel_23/doc/Kernel_23/Kernel_23.txt +++ b/Kernel_23/doc/Kernel_23/Kernel_23.txt @@ -59,12 +59,12 @@ There are many approaches to this problem, one of them is to compute exactly (compute so accurate that all decisions made by the algorithm are exact) which is possible in many cases but more expensive than standard floating-point arithmetic. -C. M. Hoffmann \cite h-gsm-89, \cite h-pargc-89 illustrates some +C. M. Hoffmann \cgalCite{h-gsm-89}, \cgalCite{h-pargc-89} illustrates some of the problems arising in the implementation of geometric algorithms and discusses some approaches to solve them. -A more recent overview is given in \cite s-rpigc-00. +A more recent overview is given in \cgalCite{s-rpigc-00}. The exact computation paradigm is discussed by Yap and Dubé -\cite yd-ecp-95 and Yap \cite y-tegc-97. +\cgalCite{yd-ecp-95} and Yap \cgalCite{y-tegc-97}. In \cgal you can choose the underlying number types and arithmetic. You can use different types of arithmetic simultaneously and the choice can @@ -282,7 +282,7 @@ Other valid `FieldNumberType`s are `leda_rational` and If it is crucial for you that the computation is reliable, the right choice is probably a number type that guarantees exact computation. The `Filtered_kernel` provides a way to apply filtering techniques -\cite cgal:bbp-iayed-01 to achieve a kernel with exact and efficient +\cgalCite{cgal:bbp-iayed-01} to achieve a kernel with exact and efficient predicates. Still other people will prefer the built-in type double, because they need speed and can live with approximate results, or even algorithms that, from time to time, diff --git a/Kernel_d/doc/Kernel_d/Kernel_d.txt b/Kernel_d/doc/Kernel_d/Kernel_d.txt index 40bbed39524..20e3c041cb4 100644 --- a/Kernel_d/doc/Kernel_d/Kernel_d.txt +++ b/Kernel_d/doc/Kernel_d/Kernel_d.txt @@ -36,12 +36,12 @@ unexpected failures for some correct input data. There are many approaches to this problem, one of them is to compute exactly (compute so accurate that all decisions made by the algorithm are exact) which is possible in many cases but more expensive than standard -floating-point arithmetic. C. M. Hoffmann \cite h-gsm-89, \cite h-pargc-89 +floating-point arithmetic. C. M. Hoffmann \cgalCite{h-gsm-89}, \cgalCite{h-pargc-89} illustrates some of the problems arising in the implementation of geometric algorithms and discusses some approaches to solve them. A -more recent overview is given in \cite s-rpigc-00. The exact -computation paradigm is discussed by Yap and Dubé \cite yd-ecp-95 -and Yap \cite y-tegc-97. +more recent overview is given in \cgalCite{s-rpigc-00}. The exact +computation paradigm is discussed by Yap and Dubé \cgalCite{yd-ecp-95} +and Yap \cgalCite{y-tegc-97}. In \cgal you can choose the underlying number types and arithmetic. You can use different types of arithmetic simultaneously and the diff --git a/Kinetic_data_structures/doc/Kinetic_data_structures/Kinetic_data_structures.txt b/Kinetic_data_structures/doc/Kinetic_data_structures/Kinetic_data_structures.txt index 05caf8a292e..dcc272604aa 100644 --- a/Kinetic_data_structures/doc/Kinetic_data_structures/Kinetic_data_structures.txt +++ b/Kinetic_data_structures/doc/Kinetic_data_structures/Kinetic_data_structures.txt @@ -63,7 +63,7 @@ We are working on that one, but you will have to wait. \section seckds_intro An Overview of Kinetic Data Structures and Sweep Algorithms %Kinetic data structures were first introduced in by Basch et. al. in -1997 \cite cgal:bgh-dsmd-97. The idea stems from the observation that +1997 \cgalCite{cgal:bgh-dsmd-97}. The idea stems from the observation that most, if not all, computational geometry structures are built using predicates - functions on quantities defining the geometric input (e.g. point coordinates), which return a discrete set of diff --git a/Kinetic_data_structures/doc/Kinetic_framework/Kinetic_framework.txt b/Kinetic_data_structures/doc/Kinetic_framework/Kinetic_framework.txt index 300537edeb6..e39fa40155a 100644 --- a/Kinetic_data_structures/doc/Kinetic_framework/Kinetic_framework.txt +++ b/Kinetic_data_structures/doc/Kinetic_framework/Kinetic_framework.txt @@ -23,7 +23,7 @@ in Section \ref seckds_examples. The framework makes heavy use of our `Polynomial_kernel` package to provide models of the `Kinetic::FunctionKernel` concept. -The framework was first presented at ALENEX \cite cgal:gkr-cfhm-04. +The framework was first presented at ALENEX \cgalCite{cgal:gkr-cfhm-04}. \section seckds_architecture Architecture diff --git a/Matrix_search/doc/Matrix_search/CGAL/monotone_matrix_search.h b/Matrix_search/doc/Matrix_search/CGAL/monotone_matrix_search.h index cf47c09db4d..89407c234e9 100644 --- a/Matrix_search/doc/Matrix_search/CGAL/monotone_matrix_search.h +++ b/Matrix_search/doc/Matrix_search/CGAL/monotone_matrix_search.h @@ -52,7 +52,7 @@ binary function: `Matrix::Value` \f$ \times\f$ \cgalHeading{Implementation} The implementation uses an algorithm by Aggarwal -et al.\cite akmsw-gamsa-87. The runtime is linear in the number +et al.\cgalCite{akmsw-gamsa-87}. The runtime is linear in the number of rows and columns of the matrix. */ diff --git a/Matrix_search/doc/Matrix_search/CGAL/sorted_matrix_search.h b/Matrix_search/doc/Matrix_search/CGAL/sorted_matrix_search.h index 12503409271..1b62be3b7fb 100644 --- a/Matrix_search/doc/Matrix_search/CGAL/sorted_matrix_search.h +++ b/Matrix_search/doc/Matrix_search/CGAL/sorted_matrix_search.h @@ -51,7 +51,7 @@ true. \cgalHeading{Implementation} The implementation uses an algorithm by -Frederickson and Johnson\cite fj-fkppc-83, \cite fj-gsrsm-84 and runs in +Frederickson and Johnson\cgalCite{fj-fkppc-83}, \cgalCite{fj-gsrsm-84} and runs in \f$ \mathcal{O}(n \cdot k + f \cdot \log (n \cdot k))\f$, where \f$ n\f$ is the number of input matrices, \f$ k\f$ denotes the maximal dimension of any input matrix and \f$ f\f$ the time needed for one feasibility test. diff --git a/Mesh_2/doc/Mesh_2/Mesh_2.txt b/Mesh_2/doc/Mesh_2/Mesh_2.txt index 5a1226d85ea..e71d5ce71c6 100644 --- a/Mesh_2/doc/Mesh_2/Mesh_2.txt +++ b/Mesh_2/doc/Mesh_2/Mesh_2.txt @@ -7,7 +7,7 @@ namespace CGAL { \cgalAutoToc \author Laurent Rineau -This package implements Shewchuk's algorithm \cite s-mgdsa-00 to construct +This package implements Shewchuk's algorithm \cgalCite{s-mgdsa-00} to construct conforming triangulations and 2D meshes. Conforming triangulations will be described in Section \ref secMesh_2_conforming_triangulation and meshes in Section \ref secMesh_2_meshes. @@ -183,7 +183,7 @@ If some input angles are smaller than \f$ 60\f$ degrees, the algorithm will end up with a mesh in which some triangles violate the criteria near small input angles. This is unavoidable since small angles formed by input segments cannot be suppressed. Furthermore, it has been -shown (\cite s-mgdsa-00), that some domains with small input angles +shown (\cgalCite{s-mgdsa-00}), that some domains with small input angles cannot be meshed with angles even smaller than the small input angles. Note that if the domain is a polygonal region, the resulting mesh will satisfy size and shape criteria except for the small input angles. diff --git a/Mesh_3/doc/Mesh_3/Mesh_3.txt b/Mesh_3/doc/Mesh_3/Mesh_3.txt index 2e873731d51..5348b4b8d56 100644 --- a/Mesh_3/doc/Mesh_3/Mesh_3.txt +++ b/Mesh_3/doc/Mesh_3/Mesh_3.txt @@ -44,14 +44,14 @@ for instance in terms of sizing field or with respect to some user customized quality criteria. The meshing engine used in this mesh generator -is based on Delaunay refinement \cite c-gqmgc-93, \cite r-draq2d-95, \cite s-tmgdr-98. +is based on Delaunay refinement \cgalCite{c-gqmgc-93}, \cgalCite{r-draq2d-95}, \cgalCite{s-tmgdr-98}. It uses the notion of restricted Delaunay triangulation -to approximate 1-dimensional curve segments and surface patches \cite cgal:bo-pgsms-05. +to approximate 1-dimensional curve segments and surface patches \cgalCite{cgal:bo-pgsms-05}. Before the refinement, a mechanism of protecting balls is set up on 1-dimensional features, if any, to ensure a fair representation of those features in the mesh, and also to guarantee the termination of the refinement process, whatever may be the input geometry, in particular whatever small angles -the boundary and subdivision surface patches may form \cite cgal:cdl-pdma-07, \cite cgal:cdr-drpsc-07. +the boundary and subdivision surface patches may form \cgalCite{cgal:cdl-pdma-07}, \cgalCite{cgal:cdr-drpsc-07}. The Delaunay refinement is followed by a mesh optimization phase to remove slivers and provide a good quality mesh. @@ -184,7 +184,7 @@ the corresponding points are inserted into the Delaunay triangulation from the start. If the domain has 1-dimensional exposed features, -the method of protecting balls \cite cgal:cdr-drpsc-07, \cite cgal:cdl-pdma-07 +the method of protecting balls \cgalCite{cgal:cdr-drpsc-07}, \cgalCite{cgal:cdl-pdma-07} is used to achieve an accurate representation of those features in the mesh and to guarantee that the refinement process terminates whatever may be the dihedral angles formed by input surface patches incident to a @@ -238,7 +238,7 @@ a perturber and an exuder. The Lloyd and odt-smoother are global optimizers moving the mesh vertices to minimize a mesh energy. Those optimizers are described respectively in -\cite cgal:dfg-cvtaa-99t, \cite cgal:dw-tmgob-02 and in \cite cgal::c-mssbo-04, \cite cgal:acyd-vtm-05. +\cgalCite{cgal:dfg-cvtaa-99t}, \cgalCite{cgal:dw-tmgob-02} and in \cgalCite{cgal::c-mssbo-04}, \cgalCite{cgal:acyd-vtm-05}. In both cases the mesh energy is the `L1` error resulting from the interpolation of the function \f$ f(x) =x^2\f$ by a piecewise linear function. @@ -263,9 +263,9 @@ to be very efficient as a preliminary step of optimization, as they tend to enha efficiency of the perturber and/or exuder applied next, see \cgalFigureRef{figureoptimization} The perturber and the exuder focus on improving the worst mesh elements. -The perturber \cite cgal:tsa-ps3dd-09 improves the meshes by local changes +The perturber \cgalCite{cgal:tsa-ps3dd-09} improves the meshes by local changes in the vertices positions -aiming to make sliver disappear. The exuder \cite cgal:cdeft-slive-00 +aiming to make sliver disappear. The exuder \cgalCite{cgal:cdeft-slive-00} chases the remaining slivers by re-weighting mesh vertices with optimal weights. @@ -980,33 +980,33 @@ vertices/second \subsection Mesh_3TheoreticalFoundations Theoretical Foundations The \cgal mesh generation package implements a meshing engine based -on the method of Delaunay refinement introduced by Chew \cite c-gqmgc-93 and Ruppert \cite r-draq2d-95 -and pioneered in 3D by Shewchuk \cite s-tmgdr-98. +on the method of Delaunay refinement introduced by Chew \cgalCite{c-gqmgc-93} and Ruppert \cgalCite{r-draq2d-95} +and pioneered in 3D by Shewchuk \cgalCite{s-tmgdr-98}. It uses the notion of restricted Delaunay triangulation to approximate 1-dimensional curved features and curved surface patches -and rely on the work of Boissonnat and Oudot \cite cgal:bo-pgsms-05 -and Oudot et al. \cite cgal:ory-mvbss-05 +and rely on the work of Boissonnat and Oudot \cgalCite{cgal:bo-pgsms-05} +and Oudot et al. \cgalCite{cgal:ory-mvbss-05} to achieve accurate representation of boundary and subdividing surfaces in the mesh. The mechanism of protecting balls, used to ensure a fair representation of 1-dimensional features, if any, and the termination of the refinement process whatever may be the input geometry, in particular whatever small dihedral angles may form the boundary and subdivision surface patches, -was pioneered by Cheng et al. \cite cgal:cdr-drpsc-07 and further experimented by Dey, Levine et al. -\cite cgal:cdl-pdma-07. +was pioneered by Cheng et al. \cgalCite{cgal:cdr-drpsc-07} and further experimented by Dey, Levine et al. +\cgalCite{cgal:cdl-pdma-07}. The optimization phase involves global optimization processes, a perturbation process -and a sliver exudation process. The global optimizers are based on Lloyd smoothing \cite cgal:dfg-cvtaa-99t, \cite cgal:dw-tmgob-02 -and odt smoothing \cite cgal::c-mssbo-04, \cite cgal:acyd-vtm-05, where odt means +and a sliver exudation process. The global optimizers are based on Lloyd smoothing \cgalCite{cgal:dfg-cvtaa-99t}, \cgalCite{cgal:dw-tmgob-02} +and odt smoothing \cgalCite{cgal::c-mssbo-04}, \cgalCite{cgal:acyd-vtm-05}, where odt means optimal Delaunay triangulation. The perturbation process -is mainly based on the work of Tournois \cite cgal:t-om-09 -and Tournois et al. \cite cgal:twad-iropitmg-09, +is mainly based on the work of Tournois \cgalCite{cgal:t-om-09} +and Tournois et al. \cgalCite{cgal:twad-iropitmg-09}, while the exudation process is, the now famous, optimization by weighting described -in Edelsbrunner et al. \cite cgal:cdeft-slive-00. +in Edelsbrunner et al. \cgalCite{cgal:cdeft-slive-00}. \subsection Mesh_3ImplementationHistory Implementation History Work on the package `Mesh_3` started during the PhD thesis of Laurent Rineau advised by Mariette Yvinec. A code prototype, together -with a first version of design and specifications \cite cgal:ry-gsddrm-06 +with a first version of design and specifications \cgalCite{cgal:ry-gsddrm-06} came out of their collaboration. From the beginning of 2009, most of the work has been performed by Stéphane @@ -1022,7 +1022,7 @@ and appeared first in release 3.6 of \cgal. In collaboration with Laurent Rineau, Stéphane also added demos and examples. After some experiments on medical imaging data performed by -Dobrina Boltcheva et al. \cite cgal:byb-mgmmi-09, \cite cgal:-byb-fpdmgmmi-09, the handling +Dobrina Boltcheva et al. \cgalCite{cgal:byb-mgmmi-09}, \cgalCite{cgal:-byb-fpdmgmmi-09}, the handling of 1-dimensional features was worked out by Laurent Rineau, Stéphane Tayeb and Mariette Yvinec. It appeared first in the release 3.8 of \cgal. diff --git a/Minkowski_sum_2/doc/Minkowski_sum_2/CGAL/Polygon_convex_decomposition_2.h b/Minkowski_sum_2/doc/Minkowski_sum_2/CGAL/Polygon_convex_decomposition_2.h index 58aa684fc7e..eef8d2ea2ba 100644 --- a/Minkowski_sum_2/doc/Minkowski_sum_2/CGAL/Polygon_convex_decomposition_2.h +++ b/Minkowski_sum_2/doc/Minkowski_sum_2/CGAL/Polygon_convex_decomposition_2.h @@ -7,7 +7,7 @@ namespace CGAL { The `Greene_convex_decomposition_2` class implements the approximation algorithm of Greene for the decomposition of an input polygon into convex -sub-polygons \cite g-dpcp-83. This algorithm takes \f$ O(n \log n)\f$ +sub-polygons \cgalCite{g-dpcp-83}. This algorithm takes \f$ O(n \log n)\f$ time and \f$ O(n)\f$ space, where \f$ n\f$ is the size of the input polygon, and outputs a decomposition whose size is guaranteed to be no more than four times the size of the optimal decomposition. @@ -41,7 +41,7 @@ namespace CGAL { The `Hertel_Mehlhorn_convex_decomposition_2` class implements the approximation algorithm of Hertel and Mehlhorn for decomposing a polygon into convex -sub-polygons \cite hm-ftsp-83. This algorithm constructs a +sub-polygons \cgalCite{hm-ftsp-83}. This algorithm constructs a triangulation of the input polygon and proceeds by removing unnecessary triangulation edges. Given the triangulation, the algorithm requires \f$ O(n)\f$ time and space to construct a convex @@ -78,7 +78,7 @@ namespace CGAL { The `Optimal_convex_decomposition_2` class provides an implementation of Greene's dynamic programming algorithm for optimal decomposition of a -polygon into convex sub-polygons \cite g-dpcp-83. Note that +polygon into convex sub-polygons \cgalCite{g-dpcp-83}. Note that this algorithm requires \f$ O(n^4)\f$ time and \f$ O(n^3)\f$ space in the worst case, where \f$ n\f$ is the size of the input polygon. diff --git a/Minkowski_sum_2/doc/Minkowski_sum_2/CGAL/Small_side_angle_bisector_decomposition_2.h b/Minkowski_sum_2/doc/Minkowski_sum_2/CGAL/Small_side_angle_bisector_decomposition_2.h index cd1a263fb63..d507f0ef196 100644 --- a/Minkowski_sum_2/doc/Minkowski_sum_2/CGAL/Small_side_angle_bisector_decomposition_2.h +++ b/Minkowski_sum_2/doc/Minkowski_sum_2/CGAL/Small_side_angle_bisector_decomposition_2.h @@ -7,7 +7,7 @@ namespace CGAL { The `Small_side_angle_bisector_decomposition_2` class implements a simple yet efficient heuristic for decomposing an input polygon into convex sub-polygons. It is based -on the algorithm suggested by Flato and Halperin \cite fh-recpm-00, +on the algorithm suggested by Flato and Halperin \cgalCite{fh-recpm-00}, but without introducing Steiner points. The algorithm operates in two major steps. In the first step, it tries to subdivide the polygon by connect two reflex vertices with an edge. When this is not possible any diff --git a/Minkowski_sum_2/doc/Minkowski_sum_2/Minkowski_sum_2.txt b/Minkowski_sum_2/doc/Minkowski_sum_2/Minkowski_sum_2.txt index 833a1bafc34..bd4d67934a7 100644 --- a/Minkowski_sum_2/doc/Minkowski_sum_2/Minkowski_sum_2.txt +++ b/Minkowski_sum_2/doc/Minkowski_sum_2/Minkowski_sum_2.txt @@ -60,7 +60,7 @@ Let us denote the vertices of the input polygons by \f$ Q = \left( q_0, \ldots, q_{n-1} \right)\f$. We assume that both \f$ P\f$ and \f$ Q\f$ have positive orientations (i.e.\ their boundaries wind in a counterclockwise order around their interiors) and compute the convolution of the two polygon -boundaries. The convolution of these two polygons \cite grs-kfcg-83, +boundaries. The convolution of these two polygons \cgalCite{grs-kfcg-83}, denoted \f$ P * Q\f$, is a collection of line segments of the form \f$ [p_i + q_j, p_{i+1} + q_j]\f$, \cgalFootnote{Throughout this chapter, we increment or decrement an index of a vertex modulo the size of the polygon.} @@ -146,31 +146,31 @@ The Minkowski-sum package includes four models of the concept `PolygonConvexDecomposition_2`. The first three are classes that wrap the decomposition functions included in the Planar Polygon Partitioning package, while the fourth is an implementation of a decomposition algorithm -introduced in \cite cgal:afh-pdecm-02. The convex decompositions that it +introduced in \cgalCite{cgal:afh-pdecm-02}. The convex decompositions that it creates usually yield efficient running times for Minkowski sum computations:
    • The class `Optimal_convex_decomposition_2` uses the -dynamic-programming algorithm of Greene \cite g-dpcp-83 for computing an +dynamic-programming algorithm of Greene \cgalCite{g-dpcp-83} for computing an optimal decomposition of a polygon into a minimal number of convex sub-polygons. The main drawback of this strategy is that it runs in \f$ O(n^4)\f$ time and \f$ O(n^3)\f$ in the worst case,where \f$ n\f$ is the number of vertices in the input polygon.
    • The class `Hertel_Mehlhorn_convex_decomposition_2` implements the -approximation algorithm suggested by Hertel and Mehlhorn \cite hm-ftsp-83, +approximation algorithm suggested by Hertel and Mehlhorn \cgalCite{hm-ftsp-83}, which triangulates the input polygon and proceeds by throwing away unnecessary triangulation edges. This algorithm requires \f$ O(n)\f$ time and space and guarantees that the number of sub-polygons it generates is not more than four times the optimum.
    • The class `Greene_convex_decomposition_2` is an implementation of -Greene's approximation algorithm \cite g-dpcp-83, which computes a +Greene's approximation algorithm \cgalCite{g-dpcp-83}, which computes a convex decomposition of the polygon based on its partitioning into \f$ y\f$-monotone polygons. This algorithm runs in \f$ O(n \log n)\f$ time and \f$ O(n)\f$ space, and has the same approximation guarantee as Hertel and Mehlhorn's algorithm.
    • The class `Small_side_angle_bisector_decomposition_2` uses a heuristic improvement to the angle-bisector decomposition method -suggested by Chazelle and Dobkin \cite cd-ocd-85, which runs in +suggested by Chazelle and Dobkin \cgalCite{cd-ocd-85}, which runs in \f$ O(n^2)\f$ time. It starts by examining each pair of reflex vertices in the input polygon such that the entire interior of the diagonal connecting these vertices is contained in the polygon. Out of all diff --git a/Minkowski_sum_3/doc/Minkowski_sum_3/Minkowski_sum_3.txt b/Minkowski_sum_3/doc/Minkowski_sum_3/Minkowski_sum_3.txt index 57575d787c4..d53329fee70 100644 --- a/Minkowski_sum_3/doc/Minkowski_sum_3/Minkowski_sum_3.txt +++ b/Minkowski_sum_3/doc/Minkowski_sum_3/Minkowski_sum_3.txt @@ -16,8 +16,8 @@ The Minkowski sum of a spoon and a star. The Minkowski sum of two point sets \f$ P\f$ and \f$ Q\f$ in \f$ \mathbb{R}^d\f$, denoted by \f$ P \oplus Q\f$, is defined as the set \f$ \{p+q:p \in P, q \in Q \}\f$. Minkowski sums are used in a wide range of applications such as -robot motion planning \cite l-rmp-91 and computer-aided -design \cite cgal:ek-sicad-99. \cgalFigureRef{figmotionPlanning} shows +robot motion planning \cgalCite{l-rmp-91} and computer-aided +design \cgalCite{cgal:ek-sicad-99}. \cgalFigureRef{figmotionPlanning} shows an example how Minkowski sums can be used to plan the motion of a translational robot. We want to know which are legal positions of the robot, and where can the robot go to from a specified starting @@ -59,7 +59,7 @@ The decomposition method for computing the Minkowski sum of non-convex polyhedra makes use of the fact that Minkowski sums of convex polyhedra are rather easy to compute. It decomposes both polyhedra into convex pieces, computes all pairwise Minkowski sums of the convex -pieces, and merges the pairwise sums \cite bkos-cgaa-97. +pieces, and merges the pairwise sums \cgalCite{bkos-cgaa-97}. \cgalFigureBegin{Mink3decomp,decomposition_method.png} The decomposition method decomposes both input polyhedra into convex parts, computes all pairwise Minkowski sums of the convex parts, and merges the pairwise sums. diff --git a/Miscellany/doc/Miscellany/CGAL/Unique_hash_map.h b/Miscellany/doc/Miscellany/CGAL/Unique_hash_map.h index eab63c17eb6..2e88770e288 100644 --- a/Miscellany/doc/Miscellany/CGAL/Unique_hash_map.h +++ b/Miscellany/doc/Miscellany/CGAL/Unique_hash_map.h @@ -30,7 +30,7 @@ rehashing when set to the number of expected elements in the map. The design is derived from the \stl `hash_map` and the \leda type `map`. Its specialization on insertion only and unique hash values allow for a more time- and space-efficient implementation, see also -\cite mn-lpcgc-00, Chapter 5. This implementation makes also use +\cgalCite{mn-lpcgc-00}, Chapter 5. This implementation makes also use of sentinels that lead to defined keys that have not been inserted. */ diff --git a/Miscellany/doc/Miscellany/Miscellany.txt b/Miscellany/doc/Miscellany/Miscellany.txt index 4215f5966e9..1955ed51653 100644 --- a/Miscellany/doc/Miscellany/Miscellany.txt +++ b/Miscellany/doc/Miscellany/Miscellany.txt @@ -82,7 +82,7 @@ Class diagram for the modifier. It illustrates the safe access to an internal re \cgalFigureEnd The solution provided here is inspired by the strategy -pattern \cite cgal:ghjv-dpero-95, though it serves a different intent. +pattern \cgalCite{cgal:ghjv-dpero-95}, though it serves a different intent. The abstract base class `Modifier_base` declares a pure virtual member function `operator()` that accepts a single reference parameter of the diff --git a/Modular_arithmetic/doc/Modular_arithmetic/Modular_arithmetic.txt b/Modular_arithmetic/doc/Modular_arithmetic/Modular_arithmetic.txt index fa7aa889993..129a7b5f9ab 100644 --- a/Modular_arithmetic/doc/Modular_arithmetic/Modular_arithmetic.txt +++ b/Modular_arithmetic/doc/Modular_arithmetic/Modular_arithmetic.txt @@ -77,10 +77,10 @@ next nearest value. This can be ensured using `Protect_FPU_rounding` with \section Modular_arithmeticDesign Design and Implementation History The class `Residue` is based on the C-code of Sylvain Pion et. al. -as it was presented in \cite bepp-sdrns-99. +as it was presented in \cgalCite{bepp-sdrns-99}. The remaining part of the package is the result of the integration process -of the NumeriX library of Exacus \cite beh-eeeafcs-05 into \cgal. +of the NumeriX library of Exacus \cgalCite{beh-eeeafcs-05} into \cgal. */ } /* namespace CGAL */ diff --git a/Nef_3/doc/Nef_3/Nef_3.txt b/Nef_3/doc/Nef_3/Nef_3.txt index 6b2b5bbf13d..fa8845b8f09 100644 --- a/Nef_3/doc/Nef_3/Nef_3.txt +++ b/Nef_3/doc/Nef_3/Nef_3.txt @@ -20,7 +20,7 @@ namespace CGAL { In solid modeling, two major representation schemes are used: constructive solid geometry (CSG) and boundary representations (B-rep). Both have inherent strengths and -weaknesses, see \cite cgal:h-gsmi-89 for a discussion. +weaknesses, see \cgalCite{cgal:h-gsmi-89} for a discussion. In CSG a solid is represented as a set-theoretic Boolean combination of primitive solid objects, such as blocks, prisms, cylinders, or @@ -240,7 +240,7 @@ which are excluded from the volume. For each face we store a label, e.g., a set-selection mark, which indicates whether the face is part of the solid or if it is excluded. We call the resulting data structure Selective Nef -Complex, SNC for short \cite cgal:ghhkm-bosnc-03. However, in +Complex, SNC for short \cgalCite{cgal:ghhkm-bosnc-03}. However, in \cgal we identify the names and call the SNC data structure `Nef_polyhedron_3`. @@ -266,7 +266,7 @@ unspecified value, which is finite but larger than all coordinate values that may occur in the bounded part of the polyhedron. As a result, each Nef polyhedron becomes bounded. We call the boundary of the bounding volume the infimaximal -box \cite cgal:sm-iftml-00. +box \cgalCite{cgal:sm-iftml-00}. We clip lines and rays at the infimaximal box. The intersection points with the infimaximal box are called non-standard points, which @@ -290,7 +290,7 @@ polynomial), and runtime performance. \section sectoinRegularized Regularized Set Operations Since manifolds are not closed under Boolean operations, Requicha -proposes to use regularized set operations \cite cgal:km-st-76, +proposes to use regularized set operations \cgalCite{cgal:km-st-76}, cgal:r-rrstm-80. A set is regular, if it equals the closure of its interior. A regularized set operation is defined as the standard set operation followed by a regularization of the result. @@ -509,7 +509,7 @@ The other shalfloop lies on the inwards oriented halffacet and is oriented inwards, too. This shalfloop belongs to the third shell. `Nef_polyhedron_3` offers a visitor interface to explore a shell -following the well-known visitor pattern \cite cgal:ghjv-dpero-95. +following the well-known visitor pattern \cgalCite{cgal:ghjv-dpero-95}. The interface is illustrated by the following example. \cgalExample{Nef_3/shell_exploration.cpp} diff --git a/Number_types/doc/Number_types/CGAL/CORE_BigFloat.h b/Number_types/doc/Number_types/CGAL/CORE_BigFloat.h index df497481393..b00d0404983 100644 --- a/Number_types/doc/Number_types/CGAL/CORE_BigFloat.h +++ b/Number_types/doc/Number_types/CGAL/CORE_BigFloat.h @@ -9,7 +9,7 @@ Rounding mode and precision (i.e.\ mantissa length) of `CORE::BigFloat` can be set. Since it also carries the error of a computed value. -This number type is provided by the Core library \cite klpy-clp-99. +This number type is provided by the Core library \cgalCite{klpy-clp-99}. \cgal defines the necessary functions so that this class complies to the requirements on number types. diff --git a/Number_types/doc/Number_types/CGAL/CORE_BigInt.h b/Number_types/doc/Number_types/CGAL/CORE_BigInt.h index f768d6a0bfb..ef95c487d63 100644 --- a/Number_types/doc/Number_types/CGAL/CORE_BigInt.h +++ b/Number_types/doc/Number_types/CGAL/CORE_BigInt.h @@ -7,7 +7,7 @@ namespace CORE { The class `CORE::BigInt` provides exact computation in \f$ \Z\f$. Operations and comparisons between objects of this type are guaranteed to be exact. -This number type is provided by the Core library \cite klpy-clp-99. +This number type is provided by the Core library \cgalCite{klpy-clp-99}. \cgal defines the necessary functions so that this class complies to the requirements on number types. diff --git a/Number_types/doc/Number_types/CGAL/CORE_BigRat.h b/Number_types/doc/Number_types/CGAL/CORE_BigRat.h index fc3053face8..5e6934f4088 100644 --- a/Number_types/doc/Number_types/CGAL/CORE_BigRat.h +++ b/Number_types/doc/Number_types/CGAL/CORE_BigRat.h @@ -5,7 +5,7 @@ namespace CORE { The class `CORE::BigRat` provides exact computation in \f$ \Q\f$. Operations and comparisons between objects of this type are guaranteed to be exact. -This number type is provided by the Core library \cite klpy-clp-99. +This number type is provided by the Core library \cgalCite{klpy-clp-99}. \cgal defines the necessary functions so that this class complies to the requirements on number types. diff --git a/Number_types/doc/Number_types/CGAL/CORE_Expr.h b/Number_types/doc/Number_types/CGAL/CORE_Expr.h index f5cb09999f7..9f180f918d8 100644 --- a/Number_types/doc/Number_types/CGAL/CORE_Expr.h +++ b/Number_types/doc/Number_types/CGAL/CORE_Expr.h @@ -8,7 +8,7 @@ numbers that contains integers, and which is closed by the operations \f$ +,-,\times,/,\sqrt{}\f$ and \f$\sqrt[k]{}\f$. Operations and comparisons between objects of this type are guaranteed to be exact. This number type is provided by the -Core library \cite klpy-clp-99. +Core library \cgalCite{klpy-clp-99}. \cgal defines the necessary functions so that this class complies to the requirements on number types. diff --git a/Number_types/doc/Number_types/CGAL/Interval_nt.h b/Number_types/doc/Number_types/CGAL/Interval_nt.h index 313d5b36e2c..e378f1835e8 100644 --- a/Number_types/doc/Number_types/CGAL/Interval_nt.h +++ b/Number_types/doc/Number_types/CGAL/Interval_nt.h @@ -17,7 +17,7 @@ The purpose of interval arithmetic is to provide an efficient way to bound the roundoff errors made by floating point computations. You can choose the behavior of your program depending on these errors. You can find more theoretical information on this topic in -\cite cgal:bbp-iayed-01. +\cgalCite{cgal:bbp-iayed-01}. Interval arithmetic is a large concept and we will only consider here a simple arithmetic based on intervals whose bounds are doubles. diff --git a/Number_types/doc/Number_types/CGAL/leda_bigfloat.h b/Number_types/doc/Number_types/CGAL/leda_bigfloat.h index 7cdb3331387..aadeed21d62 100644 --- a/Number_types/doc/Number_types/CGAL/leda_bigfloat.h +++ b/Number_types/doc/Number_types/CGAL/leda_bigfloat.h @@ -10,7 +10,7 @@ needed to use the number type `bigfloat`. Rounding mode and precision (i.e.\ mantissa length) of `leda_bigfloat` can be set. -For more details on the number types of \leda we refer to the \leda manual \cite cgal:mnsu-lum. +For more details on the number types of \leda we refer to the \leda manual \cgalCite{cgal:mnsu-lum}. \cgalModels `FieldWithKthRoot` \cgalModels `RealEmbeddable` diff --git a/Number_types/doc/Number_types/CGAL/leda_integer.h b/Number_types/doc/Number_types/CGAL/leda_integer.h index 5b32c14ae29..b6d0af76e99 100644 --- a/Number_types/doc/Number_types/CGAL/leda_integer.h +++ b/Number_types/doc/Number_types/CGAL/leda_integer.h @@ -11,7 +11,7 @@ multiprecision integers provided by LEDA. \cgalModels `EuclideanRing` \cgalModels `RealEmbeddable` -For more details on the number types of \leda we refer to the \leda manual \cite cgal:mnsu-lum. +For more details on the number types of \leda we refer to the \leda manual \cgalCite{cgal:mnsu-lum}. */ diff --git a/Number_types/doc/Number_types/CGAL/leda_rational.h b/Number_types/doc/Number_types/CGAL/leda_rational.h index eedc9a5859e..113ad1e2b12 100644 --- a/Number_types/doc/Number_types/CGAL/leda_rational.h +++ b/Number_types/doc/Number_types/CGAL/leda_rational.h @@ -12,7 +12,7 @@ multiprecision rational numbers provided by LEDA. \cgalModels `Fraction` \cgalModels `FromDoubleConstructible` -For more details on the number types of \leda we refer to the \leda manual \cite cgal:mnsu-lum. +For more details on the number types of \leda we refer to the \leda manual \cgalCite{cgal:mnsu-lum}. */ class leda_rational { diff --git a/Number_types/doc/Number_types/CGAL/leda_real.h b/Number_types/doc/Number_types/CGAL/leda_real.h index a27657fa58a..2ff5cce2bac 100644 --- a/Number_types/doc/Number_types/CGAL/leda_real.h +++ b/Number_types/doc/Number_types/CGAL/leda_real.h @@ -16,7 +16,7 @@ to be exact. \cgalModels `RealEmbeddable` \cgalModels `FromDoubleConstructible` -For more details on the number types of \leda we refer to the \leda manual \cite cgal:mnsu-lum. +For more details on the number types of \leda we refer to the \leda manual \cgalCite{cgal:mnsu-lum}. */ diff --git a/Number_types/doc/Number_types/NumberTypeSupport.txt b/Number_types/doc/Number_types/NumberTypeSupport.txt index 9dda1d5dcaf..44b90e57d92 100644 --- a/Number_types/doc/Number_types/NumberTypeSupport.txt +++ b/Number_types/doc/Number_types/NumberTypeSupport.txt @@ -81,7 +81,7 @@ types. \anchor gmpnt -\cgal provides wrapper classes for number types defined in the Gnu Multiple Precision arithmetic library \cite g-ggmpa-. The file +\cgal provides wrapper classes for number types defined in the Gnu Multiple Precision arithmetic library \cgalCite{g-ggmpa-}. The file CGAL/Gmpz.h provides the class `Gmpz`, a wrapper class for the arbitrary-precision integer type `mpz_t`, which is compliant with the \cgal number type requirements. The file CGAL/Gmpq.h @@ -103,7 +103,7 @@ Though not necessary at first, the user will take full advantage of this number type by understanding the ideas behind floating-point arithmetic, such as precision and rounding, and understanding the flags set by this library after each operation. For more details, the reader should refer -to \cite cgal:mt-mpfr and the `Gmpfr` reference manual. +to \cgalCite{cgal:mt-mpfr} and the `Gmpfr` reference manual. In addition, it is possible to directly use the C++ number types provided by Gmp : `mpz_class`, `mpq_class` (note that support for @@ -155,7 +155,7 @@ requirements. \anchor corent -In principle Core \cite klpy-clp-99 provides the same set of number types as \leda. +In principle Core \cgalCite{klpy-clp-99} provides the same set of number types as \leda. The type `CORE::BigInt` represent integers and `CORE::BigRat` represent rationals of arbitrary length. The number type `CORE::BigFloat` is a variable precision floating-point type. It is also possible to interpret it as an @@ -188,7 +188,7 @@ of its endpoints. The result of the operations is guaranteed to be always contained in the returned interval. Since the interval arithmetic is implemented on top of `Gmpfr`, the global flags and the default precision are inherited from the `Gmpfr` interface. See -\cite cgal:r-mpfi and the `Gmpfi` reference manual for details. +\cgalCite{cgal:r-mpfi} and the `Gmpfi` reference manual for details. To use the `Gmpfi` class, Mpfi must be installed. diff --git a/Partition_2/doc/Partition_2/CGAL/partition_2.h b/Partition_2/doc/Partition_2/CGAL/partition_2.h index b90dcd14630..d94eddd399a 100644 --- a/Partition_2/doc/Partition_2/CGAL/partition_2.h +++ b/Partition_2/doc/Partition_2/CGAL/partition_2.h @@ -44,7 +44,7 @@ with the representation type determined by `std::iterator_traits \cgalHeading{Implementation} This function implements the algorithm of Hertel and Mehlhorn -\cite hm-ftsp-83 and is based on the class +\cgalCite{hm-ftsp-83} and is based on the class `Constrained_triangulation_2`. Given a triangulation of the polygon, the function requires \f$ O(n)\f$ time and space for a polygon with \f$ n\f$ vertices. @@ -117,7 +117,7 @@ with the representation type determined by `std::iterator_traits: \cgalHeading{Implementation} This function implements the approximation algorithm of -Greene \cite g-dpcp-83 and requires \f$ O(n \log n)\f$ time and \f$ O(n)\f$ space +Greene \cgalCite{g-dpcp-83} and requires \f$ O(n \log n)\f$ time and \f$ O(n)\f$ space to produce a convex partitioning given a \f$ y\f$-monotone partitioning of a polygon with \f$ n\f$ vertices. The function `y_monotone_partition_2()` is used to produce the monotone partition. @@ -185,7 +185,7 @@ with the representation type determined by `std::iterator_traits: \cgalHeading{Implementation} This function implements the dynamic programming algorithm of Greene -\cite g-dpcp-83, which requires \f$ O(n^4)\f$ time and \f$ O(n^3)\f$ space to +\cgalCite{g-dpcp-83}, which requires \f$ O(n^4)\f$ time and \f$ O(n^3)\f$ space to produce a partitioning of a polygon with \f$ n\f$ vertices. \cgalHeading{Example} @@ -256,7 +256,7 @@ with the representation type determined by `std::iterator_traits: \cgalHeading{Implementation} This function implements the algorithm presented by de Berg et al. -\cite bkos-cgaa-97 which requires \f$ O(n \log n)\f$ time +\cgalCite{bkos-cgaa-97} which requires \f$ O(n \log n)\f$ time and \f$ O(n)\f$ space for a polygon with \f$ n\f$ vertices. \cgalHeading{Example} diff --git a/Partition_2/doc/Partition_2/PackageDescription.txt b/Partition_2/doc/Partition_2/PackageDescription.txt index 7ea2dfd67f7..f3ddfab899b 100644 --- a/Partition_2/doc/Partition_2/PackageDescription.txt +++ b/Partition_2/doc/Partition_2/PackageDescription.txt @@ -33,7 +33,7 @@ Functions are available for partitioning planar polygons into two types of subpolygons (`y`-monotone polygons and convex polygons). The function that produces a `y`-monotone partitioning is based on the -algorithm presented in \cite bkos-cgaa-97 which requires \f$ O(n \log n) \f$ time +algorithm presented in \cgalCite{bkos-cgaa-97} which requires \f$ O(n \log n) \f$ time and \f$ O(n) \f$ space for a polygon with \f$ n \f$ vertices and guarantees nothing about the number of polygons produced with respect to the optimal number Three functions are provided for producing @@ -43,12 +43,12 @@ defined in terms of the number of partition polygons. The two functions that implement approximation algorithms are guaranteed to produce no more than four times the optimal number of convex pieces. The optimal partitioning function provides an implementation of Greene's dynamic programming algorithm -\cite g-dpcp-83, which requires \f$ O(n^4) \f$ time and \f$ O(n^3) \f$ space to produce a +\cgalCite{g-dpcp-83}, which requires \f$ O(n^4) \f$ time and \f$ O(n^3) \f$ space to produce a convex partitioning. One of the approximation algorithms is also due to -Greene \cite g-dpcp-83 and requires \f$ O(n \log n) \f$ time and \f$ O(n) \f$ space +Greene \cgalCite{g-dpcp-83} and requires \f$ O(n \log n) \f$ time and \f$ O(n) \f$ space to produce a convex partitioning given a `y`-monotone partitioning. The other approximation algorithm is a result of Hertel and -Mehlhorn \cite hm-ftsp-83, which requires \f$ O(n) \f$ time and space to produce +Mehlhorn \cgalCite{hm-ftsp-83}, which requires \f$ O(n) \f$ time and space to produce a convex partitioning from a triangulation of a polygon. Each of the partitioning functions uses a traits class to supply the primitive types and predicates used by the algorithms. diff --git a/Partition_2/doc/Partition_2/Partition_2.txt b/Partition_2/doc/Partition_2/Partition_2.txt index 190d7d9c57f..b0dd03a44ba 100644 --- a/Partition_2/doc/Partition_2/Partition_2.txt +++ b/Partition_2/doc/Partition_2/Partition_2.txt @@ -38,7 +38,7 @@ is a polygon whose vertices \f$ v_1, \ldots, v_n\f$ can be divided into two chai \f$ v_1, \ldots, v_k\f$ and \f$ v_k, \ldots, v_n, v_1\f$, such that any horizontal line intersects either chain at most once. For producing a \f$ y\f$-monotone partition of a given polygon, the sweep-line algorithm -presented in \cite bkos-cgaa-97 is implemented by the function +presented in \cgalCite{bkos-cgaa-97} is implemented by the function `y_monotone_partition_2()`. This algorithm runs in \f$ O(n \log n)\f$ time and requires \f$ O(n)\f$ space. This algorithm does not guarantee a bound on the number of polygons produced with respect to the optimal number. @@ -71,11 +71,11 @@ An optimal convex partition can be produced using the function `optimal_convex_p This function provides an implementation of Greene's dynamic programming algorithm for optimal -partitioning \cite g-dpcp-83. +partitioning \cgalCite{g-dpcp-83}. This algorithm requires \f$ O(n^4)\f$ time and \f$ O(n^3)\f$ space in the worst case. The function `approx_convex_partition_2()` implements the simple approximation -algorithm of Hertel and Mehlhorn \cite hm-ftsp-83 that +algorithm of Hertel and Mehlhorn \cgalCite{hm-ftsp-83} that produces a convex partitioning of a polygon from a triangulation by throwing out unnecessary triangulation edges. The triangulation used in this function is one produced by the @@ -84,7 +84,7 @@ package of \cgal. For a given triangulation, this convex partitioning algorithm requires \f$ O(n)\f$ time and space to construct a decomposition into no more than four times the optimal number of convex pieces. -The sweep-line approximation algorithm of Greene \cite g-dpcp-83, which, +The sweep-line approximation algorithm of Greene \cgalCite{g-dpcp-83}, which, given a monotone partition of a polygon, produces a convex partition in \f$ O(n \log n)\f$ time and \f$ O(n)\f$ space, is implemented by the function `greene_approx_convex_partition_2()`. The function diff --git a/Periodic_2_triangulation_2/doc/Periodic_2_triangulation_2/CGAL/Periodic_2_Delaunay_triangulation_2.h b/Periodic_2_triangulation_2/doc/Periodic_2_triangulation_2/CGAL/Periodic_2_Delaunay_triangulation_2.h index 33a2bb12830..ff134c812b4 100644 --- a/Periodic_2_triangulation_2/doc/Periodic_2_triangulation_2/CGAL/Periodic_2_Delaunay_triangulation_2.h +++ b/Periodic_2_triangulation_2/doc/Periodic_2_triangulation_2/CGAL/Periodic_2_Delaunay_triangulation_2.h @@ -94,7 +94,7 @@ public: /// case when there are co-circular points, the Delaunay triangulation /// is known not to be uniquely defined. In this case, \cgal chooses a /// particular Delaunay triangulation using a symbolic perturbation -/// scheme \cite cgal:dt-pvr3d-03. Note that insertion of a new point +/// scheme \cgalCite{cgal:dt-pvr3d-03}. Note that insertion of a new point /// can cause a switch from computing in the 9-sheeted covering space /// to computing in the 1-sheeted covering space, which invalidates /// some `Vertex_handle`s and `Face_handle`s. diff --git a/Periodic_2_triangulation_2/doc/Periodic_2_triangulation_2/CGAL/Periodic_2_triangulation_2.h b/Periodic_2_triangulation_2/doc/Periodic_2_triangulation_2/CGAL/Periodic_2_triangulation_2.h index 24961d82ffc..40656af7752 100644 --- a/Periodic_2_triangulation_2/doc/Periodic_2_triangulation_2/CGAL/Periodic_2_triangulation_2.h +++ b/Periodic_2_triangulation_2/doc/Periodic_2_triangulation_2/CGAL/Periodic_2_triangulation_2.h @@ -478,7 +478,7 @@ public: `false` nothing is known. This test runs in constant-time when not computing in the 1-sheeted covering space. (This test uses the length of the longest edge in the triangulation as a - criterion \cite cgal:ct-c3pt-09.) + criterion \cgalCite{cgal:ct-c3pt-09}.) \cgalAdvancedEnd */ bool is_extensible_triangulation_in_1_sheet_h1() const; @@ -490,7 +490,7 @@ public: `is_extensible_triangulation_in_1_sheet_h1()` would not. However, it is much less time efficient when not computing in the 1-sheeted covering space. (This test uses the diameter of the largest empty circle in the - input point set as a criterion \cite cgal:ct-c3pt-09.) + input point set as a criterion \cgalCite{cgal:ct-c3pt-09}.) \cgalAdvancedEnd */ bool is_extensible_triangulation_in_1_sheet_h2() const; diff --git a/Periodic_2_triangulation_2/doc/Periodic_2_triangulation_2/Periodic_2_triangulation_2.txt b/Periodic_2_triangulation_2/doc/Periodic_2_triangulation_2/Periodic_2_triangulation_2.txt index ce0777988e7..770a8c9e970 100644 --- a/Periodic_2_triangulation_2/doc/Periodic_2_triangulation_2/Periodic_2_triangulation_2.txt +++ b/Periodic_2_triangulation_2/doc/Periodic_2_triangulation_2/Periodic_2_triangulation_2.txt @@ -96,7 +96,7 @@ Some point sets do not admit a triangulation in \f$ \mathbb T_c^2\f$. In this case we use 9 periodic copies of the point set arranged in a square of edge length \f$ 3c\f$. Any point set constructed in this way has a triangulation in \f$ \mathbb R^2/G'\f$ with \f$ G'=(3c\cdot\mathbb Z)^2\f$ -\cite cgal:ct-c3pt-09. So we compute the triangulation in this +\cgalCite{cgal:ct-c3pt-09}. So we compute the triangulation in this space, which is a 9-sheeted covering space of \f$ \mathbb T_c^2\f$ (see Figure \cgalFigureRef{P2Triangulation2figcovering}). @@ -147,7 +147,7 @@ that is, the circumscribing circle of each face does not contain any other vertex of the triangulation in its interior. These triangulations are uniquely defined except in degenerate cases where four points are co-circular. Note however that the \cgal implementation computes a unique triangulation even in these cases -\cite cgal:dt-pvr3d-03. +\cgalCite{cgal:dt-pvr3d-03}. This implementation is fully dynamic: it supports both insertions of points and vertex removal. @@ -183,7 +183,7 @@ point insertion and vertex removal, the side-of-circle test, finding the conflicting region of a given point, dual functions etc. `Periodic_2_triangulation_2` contains all the functionality that is common to triangulations in general, such as location of a -point in the triangulation \cite cgal:dpt-wt-02, access functions, +point in the triangulation \cgalCite{cgal:dpt-wt-02}, access functions, geometric queries like the orientation test etc. They are built as layers on top of a triangulation data structure, @@ -400,7 +400,7 @@ The periodic 2D-triangulation is based on the 2D triangulation package developed by Mariette Yvinec and inspired by the periodic 3D-triangulation package developed by Manuel Caroli and Monique Teillaud. The periodic 3D-triangulation package is described in Manuel's PhD thesis -\cite cgal:c-tpsos-10 Triangulating Point Sets in Orbit Spaces and \cite cgal:ct-c3pt-09. +\cgalCite{cgal:c-tpsos-10} Triangulating Point Sets in Orbit Spaces and \cgalCite{cgal:ct-c3pt-09}. In 2009, Nico Kruithof started implementation of the `Periodic_2_triangulation_2` package. diff --git a/Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/CGAL/Periodic_3_Delaunay_triangulation_3.h b/Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/CGAL/Periodic_3_Delaunay_triangulation_3.h index 7a5790f90af..3b2eace55e2 100644 --- a/Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/CGAL/Periodic_3_Delaunay_triangulation_3.h +++ b/Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/CGAL/Periodic_3_Delaunay_triangulation_3.h @@ -69,7 +69,7 @@ P3Triangulation3secspace of the user manual). In the degenerate case when there are co-spherical points, the Delaunay triangulation is known not to be uniquely defined. In this case, \cgal chooses a particular Delaunay triangulation using a symbolic perturbation scheme -\cite cgal:dt-pvr3d-03. Note that insertion of a new point can cause a +\cgalCite{cgal:dt-pvr3d-03}. Note that insertion of a new point can cause a switch from computing in the 27-sheeted covering space to computing in the 1-sheeted covering space, which invalidates some `Vertex_handle`s and `Cell_handle`s. @@ -146,7 +146,7 @@ re-triangulated. So, the problem reduces to triangulating a polyhedral region, while preserving its boundary, or to compute a constrained triangulation. This is known to be sometimes impossible: the Schönhardt polyhedron cannot be triangulated -\cite cgal:s-cgehd-98. +\cgalCite{cgal:s-cgehd-98}. However, when dealing with Delaunay triangulations, the case of such polyhedra that cannot be re-triangulated cannot happen, so \cgal diff --git a/Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/CGAL/Periodic_3_triangulation_3.h b/Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/CGAL/Periodic_3_triangulation_3.h index 43ebe9e5fa4..3d656afcfa8 100644 --- a/Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/CGAL/Periodic_3_triangulation_3.h +++ b/Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/CGAL/Periodic_3_triangulation_3.h @@ -409,7 +409,7 @@ covering space even after adding points if this method returns `false` nothing is known. This test runs in constant-time when not computing in the 1-sheeted covering space. (This test uses the length of the longest edge in the triangulation as a -criterion \cite cgal:ct-c3pt-09.) +criterion \cgalCite{cgal:ct-c3pt-09}.) */ bool is_extensible_triangulation_in_1_sheet_h1() const; @@ -419,7 +419,7 @@ a more precise heuristic, i.e.\ it might answer `true` in cases in which `is_extensible_triangulation_in_1_sheet_h1()` would not. However, it is much less time efficient when not computing in the 1-sheeted covering space. (This test uses the diameter of the largest empty ball in the -input point set as a criterion \cite cgal:ct-c3pt-09.) +input point set as a criterion \cgalCite{cgal:ct-c3pt-09}.) */ bool is_extensible_triangulation_in_1_sheet_h2() const; diff --git a/Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/Periodic_3_triangulation_3.txt b/Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/Periodic_3_triangulation_3.txt index 2f3eb335568..bb1da3b02e7 100644 --- a/Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/Periodic_3_triangulation_3.txt +++ b/Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/Periodic_3_triangulation_3.txt @@ -96,7 +96,7 @@ Some point sets do not admit a triangulation in \f$ \mathbb T_c^3\f$. In this case we use 27 periodic copies of the point set arranged in a cube of edge length \f$ 3c\f$. Any point set constructed in this way has a triangulation in \f$ \mathbb R^3/G'\f$ with \f$ G'=((3c\cdot\mathbb Z)^3,+)\f$ -\cite cgal:ct-c3pt-09. So we compute the triangulation in this +\cgalCite{cgal:ct-c3pt-09}. So we compute the triangulation in this space, which is a 27-sheeted covering space of \f$ \mathbb T_c^3\f$ (see \cgalFigureRef{P3Triangulation3figcovering}). @@ -147,7 +147,7 @@ that is, the circumscribing sphere of each cell does not contain any other vertex of the triangulation in its interior. These triangulations are uniquely defined except in degenerate cases where five points are co-spherical. Note however that the \cgal implementation computes a unique triangulation even in these cases -\cite cgal:dt-pvr3d-03. +\cgalCite{cgal:dt-pvr3d-03}. This implementation is fully dynamic: it supports both insertions of points and vertex removal. @@ -174,7 +174,7 @@ point insertion and vertex removal, the side-of-sphere test, finding the conflicting region of a given point, dual functions etc. `Periodic_3_triangulation_3` contains all the functionality that is common to triangulations in general, such as location of a -point in the triangulation \cite cgal:dpt-wt-02, access functions, +point in the triangulation \cgalCite{cgal:dpt-wt-02}, access functions, geometric queries like the orientation test etc. They are built as layers on top of a triangulation data structure, @@ -371,7 +371,7 @@ In 2006, Nico Kruithof started to work with Monique Teillaud on the 3D Periodic Triangulations package. In 2007, Manuel Caroli continued work on the -algorithms \cite cgal:ct-c3pt-09 and on the package with Monique +algorithms \cgalCite{cgal:ct-c3pt-09} and on the package with Monique Teillaud. The package follows the design of the 3D Triangulations package diff --git a/Point_set_2/doc/Point_set_2/Point_set_2.txt b/Point_set_2/doc/Point_set_2/Point_set_2.txt index ef5a0d88084..e2ace6aa4d4 100644 --- a/Point_set_2/doc/Point_set_2/Point_set_2.txt +++ b/Point_set_2/doc/Point_set_2/Point_set_2.txt @@ -45,7 +45,7 @@ For example, the Delaunay diagram turns out to be a very powerful data structure for storing dynamic sets of points under range and nearest neighbor queries. A first implementation and computational study of using Delaunay diagrams for geometric queries is described by -Mehlhorn and Näher in \cite mn-lpcgc-00. +Mehlhorn and Näher in \cgalCite{mn-lpcgc-00}. In this section we present a generic variant of a two dimensional point set data type supporting various geometric queries. @@ -66,7 +66,7 @@ The `Point_set_2` class supports the following kinds of queries:
    • isorectangular range search
    • (k) nearest neighbor(s)
    -For details about the running times see \cite mn-lpcgc-00. +For details about the running times see \cgalCite{mn-lpcgc-00}. \section Point_set_2Example Example: Range Search diff --git a/Point_set_processing_3/doc/Point_set_processing_3/Point_set_processing_3.txt b/Point_set_processing_3/doc/Point_set_processing_3/Point_set_processing_3.txt index 468ec744e2f..c255ca2e91c 100644 --- a/Point_set_processing_3/doc/Point_set_processing_3/Point_set_processing_3.txt +++ b/Point_set_processing_3/doc/Point_set_processing_3/Point_set_processing_3.txt @@ -79,7 +79,7 @@ We provide functions to read and write sets of points or sets of points with normals from the following ASCII file formats: XYZ (three point coordinates `x y z` per line or three point coordinates and three normal vector coordinates `x y z nx ny nz` per line), and OFF -(%Object File Format) \cite cgal:p-gmgv16-96. +(%Object File Format) \cgalCite{cgal:p-gmgv16-96}. - `read_xyz_points()` - `read_off_points()` @@ -192,7 +192,7 @@ faster than `jet_estimate_normals()`. Function `mst_orient_normals()` orients the normals of a set of points with unoriented normals using the method described by Hoppe et -al. in Surface reconstruction from unorganized points \cite cgal:hddms-srup-92. +al. in Surface reconstruction from unorganized points \cgalCite{cgal:hddms-srup-92}. More specifically, this method constructs a Riemannian graph over the input points (the graph of the `k` nearest neighbor points) and propagates a seed normal orientation diff --git a/Polyhedron/doc/Polyhedron/CGAL/IO/Polyhedron_iostream.h b/Polyhedron/doc/Polyhedron/CGAL/IO/Polyhedron_iostream.h index a2d0225b974..d88c879e179 100644 --- a/Polyhedron/doc/Polyhedron/CGAL/IO/Polyhedron_iostream.h +++ b/Polyhedron/doc/Polyhedron/CGAL/IO/Polyhedron_iostream.h @@ -6,7 +6,7 @@ namespace CGAL { This operator reads a polyhedral surface in Object File Format, OFF, with file extension .off, which is also understood by -Geomview \cite cgal:p-gmgv16-96, from the input stream `in` and +Geomview \cgalCite{cgal:p-gmgv16-96}, from the input stream `in` and appends it to the polyhedral surface \f$ P\f$. Only the point coordinates and facets from the input stream are used to build the polyhedral surface. Neither normal vectors nor color attributes are evaluated. If @@ -40,7 +40,7 @@ std::istream& operator>>( std::istream& in, CGAL::Polyhedron_3.off, which is also understood by GeomView \cite cgal:p-gmgv16-96. The +.off, which is also understood by GeomView \cgalCite{cgal:p-gmgv16-96}. The output is in ASCII format. From the polyhedral surface, only the point coordinates and facets are written. Neither normal vectors nor color attributes are used. diff --git a/Polyhedron/doc/Polyhedron/CGAL/Polyhedron_3.h b/Polyhedron/doc/Polyhedron/CGAL/Polyhedron_3.h index 48edc42bce9..504c0c07ced 100644 --- a/Polyhedron/doc/Polyhedron/CGAL/Polyhedron_3.h +++ b/Polyhedron/doc/Polyhedron/CGAL/Polyhedron_3.h @@ -27,7 +27,7 @@ namespace CGAL { define a closed object. If normal vectors are considered for the facets, normals point outwards (following the right hand rule). - The strict definition can be found in \cite k-ugpdd-99. One + The strict definition can be found in \cgalCite{k-ugpdd-99}. One implication of this definition is that the polyhedral surface is always an orientable and oriented 2-manifold with border edges, i.e., the neighborhood of each point on the polyhedral surface is either diff --git a/Polyhedron/doc/Polyhedron/CGAL/Polyhedron_incremental_builder_3.h b/Polyhedron/doc/Polyhedron/CGAL/Polyhedron_incremental_builder_3.h index 8b66073d83b..dc62a2a620f 100644 --- a/Polyhedron/doc/Polyhedron/CGAL/Polyhedron_incremental_builder_3.h +++ b/Polyhedron/doc/Polyhedron/CGAL/Polyhedron_incremental_builder_3.h @@ -7,9 +7,9 @@ namespace CGAL { The auxiliary class `Polyhedron_incremental_builder_3` supports the incremental construction of polyhedral surfaces, which is for example convenient when constructing polyhedral surfaces from file formats, such as the -%Object File Format (OFF) \cite cgal:p-gmgv16-96, -OpenInventor \cite cgal:w-impoo-94 or -VRML \cite cgal:bpp-vrml-95, \cite cgal:vrmls-97. +%Object File Format (OFF) \cgalCite{cgal:p-gmgv16-96}, +OpenInventor \cgalCite{cgal:w-impoo-94} or +VRML \cgalCite{cgal:bpp-vrml-95}, \cgalCite{cgal:vrmls-97}. `Polyhedron_incremental_builder_3` needs access to the internal halfedge data structure of type `HDS` of the polyhedral surface. It is intended to be used within a modifier, see `Modifier_base`. diff --git a/Polyhedron/doc/Polyhedron/PackageDescription.txt b/Polyhedron/doc/Polyhedron/PackageDescription.txt index 2daee31cd95..2705270680a 100644 --- a/Polyhedron/doc/Polyhedron/PackageDescription.txt +++ b/Polyhedron/doc/Polyhedron/PackageDescription.txt @@ -37,7 +37,7 @@ class, a default items class and an incremental builder conclude the references. The polyhedral surface is based on the highly flexible design of the halfedge data structure, see the reference for `HalfedgeDS` in Chapter \ref Chapter_Halfedge_Data_Structures "Halfedge Data Structures" -or \cite k-ugpdd-99, but the default instantiation of the polyhedral +or \cgalCite{k-ugpdd-99}, but the default instantiation of the polyhedral surface can be used without knowing the halfedge data structure. \cgalClassifedRefPages diff --git a/Polyhedron/doc/Polyhedron/Polyhedron.txt b/Polyhedron/doc/Polyhedron/Polyhedron.txt index 661b8d1928c..2faa77607ad 100644 --- a/Polyhedron/doc/Polyhedron/Polyhedron.txt +++ b/Polyhedron/doc/Polyhedron/Polyhedron.txt @@ -24,7 +24,7 @@ The polyhedral surface is realized as a container class that manages vertices, halfedges, facets with their incidences, and that maintains the combinatorial integrity of them. It is based on the highly flexible design of the halfedge data structure, see the introduction -in Chapter \ref chapterHalfedgeDS "Halfedge Data Structures" and \cite k-ugpdd-99. However, the +in Chapter \ref chapterHalfedgeDS "Halfedge Data Structures" and \cgalCite{k-ugpdd-99}. However, the polyhedral surface can be used and understood without knowing the underlying design. Some of the examples in this chapter introduce also gradually into first applications of this flexibility. @@ -57,7 +57,7 @@ with border edges although they do not define a closed object. If normal vectors are considered for the facets, normals point outwards (following the right-hand rule). -The strict definition can be found in \cite k-ugpdd-99. One +The strict definition can be found in \cgalCite{k-ugpdd-99}. One implication of this definition is that the polyhedral surface is always an orientable and oriented 2-manifold with border edges, i.e., the neighborhood of each point on the polyhedral surface is either @@ -228,7 +228,7 @@ that only the polyhedron can guarantee. \subsection PolyhedronExamplewithCirculatorWritingObject Example with Circulator Writing Object File Format (OFF) We create a tetrahedron and write it to `std::cout` using the -%Object File Format (OFF) \cite cgal:p-gmgv16-96. This example makes use +%Object File Format (OFF) \cgalCite{cgal:p-gmgv16-96}. This example makes use of \stl algorithms (`std::copy`, `std::distance`), \stl `std::ostream_iterator`, and \cgal circulators. The polyhedral surface provides convenient circulators for the counterclockwise circular sequence of halfedges around a facet and the clockwise @@ -286,7 +286,7 @@ equation or any user-added attributes, such as color. The default file format supported in \cgal for output as well as for input is the %Object File Format, OFF, with file extension .off, -which is also understood by Geomview \cite cgal:p-gmgv16-96. For OFF +which is also understood by Geomview \cgalCite{cgal:p-gmgv16-96}. For OFF an ASCII and a binary format exist. The format can be selected with the \cgal modifiers for streams, `set_ascii_mode()` and `set_binary_mode()` respectively. The modifier `set_pretty_mode()` @@ -310,8 +310,8 @@ CGAL::Polyhedron_3& P); \endcode Additional formats supported for writing are OpenInventor (.iv) -\cite cgal:w-impoo-94, VRML 1.0 and 2.0 (.wrl) -\cite cgal:bpp-vrml-95, \cite cgal:vrmls-97, \cite cgal:hw-vrml2h-96, and Wavefront Advanced +\cgalCite{cgal:w-impoo-94}, VRML 1.0 and 2.0 (.wrl) +\cgalCite{cgal:bpp-vrml-95}, \cgalCite{cgal:vrmls-97}, \cgalCite{cgal:hw-vrml2h-96}, and Wavefront Advanced Visualizer object format (.obj). Another convenient output function writes a polyhedral surface to a Geomview process spawned from the \cgal program. These output functions are provided as @@ -501,10 +501,10 @@ This program reads a polyhedral surface from the standard input and writes a refined polyhedral surface to the standard output. Input and output are in the %Object File Format, OFF, with the common file extension .off, which is also understood by -Geomview \cite cgal:p-gmgv16-96. +Geomview \cgalCite{cgal:p-gmgv16-96}. The refinement is a single step of the \f$ \sqrt{3}\f$-scheme for creating -a subdivision surface \cite cgal:k-s-00. Each step subdivides a facet +a subdivision surface \cgalCite{cgal:k-s-00}. Each step subdivides a facet into triangles around a new center vertex, smoothes the position of the old vertices, and flips the old edges. The program is organized along this outline. In each of these parts, the program efficiently uses the diff --git a/Polynomial/doc/Polynomial/Concepts/PolynomialTraits_d--Resultant.h b/Polynomial/doc/Polynomial/Concepts/PolynomialTraits_d--Resultant.h index 2d8148f9b32..f738112fd12 100644 --- a/Polynomial/doc/Polynomial/Concepts/PolynomialTraits_d--Resultant.h +++ b/Polynomial/doc/Polynomial/Concepts/PolynomialTraits_d--Resultant.h @@ -42,7 +42,7 @@ the Sylvester Matrix or the Bezout Matrix as well as the so called subresultant algorithm, which is a variant of the Euclidean Algorithm. More sophisticated methods may use modular arithmetic and interpolation. -For more information we refer to, e.g., \cite gg-mca-99. +For more information we refer to, e.g., \cgalCite{gg-mca-99}. \cgalRefines `AdaptableBinaryFunction` \cgalRefines `CopyConstructible` diff --git a/Polynomial/doc/Polynomial/Polynomial.txt b/Polynomial/doc/Polynomial/Polynomial.txt index b4e22aea0d9..6602620dcbd 100644 --- a/Polynomial/doc/Polynomial/Polynomial.txt +++ b/Polynomial/doc/Polynomial/Polynomial.txt @@ -400,7 +400,7 @@ of a polynomial using its principal Sturm-Habicht coefficients. \section PolynomialDesign Design and Implementation History This package is the result of the integration process of the NumeriX library -of Exacus \cite beh-eeeafcs-05 into \cgal. +of Exacus \cgalCite{beh-eeeafcs-05} into \cgal. The class `Polynomial` had been started by Michael Seel within CGAL as part of the Nef_2 package. As part of the Exacus project diff --git a/Polytope_distance_d/doc/Polytope_distance_d/CGAL/Polytope_distance_d.h b/Polytope_distance_d/doc/Polytope_distance_d/CGAL/Polytope_distance_d.h index c358af11899..02febcb0aeb 100644 --- a/Polytope_distance_d/doc/Polytope_distance_d/CGAL/Polytope_distance_d.h +++ b/Polytope_distance_d/doc/Polytope_distance_d/CGAL/Polytope_distance_d.h @@ -46,7 +46,7 @@ The problem of finding the distance between two convex polytopes given as the convex hulls of two finite point sets can be formulated as an optimization problem with linear constraints and a convex quadratic objective function. The solution is obtained using our exact solver -for quadratic programs \cite gs-eegqp-00. +for quadratic programs \cgalCite{gs-eegqp-00}. The creation time is almost always linear in the number of points. Access functions and predicates take constant time, inserting a point might take diff --git a/Polytope_distance_d/doc/Polytope_distance_d/CGAL/all_furthest_neighbors_2.h b/Polytope_distance_d/doc/Polytope_distance_d/CGAL/all_furthest_neighbors_2.h index 849b14faf47..4688aeb2dad 100644 --- a/Polytope_distance_d/doc/Polytope_distance_d/CGAL/all_furthest_neighbors_2.h +++ b/Polytope_distance_d/doc/Polytope_distance_d/CGAL/all_furthest_neighbors_2.h @@ -39,7 +39,7 @@ for `AllFurthestNeighborsTraits_2`. \cgalHeading{Implementation} -The implementation uses monotone matrix search \cite akmsw-gamsa-87. +The implementation uses monotone matrix search \cgalCite{akmsw-gamsa-87}. Its runtime complexity is linear in the number of vertices of \f$ P\f$. diff --git a/QP_solver/doc/QP_solver/QP_solver.txt b/QP_solver/doc/QP_solver/QP_solver.txt index c7d37493565..c7850995e6d 100644 --- a/QP_solver/doc/QP_solver/QP_solver.txt +++ b/QP_solver/doc/QP_solver/QP_solver.txt @@ -631,7 +631,7 @@ but why is there no better one? Certificates are proofs that the solver can give you in order to convince you that what it claims is indeed true. The archetype -of such a proof is Farkas Lemma \cite cgal:mg-uulp-06. +of such a proof is Farkas Lemma \cgalCite{cgal:mg-uulp-06}. Farkas Lemma: Either the inequality system \f[ diff --git a/Ridges_3/doc/Ridges_3/Ridges_3.txt b/Ridges_3/doc/Ridges_3/Ridges_3.txt index 59300c8cafe..ef9a29b7f56 100644 --- a/Ridges_3/doc/Ridges_3/Ridges_3.txt +++ b/Ridges_3/doc/Ridges_3/Ridges_3.txt @@ -22,7 +22,7 @@ curve, and umbilics are special points on this curve. Ridges are curves of extremal curvature and therefore encode important informations used in segmentation, registration, matching and surface analysis. Based on the results of the article -\cite cgal:cp-tdare-05, we propose algorithms to identify and extract +\cgalCite{cgal:cp-tdare-05}, we propose algorithms to identify and extract different parts of this singular ridge curve as well as umbilics on a surface given as a triangulated surface mesh. Differential quantities associated to the mesh vertices are assumed to be given for these @@ -44,8 +44,8 @@ functions of the package are provided in Section \ref examples. For a detailed introduction to ridges and related topics, the reader may consult -\cite cgal:hgygm-ttdpf-99,cgal:p-gd-01, as well as -the following survey article \cite cgal:cp-ssulc-05. +\cgalCite{cgal:hgygm-ttdpf-99},cgal:p-gd-01, as well as +the following survey article \cgalCite{cgal:cp-ssulc-05}. In the sequel, we just introduce the basic notions so as to explain our algorithms. Consider a smooth embedded surface, and denote \f$ k_1\f$ and \f$ k_2\f$ the principal curvatures, with \f$ k_1\geq k_2\f$. Umbilics are @@ -149,7 +149,7 @@ Hence ridge types are characterized by As illustrated in \cgalFigureRef{index_umbilic} and \cgalFigureRef{umbilics}, the patterns made by curvature lines around an umbilic can be characterized using the notion of an index associated to the -principal directions - see also \cite cgal:cp-ssulc-05. +principal directions - see also \cgalCite{cgal:cp-ssulc-05}. As depicted in \cgalFigureRef{index_umbilic}, consider a small circuit \f$ C\f$ around the umbilic, and a point \f$ p \in C\f$. Starting from an initial orientation \f$ u\f$ of a tangent vector to the curvature line through point \f$ p\f$, @@ -198,7 +198,7 @@ the ridges reported matches that of the ridges on the smooth surface. To summarize things, a compliant mesh is a mesh dense enough so that (i) umbilics are properly isolated (ii) ridges running next to one another are also properly separated. -See \cite cgal:cp-tdare-05 for a detailed discussion of compliant meshes.
    +See \cgalCite{cgal:cp-tdare-05} for a detailed discussion of compliant meshes.
    As 0-level set of the extremality coefficients \f$ b_0\f$ and \f$ b_3\f$, ridges are extracted by a marching triangles algorithm.\cgalFootnote{A marching triangles algorithm is similar to a 2d marching cubes algorithm (or marching rectangles algorithm), except that a one-manifold is reported on a two-manifold tessellated by triangles.} @@ -210,7 +210,7 @@ point vertex of the mesh. Except in the neighborhood of umbilics, if the mesh is dense enough, a coherent orientation of principal directions at both endpoints of an edge is chosen such that the angle between the two vectors is acute. This rule, the acute rule, is -precisely analyzed in \cite cgal:cp-tdare-05. +precisely analyzed in \cgalCite{cgal:cp-tdare-05}. Moreover, we only seek ridges in triangles for which one can find an orientation of its three vertices such that the three edges are coherently oriented by the acute rule. Such triangles are called @@ -231,7 +231,7 @@ the mean value of the \f$ P_i\f$ values of the two crossing points on edges mean value of the values at endpoints). Alternatively, if third order differential quantities only are available, one may use the geometric method developed in -\cite cgal:cp-tdare-05. +\cgalCite{cgal:cp-tdare-05}. Using the notion of ridge segment, a `Ridge_line` is defined as a maximal connected sequence of ridge segments of the same type and connected @@ -248,7 +248,7 @@ method to detect umbilics independently. For real world applications dealing with coarse meshes, or meshes featuring degenerate regions or sharp features, or meshes conveying some amount of noise, the compliance hypothesis -\cite cgal:cp-tdare-05 cannot be met. In that case, it still makes +\cgalCite{cgal:cp-tdare-05} cannot be met. In that case, it still makes sense to seek loci of points featuring extremality of estimated principal curvatures, but the ridges reported may require filtering. For example, if the principal curvatures are constant @@ -270,7 +270,7 @@ the model size gives a threshold and an associated sharpness-filter which are scale independent. Another filtering is also available with the strength which is the integral of the curvature along the ridge line -\cite cgal:ybs-rvlmi-04. +\cgalCite{cgal:ybs-rvlmi-04}. \section Ridges_3Approximating_1 Approximating Umbilics on Triangulated Surface Meshes @@ -318,7 +318,7 @@ On a generic surface, generic umbilics are traversed by one or three ridges. For compliant meshes, an umbilic can thus be connected to the ridge points located on the boundary of its patch. This functionality is not provided, and -the interested reader is referred to \cite cgal:cp-tdare-05 for more +the interested reader is referred to \cgalCite{cgal:cp-tdare-05} for more details. \section Ridges_3Software Software Design diff --git a/STL_Extension/doc/STL_Extension/CGAL/Multiset.h b/STL_Extension/doc/STL_Extension/CGAL/Multiset.h index 669a01db010..833c51dff9a 100644 --- a/STL_Extension/doc/STL_Extension/CGAL/Multiset.h +++ b/STL_Extension/doc/STL_Extension/CGAL/Multiset.h @@ -10,7 +10,7 @@ namespace CGAL { An instance `s` of the parametrized data type `Multiset` is a multi-set of elements of type `Type`, represented as a red-black tree -(see [\cite clrs-ia-01 Chapter 13 for an excellent introduction to red-black +(see [\cgalCite{clrs-ia-01} Chapter 13 for an excellent introduction to red-black trees). The main difference between `Multiset` and the \stl `std::multiset` is that the latter uses a less-than functor with a Boolean return type, while our @@ -89,7 +89,7 @@ perform \f$ O(\log{n})\f$ comparison operations. On the other hand, the set operations that accept a position iterator (namely `insert_before(pos, x)`, `insert_after(pos, x)` and `erase(pos)`) are much more efficient as they can be performed at a constant amortized -cost (see \cite gs-dfbt-78 and \cite t-dsna-83 for more details). +cost (see \cgalCite{gs-dfbt-78} and \cgalCite{t-dsna-83} for more details). More important, these set operations require no comparison operations. Therefore, it is highly recommended to maintain the set via iterators to the stored elements, whenever possible. The function `insert(pos, x)` @@ -100,14 +100,14 @@ In addition, it always performs at least two comparison operations. The `catenate()` and `split()` functions are also very efficient, and can be performed in \f$ O(\log{n})\f$ time, where \f$ n\f$ is the total number of elements in the sets, and without performing any comparison operations -(see \cite t-dsna-83 for the details). +(see \cgalCite{t-dsna-83} for the details). Note however that the size of two sets resulting from a split operation is initially unknown, as it is impossible to compute it in less than linear time. Thus, the first invocation of `size()` on such a set takes linear time, and not constant time. The design is derived from the \stl `multiset` class-template (see, -e.g, \cite cgal:ms-strg-96), where the main differences between the two +e.g, \cgalCite{cgal:ms-strg-96}), where the main differences between the two classes are highlighted in the class definition above. */ diff --git a/STL_Extension/doc/STL_Extension/STL_Extension.txt b/STL_Extension/doc/STL_Extension/STL_Extension.txt index e732b01f9e9..61a5cacb25b 100644 --- a/STL_Extension/doc/STL_Extension/STL_Extension.txt +++ b/STL_Extension/doc/STL_Extension/STL_Extension.txt @@ -11,7 +11,7 @@ namespace CGAL { \cgal is designed in the spirit of the generic programming paradigm to work together with the Standard Template Library (\stl) -\cite cgal:ansi-is14882-98, \cite cgal:a-gps-98. This chapter documents non-geometric +\cgalCite{cgal:ansi-is14882-98}, \cgalCite{cgal:a-gps-98}. This chapter documents non-geometric \stl-like components that are not provided in the \stl standard but in \cgal: a doubly-connected list managing items in place (where inserted items are not copied), a compact container, a multi-set class that @@ -77,7 +77,7 @@ probably be useful for other kinds of graphs as well. The class `Multiset` represents a multi-set of elements of type `Type`, represented as a red-black tree -(see \cite clrs-ia-01 for an excellent introduction to red-black +(see \cgalCite{clrs-ia-01} for an excellent introduction to red-black trees). It differs from the \stl's `multiset` class-template mainly due to the fact that it is parameterized by a comparison functor `Compare` that returns the three-valued `Comparison_result` (namely it returns diff --git a/SearchStructures/doc/SearchStructures/SearchStructures.txt b/SearchStructures/doc/SearchStructures/SearchStructures.txt index 029267f84a6..6c6cb96281c 100644 --- a/SearchStructures/doc/SearchStructures/SearchStructures.txt +++ b/SearchStructures/doc/SearchStructures/SearchStructures.txt @@ -83,7 +83,7 @@ trees is given in the reference manual. In the following two sections we give short definitions of the version of the range tree and segment tree implemented here together with some -examples. The presentation closely follows \cite bkos-cgaa-97. +examples. The presentation closely follows \cgalCite{bkos-cgaa-97}. \section SearchStructuresSoftware Software Design @@ -147,7 +147,7 @@ order to access data. These functions have to be provided by class `Traits`. The design partly follows the prototype design pattern -in \cite cgal:ghjv-dpero-95. In comparison to our first approach +in \cgalCite{cgal:ghjv-dpero-95}. In comparison to our first approach using templates we want to note the following: In this approach the sublayer type is defined in use of object oriented programming at run time, while in the @@ -282,7 +282,7 @@ A ` d`-dimensional range tree is a binary leaf search tree according to the first dimension of the ` d`-dimensional point data, where each vertex contains a ` (d-1)`-dimensional search tree of the points in the subtree (sublayer tree) with respect to the second dimension. -See \cite bkos-cgaa-97 and \cite s-dasds-90 for more detailed information. +See \cgalCite{bkos-cgaa-97} and \cgalCite{s-dasds-90} for more detailed information. A ` d`-dimensional range tree can be used to determine all ` d`-dimensional points that lie inside a given ` d`-dimensional diff --git a/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/CGAL/Segment_Delaunay_graph_filtered_traits_2.h b/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/CGAL/Segment_Delaunay_graph_filtered_traits_2.h index 4d5cf30a807..e03ab1c5bf4 100644 --- a/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/CGAL/Segment_Delaunay_graph_filtered_traits_2.h +++ b/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/CGAL/Segment_Delaunay_graph_filtered_traits_2.h @@ -7,7 +7,7 @@ namespace CGAL { The class `Segment_Delaunay_graph_filtered_traits_2` provides a model for the `SegmentDelaunayGraphTraits_2` concept. -The class `Segment_Delaunay_graph_filtered_traits_2` uses the filtering technique \cite cgal:bbp-iayed-01 +The class `Segment_Delaunay_graph_filtered_traits_2` uses the filtering technique \cgalCite{cgal:bbp-iayed-01} to achieve traits for the `Segment_Delaunay_graph_2` class with efficient and exact predicates given an exact kernel `EK` and a filtering kernel `FK`. The geometric @@ -38,7 +38,7 @@ must be set to `Field_with_sqrt_tag` and the number type in `CK` must support operations involing divisions and square roots (as well as the other three basic operations of course). The way the predicates are evaluated is discussed in -\cite b-ecvdl-96 and \cite cgal:k-reisv-04 (the geometric filtering +\cgalCite{b-ecvdl-96} and \cgalCite{cgal:k-reisv-04} (the geometric filtering part). The default values for the template parameters are as follows: @@ -156,7 +156,7 @@ namespace CGAL { The class `Segment_Delaunay_graph_filtered_traits_without_intersections_2` provides a model for the `SegmentDelaunayGraphTraits_2` concept. -The class `Segment_Delaunay_graph_filtered_traits_without_intersections_2` uses the filtering technique \cite cgal:bbp-iayed-01 +The class `Segment_Delaunay_graph_filtered_traits_without_intersections_2` uses the filtering technique \cgalCite{cgal:bbp-iayed-01} to achieve traits for the `Segment_Delaunay_graph_2` class with efficient and exact predicates given an exact kernel `EK` and a filtering kernel `FK`. The geometric @@ -189,7 +189,7 @@ and multiplications. Finally, in order to get exact constructions in `CK` must support operations involing divisions and square roots (as well as the other three basic operations of course). The way the predicates are evaluated is discussed in -\cite b-ecvdl-96 and \cite cgal:k-reisv-04 (the geometric filtering +\cgalCite{b-ecvdl-96} and \cgalCite{cgal:k-reisv-04} (the geometric filtering part). The default values for the template parameters are as follows: diff --git a/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/CGAL/Segment_Delaunay_graph_hierarchy_2.h b/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/CGAL/Segment_Delaunay_graph_hierarchy_2.h index ecdef076d2b..2d26a940f54 100644 --- a/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/CGAL/Segment_Delaunay_graph_hierarchy_2.h +++ b/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/CGAL/Segment_Delaunay_graph_hierarchy_2.h @@ -28,8 +28,8 @@ done as follows: at the top most level we find the nearest neighbor of \f$ p\f$ as in the `Segment_Delaunay_graph_2` class. At every subsequent level \f$ i\f$ we use the nearest neighbor found at level \f$ i+1\f$ to find the nearest neighbor at level \f$ i\f$. This is a variant of -the corresponding hierarchy for points found in \cite cgal:d-dh-02. The -details are described in \cite cgal:k-reisv-04. +the corresponding hierarchy for points found in \cgalCite{cgal:d-dh-02}. The +details are described in \cgalCite{cgal:k-reisv-04}. The class has three template parameters. The first and third have essentially the same semantics as in the diff --git a/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/CGAL/Segment_Delaunay_graph_traits_2.h b/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/CGAL/Segment_Delaunay_graph_traits_2.h index dd304368fd0..e9f98f39ffb 100644 --- a/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/CGAL/Segment_Delaunay_graph_traits_2.h +++ b/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/CGAL/Segment_Delaunay_graph_traits_2.h @@ -18,7 +18,7 @@ field-type expressions, i.e., expressions involving additions, subtractions, multiplications and divisions. The default value for `MTag` is `Field_tag`. The way the predicates are evaluated is discussed in -\cite b-ecvdl-96 and \cite cgal:k-reisv-04 (the geometric filtering +\cgalCite{b-ecvdl-96} and \cgalCite{cgal:k-reisv-04} (the geometric filtering part). \cgalModels `SegmentDelaunayGraphTraits_2` @@ -90,7 +90,7 @@ evaluation of signs of ring-type expressions, i.e., expressions involving only additions, subtractions and multiplications. The default value for `MTag` is `Euclidean_ring_tag`. The way the predicates are evaluated is discussed in -\cite b-ecvdl-96 and \cite cgal:k-reisv-04 (the geometric filtering +\cgalCite{b-ecvdl-96} and \cgalCite{cgal:k-reisv-04} (the geometric filtering part). \cgalModels `SegmentDelaunayGraphTraits_2` diff --git a/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/Segment_Delaunay_graph_2.txt b/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/Segment_Delaunay_graph_2.txt index f2c81951ed2..46a0e693f14 100644 --- a/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/Segment_Delaunay_graph_2.txt +++ b/Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/Segment_Delaunay_graph_2.txt @@ -34,7 +34,7 @@ implemented is incremental. The corresponding \cgal class is called `Segment_Delaunay_graph_2` and will be discussed in more detail in the sequel. The interested reader may want to refer to the paper by Karavelas -\cite cgal:k-reisv-04 for the general idea as well as the details of +\cgalCite{cgal:k-reisv-04} for the general idea as well as the details of the algorithm implemented. \subsection Segment_Delaunay_graph_2Definitions Definitions @@ -67,7 +67,7 @@ segments whose bisector is two-dimensional. If we allow pairs of segments that intersect properly at their interior, the interiors of their Voronoi cells are no longer simply connected. In both cases above the resulting Voronoi diagrams are no longer instances of -abstract Voronoi diagrams (cf. \cite k-cavd-89), which has a direct +abstract Voronoi diagrams (cf. \cgalCite{k-cavd-89}), which has a direct consequence on the efficient computation of the corresponding Voronoi diagram. The remedy to these problems is to consider linear segments not as one object, but rather as three, namely the two endpoints and @@ -343,7 +343,7 @@ that have meaning only in the case of strongly intersecting sites. The predicates required for the computation of the segment Voronoi diagram are rather complicated. It is not the purpose of this document to discuss them in detail. The interested reader may refer to Burnikel's -thesis \cite b-ecvdl-96, where it is shown that in the case of weakly +thesis \cgalCite{b-ecvdl-96}, where it is shown that in the case of weakly intersecting sites represented in homogeneous coordinates of bit size \f$ b\f$, the maximum bit size of the algebraic expressions involved in the predicates is \f$ 40 b+O(1)\f$. Given our site representation given above we @@ -477,14 +477,14 @@ of the `Triangulation_hierarchy_2` or the `Apollonius_graph_hierarchy_2` classes, applied to the segment Delaunay graph. It consists of a hierarchy of segment Delaunay graphs constructed in a manner analogous to the -Delaunay hierarchy by Devillers \cite cgal:d-dh-02. Unlike the +Delaunay hierarchy by Devillers \cgalCite{cgal:d-dh-02}. Unlike the triangulation hierarchy or the Apollonius graph hierarchy, the situation here is more complicated because of two factors: firstly, segments are treated as three objects instead of one (the two endpoints and the interior of the segments), and secondly, the presence of strongly intersecting sites complicates significantly the way the hierarchy is constructed. The interested reader may refer to -the paper by Karavelas \cite cgal:k-reisv-04 for the details of the +the paper by Karavelas \cgalCite{cgal:k-reisv-04} for the details of the construction of the hierarchy. Another alternative is to have a hybrid hierarchy that consists of the segment Delaunay graph at the bottom-most level and point Voronoi @@ -494,7 +494,7 @@ Delaunay graph for segments at the upper levels of the hierarchy. However, it seems much less likely to be possible to give any theoretical guarantees for its performance, in contrast to the hierarchy with segment Delaunay graphs at all levels -(cf. \cite cgal:k-reisv-04). The user can choose between the two +(cf. \cgalCite{cgal:k-reisv-04}). The user can choose between the two types of hierarchies by means of the template parameter `SSTag`. If `SSTag` is set to `false` (which is also the default value), the upper levels of the hierarchy consist of point diff --git a/Skin_surface_3/doc/Skin_surface_3/CGAL/make_skin_surface_mesh_3.h b/Skin_surface_3/doc/Skin_surface_3/CGAL/make_skin_surface_mesh_3.h index 1ddadf33ae8..2df94dec5fb 100644 --- a/Skin_surface_3/doc/Skin_surface_3/CGAL/make_skin_surface_mesh_3.h +++ b/Skin_surface_3/doc/Skin_surface_3/CGAL/make_skin_surface_mesh_3.h @@ -7,7 +7,7 @@ constructs a mesh of the skin surface defined by the weighted points and the shrink factor. The function `make_skin_surface_mesh_3()` constructs a mesh isotopic to the skin -surface based on the algorithm in \cite cgal:kv-mssct-05. It takes +surface based on the algorithm in \cgalCite{cgal:kv-mssct-05}. It takes as input a range of weighted points and a shrink factor and outputs the mesh in a `Polyhedron_3` object. A number of subdivision steps might be applied to refine the mesh. diff --git a/Skin_surface_3/doc/Skin_surface_3/CGAL/mesh_skin_surface_3.h b/Skin_surface_3/doc/Skin_surface_3/CGAL/mesh_skin_surface_3.h index f3f9317724b..8ab6fe9ca0b 100644 --- a/Skin_surface_3/doc/Skin_surface_3/CGAL/mesh_skin_surface_3.h +++ b/Skin_surface_3/doc/Skin_surface_3/CGAL/mesh_skin_surface_3.h @@ -7,7 +7,7 @@ namespace CGAL { constructs a mesh of the `skin_surface` in `p`. The function `mesh_skin_surface_3()` constructs a mesh isotopic to the skin -surface based on the algorithm in \cite cgal:kv-mssct-05. It takes +surface based on the algorithm in \cgalCite{cgal:kv-mssct-05}. It takes as input a `SkinSurface_3` object, which is a model of the `SkinSurface_3` concept and outputs the mesh in a `Polyhedron_3` object. diff --git a/Skin_surface_3/doc/Skin_surface_3/Skin_surface_3.txt b/Skin_surface_3/doc/Skin_surface_3/Skin_surface_3.txt index 4681cd6a7e3..1dfb9f608ac 100644 --- a/Skin_surface_3/doc/Skin_surface_3/Skin_surface_3.txt +++ b/Skin_surface_3/doc/Skin_surface_3/Skin_surface_3.txt @@ -19,7 +19,7 @@ namespace CGAL { \section sectionSkinSurfaceIntro Introduction -Skin surfaces, introduced by Edelsbrunner in \cite cgal:e-dssd-99, +Skin surfaces, introduced by Edelsbrunner in \cgalCite{cgal:e-dssd-99}, have a rich and simple combinatorial and geometric structure that makes them suitable for modeling large molecules in biological computing. Meshing such surfaces is often required for further @@ -35,7 +35,7 @@ hyperboloids connecting the balls. This package constructs a mesh isotopic to the skin surface defined by a set of balls and a shrink factor using the algorithm described in -\cite cgal:kv-mssct-05. +\cgalCite{cgal:kv-mssct-05}. An optimized algorithm is implemented for meshing the union of a set of balls. @@ -47,7 +47,7 @@ Left: Convex combinations of two weighted points (the two dashed circles). Righ \cgalFigureEnd This section first briefly reviews skin surfaces. For a more thorough -introduction to skin surfaces, we refer to \cite cgal:e-dssd-99 where +introduction to skin surfaces, we refer to \cgalCite{cgal:e-dssd-99} where they were originally introduced. A skin surface is defined in terms of a finite set of weighted points @@ -72,7 +72,7 @@ combinations of their distance functions. \cgalFigureRef{figtwoPoints} (left) shows weighted points that are obtained as convex combinations of the dashed circles. For further reading on the space of circles and spheres we refer to -\cite p-gcc-70. +\cgalCite{p-gcc-70}. Starting from a weighted point \f$ \ssWpoint{p}=({p},\ssWeight{P})\f$, the shrunk weighted point \f$ \ssWpoint{p}^s\f$ is obtained by taking a convex diff --git a/Snap_rounding_2/doc/Snap_rounding_2/CGAL/Snap_rounding_2.h b/Snap_rounding_2/doc/Snap_rounding_2/CGAL/Snap_rounding_2.h index d6c59b8990d..4874ee272f8 100644 --- a/Snap_rounding_2/doc/Snap_rounding_2/CGAL/Snap_rounding_2.h +++ b/Snap_rounding_2/doc/Snap_rounding_2/CGAL/Snap_rounding_2.h @@ -37,17 +37,17 @@ pixel to the right of the pixel containing the origin, for example, will be `(w,0)`. \param number_of_kd_trees The seventh parameter is briefly described later on this page; for a -detailed description see \cite cgal:hp-isr-02. +detailed description see \cgalCite{cgal:hp-isr-02}. Snap Rounding (SR, for short) is a well known method for converting arbitrary-precision arrangements of segments into a fixed-precision -representation \cite gght-srlse-97, \cite gm-rad-98, \cite h-psifp-99. In +representation \cgalCite{gght-srlse-97}, \cgalCite{gm-rad-98}, \cgalCite{h-psifp-99}. In the study of robust geometric computing, it can be classified as a finite precision approximation technique. Iterated Snap Rounding (ISR, for short) is a modification of SR in which each vertex is at least half-the-width-of-a-pixel away from any non-incident edge -\cite cgal:hp-isr-02. This package supports both methods. Algorithmic -details and experimental results are given in \cite cgal:hp-isr-02. +\cgalCite{cgal:hp-isr-02}. This package supports both methods. Algorithmic +details and experimental results are given in \cgalCite{cgal:hp-isr-02}. Given a finite collection \f$ \S\f$ of segments in the plane, the arrangement of \f$ \S\f$ denoted \f$ \A(\S)\f$ is the subdivision of the plane @@ -68,7 +68,7 @@ pixel in the grid used for rounding. ISR is a modification of SR which makes a vertex and a non-incident edge well separated (the distance between each is at least half-the-width-of-a-pixel). However, the guaranteed quality of the approximation in ISR degrades. For more -details on ISR see \cite cgal:hp-isr-02. +details on ISR see \cgalCite{cgal:hp-isr-02}. The traits used here must support (arbitrary-precision) rational number type as this is a basic requirement of SR. diff --git a/Snap_rounding_2/doc/Snap_rounding_2/Snap_rounding_2.txt b/Snap_rounding_2/doc/Snap_rounding_2/Snap_rounding_2.txt index c9d5ffc9393..b88fb92596f 100644 --- a/Snap_rounding_2/doc/Snap_rounding_2/Snap_rounding_2.txt +++ b/Snap_rounding_2/doc/Snap_rounding_2/Snap_rounding_2.txt @@ -14,13 +14,13 @@ namespace CGAL { Snap Rounding (SR, for short) is a well known method for converting arbitrary-precision arrangements of segments into a fixed-precision -representation \cite gght-srlse-97, \cite gm-rad-98, \cite h-psifp-99. In +representation \cgalCite{gght-srlse-97}, \cgalCite{gm-rad-98}, \cgalCite{h-psifp-99}. In the study of robust geometric computing, it can be classified as a finite precision approximation technique. Iterated Snap Rounding (ISR, for short) is a modification of SR in which each vertex is at least half-the-width-of-a-pixel away from any non-incident edge -\cite cgal:hp-isr-02. This package supports both methods. Algorithmic -details and experimental results are given in \cite cgal:hp-isr-02. +\cgalCite{cgal:hp-isr-02}. This package supports both methods. Algorithmic +details and experimental results are given in \cgalCite{cgal:hp-isr-02}. \cgalFigureBegin{figsr1,sr1.png} An arrangement of segments before (a) and after (b) SR (hot pixels are shaded) @@ -56,12 +56,12 @@ the output of SR as input to another round of SR and so on until all the vertices are well separated from non-incident edges. Algorithmically we operate differently, as this repeated application of SR would have resulted in an efficient overall process. The algorithmic details are -given in \cite cgal:hp-isr-02. +given in \cgalCite{cgal:hp-isr-02}. \section Snap_rounding_2Terms Terms and Software Design Our package supports both schemes, implementing the algorithm -described in \cite cgal:hp-isr-02. +described in \cgalCite{cgal:hp-isr-02}. Although the paper only describes an algorithm for ISR, it is easy to derive an algorithm for SR, by performing only the first rounding level for each segment. diff --git a/Spatial_searching/doc/Spatial_searching/Spatial_searching.txt b/Spatial_searching/doc/Spatial_searching/Spatial_searching.txt index 74e6363dce5..dc529f9c988 100644 --- a/Spatial_searching/doc/Spatial_searching/Spatial_searching.txt +++ b/Spatial_searching/doc/Spatial_searching/Spatial_searching.txt @@ -60,7 +60,7 @@ nearest neighbors has to be guessed. If the guess is too large redundant computations are performed. If the number is too small the computation has to be re-invoked for a larger number of neighbors, thereby performing redundant computations. Therefore, Hjaltason and -Samet \cite hs-rsd-95 introduced incremental nearest neighbor +Samet \cgalCite{hs-rsd-95} introduced incremental nearest neighbor searching in the sense that having obtained the `k` nearest neighbors, the `k + 1`st neighbor can be obtained without having to calculate the `k + 1` nearest neighbor from scratch. @@ -337,7 +337,7 @@ splitting rule, needed to set the maximal allowed bucket size. \subsection Kd_tree_subsection The k-d tree -Bentley \cite b-mbstu-75 introduced the `k-d` tree as a +Bentley \cgalCite{b-mbstu-75} introduced the `k-d` tree as a generalization of the binary search tree in higher dimensions. `k-d` trees hierarchically decompose space into a relatively small number of rectangles such that no rectangle contains too many input objects. @@ -361,7 +361,7 @@ threshold. The rectangles associated with the leaf nodes are called rectangles. Data points are only stored in the leaf nodes of the tree, not in the internal nodes. -Friedmann, Bentley and Finkel \cite fbf-afbml-77 described the +Friedmann, Bentley and Finkel \cgalCite{fbf-afbml-77} described the standard search algorithm to find the `k`th nearest neighbor by searching a `k-d` tree recursively. @@ -369,7 +369,7 @@ When encountering a node of the tree, the algorithm first visits the child that is closest to the query point. On return, if the rectangle containing the other child lies within 1/ (1+\f$ \epsilon\f$) times the distance to the `k`th nearest neighbors so far, then the other child -is visited recursively. Priority search \cite am-annqf-93 visits the +is visited recursively. Priority search \cgalCite{am-annqf-93} visits the nodes in increasing order of distance from the queue with help of a priority queue. The search stops when the distance of the query point to the nearest nodes exceeds the distance to the nearest point found @@ -381,7 +381,7 @@ neighbor searching in high dimensional space, the approximate searching package supports orthogonal distance computation. Orthogonal distance computation implements the efficient incremental distance computation technique -introduced by Arya and Mount \cite am-afvq-93. This technique +introduced by Arya and Mount \cgalCite{am-afvq-93}. This technique works only for neighbor queries with query items represented as points and with a quadratic form distance, defined by \f$ d_A(x,y)= (x-y)A(x-y)^T\f$, where the matrix \f$ A\f$ is positive definite, diff --git a/Spatial_sorting/doc/Spatial_sorting/Spatial_sorting.txt b/Spatial_sorting/doc/Spatial_sorting/Spatial_sorting.txt index 7fb80fc89cb..55f77e5402c 100644 --- a/Spatial_sorting/doc/Spatial_sorting/Spatial_sorting.txt +++ b/Spatial_sorting/doc/Spatial_sorting/Spatial_sorting.txt @@ -29,7 +29,7 @@ Some algorithms have a good complexity under randomized hypotheses which contradicts the idea of sorting the input using any sorting criterion. In such a case, it is possible to introduce just a bit of randomness to be able to combine the good randomized complexity and the -good effects of locality \cite acr-icb-03. +good effects of locality \cgalCite{acr-icb-03}. The predicates used by this package are comparisons between coordinates, thus there is no robustness issue involved here, for example to choose the @@ -99,7 +99,7 @@ Since the median policy cannot be much worse than the middle policy, while the converse can happen, the median policy is the default behavior. Most theoretical results are using the middle policy -\cite acr-icb-03, \cite b-aahsf-71, \cite bg-sfche-89,pb-scpts-89. +\cgalCite{acr-icb-03}, \cgalCite{b-aahsf-71}, \cgalCite{bg-sfche-89},pb-scpts-89. This other example illustrates the use of the two different policies @@ -113,7 +113,7 @@ sizes, Hilbert sort being used only inside a bucket. It has been proved, in the context of Delaunay triangulation, that such an order provides enough randomness to combine the advantages of a random -order and a space filling curve order \cite acr-icb-03. +order and a space filling curve order \cgalCite{acr-icb-03}. \cgal provides spatial sorting for points in 2D, 3D and higher dimensions, with the middle and the median policies for Hilbert sort in the buckets. diff --git a/Straight_skeleton_2/doc/Straight_skeleton_2/CGAL/Straight_skeleton_builder_2.h b/Straight_skeleton_2/doc/Straight_skeleton_2/CGAL/Straight_skeleton_builder_2.h index 92bb30cd894..68d251c27bb 100644 --- a/Straight_skeleton_2/doc/Straight_skeleton_2/CGAL/Straight_skeleton_builder_2.h +++ b/Straight_skeleton_2/doc/Straight_skeleton_2/CGAL/Straight_skeleton_builder_2.h @@ -35,7 +35,7 @@ The class `Straight_skeleton_builder_2` encapsulates the construction of the 2D \cgalHeading{Algorithm} -The implemented algorithm is closely based on \cite cgal:fo-ss-98 with the addition of vertex events as described in \cite cgal:ee-rrccpp-98. +The implemented algorithm is closely based on \cgalCite{cgal:fo-ss-98} with the addition of vertex events as described in \cgalCite{cgal:ee-rrccpp-98}. It simulates a grassfire propagation of moving polygon edges as they move inward at constant and equal speed. That is, the continuous inward offsetting of the polygon. diff --git a/Straight_skeleton_2/doc/Straight_skeleton_2/Straight_skeleton_2.txt b/Straight_skeleton_2/doc/Straight_skeleton_2/Straight_skeleton_2.txt index 4086135cc7b..5a727d6b5e5 100644 --- a/Straight_skeleton_2/doc/Straight_skeleton_2/Straight_skeleton_2.txt +++ b/Straight_skeleton_2/doc/Straight_skeleton_2/Straight_skeleton_2.txt @@ -63,7 +63,7 @@ Each offset polygon has the same orientation as the source polygon. \subsection Straight_skeleton_2StraightSkeletonofa2D Straight Skeleton of a 2D Non-degenerate Strictly-Simple Polygon with Holes -The 2D straight skeleton of a non-degenerate strictly-simple polygon with holes \cite aaag-ntsp-95 is a special partitioning of the polygon interior into straight skeleton regions corresponding to the monotone areas traced by a continuous inward offsetting of the contour edges. Each region corresponds to exactly 1 contour edge. +The 2D straight skeleton of a non-degenerate strictly-simple polygon with holes \cgalCite{aaag-ntsp-95} is a special partitioning of the polygon interior into straight skeleton regions corresponding to the monotone areas traced by a continuous inward offsetting of the contour edges. Each region corresponds to exactly 1 contour edge. These regions are bounded by angular bisectors of the supporting lines of the contour edges and each such region is itself a non-convex non-degenerate strictly-simple polygon. @@ -450,7 +450,7 @@ pretty much alike a proper medial axis. The most natural usage of straight skeletons is offsetting: growing and shrinking polygons (provided by this \cgal package). -Another usage, perhaps its very first, is roof design: The straight skeleton of a polygonal roof directly gives the layout of each tent. If each skeleton edge is lifted from the plane a height equal to its offset distance, the resulting roof is "correct" in that water will always fall down to the contour edges (roof border) regardless of were in the roof it falls. \cite cgal:ld-agrm-03 gives an algorithm for roof design based on the straight skeleton. +Another usage, perhaps its very first, is roof design: The straight skeleton of a polygonal roof directly gives the layout of each tent. If each skeleton edge is lifted from the plane a height equal to its offset distance, the resulting roof is "correct" in that water will always fall down to the contour edges (roof border) regardless of were in the roof it falls. \cgalCite{cgal:ld-agrm-03} gives an algorithm for roof design based on the straight skeleton. Just like medial axes, 2D straight skeletons can also be used for 2D shape description and matching. Essentially, all the applications of image-based skeletonization (for which there is a vast literature) are also direct applications of the straight skeleton, specially since skeleton edges are simply straight line segments. @@ -466,7 +466,7 @@ Each skeleton edge in a skeleton branch is associated with 2 contour edges which \section Straight_skeleton_2Straight_1 Straight Skeleton of a General Figure in the Plane A straight skeleton can also be defined for a general -multiply-connected planar directed straight-line graph \cite aa-skfgpf-95 by considering +multiply-connected planar directed straight-line graph \cgalCite{aa-skfgpf-95} by considering all the edges as embedded in an unbounded region. The only difference is that in this case some faces will be only partially bounded. diff --git a/Stream_lines_2/doc/Stream_lines_2/Stream_lines_2.txt b/Stream_lines_2/doc/Stream_lines_2/Stream_lines_2.txt index e8737e69c82..fa97db476f6 100644 --- a/Stream_lines_2/doc/Stream_lines_2/Stream_lines_2.txt +++ b/Stream_lines_2/doc/Stream_lines_2/Stream_lines_2.txt @@ -101,12 +101,12 @@ p_{k+1} & = & p_k & + & hv(p'_k) \\ \end{array} \f] -See \cite cgal:ptvf-nrcpp-02 for further details about numerical +See \cgalCite{cgal:ptvf-nrcpp-02} for further details about numerical integration. \section Section_2D_Streamlines_Strategy Farthest Point Seeding Strategy -The algorithm implemented in this package \cite cgal:mad-fpsep-05 +The algorithm implemented in this package \cgalCite{cgal:mad-fpsep-05} consists of placing one streamline at a time by numerical integration starting farthest away from all previously placed streamlines. @@ -158,7 +158,7 @@ processed via a list of Delaunay triangulation vertices. To implement the triangular grid, the class `Delaunay_triangulation_2` is used. The priority queue used to store candidate seed points is taken from the Standard Template -Library \cite cgal:sgcsi-stlpg-97. +Library \cgalCite{cgal:sgcsi-stlpg-97}. \section Section_2D_Streamlines_Example Examples diff --git a/Subdivision_method_3/doc/Subdivision_method_3/Subdivision_method_3.txt b/Subdivision_method_3/doc/Subdivision_method_3/Subdivision_method_3.txt index 265a6da2da8..4c48b55964b 100644 --- a/Subdivision_method_3/doc/Subdivision_method_3/Subdivision_method_3.txt +++ b/Subdivision_method_3/doc/Subdivision_method_3/Subdivision_method_3.txt @@ -35,7 +35,7 @@ host. In this chapter, we explain some fundamentals of subdivision methods. We focus only on the topics that help you -to understand the design of the package. \cite cgal:ww-smgd-02 +to understand the design of the package. \cgalCite{cgal:ww-smgd-02} has details on subdivision methods. Some terminology introduced in this section will be used again in later sections. If you are only interested in using a @@ -57,7 +57,7 @@ to approximate a smooth surface. Many refinement patterns are used in practice. `Subdivision_method_3` supports the four most popular patterns, and each of them is used by -Catmull-Clark\cite cgal:cc-rgbss-78, Loop, Doo-Sabin +Catmull-Clark\cgalCite{cgal:cc-rgbss-78}, Loop, Doo-Sabin and \f$ \sqrt{3}\f$ subdivision (left to right in the figure). We name these patterns by their topological characteristics instead of the associated subdivision methods. @@ -111,7 +111,7 @@ a facet-node of PQQ refinement may be computed by the summation of \f$ 1/5\f$ of each stencil node instead of \f$ 1/4\f$. Although it is legal in `Subdivision_method_3` to have any kind of geometry mask, the result surfaces may be odd, -not smooth, or not even exist. \cite cgal:ww-smgd-02 explains the +not smooth, or not even exist. \cgalCite{cgal:ww-smgd-02} explains the details on designing masks for a quality subdivision surface. \section secFirstSub A Quick Example: Catmull-Clark Subdivision @@ -385,7 +385,7 @@ polyhedron is undefined. `Subdivision_method_3` does not verify the precondition of the mesh characteristics before the refinement. For details of the refinement implementation, -interested users should refer to \cite cgal:sp-mrbee-05. +interested users should refer to \cgalCite{cgal:sp-mrbee-05}. \section Subdivision_method_3Geometry Geometry Policy diff --git a/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/BorderParameterizer_3.h b/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/BorderParameterizer_3.h index 095e7b7a9a5..676be8ffa94 100644 --- a/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/BorderParameterizer_3.h +++ b/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/BorderParameterizer_3.h @@ -10,7 +10,7 @@ Implementation note: To simplify the implementation, `BorderParameterizer_3` mod Design Pattern -------------- -`BorderParameterizer_3` models are Strategies \cite cgal:ghjv-dpero-95 : they implement a strategy of border parameterization for models of `ParameterizationMesh_3`. +`BorderParameterizer_3` models are Strategies \cgalCite{cgal:ghjv-dpero-95} : they implement a strategy of border parameterization for models of `ParameterizationMesh_3`. Creation -------------- diff --git a/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/ParameterizationMesh_3.h b/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/ParameterizationMesh_3.h index afca395c773..bc834ae49be 100644 --- a/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/ParameterizationMesh_3.h +++ b/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/ParameterizationMesh_3.h @@ -16,7 +16,7 @@ The surface must be an oriented 2-manifold with border vertices, i.e.\ the neigh Design Pattern -------------- -`ParameterizationMesh_3` is an Adaptor \cite cgal:ghjv-dpero-95 : it changes the interface of a 3D mesh to match the interface expected by the parameterization methods. +`ParameterizationMesh_3` is an Adaptor \cgalCite{cgal:ghjv-dpero-95} : it changes the interface of a 3D mesh to match the interface expected by the parameterization methods. Creation -------------- diff --git a/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/ParameterizationPatchableMesh_3.h b/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/ParameterizationPatchableMesh_3.h index 1b9dab2385e..890ed1575ba 100644 --- a/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/ParameterizationPatchableMesh_3.h +++ b/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/ParameterizationPatchableMesh_3.h @@ -14,7 +14,7 @@ The main purpose of this feature is to allow the `Surface_mesh_parameterization` Design Pattern -------------- -`ParameterizationPatchableMesh_3` is an Adaptor \cite cgal:ghjv-dpero-95 : it changes the interface of a 3D mesh to match the interface expected by class `Parameterization_mesh_patch_3`. +`ParameterizationPatchableMesh_3` is an Adaptor \cgalCite{cgal:ghjv-dpero-95} : it changes the interface of a 3D mesh to match the interface expected by class `Parameterization_mesh_patch_3`. \cgalRefines `ParameterizationMesh_3` diff --git a/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/ParameterizerTraits_3.h b/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/ParameterizerTraits_3.h index 43e0cb9c336..8a2c7757795 100644 --- a/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/ParameterizerTraits_3.h +++ b/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Concepts/ParameterizerTraits_3.h @@ -8,7 +8,7 @@ Design Pattern -------------- -`ParameterizerTraits_3` models are Strategies \cite cgal:ghjv-dpero-95 : they implement a strategy of surface parameterization for models of `ParameterizationMesh_3`. +`ParameterizerTraits_3` models are Strategies \cgalCite{cgal:ghjv-dpero-95} : they implement a strategy of surface parameterization for models of `ParameterizationMesh_3`. Creation -------------- diff --git a/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/PackageDescription.txt b/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/PackageDescription.txt index 14d9f2b144f..73c7695b60d 100644 --- a/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/PackageDescription.txt +++ b/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/PackageDescription.txt @@ -39,16 +39,16 @@ This \cgal package implements several parameterization methods: - Fixed border: - - Tutte Barycentric Mapping \cite t-hdg-63. + - Tutte Barycentric Mapping \cgalCite{t-hdg-63}. One-to-one mapping is guaranteed for convex border. - - Floater Mean Value Coordinates \cite cgal:f-mvc-03. + - Floater Mean Value Coordinates \cgalCite{cgal:f-mvc-03}. One-to-one mapping is guaranteed for convex border. - - Discrete Conformal Map \cite cgal:eddhls-maam-95. + - Discrete Conformal Map \cgalCite{cgal:eddhls-maam-95}. Conditionally guaranteed if all weights are positive and border is convex. - - Discrete Authalic parameterization \cite cgal:dma-ipsm-02. + - Discrete Authalic parameterization \cgalCite{cgal:dma-ipsm-02}. Conditionally guaranteed if all weights are positive and border is convex. - Free border: - - Least Squares Conformal Maps \cite cgal:lprm-lscm-02. + - Least Squares Conformal Maps \cgalCite{cgal:lprm-lscm-02}. - `CGAL::Parameterizer_traits_3` - `CGAL::Fixed_border_parameterizer_3` @@ -175,16 +175,16 @@ use `SURFACE_MESH_PARAMETERIZATION` in their names (e.g. `CGAL_SURFACE_MESH_PARA This \cgal package implements several parameterization methods: - Fixed border: - - Tutte Barycentric Mapping \cite t-hdg-63. + - Tutte Barycentric Mapping \cgalCite{t-hdg-63}. One-to-one mapping is guaranteed for convex border. - - Floater Mean Value Coordinates \cite cgal:f-mvc-03. + - Floater Mean Value Coordinates \cgalCite{cgal:f-mvc-03}. One-to-one mapping is guaranteed for convex border. - - Discrete Conformal Map \cite cgal:eddhls-maam-95. + - Discrete Conformal Map \cgalCite{cgal:eddhls-maam-95}. Conditionally guaranteed if all weights are positive and border is convex. - - Discrete Authalic parameterization \cite cgal:dma-ipsm-02. + - Discrete Authalic parameterization \cgalCite{cgal:dma-ipsm-02}. Conditionally guaranteed if all weights are positive and border is convex. - Free border: - - Least Squares Conformal Maps \cite cgal:lprm-lscm-02. + - Least Squares Conformal Maps \cgalCite{cgal:lprm-lscm-02}. */ /*! diff --git a/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Surface_mesh_parameterization.txt b/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Surface_mesh_parameterization.txt index f5f3c3e01f1..c431ce598a6 100644 --- a/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Surface_mesh_parameterization.txt +++ b/Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Surface_mesh_parameterization.txt @@ -68,9 +68,9 @@ Parameterizer_traits_3::Error_code parameterize (Paramet \endcode The function `parameterize()` applies a default surface parameterization -method, namely Floater Mean Value Coordinates \cite cgal:f-mvc-03, with an +method, namely Floater Mean Value Coordinates \cgalCite{cgal:f-mvc-03}, with an arc-length circular border parameterization, and using OpenNL sparse -linear solver \cite cgal:l-nmdgp-05. The `ParameterizationMesh_3` concept defines the input meshes handled by `parameterize()`. See Section \ref secInputMeshforparameterize. The result is stored into the `(u,v)` fields of the mesh halfedges. +linear solver \cgalCite{cgal:l-nmdgp-05}. The `ParameterizationMesh_3` concept defines the input meshes handled by `parameterize()`. See Section \ref secInputMeshforparameterize. The result is stored into the `(u,v)` fields of the mesh halfedges. The mesh must be a triangle mesh surface with one connected component. Note: `Parameterizer_traits_3` is the (pure virtual) superclass of all surface parameterizations and defines the error codes. @@ -202,7 +202,7 @@ Such border parameterizations are described in Section `Barycentric_mapping_parameterizer_3` The Barycentric Mapping parameterization method has been introduced by -Tutte \cite t-hdg-63. In parameter space, each vertex is +Tutte \cgalCite{t-hdg-63}. In parameter space, each vertex is placed at the barycenter of its neighbors to achieve the so-called convex combination condition. This algorithm amounts to solve one sparse linear solver for each set of parameter coordinates, with a @@ -223,10 +223,10 @@ Left: Tutte barycentric mapping parameterization (the red line depicts the cut g `Discrete_conformal_map_parameterizer_3` Discrete conformal map parameterization has been introduced by Eck et -al. to the graphics community \cite cgal:eddhls-maam-95. It attempts to +al. to the graphics community \cgalCite{cgal:eddhls-maam-95}. It attempts to lower angle deformation by minimizing a discrete version of the Dirichlet energy as derived by Pinkall and -Polthier \cite cgal:pp-cdmsc-93. A one-to-one mapping is guaranteed +Polthier \cgalCite{cgal:pp-cdmsc-93}. A one-to-one mapping is guaranteed only when the two following conditions are fulfilled: the barycentric mapping condition (each vertex in parameter space is a convex combination if its neighboring vertices), and the border is convex. @@ -245,7 +245,7 @@ Left: discrete conformal map. Right: parameter space. `Mean_value_coordinates_parameterizer_3` The mean value coordinates parameterization method has been introduced -by Floater \cite cgal:f-mvc-03. Each vertex in parameter space is +by Floater \cgalCite{cgal:f-mvc-03}. Each vertex in parameter space is optimized so as to be a convex combination of its neighboring vertices. The barycentric coordinates are this time unconditionally positive, by deriving an application of the mean theorem for harmonic @@ -263,7 +263,7 @@ Floater Mean Value Coordinates `Discrete_authalic_parameterizer_3` The discrete authalic parameterization method has been introduced by -Desbrun et al. \cite cgal:dma-ipsm-02. It corresponds to +Desbrun et al. \cgalCite{cgal:dma-ipsm-02}. It corresponds to a weak formulation of an area-preserving method, and in essence locally minimizes the area distortion. A one-to-one mapping is guaranteed only if the convex combination condition is fulfilled and @@ -326,7 +326,7 @@ Left: Julius Cesar mask parameterization with Authalic/circular border. Right: J `LSCM_parameterizer_3` The Least Squares Conformal Maps (LSCM) parameterization method has -been introduced by Lévy et al. \cite cgal:lprm-lscm-02. +been introduced by Lévy et al. \cgalCite{cgal:lprm-lscm-02}. It corresponds to a conformal method with a free border (at least two vertices have to be constrained to obtain a unique solution), which allows further lowering of the angle distortion. A one-to-one mapping @@ -431,7 +431,7 @@ and include a separate package devoted to OpenNL sparse linear solver. We provide an interface to several sparse linear solvers, as models of the `SparseLinearAlgebraTraits_d` concept: -- An interface to sparse solvers from the `OpenNL` library \cite cgal:l-nmdgp-05 is provided through classes +- An interface to sparse solvers from the `OpenNL` library \cgalCite{cgal:l-nmdgp-05} is provided through classes `OpenNL::DefaultLinearSolverTraits` and `OpenNL::SymmetricLinearSolverTraits`. The OpenNL library version shipped with \cgal is a lightweight default sparse linear solver. It does not support large systems, but it is portable and supports exact number types. @@ -710,7 +710,7 @@ You may also wonder why there is not just one `parameterize()` function with a default `ParameterizerTraits_3` argument equal to `Mean_value_coordinates_parameterizer_3`. The reason is simply that this is not allowed by the C++ standard (see -\cite cgal:ansi-is14882-98, paragraph 14.1/9). +\cgalCite{cgal:ansi-is14882-98}, paragraph 14.1/9). \subsection Surface_mesh_parameterizationNoCommonParameterization No Common Parameterization Algorithm @@ -770,7 +770,7 @@ superclass of all surface parameterization classes. Linear fixed border parameterization algorithms are very close. They mainly differ by the energy that they try to minimize, i.e.\ by the value of the \f$ w_{ij}\f$ coefficient of the \f$ A\f$ matrix, for \f$ v_i\f$ and \f$ v_j\f$ neighbor vertices of the mesh -\cite cgal:fh-survey-05. One consequence is that most of the code of the fixed border methods is factorized in the +\cgalCite{cgal:fh-survey-05}. One consequence is that most of the code of the fixed border methods is factorized in the `Fixed_border_parameterizer_3` class. Subclasses: @@ -813,7 +813,7 @@ and accessors to the extra field arrays. This is the choice of the Boost Graph Library with `boost::graph_traits<>` and the property maps.
  • Pass to all classes and methods an object that points to the actual mesh and knows -how to access to its fields. This is the Adaptor concept \cite cgal:ghjv-dpero-95. +how to access to its fields. This is the Adaptor concept \cgalCite{cgal:ghjv-dpero-95}. The current design of this package uses the second option, which is simpler. diff --git a/Surface_mesh_parameterization/include/CGAL/Barycentric_mapping_parameterizer_3.h b/Surface_mesh_parameterization/include/CGAL/Barycentric_mapping_parameterizer_3.h index 4dcd99a433a..f9b4186010a 100644 --- a/Surface_mesh_parameterization/include/CGAL/Barycentric_mapping_parameterizer_3.h +++ b/Surface_mesh_parameterization/include/CGAL/Barycentric_mapping_parameterizer_3.h @@ -31,7 +31,7 @@ namespace CGAL { /// \ingroup PkgSurfaceParameterizationMethods /// -/// The class Barycentric_mapping_parameterizer_3 implements Tutte Barycentric Mapping algorithm \cite t-hdg-63. +/// The class Barycentric_mapping_parameterizer_3 implements Tutte Barycentric Mapping algorithm \cgalCite{t-hdg-63}. /// This algorithm is also called Tutte Uniform Weights by other authors. /// /// One-to-one mapping is guaranteed if the surface's border is mapped to a convex polygon. diff --git a/Surface_mesh_parameterization/include/CGAL/Discrete_authalic_parameterizer_3.h b/Surface_mesh_parameterization/include/CGAL/Discrete_authalic_parameterizer_3.h index 8f5d50da438..f007f2d825c 100644 --- a/Surface_mesh_parameterization/include/CGAL/Discrete_authalic_parameterizer_3.h +++ b/Surface_mesh_parameterization/include/CGAL/Discrete_authalic_parameterizer_3.h @@ -33,7 +33,7 @@ namespace CGAL { /// \ingroup PkgSurfaceParameterizationMethods /// /// The class `Discrete_authalic_parameterizer_3` -/// implements the *Discrete Authalic Parameterization* algorithm \cite cgal:dma-ipsm-02. +/// implements the *Discrete Authalic Parameterization* algorithm \cgalCite{cgal:dma-ipsm-02}. /// This method is sometimes called DAP or just Authalic parameterization. /// /// DAP is a weak area-preserving parameterization. It is a compromise between @@ -41,7 +41,7 @@ namespace CGAL { /// /// One-to-one mapping is guaranteed if surface's border is mapped onto a convex polygon. /// -/// This class is a Strategy \cite cgal:ghjv-dpero-95 called by the main +/// This class is a Strategy \cgalCite{cgal:ghjv-dpero-95} called by the main /// parameterization algorithm `Fixed_border_parameterizer_3::parameterize()`. /// `Discrete_authalic_parameterizer_3`: /// - It provides default `BorderParameterizer_3` and `SparseLinearAlgebraTraits_d` template diff --git a/Surface_mesh_parameterization/include/CGAL/Discrete_conformal_map_parameterizer_3.h b/Surface_mesh_parameterization/include/CGAL/Discrete_conformal_map_parameterizer_3.h index cd927f18d2c..d31f702c7e4 100644 --- a/Surface_mesh_parameterization/include/CGAL/Discrete_conformal_map_parameterizer_3.h +++ b/Surface_mesh_parameterization/include/CGAL/Discrete_conformal_map_parameterizer_3.h @@ -33,7 +33,7 @@ namespace CGAL { /// \ingroup PkgSurfaceParameterizationMethods /// /// The class Discrete_conformal_map_parameterizer_3 -/// implements the Discrete Conformal Map (DCM) parameterization \cite cgal:eddhls-maam-95. +/// implements the Discrete Conformal Map (DCM) parameterization \cgalCite{cgal:eddhls-maam-95}. /// This algorithm is also called Discrete Conformal Parameterization (DCP), /// Discrete Harmonic Map or Fixed Conformal Parameterization by other authors. /// diff --git a/Surface_mesh_parameterization/include/CGAL/LSCM_parameterizer_3.h b/Surface_mesh_parameterization/include/CGAL/LSCM_parameterizer_3.h index bbcff1171a5..8caf76f3fa6 100644 --- a/Surface_mesh_parameterization/include/CGAL/LSCM_parameterizer_3.h +++ b/Surface_mesh_parameterization/include/CGAL/LSCM_parameterizer_3.h @@ -44,7 +44,7 @@ namespace CGAL { /// \ingroup PkgSurfaceParameterizationMethods /// /// The class LSCM_parameterizer_3 implements the -/// *Least Squares Conformal Maps (LSCM)* parameterization \cite cgal:lprm-lscm-02. +/// *Least Squares Conformal Maps (LSCM)* parameterization \cgalCite{cgal:lprm-lscm-02}. /// /// This is a conformal parameterization, i.e. it attempts to preserve angles. /// diff --git a/Surface_mesh_parameterization/include/CGAL/Mean_value_coordinates_parameterizer_3.h b/Surface_mesh_parameterization/include/CGAL/Mean_value_coordinates_parameterizer_3.h index ea8a45d5c3f..bbb8246fb81 100644 --- a/Surface_mesh_parameterization/include/CGAL/Mean_value_coordinates_parameterizer_3.h +++ b/Surface_mesh_parameterization/include/CGAL/Mean_value_coordinates_parameterizer_3.h @@ -33,7 +33,7 @@ namespace CGAL { /// \ingroup PkgSurfaceParameterizationMethods /// /// The class Mean_value_coordinates_parameterizer_3 -/// implements *Floater Mean Value Coordinates* parameterization \cite cgal:f-mvc-03. +/// implements *Floater Mean Value Coordinates* parameterization \cgalCite{cgal:f-mvc-03}. /// This method is sometimes called simply *Floater parameterization*. /// /// This is a conformal parameterization, i.e. it attempts to preserve angles. diff --git a/Surface_mesh_simplification/doc/Surface_mesh_simplification/Concepts/EdgeCollapsableMesh.h b/Surface_mesh_simplification/doc/Surface_mesh_simplification/Concepts/EdgeCollapsableMesh.h index 5891a6ac98f..17db00f9526 100644 --- a/Surface_mesh_simplification/doc/Surface_mesh_simplification/Concepts/EdgeCollapsableMesh.h +++ b/Surface_mesh_simplification/doc/Surface_mesh_simplification/Concepts/EdgeCollapsableMesh.h @@ -74,7 +74,7 @@ remains. \cgalHasModel `CGAL::Polyhedron_3` (If it has only triangular faces, and via -External Adaptation, which is described in \cite cgal:sll-bgl-02 +External Adaptation, which is described in \cgalCite{cgal:sll-bgl-02} and this Bgl web page: http://www.boost.org/libs/graph/doc/leda_conversion.html). \sa `boost::graph_traits< CGAL::Polyhedron_3 >` @@ -89,7 +89,7 @@ public: /*! Collapses the undirected edge `(v0v1,v1v0)` replacing it with `v0` or `v1`, as described in the following paragraph. -\pre This function requires `mesh` to be an oriented 2-manifold with or without boundaries. Furthermore, the undirected edge `(v0v1,v1v0)` must satisfy the link condition \cite degn-tpec-98, which guarantees that the surface is also 2-manifold after the edge collapse. +\pre This function requires `mesh` to be an oriented 2-manifold with or without boundaries. Furthermore, the undirected edge `(v0v1,v1v0)` must satisfy the link condition \cgalCite{degn-tpec-98}, which guarantees that the surface is also 2-manifold after the edge collapse. \relates EdgeCollapsableMesh */ template diff --git a/Surface_mesh_simplification/doc/Surface_mesh_simplification/Surface_mesh_simplification.txt b/Surface_mesh_simplification/doc/Surface_mesh_simplification/Surface_mesh_simplification.txt index b942f9bcaf0..e9663bfcb7c 100644 --- a/Surface_mesh_simplification/doc/Surface_mesh_simplification/Surface_mesh_simplification.txt +++ b/Surface_mesh_simplification/doc/Surface_mesh_simplification/Surface_mesh_simplification.txt @@ -36,7 +36,7 @@ of functions and traits, making it easy to adapt any concrete surface type, even if it is not a halfedge data structure at all. In particular, the concept definition follows the design of the Boost Graph Library (Bgl) -\cite cgal:sll-bgl-02. +\cgalCite{cgal:sll-bgl-02}. The design is policy-based (http://en.wikipedia.org/wiki/Policy-based_design), @@ -84,8 +84,8 @@ Global error tracking methods produce highly accurate simplifications but take u of additional space. Cost-driven methods, like the one in this package, produce slightly less accurate simplifications but take up much less additional space, even none in some cases. -The cost-driven method implemented in this package is mainly based on \cite cgal:lt-fmeps-98, \cite cgal:lt-ems-99, with contributions from \cite hddms-mo-93, \cite gh-ssqem-97 -and \cite degn-tpec-98. +The cost-driven method implemented in this package is mainly based on \cgalCite{cgal:lt-fmeps-98}, \cgalCite{cgal:lt-ems-99}, with contributions from \cgalCite{hddms-mo-93}, \cgalCite{gh-ssqem-97} +and \cgalCite{degn-tpec-98}. The algorithm proceeds in two stages. In the first stage, called collection stage, an initial collapse cost is assigned to each and every edge in the surface. @@ -99,9 +99,9 @@ Not all edges selected for processing are collapsed. A processed edge can be dis right away, without being collapsed, if it does not satisfy certain topological and geometric conditions. -The algorithm presented in \cite gh-ssqem-97 contracts (collapses) arbitrary vertex pairs and not +The algorithm presented in \cgalCite{gh-ssqem-97} contracts (collapses) arbitrary vertex pairs and not only edges by considering certain vertex pairs as forming a pseudo-edge and proceeding to collapse -both edges and pseudo-edges in the same way as in \cite cgal:lt-fmeps-98, \cite cgal:lt-ems-99 ( +both edges and pseudo-edges in the same way as in \cgalCite{cgal:lt-fmeps-98}, \cgalCite{cgal:lt-ems-99} ( which is the algorithm implemented here). However, contracting an arbitrary vertex-pair may result in a non-manifold surface, but the current state of this package can only deal with manifold surfaces, thus, it can only collapse edges. That is, this package cannot be used as a framework for vertex contraction. \section Surface_mesh_simplificationCost Cost Strategy @@ -119,7 +119,7 @@ midpoint placement (much faster but less accurate). \subsection SurfaceMeshSimplificationLindstromTurkStrategy Lindstrom-Turk Cost and Placement Strategy The main characteristic of the strategy presented in -\cite cgal:lt-fmeps-98, \cite cgal:lt-ems-99 is that the simplified surface +\cgalCite{cgal:lt-fmeps-98}, \cgalCite{cgal:lt-ems-99} is that the simplified surface is not compared at each step with the original surface (or the surface at a previous step) so there is no need to keep extra information, such as the original surface or a history of the local changes. Hence @@ -216,7 +216,7 @@ There are two main parameters to the algorithm: the surface to be simplified (in The surface to simplify must be a model of the `EdgeCollapsableMesh` concept. Many concrete surface types, such as `Polyhedron_3` with only triangular faces, become models of that concept via a technique known as -external adaptation, which is described in \cite cgal:sll-bgl-02 +external adaptation, which is described in \cgalCite{cgal:sll-bgl-02} and this Bgl web page: http://www.boost.org/libs/graph/doc/leda_conversion.html External adaptation is a way to add an interface to an @@ -231,7 +231,7 @@ returns `true` the algorithm terminates. \subsection Surface_mesh_simplificationOptionalNamed Optional Named Parameters -The notion of named parameters was also introduced in the Bgl. You can read about it in \cite cgal:sll-bgl-02 or the following site: http://www.boost.org/libs/graph/doc/bgl_named_params.html. Named parameters allow the user to specify only those parameters which are really needed, by name, making the parameter ordering unimportant. +The notion of named parameters was also introduced in the Bgl. You can read about it in \cgalCite{cgal:sll-bgl-02} or the following site: http://www.boost.org/libs/graph/doc/bgl_named_params.html. Named parameters allow the user to specify only those parameters which are really needed, by name, making the parameter ordering unimportant. Say there is a function `f()` that takes 3 parameters called `name`, `age` and `gender`, and you have variables `n,a and g` to pass as parameters to that function. Without named parameters, you would call it like this: `f(n,a,g)`, but with named parameters, you call it like this: `f(name(n).age(a).gender(g))`. diff --git a/Surface_mesher/doc/Surface_mesher/Surface_mesher.txt b/Surface_mesher/doc/Surface_mesher/Surface_mesher.txt index 57ff2a05cb4..f67e8fd9150 100644 --- a/Surface_mesher/doc/Surface_mesher/Surface_mesher.txt +++ b/Surface_mesher/doc/Surface_mesher/Surface_mesher.txt @@ -236,7 +236,7 @@ Surface mesh of an iso-contour extracted from a gray level 3D image \anchor SurfaceMesher_section_variations The guarantees on the output mesh depend on the mesh criteria. -Theoretical guarantees are given in \cite cgal:bo-pgsms-05. +Theoretical guarantees are given in \cgalCite{cgal:bo-pgsms-05}. First, the meshing algorithm is proved to terminate if the lower bound on facets angles is not bigger than `30` degrees. @@ -291,7 +291,7 @@ guarantees nothing else. \section Surface_mesherOutput Output -This \cgal component also provides functions to write the reconstructed surface mesh to the %Object File Format (OFF) \cite cgal:p-gmgv16-96 and to convert it to a polyhedron (when it is manifold): +This \cgal component also provides functions to write the reconstructed surface mesh to the %Object File Format (OFF) \cgalCite{cgal:p-gmgv16-96} and to convert it to a polyhedron (when it is manifold): - `output_surface_facets_to_off()` - `output_surface_facets_to_polyhedron()` @@ -312,11 +312,11 @@ medical images. \section Surface_mesherDesign Design and Implementation History The algorithm implemented in this package is mainly based on the work of -Jean-Daniel Boissonnat and Steve Oudot \cite cgal:bo-pgsms-05. Steve Oudot +Jean-Daniel Boissonnat and Steve Oudot \cgalCite{cgal:bo-pgsms-05}. Steve Oudot implemented a first working prototype of the algorithm during his PhD thesis. The meshing algorithm is implemented using the design of mesher levels -described in \cite cgal:ry-gsddrm-06. +described in \cgalCite{cgal:ry-gsddrm-06}. David Rey, Steve Oudot and Andreas Fabri have participated in the development of this package. diff --git a/Surface_reconstruction_points_3/doc/Surface_reconstruction_points_3/Surface_reconstruction_points_3.txt b/Surface_reconstruction_points_3/doc/Surface_reconstruction_points_3/Surface_reconstruction_points_3.txt index ce4b04059fa..7da4dfb7f5f 100644 --- a/Surface_reconstruction_points_3/doc/Surface_reconstruction_points_3/Surface_reconstruction_points_3.txt +++ b/Surface_reconstruction_points_3/doc/Surface_reconstruction_points_3/Surface_reconstruction_points_3.txt @@ -14,7 +14,7 @@ takes as input point sets with oriented normals and computes an implicit function. We assume that the input points contain no outliers and little noise. The output surface mesh is generated by extracting an isosurface of this function with the \cgal Surface Mesh Generator -\cite cgal:ry-gsddrm-06 or potentially with any other surface +\cgalCite{cgal:ry-gsddrm-06} or potentially with any other surface contouring algorithm. \cgalFigureBegin{Surface_reconstruction_points_3figintroduction,introduction.jpg} @@ -53,7 +53,7 @@ Common surface reconstruction pipeline. Given a set of 3D points with oriented normals (denoted oriented points in the sequel) sampled on the boundary of a 3D solid, the -Poisson Surface Reconstruction method \cite Kazhdan06 solves for an +Poisson Surface Reconstruction method \cgalCite{Kazhdan06} solves for an approximate indicator function of the inferred solid, whose gradient best matches the input normals. The output scalar function, represented in an adaptive octree, is then iso-contoured using an @@ -92,7 +92,7 @@ The following example reads a point set, creates a Poisson implicit function and The computed implicit functions can be iso-contoured to reconstruct a surface by using the \cgal surface mesh generator -\cite cgal:ry-gsddrm-06 \cite cgal:bo-pgsms-05 : +\cgalCite{cgal:ry-gsddrm-06} \cgalCite{cgal:bo-pgsms-05} : `make_surface_mesh()` @@ -111,7 +111,7 @@ a three dimensional triangulation. `SurfaceMeshComplex_2InTriangulation_3` defines the methods to traverse the reconstructed surface, and e.g. convert it to a triangle soup. Other \cgal components provide functions to write the reconstructed -surface mesh to the %Object File Format (OFF) \cite cgal:p-gmgv16-96 +surface mesh to the %Object File Format (OFF) \cgalCite{cgal:p-gmgv16-96} and to convert it to a polyhedron (when it is manifold): - `output_surface_facets_to_off()` - `output_surface_facets_to_polyhedron()` @@ -139,7 +139,7 @@ parameter tuning. Ideally the current implementation of the Poisson surface reconstruction method expects a dense 3D oriented point set (typically -matching the epsilon-sampling condition \cite cgal:bo-pgsms-05) and +matching the epsilon-sampling condition \cgalCite{cgal:bo-pgsms-05}) and sampled over a closed, smooth surface. Oriented herein means that all 3D points must come with consistently oriented normals to the inferred surface. \cgalFigureRef{Surface_reconstruction_points_3figbimba} and \cgalFigureRef{Surface_reconstruction_points_3figeros} diff --git a/Surface_reconstruction_points_3/include/CGAL/Poisson_reconstruction_function.h b/Surface_reconstruction_points_3/include/CGAL/Poisson_reconstruction_function.h index 0fd3fac8a47..8e9b3756336 100644 --- a/Surface_reconstruction_points_3/include/CGAL/Poisson_reconstruction_function.h +++ b/Surface_reconstruction_points_3/include/CGAL/Poisson_reconstruction_function.h @@ -151,7 +151,7 @@ struct Special_wrapper_of_two_functions_keep_pointers { \brief Implementation of the Poisson Surface Reconstruction method. Given a set of 3D points with oriented normals sampled on the boundary -of a 3D solid, the Poisson Surface Reconstruction method \cite Kazhdan06 +of a 3D solid, the Poisson Surface Reconstruction method \cgalCite{Kazhdan06} solves for an approximate indicator function of the inferred solid, whose gradient best matches the input normals. The output scalar function, represented in an adaptive octree, is then diff --git a/Triangulation_2/doc/Triangulation_2/CGAL/Delaunay_triangulation_2.h b/Triangulation_2/doc/Triangulation_2/CGAL/Delaunay_triangulation_2.h index 11a030eed4d..25636847d72 100644 --- a/Triangulation_2/doc/Triangulation_2/CGAL/Delaunay_triangulation_2.h +++ b/Triangulation_2/doc/Triangulation_2/CGAL/Delaunay_triangulation_2.h @@ -111,7 +111,7 @@ Delaunay_triangulation_2 dt ( InputIterator first, InputIterator las /// there are co-circular points, the Delaunay triangulation is known /// not to be uniquely defined. In this case, \cgal chooses a /// particular Delaunay triangulation using a symbolic perturbation -/// scheme \cite cgal:dt-pvr3d-03. Note that the other modifier +/// scheme \cgalCite{cgal:dt-pvr3d-03}. Note that the other modifier /// functions of `Triangulation_2` are not /// overwritten. Thus a call to \link Triangulation_2::insert_in_face()\endlink /// \link Triangulation_2::insert_in_face() `insert_in_face()`\endlink diff --git a/Triangulation_2/doc/Triangulation_2/CGAL/Triangulation_hierarchy_2.h b/Triangulation_2/doc/Triangulation_2/CGAL/Triangulation_hierarchy_2.h index 3031329ddb8..74deac2f6ee 100644 --- a/Triangulation_2/doc/Triangulation_2/CGAL/Triangulation_hierarchy_2.h +++ b/Triangulation_2/doc/Triangulation_2/CGAL/Triangulation_hierarchy_2.h @@ -27,7 +27,7 @@ Because the number of vertices in each triangulation is only a small fraction of the number of vertices of the preceding triangulation the data structure remains small and achieves fast point location queries on real -data. As proved in \cite d-iirdt-98, this structure has an optimal behavior +data. As proved in \cgalCite{d-iirdt-98}, this structure has an optimal behavior when it is built for Delaunay triangulations. However it can be used as well for other triangulations. diff --git a/Triangulation_2/doc/Triangulation_2/Triangulation_2.txt b/Triangulation_2/doc/Triangulation_2/Triangulation_2.txt index fa29df31d5a..123bc5030fc 100644 --- a/Triangulation_2/doc/Triangulation_2/Triangulation_2.txt +++ b/Triangulation_2/doc/Triangulation_2/Triangulation_2.txt @@ -182,7 +182,7 @@ as a layer on top of a planar map. representation of triangulations based on faces and vertices rather than on edges. Such a representation saves storage space and results in faster -algorithms \cite bdty-tcgal-00. +algorithms \cgalCite{bdty-tcgal-00}. The basic elements of the representation are vertices and faces. Each triangular face gives access to its three incident vertices @@ -566,7 +566,7 @@ The degree \f$ d\f$ is \f$ O(1)\f$ for a random vertex in the triangulation. When the degree of the removed vertex is small (\f$ \leq7\f$) a special procedure is used that allows to increase global removal time by a factor of 2 -for random points \cite d-vrtdd-09. +for random points \cgalCite{d-vrtdd-09}. The displacement of a vertex \f$ v\f$ at a point \f$ p\f$ to a new location \f$ p'\f$, first checks whether the triangulation embedding remains planar or not after moving \f$ v\f$ to \f$ p'\f$. If yes, it moves \f$ v\f$ to \f$ p'\f$ and simply performs a sequence of flips @@ -1065,7 +1065,7 @@ Because the number of vertices in each triangulation is only a small fraction of the number of vertices of the preceding triangulation, the data structure remains small and achieves fast point location queries on real -data. As proved in \cite d-iirdt-98, this structure has an optimal behavior +data. As proved in \cgalCite{d-iirdt-98}, this structure has an optimal behavior when it is built for Delaunay triangulations. However it can be used as well for other triangulations and the class `Triangulation_hierarchy_2