Merge remote-tracking branch 'cgal/master' into Aos_2-boundary_objects-efic

.github/workflows/delete_doc.yml

@@ -26,7 +26,7 @@ jobs:
            git rm -r ${PR_NUMBER} 
          fi
          #git diff exits with 1 if there is a diff
-         if !git diff --quiet; then
+         if ! git diff --quiet; then
            git commit -a --amend -m"base commit" && git push -f -u origin master
          fi
 

.travis.yml

@@ -1,79 +0,0 @@
-language: cpp
-dist: bionic
-sudo: required
-git:
-  depth: 3
-env:
-  matrix:
-    - PACKAGE='CHECK'
-    - PACKAGE='AABB_tree Advancing_front_surface_reconstruction Algebraic_foundations '
-    - PACKAGE='Algebraic_kernel_d Algebraic_kernel_for_circles Algebraic_kernel_for_spheres '
-    - PACKAGE='Alpha_shapes_2 Alpha_shapes_3 Apollonius_graph_2 '
-    - PACKAGE='Arithmetic_kernel Arrangement_on_surface_2 BGL '
-    - PACKAGE='Barycentric_coordinates_2 Boolean_set_operations_2 Bounding_volumes '
-    - PACKAGE='Box_intersection_d CGAL_Core CGAL_ImageIO '
-    - PACKAGE='CGAL_ipelets Cartesian_kernel Circular_kernel_2 '
-    - PACKAGE='Circular_kernel_3 Circulator Classification '
-    - PACKAGE='Combinatorial_map Cone_spanners_2 Convex_decomposition_3 '
-    - PACKAGE='Convex_hull_2 Convex_hull_3 Convex_hull_d '
-    - PACKAGE='Distance_2 Distance_3 Envelope_2 '
-    - PACKAGE='Envelope_3 Filtered_kernel Generalized_map '
-    - PACKAGE='Generator Geomview GraphicsView '
-    - PACKAGE='HalfedgeDS Hash_map Heat_method_3 '
-    - PACKAGE='Homogeneous_kernel Hyperbolic_triangulation_2 Inscribed_areas '
-    - PACKAGE='Installation Interpolation Intersections_2 '
-    - PACKAGE='Intersections_3 Interval_skip_list Interval_support '
-    - PACKAGE='Jet_fitting_3 Kernel_23 Kernel_d '
-    - PACKAGE='LEDA Linear_cell_complex MacOSX '
-    - PACKAGE='Maintenance Matrix_search Mesh_2 '
-    - PACKAGE='Mesh_3 Mesher_level Minkowski_sum_2 '
-    - PACKAGE='Minkowski_sum_3 Modifier Modular_arithmetic '
-    - PACKAGE='Nef_2 Nef_3 Nef_S2 '
-    - PACKAGE='NewKernel_d Number_types OpenNL '
-    - PACKAGE='Optimal_bounding_box Optimal_transportation_reconstruction_2 Optimisation_basic '
-    - PACKAGE='Partition_2 Periodic_2_triangulation_2 Periodic_3_mesh_3 '
-    - PACKAGE='Periodic_3_triangulation_3 Periodic_4_hyperbolic_triangulation_2 Point_set_2 '
-    - PACKAGE='Point_set_3 Point_set_processing_3 Poisson_surface_reconstruction_3 '
-    - PACKAGE='Polygon Polygon_mesh_processing Polygonal_surface_reconstruction '
-    - PACKAGE='Polyhedron Polyline_simplification_2 Polynomial '
-    - PACKAGE='Polytope_distance_d Principal_component_analysis Principal_component_analysis_LGPL '
-    - PACKAGE='Profiling_tools Property_map QP_solver '
-    - PACKAGE='Random_numbers Ridges_3 STL_Extension '
-    - PACKAGE='Scale_space_reconstruction_3 Scripts SearchStructures '
-    - PACKAGE='Segment_Delaunay_graph_2 Segment_Delaunay_graph_Linf_2 Set_movable_separability_2 '
-    - PACKAGE='Shape_detection Skin_surface_3 Snap_rounding_2 '
-    - PACKAGE='Solver_interface Spatial_searching Spatial_sorting '
-    - PACKAGE='Straight_skeleton_2 Stream_lines_2 Stream_support '
-    - PACKAGE='Subdivision_method_3 Surface_mesh Surface_mesh_approximation '
-    - PACKAGE='Surface_mesh_deformation Surface_mesh_parameterization Surface_mesh_segmentation '
-    - PACKAGE='Surface_mesh_shortest_path Surface_mesh_simplification Surface_mesh_skeletonization '
-    - PACKAGE='Surface_mesh_topology Surface_mesher Surface_sweep_2 '
-    - PACKAGE='TDS_2 TDS_3 Testsuite '
-    - PACKAGE='Tetrahedral_remeshing Three Triangulation '
-    - PACKAGE='Triangulation_2 Triangulation_3 Union_find '
-    - PACKAGE='Visibility_2 Voronoi_diagram_2 wininst '
-compiler: clang
-install:
-  - echo "$PWD"
-  - if [ -n "$TRAVIS_PULL_REQUEST_BRANCH" ] && [ "$PACKAGE" != CHECK ]; then  DO_IGNORE=FALSE;  for ARG in $(echo "$PACKAGE");do if [ "$ARG" = "Maintenance" ]; then continue; fi; . $PWD/.travis/test_package.sh "$PWD" "$ARG";  echo "DO_IGNORE is $DO_IGNORE";  if [ "$DO_IGNORE" = "FALSE" ]; then  break; fi; done; if [ "$DO_IGNORE" = "TRUE" ]; then travis_terminate 0; fi;fi
-  - /usr/bin/time -f 'Spend time of %C -- %E (real)' bash .travis/install.sh
-  - export CXX=clang++-10 CC=clang-10;
-before_script:
-  - wget -O doxygen_exe https://cgal.geometryfactory.com/~mgimeno/doxygen_exe
-  - sudo mv doxygen_exe /usr/bin/doxygen
-  - sudo chmod +x /usr/bin/doxygen
-  - mkdir -p build
-  - cd build
-  - /usr/bin/time -f 'Spend time of %C -- %E (real)' cmake -DCMAKE_CXX_FLAGS="-std=c++1y" -DCGAL_HEADER_ONLY=ON -DCMAKE_CXX_FLAGS_RELEASE=-DCGAL_NDEBUG -DWITH_examples=ON -DWITH_demos=ON -DWITH_tests=ON ..
-  - /usr/bin/time -f 'Spend time of %C -- %E (real)' make
-  - /usr/bin/time -f 'Spend time of %C -- %E (real)' sudo make install &>/dev/null
-  - cd ..
-script:
-  - cd ./.travis
-  - /usr/bin/time -f 'Spend time of %C -- %E (real)' bash ./build_package.sh $PACKAGE
-notifications:
-  email:
-    on_success: change
-    # default: always
-    on_failure: always
-    # default: always

.travis/build_package.sh

@@ -1,144 +0,0 @@
-#!/bin/bash
-set -e
-[ -n "$CGAL_DEBUG_TRAVIS" ] && set -x
-
-CXX_FLAGS="-DCGAL_NDEBUG -ftemplate-backtrace-limit=0"
-
-function mytime {
-  /usr/bin/time -f "Spend time of %C: %E (real)" "$@"
-}
-old_IFS=$IFS
-IFS=$' '
-ROOT="$PWD/.."
-for ARG in $(echo "$@")
-do
-#skip package maintenance
-  if [ "$ARG" = "Maintenance" ]; then
-    continue
-  fi
-cd $ROOT
-
-#install openmesh only if necessary
-  if [ "$ARG" = "CHECK" ] || [ "$ARG" = BGL ] || [ "$ARG" = Convex_hull_3 ] ||\
-     [ "$ARG" = Polygon_mesh_processing ] || [ "$ARG" = Property_map ] ||\
-     [ "$ARG" = Surface_mesh_deformation ] || [ "$ARG" = Surface_mesh_shortest_path ] ||\
-     [ "$ARG" = Surface_mesh_simplification ]; then
-    mytime sudo bash .travis/install_openmesh.sh
-  fi
-
-
-  if [ "$ARG" = "CHECK" ]
-  then
-    cd .travis
-    mytime ./generate_travis.sh --check
-    cd ..
-    IFS=$old_IFS
-    mytime zsh $ROOT/Scripts/developer_scripts/test_merge_of_branch HEAD
-    #test dependencies
-    cd $ROOT
-    mytime bash Scripts/developer_scripts/cgal_check_dependencies.sh --check_headers /usr/bin/doxygen
-
-    cd .travis
-    #parse current matrix and check that no package has been forgotten
-
-    IFS=$'\n'
-    COPY=0
-    MATRIX=()
-    for LINE in $(cat "$PWD/packages.txt")
-    do
-          MATRIX+="$LINE "
-    done
-
-    PACKAGES=()
-    cd ..
-    for f in *
-    do
-      if [ -d  "$f/package_info/$f" ]
-          then
-                  PACKAGES+="$f "
-          fi
-    done
-
-    DIFFERENCE=$(echo ${MATRIX[@]} ${PACKAGES[@]} | tr ' ' '\n' | sort | uniq -u)
-    IFS=$' '
-    if [ "${DIFFERENCE[0]}" != "" ]
-    then
-          echo "The matrix and the actual package list differ : ."
-          echo ${DIFFERENCE[*]}
-            echo "You should run generate_travis.sh."
-          exit 1
-    fi
-    echo "Matrix is up to date."
-     #check if non standard cgal installation works
-    cd $ROOT
-    mkdir build_test
-    cd build_test
-    mytime cmake -DCMAKE_INSTALL_PREFIX=install/ -DCGAL_BUILD_THREE_DOC=TRUE ..
-    mytime make install
-    # test install with minimal downstream example
-    mkdir installtest
-    cd installtest
-    touch main.cpp
-    mkdir build
-    echo 'project(Example)' >> CMakeLists.txt
-    echo 'set(PROJECT_SRCS ${PROJECT_SOURCE_DIR}/main.cpp)' >> CMakeLists.txt
-    echo 'find_package(CGAL REQUIRED)' >> CMakeLists.txt
-    echo 'add_executable(${PROJECT_NAME} ${PROJECT_SRCS})' >> CMakeLists.txt
-    echo 'target_link_libraries(${PROJECT_NAME} CGAL::CGAL)' >> CMakeLists.txt
-    echo '#include "CGAL/remove_outliers.h"' >> main.cpp
-    cd build
-    mytime cmake -DCMAKE_INSTALL_PREFIX=../../install -DCGAL_BUILD_THREE_DOC=TRUE ..
-    exit 0
-  fi
-
-  if [ "$ARG" = "Installation" ]
-  then
-  mkdir build_dir
-  cd build_dir
-  cmake -DWITH_tests=ON -DBUILD_TESTING=ON ..
-  ctest -j2 -L CGAL_cmake_testsuite --output-on-failure
-  cd ..
-  rm -rf ./build_dir
-  #==-- configure all CGAL with -DWITH_examples=ON -DWITH_demos=ON -DWITH_tests=ON, and then launch CTest on a few labels. --==
-  mkdir config_dir
-  cd config_dir
-  cmake -DWITH_examples=ON -DWITH_demos=ON -DWITH_tests=ON -DBUILD_TESTING=ON ..
-  ctest -j2 -L AABB_tree --output-on-failure
-  cd ..
-  rm -rf ./config_dir
-    exit 0
-  fi
-
-  IFS=$old_IFS
-
-  if [ -n "$TRAVIS_PULL_REQUEST_BRANCH" ]; then
-    DO_IGNORE=FALSE
-    . $ROOT/.travis/test_package.sh "$ROOT" "$ARG"
-    echo "DO_IGNORE is $DO_IGNORE"
-    if [ "$DO_IGNORE" = "TRUE" ]; then
-      continue
-    fi
-  fi
-  IFS=$' '
-  mkdir -p build-travis
-  cd build-travis
-  WITHDEMOS=ON
-  if [ "$ARG" = "Polyhedron" ]; then
-    WITHDEMOS=OFF
-  fi
-  EXTRA_CXX_FLAGS=
-  case "$CC" in
-    clang*)
-      EXTRA_CXX_FLAGS="-Werror=inconsistent-missing-override"
-      ;;
-  esac
-
-
-  mytime cmake -DCMAKE_CXX_FLAGS="${CXX_FLAGS} ${EXTRA_CXX_FLAGS}" -DCGAL_DONT_OVERRIDE_CMAKE_FLAGS:BOOL=ON -DBUILD_TESTING=ON -DWITH_tests=ON -DWITH_examples=ON -DWITH_demos=$WITHDEMOS ..
-  mytime ctest -j2 -L $ARG'([_][A-Z]|$)'  -E execution___of__ --output-on-failure
-done
-IFS=$old_IFS
-# Local Variables:
-# tab-width: 2
-# sh-basic-offset: 2
-# End:

.travis/generate_travis.sh

@@ -1,94 +0,0 @@
-#!/bin/bash
-
-CHECK=
-case $1 in
-  --check) CHECK=y;;
-esac
-
-set -e
-cd ../
-
-if [ -f "$PWD/.travis/packages.txt" ] 
-then
-	rm "$PWD/.travis/packages.txt"
-fi
-
-#find all the packages
-PACKAGES=()
-INDEX=0
-i=0
-for f in *
-do
-  if [ -d  "$f/package_info/$f" ]
-	then
-	echo "$f" >> ./tmp.txt
-	fi
-done
-        LC_ALL=C sort ./tmp.txt > ./.travis/packages.txt
-  	rm ./tmp.txt
-  	while read p; do
-  	PACKAGES[$INDEX]+="$p "
-		i=$[i+1]
-		if [ $i = 3 ]
-		then
-			i=0
- 			INDEX=$[INDEX+1]
-		fi
-done <./.travis/packages.txt
-if [ -f ".travis.yml" ] 
-then
-  #copy the current .travis.yml for later check
-  mv ./.travis.yml ./.travis.old
-fi
-#writes the first part of the file	
-old_IFS=$IFS       
-IFS=$'\n'
-for LINE in $(cat "$PWD/.travis/template.txt")
-do
-	if [ "$LINE" != "  matrix:" ]
-	then
-		echo "$LINE" >> .travis.yml
-  else
-  	break
-	fi
-done
-echo "  matrix:" >> .travis.yml
-#writes the matrix
-echo "    - PACKAGE='CHECK'" >> .travis.yml
-for package in ${PACKAGES[@]}
-do
-echo "    - PACKAGE='$package'" >> .travis.yml
-done
-
-#writes the end of the file
-COPY=0
-for LINE in $(cat "$PWD/.travis/template.txt")
-do
-	if [ "$LINE" = "compiler: clang" ]
-	then
-		COPY=1
-	fi
-	if [ $COPY = 1 ]
-	then
-		echo "$LINE" >> .travis.yml
-	fi
-done
-IFS=$' '
-#check if there are differences between the files
-if ! cmp -s ./.travis.yml ./.travis.old;
-then
-    echo ".travis.yml has changed : "
-    diff ./.travis.yml ./.travis.old
-    if [ -n "$CHECK" ]; then
-        echo "You should modify the file .travis/template.txt"
-        exit 1
-    fi
-fi
-#erase old travis
-rm ./.travis.old
-IFS=$old_IFS
-
-# Local Variables:
-# tab-width: 2
-# sh-basic-offset: 2
-# End:

.travis/install.sh

@@ -1,16 +0,0 @@
-#!/bin/bash
-
-[ -n "$CGAL_DEBUG_TRAVIS" ] && set -x
-DONE=0
-sudo add-apt-repository ppa:mikhailnov/pulseeffects -y
-sudo apt-get update
-
-while [ $DONE = 0 ]
-do
-  DONE=1 && sudo -E apt-get -yq --no-install-suggests --no-install-recommends --force-yes install clang-10 zsh \
-flex bison cmake graphviz libgmp-dev libmpfr-dev libmpfi-dev zlib1g-dev libeigen3-dev  \
-qtbase5-dev libqt5sql5-sqlite libqt5opengl5-dev qtscript5-dev libqt5svg5-dev qttools5-dev qttools5-dev-tools qml-module-qtgraphicaleffects libopencv-dev mesa-common-dev libmetis-dev libglu1-mesa-dev \
-libboost1.72-dev || DONE=0 && sudo apt-get update
-done
-exit 0
-

.travis/install_openmesh.sh

@@ -1,16 +0,0 @@
-#!/bin/bash
-mkdir -p openmesh
-cd openmesh
-wget -O openmesh.tar.gz https://www.openmesh.org/media/Releases/6.3/OpenMesh-6.3.tar.gz
-tar xf openmesh.tar.gz --strip-components=1
-sed -i '94i #include <sys/time.h>' src/OpenMesh/Tools/Utils/conio.cc
-
-mkdir build
-cd build
-cmake -DBUILD_APPS=FALSE ..
-make -j2
-sudo make -j2 install &>/dev/null
-
-#clean up
-cd ../..
-rm -rf ./openmesh

.travis/packages.txt

@@ -1,138 +0,0 @@
-AABB_tree
-Advancing_front_surface_reconstruction
-Algebraic_foundations
-Algebraic_kernel_d
-Algebraic_kernel_for_circles
-Algebraic_kernel_for_spheres
-Alpha_shapes_2
-Alpha_shapes_3
-Apollonius_graph_2
-Arithmetic_kernel
-Arrangement_on_surface_2
-BGL
-Barycentric_coordinates_2
-Boolean_set_operations_2
-Bounding_volumes
-Box_intersection_d
-CGAL_Core
-CGAL_ImageIO
-CGAL_ipelets
-Cartesian_kernel
-Circular_kernel_2
-Circular_kernel_3
-Circulator
-Classification
-Combinatorial_map
-Cone_spanners_2
-Convex_decomposition_3
-Convex_hull_2
-Convex_hull_3
-Convex_hull_d
-Distance_2
-Distance_3
-Envelope_2
-Envelope_3
-Filtered_kernel
-Generalized_map
-Generator
-Geomview
-GraphicsView
-HalfedgeDS
-Hash_map
-Heat_method_3
-Homogeneous_kernel
-Hyperbolic_triangulation_2
-Inscribed_areas
-Installation
-Interpolation
-Intersections_2
-Intersections_3
-Interval_skip_list
-Interval_support
-Jet_fitting_3
-Kernel_23
-Kernel_d
-LEDA
-Linear_cell_complex
-MacOSX
-Maintenance
-Matrix_search
-Mesh_2
-Mesh_3
-Mesher_level
-Minkowski_sum_2
-Minkowski_sum_3
-Modifier
-Modular_arithmetic
-Nef_2
-Nef_3
-Nef_S2
-NewKernel_d
-Number_types
-OpenNL
-Optimal_bounding_box
-Optimal_transportation_reconstruction_2
-Optimisation_basic
-Partition_2
-Periodic_2_triangulation_2
-Periodic_3_mesh_3
-Periodic_3_triangulation_3
-Periodic_4_hyperbolic_triangulation_2
-Point_set_2
-Point_set_3
-Point_set_processing_3
-Poisson_surface_reconstruction_3
-Polygon
-Polygon_mesh_processing
-Polygonal_surface_reconstruction
-Polyhedron
-Polyline_simplification_2
-Polynomial
-Polytope_distance_d
-Principal_component_analysis
-Principal_component_analysis_LGPL
-Profiling_tools
-Property_map
-QP_solver
-Random_numbers
-Ridges_3
-STL_Extension
-Scale_space_reconstruction_3
-Scripts
-SearchStructures
-Segment_Delaunay_graph_2
-Segment_Delaunay_graph_Linf_2
-Set_movable_separability_2
-Shape_detection
-Skin_surface_3
-Snap_rounding_2
-Solver_interface
-Spatial_searching
-Spatial_sorting
-Straight_skeleton_2
-Stream_lines_2
-Stream_support
-Subdivision_method_3
-Surface_mesh
-Surface_mesh_approximation
-Surface_mesh_deformation
-Surface_mesh_parameterization
-Surface_mesh_segmentation
-Surface_mesh_shortest_path
-Surface_mesh_simplification
-Surface_mesh_skeletonization
-Surface_mesh_topology
-Surface_mesher
-Surface_sweep_2
-TDS_2
-TDS_3
-Testsuite
-Tetrahedral_remeshing
-Three
-Triangulation
-Triangulation_2
-Triangulation_3
-Union_find
-Visibility_2
-Voronoi_diagram_2
-wininst

.travis/template.txt

@@ -1,34 +0,0 @@
-language: cpp
-dist: bionic
-sudo: required
-git:
-  depth: 3
-env:
-  matrix:
-  PACKAGES_MATRIX
-
-compiler: clang
-install:
-  - echo "$PWD"
-  - if [ -n "$TRAVIS_PULL_REQUEST_BRANCH" ] && [ "$PACKAGE" != CHECK ]; then  DO_IGNORE=FALSE;  for ARG in $(echo "$PACKAGE");do if [ "$ARG" = "Maintenance" ]; then continue; fi; . $PWD/.travis/test_package.sh "$PWD" "$ARG";  echo "DO_IGNORE is $DO_IGNORE";  if [ "$DO_IGNORE" = "FALSE" ]; then  break; fi; done; if [ "$DO_IGNORE" = "TRUE" ]; then travis_terminate 0; fi;fi
-  - /usr/bin/time -f 'Spend time of %C -- %E (real)' bash .travis/install.sh
-  - export CXX=clang++-10 CC=clang-10;
-before_script:
-  - wget -O doxygen_exe https://cgal.geometryfactory.com/~mgimeno/doxygen_exe
-  - sudo mv doxygen_exe /usr/bin/doxygen
-  - sudo chmod +x /usr/bin/doxygen
-  - mkdir -p build
-  - cd build
-  - /usr/bin/time -f 'Spend time of %C -- %E (real)' cmake -DCMAKE_CXX_FLAGS="-std=c++1y" -DCGAL_HEADER_ONLY=ON -DCMAKE_CXX_FLAGS_RELEASE=-DCGAL_NDEBUG -DWITH_examples=ON -DWITH_demos=ON -DWITH_tests=ON ..
-  - /usr/bin/time -f 'Spend time of %C -- %E (real)' make
-  - /usr/bin/time -f 'Spend time of %C -- %E (real)' sudo make install &>/dev/null
-  - cd ..
-script:
-  - cd ./.travis
-  - /usr/bin/time -f 'Spend time of %C -- %E (real)' bash ./build_package.sh $PACKAGE
-notifications:
-  email:
-    on_success: change
-    # default: always
-    on_failure: always
-    # default: always

.travis/test_package.sh

@@ -1,30 +0,0 @@
-#!/bin/bash
-
-#Will cd $1 and test package named $2
-#to find out if it or one of its dependencies has changed in the current branch
-
-DO_IGNORE=FALSE
-cd $1
-
-if [ ! -d "$2" ]; then
-  echo "$2 : MISSING PACKAGE. Ignoring."
-  DO_IGNORE=TRUE
-  exit 1
-fi
-  
-  
-if [ ! -f "$2/package_info/$2/dependencies" ];then
-  echo "No dependencies found for $2"
-  bash Scripts/developer_scripts/cgal_check_dependencies.sh --check_headers /usr/bin/doxygen	
-  exit 1
-fi
-LIST_OF_FILES=$(git diff --name-only origin/master... |cut -d/ -f1 |uniq |sort)
-LIST_OF_DEPS=$(cat "$2/package_info/$2/dependencies")
-echo "$LIST_OF_DEPS"
-for flie in $LIST_OF_DEPS
-do
-  [[ $LIST_OF_FILES =~ (^|[[:space:]])$flie($|[[:space:]]) ]] && return
-done
-echo "Package ignored because none of its dependencies has been modified."
-DO_IGNORE=TRUE
-

.travis/windows.h

@@ -1,12 +0,0 @@
-#define MAX(a,b)            (((a) > (b)) ? (a) : (b))
-#define max(a,b)            (((a) > (b)) ? (a) : (b))
-
-#define MIN(a,b)            (((a) < (b)) ? (a) : (b))
-#define min(a,b)            (((a) < (b)) ? (a) : (b))
-
-
-#define FAR #error named reserved in windows.h
-#define far #error named reserved in windows.h
-
-#define Polyline #error named reserved in windows.h
-#define Polygon #error named reserved in windows.h

AABB_tree/include/CGAL/AABB_traits.h

@@ -428,6 +428,11 @@ public:
   Closest_point closest_point_object() const {return Closest_point(*this);}
   Compare_distance compare_distance_object() const {return Compare_distance();}
 
+  typedef enum { CGAL_AXIS_X = 0,
+                 CGAL_AXIS_Y = 1,
+                 CGAL_AXIS_Z = 2} Axis;
+
+  static Axis longest_axis(const Bounding_box& bbox);
 
 private:
   /**
@@ -446,13 +451,6 @@ private:
     return internal::Primitive_helper<AT>::get_datum(pr,*this).bbox();
   }
 
-
-  typedef enum { CGAL_AXIS_X = 0,
-                 CGAL_AXIS_Y = 1,
-                 CGAL_AXIS_Z = 2} Axis;
-
-  static Axis longest_axis(const Bounding_box& bbox);
-
   /// Comparison functions
   static bool less_x(const Primitive& pr1, const Primitive& pr2,const AABB_traits<GeomTraits,AABBPrimitive, BboxMap>& traits)
   {

AABB_tree/include/CGAL/AABB_tree.h

@@ -126,7 +126,7 @@ namespace CGAL {
     Self& operator=(const Self&) = delete;
 
     /**
-     * @brief Builds the datastructure from a sequence of primitives.
+     * @brief Builds the data structure from a sequence of primitives.
      * @param first iterator over first primitive to insert
      * @param beyond past-the-end iterator
      *

Advancing_front_surface_reconstruction/doc/Advancing_front_surface_reconstruction/Concepts/AdvancingFrontSurfaceReconstructionTraits_3.h

@@ -0,0 +1,159 @@
+
+/*!
+\ingroup PkgAdvancingFrontSurfaceReconstructionRef
+\cgalConcept
+
+The concept `AdvancingFrontSurfaceReconstructionTraits_3` describes the requirements
+for the the geometric traits of the class `CGAL::Delaunay_triangulation_3`
+used in the class `CGAL::Advancing_front_surface_reconstruction`.
+It defines the geometric objects (points, segments...) forming the triangulation
+together with a few geometric predicates and constructions on these objects.
+
+\cgalRefines `DelaunayTriangulationTraits_3`
+
+\cgalHasModel All models of `Kernel`.
+*/
+class AdvancingFrontSurfaceReconstructionTraits_3
+{
+public:
+
+/// \name Types
+/// @{
+
+/*!
+The coordinate type.
+*/
+typedef unspecified_type FT;
+
+/*!
+The vector type.
+*/
+typedef unspecified_type Vector_3;
+
+/*!
+The sphere type.
+*/
+typedef unspecified_type Sphere_3;
+
+/*!
+A constructor object that must provide the function operator
+
+`Vector_3 operator()(Point_3 p, Point_3 q)`,
+
+which constructs the vector `q-p`.
+*/
+typedef unspecified_type Construct_vector_3;
+
+/*!
+A constructor object that must provide the function operator
+
+`Vector_3 operator()(Vector_3 v, Vector_3 w)`,
+
+which returns the cross product of `v` and `w`.
+*/
+typedef unspecified_type Construct_cross_product_vector_3;
+
+/*!
+A constructor object that must provide the function operator
+
+`FT operator()(Vector_3 v, Vector_3 w)`,
+
+which returns the scalar (inner) product of `v` and `w`.
+*/
+typedef unspecified_type Compute_scalar_product_3;
+
+/*!
+A constructor object that must provide the function operator
+
+`Sphere_3 operator()(Point_3 p, Point_3 q, Point_3 r)`,
+
+which constructs a sphere initialized to the smallest sphere which passes
+through the points `p`, `q`, and `r`.
+*/
+typedef unspecified_type Construct_sphere_3;
+
+/*!
+A constructor object that must provide the function operator
+
+`Point_3 operator()(Sphere_3 s)`,
+
+which returns the center of the sphere `s`.
+*/
+typedef unspecified_type Construct_center_3;
+
+/*!
+A constructor object that must provide the function operators
+
+`FT operator()(Point_3 p, Point_3 q, Point_3 r, Point_3 s)`,
+
+which returns the squared radius of the sphere passing through `p`, `q` and `r`,
+and whose center is in the plane defined by these three points.
+
+and
+
+`FT operator()(Point_3 p, Point_3 q, Point_3 r, Point_3 s)`,
+
+which returns the squared radius of the sphere passing through `p`, `q`, `r`, and `s`.
+
+and
+
+`FT operator()(Sphere_3 s)`,
+
+which returns the squared radius of the sphere `s`.
+*/
+typedef unspecified_type Compute_squared_radius_3;
+
+/*!
+A constructor object that must provide the function operator
+
+`FT operator()(Point_3 p, Point_3 q)`,
+
+which returns the squared distance between the points `p` and `q`.
+*/
+typedef unspecified_type Compute_squared_distance_3;
+
+/// @}
+
+/// \name Operations
+/// The following functions give access to the predicate and construction objects:
+/// @{
+
+/*!
+gives access to the `Construct_vector_3` construction.
+*/
+Construct_vector_3 construct_vector_3_object();
+
+/*!
+gives access to the `Construct_cross_product_vector_3` construction.
+*/
+Construct_cross_product_vector_3 construct_cross_product_vector_3_object();
+
+/*!
+gives access to the `Compute_scalar_product_3` construction.
+*/
+Compute_scalar_product_3 compute_scalar_product_3_object();
+
+/*!
+gives access to the `Construct_sphere_3` construction.
+*/
+Construct_sphere_3 construct_sphere_3_object();
+
+/*!
+gives access to the `Construct_center_3` construction.
+*/
+Construct_center_3 construct_center_3_object();
+
+/*!
+gives access to the `Compute_squared_radius_3` construction.
+*/
+Compute_squared_radius_3 compute_squared_radius_3_object();
+
+/*!
+gives access to the `Compute_squared_distance_3` construction.
+*/
+Compute_squared_distance_3 compute_squared_distance_3_object();
+
+/// @}
+
+}; /* end AdvancingFrontSurfaceReconstructionTraits_3 */
+

Advancing_front_surface_reconstruction/doc/Advancing_front_surface_reconstruction/PackageDescription.txt

@@ -1,5 +1,8 @@
 /// \defgroup PkgAdvancingFrontSurfaceReconstructionRef Advancing Front Surface Reconstruction Reference
 
+/// \defgroup PkgAdvancingFrontSurfaceReconstructionRefConcepts Concepts
+/// \ingroup PkgAdvancingFrontSurfaceReconstructionRef
+
 /*!
 \addtogroup PkgAdvancingFrontSurfaceReconstructionRef
 
@@ -25,6 +28,10 @@ of topological singularities. }
 
 \cgalClassifedRefPages
 
+\cgalCRPSection{Concepts}
+
+- `AdvancingFrontSurfaceReconstructionTraits_3`
+
 \cgalCRPSection{Classes}
 
 - `CGAL::Advancing_front_surface_reconstruction`

Advancing_front_surface_reconstruction/doc/Advancing_front_surface_reconstruction/dependencies

@@ -5,6 +5,7 @@ Algebraic_foundations
 Circulator
 Stream_support
 TDS_2
+TDS_3
 Triangulation_2
 Triangulation_3
 Number_types

Advancing_front_surface_reconstruction/include/CGAL/Advancing_front_surface_reconstruction.h

@@ -175,23 +175,42 @@ namespace CGAL {
   store handles to the vertices and faces of the 3D triangulation, which enables the user to explore the
   2D as well as 3D neighborhood of vertices and facets of the surface.
 
-  \tparam Dt must be a `Delaunay_triangulation_3` with
+  \tparam Dt must be a `Delaunay_triangulation_3` whose `Traits` template parameter must be a model of
-  `Advancing_front_surface_reconstruction_vertex_base_3` and `Advancing_front_surface_reconstruction_cell_base_3` blended into the vertex and cell type.
+  `AdvancingFrontSurfaceReconstructionTraits_3` and whose `Tds` template parameter must be
-  The default uses the `Exact_predicates_inexact_constructions_kernel` as geometric traits class.
+  a model of `TriangulationDataStructure_3` with `Advancing_front_surface_reconstruction_vertex_base_3` and
+  `Advancing_front_surface_reconstruction_cell_base_3` blended into the vertex and cell type, respectively.
+  The default value is:
+  \code
+    CGAL::Delaunay_triangulation_3<CGAL::Exact_predicates_inexact_constructions_kernel,
+                                   CGAL::Triangulation_data_structure_3<
+                                     CGAL::Advancing_front_surface_reconstruction_vertex_base_3<
+                                       CGAL::Exact_predicates_inexact_constructions_kernel>,
+                                     CGAL::Advancing_front_surface_reconstruction_cell_base_3<
+                                       CGAL::Exact_predicates_inexact_constructions_kernel> > >`
+  \endcode
 
-  \tparam P must be a functor with `double operator()(AdvancingFront,Cell_handle,int)` returning the
+  \tparam P must be a functor offering
-  priority of the facet `(Cell_handle,int)`. This functor enables the user to choose how candidate
+  \code
-  triangles are prioritized. If a facet should not appear in the output,
+    FT operator()(Advancing_front_surface_reconstruction,Cell_handle,int)
+  \endcode
+  returning the priority of the facet `(Cell_handle,int)`. This functor enables the user
+  to choose how candidate triangles are prioritized. If a facet should not appear in the output,
   `infinity()` must be returned. It defaults to a functor that returns the
   `smallest_radius_delaunay_sphere()`.
 
   */
-  template <
+  template <class Dt = Default,
-    class Dt = Default,
             class P = Default>
-  class Advancing_front_surface_reconstruction {
+  class Advancing_front_surface_reconstruction
-
+  {
-    typedef typename Default::Get<Dt,Delaunay_triangulation_3<Exact_predicates_inexact_constructions_kernel, Triangulation_data_structure_3<Advancing_front_surface_reconstruction_vertex_base_3<Exact_predicates_inexact_constructions_kernel>, Advancing_front_surface_reconstruction_cell_base_3<Exact_predicates_inexact_constructions_kernel> > > >::type Triangulation;
+    typedef typename Default::Get<Dt,
+                                  Delaunay_triangulation_3<
+                                    Exact_predicates_inexact_constructions_kernel,
+                                    Triangulation_data_structure_3<
+                                      Advancing_front_surface_reconstruction_vertex_base_3<
+                                        Exact_predicates_inexact_constructions_kernel>,
+                                      Advancing_front_surface_reconstruction_cell_base_3<
+                                        Exact_predicates_inexact_constructions_kernel> > > >::type Triangulation;
     typedef typename Default::Get<P,AFSR::Default_priority>::type Priority;
   public:
 
@@ -202,9 +221,9 @@ namespace CGAL {
   /*!
     The type of the 2D triangulation data structure describing the reconstructed surface, being a model of `TriangulationDataStructure_2`.
     - The type `Triangulation_data_structure_2::Vertex` is model of the concept `TriangulationDataStructure_2::Vertex` and has additionally the
-    method `vertex_3()` that returns a `#Vertex_handle` to the associated 3D vertex.
+    method `vertex_3()` that returns a `Vertex_handle` to the associated 3D vertex.
     - The type `Triangulation_data_structure_2::Face` is model of the concept `TriangulationDataStructure_2::Face` and  has additionally the
-    method `facet()` that returns the associated `#Facet`, and a method `bool is_on_surface()`
+    method `facet()` that returns the associated `Facet`, and a method `bool is_on_surface()`
     for testing if a face is part of the reconstructed surface or a face incident to a boundary edge.
 
     In case the surface has boundaries, the 2D surface has one vertex which is associated to the infinite
@@ -213,15 +232,20 @@ namespace CGAL {
     typedef unspecified_type Triangulation_data_structure_2;
 
   /*!
-  The type of the 3D triangulation.
+  The type of the 3D Delaunay triangulation (the first template parameter).
   */
     typedef unspecified_type Triangulation_3;
 
   /*!
-  The type of the facet priority functor.
+  The type of the facet priority functor (the second template parameter).
   */
     typedef unspecified_type Priority;
 
+  /*!
+  The number type.
+  */
+    typedef typename Triangulation_3::Geom_traits::FT FT;
+
   /*!
   The point type.
   */
@@ -245,21 +269,21 @@ namespace CGAL {
   /*!
     A bidirectional iterator range which enables to enumerate all points that were removed
     from the 3D Delaunay triangulation during the surface reconstruction. The value type
-    of the iterator is `#Point`.
+    of the iterator is `Point`.
   */
     typedef unspecified_type Outlier_range;
 
+  /*!
+     A bidirectional iterator range which enables to visit all vertices on a boundary.
+     The value type of the iterator is `Vertex_handle`.
+   */
+     typedef unspecified_type Vertex_on_boundary_range;
+
   /*!
     A bidirectional iterator range which enables to visit all boundaries.
     The value type of the iterator is `Vertex_on_boundary_range`.
   */
     typedef unspecified_type Boundary_range;
-
- /*!
-    A bidirectional iterator range which enables to visit all vertices on a boundary.
-    The value type of the iterator is  `#Vertex_handle`
-  */
-    typedef unspecified_type Vertex_on_boundary_range;
   /// @}
 #endif
 
@@ -268,6 +292,7 @@ namespace CGAL {
     typedef Advancing_front_surface_reconstruction<Dt,P> Extract;
     typedef typename Triangulation_3::Geom_traits Geom_traits;
 
+    typedef typename Kernel::FT FT;
     typedef typename Kernel::FT coord_type;
 
     typedef typename Kernel::Point_3  Point;
@@ -377,7 +402,23 @@ namespace CGAL {
     std::list<Next_border_elt> nbe_pool;
     std::list<Intern_successors_type> ist_pool;
 
+  public:
+    Vector construct_vector(const Point& p, const Point& q) const
+    {
+      return T.geom_traits().construct_vector_3_object()(p, q);
+    }
 
+    Vector construct_cross_product(const Vector& v, const Vector& w) const
+    {
+      return T.geom_traits().construct_cross_product_vector_3_object()(v, w);
+    }
+
+    FT compute_scalar_product(const Vector& v, const Vector& w) const
+    {
+      return T.geom_traits().compute_scalar_product_3_object()(v, w);
+    }
+
+  private:
     Intern_successors_type* new_border()
     {
       nbe_pool.resize(nbe_pool.size()+1);
@@ -679,12 +720,14 @@ namespace CGAL {
           ++it;
         }while(collinear(p,q,it->point()));
         const Point& r = it->point();
-        Vector u = q-r;
+        Vector u = construct_vector(r, q);
-        Vector v = q-p;
+        Vector v = construct_vector(p, q);
-        Vector w = r-p;
+        Vector w = construct_vector(p, r);
-        Vector vw = cross_product(v,w);
+        Vector vw = construct_cross_product(v,w);
-        double len = (std::max)(u*u,(std::max)(v*v,w*w));
+        double len = (std::max)(compute_scalar_product(u,u),
-        Point s = p + 10* len * (vw/(vw*vw));
+                                (std::max)(compute_scalar_product(v,v),
+                                           compute_scalar_product(w,w)));
+        Point s = p + 10 * len * (vw/compute_scalar_product(vw,vw));
         added_vertex = T.insert(s);
       }
     }
@@ -736,9 +779,9 @@ namespace CGAL {
 
     \param radius_ratio_bound candidates incident to surface triangles which are not in the beta-wedge
            are discarded, if the ratio of their radius and the radius of the surface triangle is larger than `radius_ratio_bound`.
-           Described in Section \ref AFSR_Boundaries
+           Described in Section \ref AFSR_Boundaries.
     \param beta half the angle of the wedge in which only the radius of triangles counts for the plausibility of candidates.
-           Described in Section \ref AFSR_Selection
+           Described in Section \ref AFSR_Selection.
 
     */
     void run(double radius_ratio_bound=5, double beta= 0.52)
@@ -1186,7 +1229,7 @@ namespace CGAL {
     \param index index of the facet in `c`
 
     */
-    coord_type
+    FT
     smallest_radius_delaunay_sphere(const Cell_handle& c,
                                     const int& index) const
     {
@@ -1249,16 +1292,16 @@ namespace CGAL {
               const Point& pp2 = cc->vertex(i2)->point();
               const Point& pp3 = cc->vertex(i3)->point();
 
-              Sphere facet_sphere(pp1, pp2, pp3);
+              Sphere facet_sphere = T.geom_traits().construct_sphere_3_object()(pp1, pp2, pp3);
-              if (squared_distance(facet_sphere.center(), pp0) <
+              if (squared_distance(T.geom_traits().construct_center_3_object()(facet_sphere), pp0) <
-                  facet_sphere.squared_radius())
+                  T.geom_traits().compute_squared_radius_3_object()(facet_sphere))
                 {
 #ifdef AFSR_LAZY
                   value = lazy_squared_radius(cc);
 #else
                   // qualified with CGAL, to avoid a compilation error with clang
                   if(volume(pp0, pp1, pp2, pp3) != 0){
-                    value = CGAL::squared_radius(pp0, pp1, pp2, pp3);
+                    value = T.geom_traits().compute_squared_radius_3_object()(pp0, pp1, pp2, pp3);
                   } else {
                     typedef Exact_predicates_exact_constructions_kernel EK;
                     Cartesian_converter<Kernel, EK> to_exact;
@@ -1280,26 +1323,30 @@ namespace CGAL {
               cc = lazy_circumcenter(c);
               cn = lazy_circumcenter(n);
 #else
-              cc = CGAL::circumcenter(cp0, cp1, cp2, cp3);
+              cc = T.geom_traits().construct_circumcenter_3_object()(cp0, cp1, cp2, cp3);
-              cn = CGAL::circumcenter(np0, np1, np2, np3);
+              cn = T.geom_traits().construct_circumcenter_3_object()(np0, np1, np2, np3);
 #endif
               // computation of the distance of  cp1  to the  dual segment cc, cn...
-              Vector V(cc - cn), Vc(cc - cp1), Vn(cp1 - cn);
+              Vector V = construct_vector(cn, cc),
-              coord_type ac(V * Vc), an(V * Vn), norm_V(V * V);
+                     Vc = construct_vector(cp1, cc),
+                     Vn = construct_vector(cn, cp1);
+              coord_type ac = compute_scalar_product(V, Vc),
+                         an = compute_scalar_product(V, Vn),
+                         norm_V = compute_scalar_product(V, V);
               if ((ac > 0) && (an > 0))
                 {
-                  value = (Vc*Vc) - ac*ac/norm_V;
+                  value = compute_scalar_product(Vc, Vc) - ac*ac/norm_V;
                   if ((value < 0)||(norm_V > inv_eps_2)){
                     // qualified with CGAL, to avoid a compilation error with clang
-                    value = CGAL::squared_radius(cp1, cp2, cp3);
+                    value = T.geom_traits().compute_squared_radius_3_object()(cp1, cp2, cp3);
                   }
                 }
               else
                 {
                   if (ac <= 0)
-                    value = squared_distance(cc, cp1);
+                    value = T.geom_traits().compute_squared_distance_3_object()(cc, cp1);
                   else // (an <= 0)
-                    value = squared_distance(cn, cp1);
+                    value = T.geom_traits().compute_squared_distance_3_object()(cn, cp1);
                 }
             }
         }
@@ -1314,7 +1361,7 @@ namespace CGAL {
 
       returns the infinite floating value that prevents a facet to be used.
     */
-    coord_type infinity() const { return std::numeric_limits<coord_type>::infinity(); }
+    FT infinity() const { return std::numeric_limits<FT>::infinity(); }
     /// @}
 
     //---------------------------------------------------------------------
@@ -1341,9 +1388,9 @@ namespace CGAL {
       const Point& p2 = c->vertex(i2)->point();
       const Point& pc = c->vertex(i3)->point();
 
-      Vector P2P1 = p1-p2, P2Pn, PnP1;
+      Vector P2P1 = construct_vector(p2, p1), P2Pn, PnP1;
 
-      Vector v2, v1 = cross_product(pc-p2, P2P1);
+      Vector v2, v1 = construct_cross_product(construct_vector(p2, pc), P2P1);
 
       coord_type norm, norm1 = v1*v1;
       coord_type norm12 = P2P1*P2P1;
@@ -1375,12 +1422,12 @@ namespace CGAL {
                 {
                   const Point& pn = neigh->vertex(n_i3)->point();
 
-                  P2Pn = pn-p2;
+                  P2Pn = construct_vector(p2, pn);
-                  v2 = cross_product(P2P1,P2Pn);
+                  v2 = construct_cross_product(P2P1,P2Pn);
 
                   //pas necessaire de normer pour un bon echantillon:
                   //            on peut alors tester v1*v2 >= 0
-                  norm =  sqrt(norm1 * (v2*v2));
+                  norm =  sqrt(norm1 * compute_scalar_product(v2,v2));
                   pscal = v1*v2;
                   // check if the triangle will produce a sliver on the surface
                   bool sliver_facet = (pscal <= COS_ALPHA_SLIVER*norm);
@@ -1394,10 +1441,9 @@ namespace CGAL {
                           // We skip triangles having an internal angle along e
                           // whose cosinus is smaller than -DELTA
                           // that is the angle is larger than arcos(-DELTA)
-                          border_facet = !((P2P1*P2Pn >=
+                          border_facet =
-                                            -DELTA*sqrt(norm12*(P2Pn*P2Pn)))&&
+                            !((P2P1*P2Pn >= -DELTA*sqrt(norm12*compute_scalar_product(P2Pn,P2Pn))) &&
-                                           (P2P1*PnP1 >=
+                              (P2P1*PnP1 >= -DELTA*sqrt(norm12*compute_scalar_product(PnP1,PnP1))));
-                                            -DELTA*sqrt(norm12*(PnP1*PnP1))));
                           // \todo investigate why we simply do not skip this triangle
                           // but continue looking for a better candidate
                           // if (!border_facet){
@@ -1569,9 +1615,11 @@ namespace CGAL {
       int n_i3 = (6 - n_ind - n_i1 - n_i2);
 
       const Point& pn = neigh->vertex(n_i3)->point();
-      Vector v1 = cross_product(pc-p2,p1-p2),
+      Vector v1 = construct_cross_product(construct_vector(p2, pc),
-        v2 = cross_product(p1-p2,pn-p2);
+                                          construct_vector(p2, p1)),
-      coord_type norm = sqrt((v1*v1)*(v2*v2));
+             v2 = construct_cross_product(construct_vector(p2, p1),
+                                          construct_vector(p2, pn));
+      coord_type norm = sqrt(compute_scalar_product(v1, v1) * compute_scalar_product(v2, v2));
 
       if (v1*v2 > COS_BETA*norm)
         return 1; // label bonne pliure sinon:
@@ -2487,9 +2535,9 @@ namespace CGAL {
   \param out output iterator
   \param radius_ratio_bound candidates incident to surface triangles which are not in the beta-wedge
          are discarded, if the ratio of their radius and the radius of the surface triangle is larger than `radius_ratio_bound`.
-         Described in Section \ref AFSR_Boundaries
+         Described in Section \ref AFSR_Boundaries.
   \param beta half the angle of the wedge in which only the radius of triangles counts for the plausibility of candidates.
-         Described in Section \ref AFSR_Selection
+         Described in Section \ref AFSR_Selection.
 
   */
   template <typename PointInputIterator, typename IndicesOutputIterator>
@@ -2533,7 +2581,7 @@ namespace CGAL {
   be convertible to `Exact_predicates_inexact_constructions_kernel::Point_3` with the `Cartesian_converter`.
   \tparam IndicesOutputIterator must be an output iterator to which
   `std::array<std::size_t, 3>` can be assigned.
-  \tparam Priority must be a functor with `double operator()(AdvancingFront,Cell_handle,int)` returning the
+  \tparam Priority must be a functor with `double operator()(Advancing_front_surface_reconstruction,Cell_handle,int)` returning the
   priority of the facet `(Cell_handle,int)`.
 
   \param b iterator on the first point of the sequence

Algebraic_foundations/doc/Algebraic_foundations/CGAL/number_utils.h

@@ -22,7 +22,7 @@ namespace CGAL {
 \ingroup PkgAlgebraicFoundationsRef
 
 The template function `compare()` compares the first argument with respect to
-the second, i.e.\ it returns `CGAL::LARGER` if \f$ x\f$ is larger then \f$ y\f$.
+the second, i.e.\ it returns `CGAL::LARGER` if \f$ x\f$ is larger than \f$ y\f$.
 
 In case the argument types `NT1` and `NT2` differ,
 `compare` is performed with the semantic of the type determined via

Algebraic_kernel_d/examples/Algebraic_kernel_d/CMakeLists.txt

@@ -5,23 +5,15 @@ find_package(CGAL REQUIRED COMPONENTS Core)
 
 find_package(MPFI QUIET)
 
-if(MPFI_FOUND)
+if(MPFI_FOUND AND NOT CGAL_DISABLE_GMP)
-
   include(${CGAL_USE_FILE})
   include(${MPFI_USE_FILE})
   include(CGAL_VersionUtils)
-
   create_single_source_cgal_program("Compare_1.cpp")
   create_single_source_cgal_program("Construct_algebraic_real_1.cpp")
   create_single_source_cgal_program("Isolate_1.cpp")
   create_single_source_cgal_program("Sign_at_1.cpp")
   create_single_source_cgal_program("Solve_1.cpp")
-
 else()
-
+    message(STATUS "This program requires the CGAL, CGAL_Core and MPFI libraries, and will not be compiled.")
-  message(
-    STATUS
-      "This program requires the CGAL library and MPFI, and will not be compiled."
-  )
-
 endif()

Algebraic_kernel_d/include/CGAL/Algebraic_kernel_d/Curve_analysis_2.h

@@ -2007,7 +2007,7 @@ public:
      *
      * For each status line at an event and each status line that represents
      * an interval, all y-coordinates are approximated such that their
-     * isolating interval has absolute size smaller then \c precision.
+     * isolating interval has absolute size smaller than \c precision.
      */
     void refine_all(Bound precision) {
 

Algebraic_kernel_d/test/Algebraic_kernel_d/CMakeLists.txt

@@ -34,32 +34,36 @@ include(${CGAL_USE_FILE})
 # ##########################################################
 
 create_single_source_cgal_program("cyclic.cpp")
-create_single_source_cgal_program("Algebraic_curve_kernel_2.cpp")
+create_single_source_cgal_program("Descartes.cpp")
-create_single_source_cgal_program("algebraic_curve_kernel_2_tools.cpp")
+if(NOT CGAL_DISABLE_GMP)
-create_single_source_cgal_program("Algebraic_kernel_d_1_LEDA.cpp")
+  create_single_source_cgal_program("Algebraic_curve_kernel_2.cpp")
+  create_single_source_cgal_program("algebraic_curve_kernel_2_tools.cpp")
+  create_single_source_cgal_program("Algebraic_kernel_d_1_LEDA.cpp")
 
-create_single_source_cgal_program(
+  create_single_source_cgal_program(
     "Algebraic_kernel_d_1_CORE_Integer_rational.cpp")
-create_single_source_cgal_program(
+  create_single_source_cgal_program(
     "Algebraic_kernel_d_1_CORE_SqrtII_rational.cpp")
-create_single_source_cgal_program(
+  create_single_source_cgal_program(
     "Algebraic_kernel_d_1_CORE_SqrtRI_rational.cpp")
-create_single_source_cgal_program(
+  create_single_source_cgal_program(
     "Algebraic_kernel_d_1_CORE_SqrtRR_rational.cpp")
 
-create_single_source_cgal_program("Algebraic_kernel_d_1_GMP.cpp")
+  create_single_source_cgal_program("Algebraic_kernel_d_1_GMP.cpp")
-create_single_source_cgal_program("Algebraic_kernel_d_2.cpp")
+  create_single_source_cgal_program("Algebraic_kernel_d_2.cpp")
-create_single_source_cgal_program("Algebraic_real_d_1.cpp")
+  create_single_source_cgal_program("Algebraic_real_d_1.cpp")
-create_single_source_cgal_program("Bitstream_descartes.cpp")
+  create_single_source_cgal_program("Bitstream_descartes.cpp")
-create_single_source_cgal_program("Curve_analysis_2.cpp")
+  create_single_source_cgal_program("Curve_analysis_2.cpp")
-create_single_source_cgal_program("Curve_pair_analysis_2.cpp")
+  create_single_source_cgal_program("Curve_pair_analysis_2.cpp")
-create_single_source_cgal_program("Descartes.cpp")
+  create_single_source_cgal_program("Real_embeddable_traits_extension.cpp")
-create_single_source_cgal_program("Real_embeddable_traits_extension.cpp")
+  if(RS_FOUND)
-if(RS_FOUND)
     create_single_source_cgal_program("Algebraic_kernel_rs_gmpq_d_1.cpp")
     create_single_source_cgal_program("Algebraic_kernel_rs_gmpz_d_1.cpp")
-else()
+  else()
     message(
       STATUS
         "NOTICE: Some tests require the RS library, and will not be compiled.")
+  endif()
+else()
+  message(STATUS "NOTICE: Some tests require the CGAL_Core library, and will not be compiled.")
 endif()

Algebraic_kernel_for_spheres/include/CGAL/Algebraic_kernel_for_spheres/internal_functions_comparison_root_for_spheres_2_3.h

@@ -30,19 +30,19 @@ namespace CGAL {
     template <typename RT>
       Comparison_result
       compare_x(const CGAL::Root_for_spheres_2_3<RT>& r1, const CGAL::Root_for_spheres_2_3<RT>& r2){
-      return compare(r1.x(), r2.x());
+      return CGAL::compare(r1.x(), r2.x());
     }
 
     template <typename RT>
       Comparison_result
       compare_y(const CGAL::Root_for_spheres_2_3<RT>& r1, const CGAL::Root_for_spheres_2_3<RT>& r2){
-      return compare(r1.y(), r2.y());
+      return CGAL::compare(r1.y(), r2.y());
     }
 
     template <typename RT>
       Comparison_result
       compare_z(const CGAL::Root_for_spheres_2_3<RT>& r1, const CGAL::Root_for_spheres_2_3<RT>& r2){
-      return compare(r1.z(), r2.z());
+      return CGAL::compare(r1.z(), r2.z());
     }
 
     template <typename RT>

Alpha_shapes_2/doc/Alpha_shapes_2/Alpha_shapes_2.txt

@@ -134,9 +134,8 @@ All \cgal kernels are models of both concepts.
 
 The triangulation data structure of the triangulation
 has to be a model of the concept `TriangulationDataStructure_2`,
-and it must be parameterized with
+whose vertex and face classes are models of the concepts
-vertex and face classes which are models of the concepts
+`AlphaShapeVertex_2` and `AlphaShapeFace_2`, respectively.
-`AlphaShapeVertex_2` and `AlphaShapeFace_2`.
 The classes `Alpha_shape_vertex_base_2<Gt, Vb>` and `Alpha_shape_face_base_2<Gt, Fb>`
 are models of these concepts and can be used for all type of alpha shapes,
 provided that the template parameters `Vb` and `Fb` are appropriately chosen,

Alpha_shapes_2/doc/Alpha_shapes_2/CGAL/Weighted_alpha_shape_euclidean_traits_2.h

@@ -1,26 +0,0 @@
-
-namespace CGAL {
-
-/*!
-\ingroup PkgAlphaShapes2Ref
-
-\deprecated The class is deprecated since \cgal 4.10, as the weighted point and the function
-objects for weighted points are part of the concept `Kernel`. The class is kept for backward
-compatibility.
-
-The class `Weighted_alpha_shape_euclidean_traits_2` was the default model for the concept
-`AlphaShapeTraits_2` for the regular version of Alpha Shapes.
-
-\tparam K must be a model of `Kernel`.
-
-\cgalModels `AlphaShapeTraits_2`
-
-*/
-template< typename K >
-class Weighted_alpha_shape_euclidean_traits_2
-  : public K
-{
-public:
-
-}; /* end Weighted_alpha_shape_euclidean_traits_2 */
-} /* end namespace CGAL */

Alpha_shapes_2/doc/Alpha_shapes_2/Concepts/WeightedAlphaShapeTraits_2.h

@@ -45,7 +45,7 @@ typedef unspecified_type FT;
 /*!
 A default constructor.
 */
-  AlphaShapeTraits_2();
+  WeightedAlphaShapeTraits_2();
 
 /// @}
 

Alpha_shapes_2/doc/Alpha_shapes_2/PackageDescription.txt

@@ -70,12 +70,12 @@ finite number of different \f$ \alpha\f$-shapes and corresponding
 
 \cgalCRPSection{Concepts}
 - `AlphaShapeTraits_2`
+- `WeightedAlphaShapeTraits_2`
 - `AlphaShapeFace_2`
 - `AlphaShapeVertex_2`
 
 \cgalCRPSection{Classes}
 - `CGAL::Alpha_shape_2<Dt>`
-- `CGAL::Weighted_alpha_shape_euclidean_traits_2<K>`
 - `CGAL::Alpha_shape_vertex_base_2<AlphaShapeTraits_2>`
 - `CGAL::Alpha_shape_face_base_2<AlphaShapeTraits_2, TriangulationFaceBase_2>`
 

Alpha_shapes_2/include/CGAL/Alpha_shape_euclidean_traits_2.h

@@ -1,29 +0,0 @@
-// Copyright (c) 1997  INRIA Sophia-Antipolis (France).
-// All rights reserved.
-//
-// This file is part of CGAL (www.cgal.org).
-//
-// $URL$
-// $Id$
-// SPDX-License-Identifier: GPL-3.0-or-later OR LicenseRef-Commercial
-//
-//
-// Author(s)     : Tran Kai Frank DA <Frank.Da@sophia.inria.fr>
-//                 Andreas Fabri <Andreas.Fabri@geometryfactory.com>
-
-#ifndef CGAL_ALPHA_SHAPE_EUCLIDEAN_TRAITS_H
-#define CGAL_ALPHA_SHAPE_EUCLIDEAN_TRAITS_H
-
-#include <CGAL/license/Alpha_shapes_2.h>
-
-
-
-namespace CGAL {
-
-template < class R >
-class Alpha_shape_euclidean_traits_2 : public R
-{};
-
-} //namespace CGAL
-
-#endif

Alpha_shapes_2/include/CGAL/Weighted_alpha_shape_euclidean_traits_2.h

@@ -1,37 +0,0 @@
-// Copyright (c) 1997  INRIA Sophia-Antipolis (France).
-// All rights reserved.
-//
-// This file is part of CGAL (www.cgal.org).
-//
-// $URL$
-// $Id$
-// SPDX-License-Identifier: GPL-3.0-or-later OR LicenseRef-Commercial
-//
-// Author(s)     : Tran Kai Frank DA <Frank.Da@sophia.inria.fr>
-//                 Andreas Fabri <Andreas.Fabri@geometryfactory.com>
-
-#ifndef CGAL_WEIGHTED_ALPHA_SHAPE_EUCLIDEAN_TRAITS_2_H
-#define CGAL_WEIGHTED_ALPHA_SHAPE_EUCLIDEAN_TRAITS_2_H
-
-#include <CGAL/license/Alpha_shapes_2.h>
-
-#define CGAL_DEPRECATED_HEADER "<CGAL/Weighted_alpha_shape_euclidean_traits_2.h>"
-#define CGAL_DEPRECATED_MESSAGE_DETAILS \
-  "The kernel K can be used directly as traits since weighted points and "\
-  "the associated function objects are now part of the concept Kernel."
-#include <CGAL/internal/deprecation_warning.h>
-
-namespace CGAL {
-
-template< class K_ >
-class Weighted_alpha_shape_euclidean_traits_2
-  : public K_
-{
-public:
-  Weighted_alpha_shape_euclidean_traits_2() { }
-  Weighted_alpha_shape_euclidean_traits_2(const K_& k) : K_(k) { }
-};
-
-} // namespace CGAL
-
-#endif // CGAL_WEIGHTED_ALPHA_SHAPE_EUCLIDEAN_TRAITS_2_H

Alpha_shapes_3/TODO

@@ -12,14 +12,6 @@ when alpha is given as an int.
   Alpha_shape_3(Dt& dt, bool swap=true, NT alpha = 0, Mode m = REGULARIZED)
   The triangulation is swapped  if swap=true and copied otherwise.
 
-- suppress the traits classes Alpha_shape_euclidean_traits_3.h
-  and Weighted_alpha_shape_euclidean_traits_3.h
-  their purpose was to rename the Compute_squared_radius_3 constructor.
-  The same can be achieved in class Alpha_shapes_3 using the Weighted_tag
-  of the triangulation
-
-- same as previous for Alpha_shapes_2
-
 - test the  taking into account of paramater alpha in functions
 get_alpha_shape_edges
 get_alpha_shape_facets

Alpha_shapes_3/doc/Alpha_shapes_3/Alpha_shapes_3.txt

@@ -219,8 +219,8 @@ in the non-weighted case and `WeightedAlphaShapeTraits_3` in the weighted case.
 All \cgal kernels are models of both concepts.
 
 The triangulation data structure of the triangulation
-has to be a model of the concept `TriangulationDataStructure_3`,
+has to be a model of the concept `TriangulationDataStructure_3`
-and it must be parameterized with vertex and cell classes, which are model of the concepts
+whose vertex and cell classes are model of the concepts
 `AlphaShapeVertex_3` and `AlphaShapeCell_3`.
 The classes `Alpha_shape_vertex_base_3<Gt>` and `Alpha_shape_cell_base_3<Gt>`
 are models of these concepts and can be used for all type of alpha shapes,
@@ -234,8 +234,8 @@ the traits class are described in the concepts `FixedAlphaShapeTraits_3`
 in the non-weighted case and `FixedWeightedAlphaShapeTraits_3` in the weighted case.
 All \cgal kernels are models of both concepts.
 The triangulation data structure of the triangulation
-has to be a model of the concept `TriangulationDataStructure_3`,
+has to be a model of the concept `TriangulationDataStructure_3`
-and it must be parameterized with vertex and cell classes, which are model of the concepts
+whose vertex and cell classes are model of the concepts
 `FixedAlphaShapeVertex_3` and `FixedAlphaShapeCell_3`.
 The package provides models `Fixed_alpha_shape_vertex_base_3<Gt>`
 and `Fixed_alpha_shape_cell_base_3<Gt>`, respectively.

Alpha_shapes_3/include/CGAL/Alpha_shape_euclidean_traits_3.h

@@ -1,27 +0,0 @@
-// Copyright (c) 1997  INRIA Sophia-Antipolis (France).
-// All rights reserved.
-//
-// This file is part of CGAL (www.cgal.org).
-//
-// $URL$
-// $Id$
-// SPDX-License-Identifier: GPL-3.0-or-later OR LicenseRef-Commercial
-//
-//
-// Author(s)     : Tran Kai Frank DA <Frank.Da@sophia.inria.fr>
-
-#ifndef CGAL_ALPHA_SHAPE_EUCLIDEAN_TRAITS_3_H
-#define CGAL_ALPHA_SHAPE_EUCLIDEAN_TRAITS_3_H
-
-#include <CGAL/license/Alpha_shapes_3.h>
-
-
-namespace CGAL {
-
-template <class K>
-class Alpha_shape_euclidean_traits_3 : public K {};
-
-
-} //namespace CGAL
-
-#endif //CGAL_ALPHA_SHAPE_EUCLIDEAN_TRAITS_3_H

Alpha_shapes_3/include/CGAL/Weighted_alpha_shape_euclidean_traits_3.h

@@ -1,36 +0,0 @@
-// Copyright (c) 1997  INRIA Sophia-Antipolis (France).
-// All rights reserved.
-//
-// This file is part of CGAL (www.cgal.org).
-//
-// $URL$
-// $Id$
-// SPDX-License-Identifier: GPL-3.0-or-later OR LicenseRef-Commercial
-//
-// Author(s)     : Tran Kai Frank DA <Frank.Da@sophia.inria.fr>
-
-#ifndef CGAL_WEIGHTED_ALPHA_SHAPE_EUCLIDEAN_TRAITS_3_H
-#define CGAL_WEIGHTED_ALPHA_SHAPE_EUCLIDEAN_TRAITS_3_H
-
-#include <CGAL/license/Alpha_shapes_3.h>
-
-#define CGAL_DEPRECATED_HEADER "<CGAL/Weighted_alpha_shape_euclidean_traits_3.h>"
-#define CGAL_DEPRECATED_MESSAGE_DETAILS \
-  "The kernel K can be used directly as traits since weighted points and "\
-  "the associated function objects are now part of the concept Kernel."
-#include <CGAL/internal/deprecation_warning.h>
-
-namespace CGAL {
-
-template < class K_ >
-class Weighted_alpha_shape_euclidean_traits_3
-  : public K_
-{
-public:
-  Weighted_alpha_shape_euclidean_traits_3() { }
-  Weighted_alpha_shape_euclidean_traits_3(const K_& k) : K_(k) { }
-};
-
-} // namespace CGAL
-
-#endif // CGAL_WEIGHTED_ALPHA_SHAPE_EUCLIDEAN_TRAITS_3_H

Apollonius_graph_2/doc/Apollonius_graph_2/Apollonius_graph_2.txt

@@ -181,7 +181,7 @@ two visible circles.
 
 The 2D Apollonius graph class
 `Apollonius_graph_2<ApolloniusGraphTraits_2,ApolloniusGraphDataStructure_2>`
-follows the design of the triangulation package of \cgal. It is
+follows the design of the triangulation packages of \cgal. It is
 parametrized by two arguments:
 <UL>
 <LI>the <B>geometric traits</B> class. It provides the basic

Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_2.h

@@ -4,14 +4,20 @@ namespace CGAL {
 /*!
 \ingroup PkgApolloniusGraph2Ref
 
-The class `Apollonius_graph_2` represents the
+The class `Apollonius_graph_2` represents the Apollonius graph.
-Apollonius graph. It supports insertions and deletions of sites.
+It supports insertions and deletions of sites.
-It is templated by two template arguments `Gt`, which
+
-must be a model of `ApolloniusGraphTraits_2`, and `Agds`,
+\tparam Gt is the geometric traits class and must be a model of `ApolloniusGraphTraits_2`.
-which must be a model of `ApolloniusGraphDataStructure_2`.
+
-The second template argument defaults to
+\tparam Agds is the Apollonius graph data structure and must be a model of `ApolloniusGraphDataStructure_2`
-`CGAL::Triangulation_data_structure_2< CGAL::Apollonius_graph_vertex_base_2<Gt,true>, CGAL::Triangulation_face_base_2<Gt> >`.
+whose vertex and face must be models of `ApolloniusGraphVertexBase_2` and `TriangulationFaceBase_2`,
-\cgalModels `DelaunayGraph_2`
+respectively.
+It defaults to:
+\code
+  CGAL::Triangulation_data_structure_2<
+    CGAL::Apollonius_graph_vertex_base_2<Gt,true>,
+    CGAL::Triangulation_face_base_2<Gt> >`
+\endcode
 
 \cgalHeading{Traversal of the Apollonius Graph}
 
@@ -40,17 +46,11 @@ ag.incident_edges(ag.infinite_vertex());
 ag.incident_edges(ag.infinite_vertex(), f);
 \endcode
 
-\sa `DelaunayGraph_2`
+\cgalModels `DelaunayGraph_2`
-\sa `ApolloniusGraphTraits_2`
+
-\sa `ApolloniusGraphDataStructure_2`
-\sa `ApolloniusGraphVertexBase_2`
-\sa `TriangulationFaceBase_2`
 \sa `CGAL::Apollonius_graph_traits_2<K,Method_tag>`
 \sa `CGAL::Apollonius_graph_filtered_traits_2<CK,CM,EK,EM,FK,FM>`
-\sa `CGAL::Triangulation_data_structure_2<Vb,Fb>`
+\sa `CGAL::Apollonius_graph_hierarchy_2<Gt,Agds>`
-\sa `CGAL::Apollonius_graph_vertex_base_2<Gt,StoreHidden>`
-\sa `CGAL::Triangulation_face_base_2<Gt>`
-
 */
 template< typename Gt, typename Agds >
 class Apollonius_graph_2 {
@@ -92,7 +92,7 @@ typedef Gt::Site_2 Site_2;
 
 /// \name Handles And Iterators
 /// The vertices and faces of the Apollonius graph are accessed
-/// through `handles`, `iterators` and `circulators`. The iterators
+/// through `handles`, `iterators`, and `circulators`. The iterators
 /// and circulators are all bidirectional and non-mutable. The
 /// circulators and iterators are assignable to the corresponding
 /// handle types, and they are also convertible to the corresponding
@@ -261,63 +261,62 @@ operator=(const Apollonius_graph_2<Gt,Agds>& other);
 /*!
 Returns a reference to the Apollonius graph traits object.
 */
-Geom_traits geom_traits();
+const Geom_traits& geom_traits() const;
 
 /*!
 Returns a reference to the
 underlying data structure.
 */
-Data_structure data_structure();
+const Data_structure& data_structure() const;
 
 /*!
 Same as `data_structure()`. This
 method has been added in compliance with the `DelaunayGraph_2`
 concept.
 */
-Data_structure tds();
+const Data_structure& tds() const;
 
 /*!
 Returns the dimension of the Apollonius graph.
 */
-int dimension();
+int dimension() const;
 
 /*!
 Returns the number of finite vertices.
 */
-size_type number_of_vertices();
+size_type number_of_vertices() const;
 
 /*!
 Returns the number of visible sites.
 */
-size_type number_of_visible_sites();
+size_type number_of_visible_sites() const;
 
 /*!
 Returns the number of hidden sites.
 */
-size_type number_of_hidden_sites();
+size_type number_of_hidden_sites() const;
 
 /*!
 Returns the number of faces (both finite and infinite) of the
 Apollonius graph.
 */
-size_type number_of_faces();
+size_type number_of_faces() const;
 
 /*!
 Returns a face incident to the `infinite_vertex`.
 */
-Face_handle infinite_face();
+Face_handle infinite_face() const;
 
 /*!
 Returns the `infinite_vertex`.
 */
-Vertex_handle
+Vertex_handle infinite_vertex() const;
-infinite_vertex();
 
 /*!
 Returns a vertex distinct from the `infinite_vertex`.
 \pre The number of (visible) vertices in the Apollonius graph must be at least one.
 */
-Vertex_handle finite_vertex();
+Vertex_handle finite_vertex() const;
 
 /// @}
 
@@ -337,63 +336,62 @@ Vertex_handle finite_vertex();
 /*!
 Starts at an arbitrary finite vertex.
 */
-Finite_vertices_iterator finite_vertices_begin();
+Finite_vertices_iterator finite_vertices_begin() const;
 
 /*!
 Past-the-end iterator.
 */
-Finite_vertices_iterator finite_vertices_end();
+Finite_vertices_iterator finite_vertices_end() const;
 
 /*!
 Starts at an arbitrary finite edge.
 */
-Finite_edges_iterator finite_edges_begin();
+Finite_edges_iterator finite_edges_begin() const;
 
 /*!
 Past-the-end iterator.
 */
-Finite_edges_iterator finite_edges_end();
+Finite_edges_iterator finite_edges_end() const;
 
 /*!
 Starts at an arbitrary finite face.
 */
-Finite_faces_iterator finite_faces_begin();
+Finite_faces_iterator finite_faces_begin() const;
 
 /*!
 Past-the-end iterator.
 */
-Finite_faces_iterator finite_faces_end()
+Finite_faces_iterator finite_faces_end() const;
-const;
 
 /*!
 Starts at an arbitrary vertex.
 */
-All_vertices_iterator all_vertices_begin();
+All_vertices_iterator all_vertices_begin() const;
 
 /*!
 Past-the-end iterator.
 */
-All_vertices_iterator all_vertices_end();
+All_vertices_iterator all_vertices_end() const;
 
 /*!
 Starts at an arbitrary edge.
 */
-All_edges_iterator all_edges_begin();
+All_edges_iterator all_edges_begin() const;
 
 /*!
 Past-the-end iterator.
 */
-All_edges_iterator all_edges_end();
+All_edges_iterator all_edges_end() const;
 
 /*!
 Starts at an arbitrary face.
 */
-All_faces_iterator all_faces_begin();
+All_faces_iterator all_faces_begin() const;
 
 /*!
 Past-the-end iterator.
 */
-All_faces_iterator all_faces_end();
+All_faces_iterator all_faces_end() const;
 
 /// @}
 
@@ -407,32 +405,32 @@ All_faces_iterator all_faces_end();
 /*!
 Starts at an arbitrary site.
 */
-Sites_iterator sites_begin();
+Sites_iterator sites_begin() const;
 
 /*!
 Past-the-end iterator.
 */
-Sites_iterator sites_end();
+Sites_iterator sites_end() const;
 
 /*!
 Starts at an arbitrary visible site.
 */
-Visible_sites_iterator visible_sites_begin();
+Visible_sites_iterator visible_sites_begin() const;
 
 /*!
 Past-the-end iterator.
 */
-Visible_sites_iterator visible_sites_end();
+Visible_sites_iterator visible_sites_end() const;
 
 /*!
 Starts at an arbitrary hidden site.
 */
-Hidden_sites_iterator hidden_sites_begin();
+Hidden_sites_iterator hidden_sites_begin() const;
 
 /*!
 Past-the-end iterator.
 */
-Hidden_sites_iterator hidden_sites_end();
+Hidden_sites_iterator hidden_sites_end() const;
 
 /// @}
 
@@ -454,39 +452,39 @@ Hidden_sites_iterator hidden_sites_end();
 Starts at an arbitrary face incident
 to `v`.
 */
-Face_circulator incident_faces(Vertex_handle v);
+Face_circulator incident_faces(Vertex_handle v) const;
 
 /*!
 Starts at face `f`.
 \pre Face `f` is incident to vertex `v`.
 */
-Face_circulator incident_faces(Vertex_handle v, Face_handle f);
+Face_circulator incident_faces(Vertex_handle v, Face_handle f) const;
 
 /*!
 Starts at an arbitrary edge incident
 to `v`.
 */
-Edge_circulator incident_edges(Vertex_handle v);
+Edge_circulator incident_edges(Vertex_handle v) const;
 
 /*!
 Starts at the first edge of `f` incident to
 `v`, in counterclockwise order around `v`.
 \pre Face `f` is incident to vertex `v`.
 */
-Edge_circulator incident_edges(Vertex_handle v, Face_handle f);
+Edge_circulator incident_edges(Vertex_handle v, Face_handle f) const;
 
 /*!
 Starts at an arbitrary vertex incident
 to `v`.
 */
-Vertex_circulator incident_vertices(Vertex_handle v);
+Vertex_circulator incident_vertices(Vertex_handle v) const;
 
 /*!
 Starts at the first vertex of `f` adjacent to `v`
 in counterclockwise order around `v`.
 \pre Face `f` is incident to vertex `v`.
 */
-Vertex_circulator incident_vertices(Vertex_handle v, Face_handle f);
+Vertex_circulator incident_vertices(Vertex_handle v, Face_handle f) const;
 
 /// @}
 
@@ -516,7 +514,7 @@ bool is_infinite(Face_handle f, int i) const;
 `true`, iff edge `e` is infinite.
 */
 bool
-is_infinite(Edge e) const;
+is_infinite(const Edge& e) const;
 
 /*!
 `true`, iff edge `*ec` is infinite.
@@ -544,7 +542,7 @@ site `s` in the Apollonius graph. If `s` is visible then the
 vertex handle of `s` is returned, otherwise
 `Vertex_handle(nullptr)` is returned.
 */
-Vertex_handle insert(Site_2 s);
+Vertex_handle insert(const Site_2& s);
 
 /*!
 Inserts `s` in the Apollonius graph using the site
@@ -553,8 +551,7 @@ the center of `s`. If `s` is visible then the vertex handle of
 `s` is returned, otherwise `Vertex_handle(nullptr)` is
 returned.
 */
-Vertex_handle insert(Site_2 s, Vertex_handle
+Vertex_handle insert(const Site_2& s, Vertex_handle vnear);
-vnear);
 
 /// @}
 
@@ -581,7 +578,7 @@ arbitrarily and one of the nearest neighbors of `p` is
 returned. If there are no visible sites in the Apollonius diagram
 `Vertex_handle(nullptr)` is returned.
 */
-Vertex_handle nearest_neighbor(Point_2 p);
+Vertex_handle nearest_neighbor(const Point_2& p) const;
 
 /*!
 Finds the nearest neighbor of the point
@@ -591,8 +588,7 @@ arbitrarily and one of the nearest neighbors of `p` is
 returned. If there are no visible sites in the Apollonius diagram
 `Vertex_handle(nullptr)` is returned.
 */
-Vertex_handle nearest_neighbor(Point_2 p,
+Vertex_handle nearest_neighbor(const Point_2& p, Vertex_handle vnear) const;
-Vertex_handle vnear);
 
 /// @}
 
@@ -645,7 +641,7 @@ the stream `str`.
 
 */
 template< class Stream >
-Stream& draw_primal(Stream& str);
+Stream& draw_primal(Stream& str) const;
 
 /*!
 Draws the dual of the
@@ -658,7 +654,7 @@ Apollonius graph, i.e., the Apollonius diagram, to the stream
 
 */
 template < class Stream >
-Stream& draw_dual(Stream& str);
+Stream& draw_dual(Stream& str) const;
 
 /*!
 Draws the edge
@@ -669,7 +665,7 @@ Draws the edge
 
 */
 template< class Stream >
-Stream& draw_primal_edge(Edge e, Stream& str);
+Stream& draw_primal_edge(const Edge& e, Stream& str) const;
 
 /*!
 Draws the dual of the
@@ -682,7 +678,7 @@ of the Apollonius diagram.
 
 */
 template< class Stream >
-Stream& draw_dual_edge(Edge e, Stream& str);
+Stream& draw_dual_edge(const Edge& e, Stream& str) const;
 
 /*!
 Writes the current
@@ -690,7 +686,7 @@ state of the Apollonius graph to an output stream. In particular,
 all visible and hidden sites are written as well as the
 underlying combinatorial data structure.
 */
-void file_output(std::ostream& os);
+void file_output(std::ostream& os) const;
 
 /*!
 Reads the state of the
@@ -701,14 +697,12 @@ void file_input(std::istream& is);
 /*!
 Writes the current state of the Apollonius graph to an output stream.
 */
-std::ostream& operator<<(std::ostream& os,
+std::ostream& operator<<(std::ostream& os, const Apollonius_graph_2<Gt,Agds>& ag) const;
-Apollonius_graph_2<Gt,Agds> ag);
 
 /*!
 Reads the state of the Apollonius graph from an input stream.
 */
-std::istream& operator>>(std::istream& is,
+std::istream& operator>>(std::istream& is, const Apollonius_graph_2<Gt,Agds>& ag);
-Apollonius_graph_2<Gt,Agds> ag);
 
 /// @}
 
@@ -721,9 +715,9 @@ Checks the validity of the Apollonius graph. If `verbose` is
 is 0, only the data structure is validated. If `level` is 1, then
 both the data structure and the Apollonius graph are
 validated. Negative values of `level` always return true, and
-values greater then 1 are equivalent to `level` being 1.
+values greater than 1 are equivalent to `level` being 1.
 */
-bool is_valid(bool verbose = false, int level = 1);
+bool is_valid(bool verbose = false, int level = 1) const;
 
 /// @}
 
@@ -737,12 +731,11 @@ void clear();
 
 /*!
 The Apollonius graphs
-`other` and `ag` are swapped. `ag`.`swap(other)` should
+`other` and `ag` are swapped. `ag.swap(other)` should
-be preferred to `ag`` = other` or to `ag``(other)` if
+be preferred to `ag = other` or to `ag(other)` if
 `other` is deleted afterwards.
 */
-void swap(Apollonius_graph_2<Gt,Agds>
+void swap(Apollonius_graph_2<Gt,Agds>& other);
-other);
 
 /// @}
 

Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_hierarchy_2.h

@@ -19,36 +19,34 @@ find the nearest neighbor of \f$ p\f$ as in the
 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 \cgalCite{d-iirdt-98}.
+
 The class has two template parameters which have essentially the same
-meaning as in the `Apollonius_graph_2<Gt,Agds>` class. The first
+meaning as in the `Apollonius_graph_2<Gt,Agds>` class.
-template parameter must be a model of the
+
-`ApolloniusGraphTraits_2` concept.
+\tparam Gt is the geometric traits class and must be a model of `ApolloniusGraphTraits_2`.
-The second template parameter must be a model of the
+
-`ApolloniusGraphDataStructure_2` concept. However, the vertex base
+\tparam Agds is the Apollonius graph data structure and must be a model of `ApolloniusGraphDataStructure_2`
-class that is to be used in the Apollonius graph data structure must
+whose vertex and face must be models of `ApolloniusGraphHierarchyVertexBase_2` and `TriangulationFaceBase_2`, respectively.
-be a model of the `ApolloniusGraphHierarchyVertexBase_2` concept.
+It defaults to:
-The second template parameter defaults to
+\code
-`Triangulation_data_structure_2< Apollonius_graph_hierarchy_vertex_base_2< Apollonius_graph_vertex_base_2<Gt,true> >, Triangulation_face_base_2<Gt> >`.
+  CGAL::Triangulation_data_structure_2<
+    CGAL::Apollonius_graph_hierarchy_vertex_base_2<CGAL::Apollonius_graph_vertex_base_2<Gt,true> >,
+    CGAL::Triangulation_face_base_2<Gt> >
+\endcode
+
+\cgalHeading{Heritage}
 
 The `Apollonius_graph_hierarchy_2` class derives publicly from the
 `Apollonius_graph_2<Gt,Agds>` class. The interface is
 the same with its base class. In the sequel only the methods
 overridden are documented.
 
-\cgalHeading{Types}
-
 `Apollonius_graph_hierarchy_2` does not introduce other types than those introduced by
 its base class `Apollonius_graph_2<Gt,Agds>`.
 
-\sa `ApolloniusGraphDataStructure_2`
-\sa `ApolloniusGraphTraits_2`
-\sa `ApolloniusGraphHierarchyVertexBase_2`
 \sa `CGAL::Apollonius_graph_2<Gt,Agds>`
-\sa `CGAL::Triangulation_data_structure_2<Vb,Fb>`
 \sa `CGAL::Apollonius_graph_traits_2<K,Method_tag>`
 \sa `CGAL::Apollonius_graph_filtered_traits_2<CK,CM,EK,EM,FK,FM>`
-\sa `CGAL::Apollonius_graph_hierarchy_vertex_base_2<Agvb>`
-
 */
 template< typename Gt, typename Agds >
 class Apollonius_graph_hierarchy_2 : public CGAL::Apollonius_graph_2<Gt,Agds> {
@@ -61,8 +59,7 @@ public:
 Creates an hierarchy of Apollonius graphs using `gt` as
 geometric traits.
 */
-Apollonius_graph_hierarchy_2(Gt
+Apollonius_graph_hierarchy_2(Gt gt=Gt());
-gt=Gt());
 
 /*!
 Creates an Apollonius graph hierarchy using
@@ -70,17 +67,15 @@ Creates an Apollonius graph hierarchy using
 range [`first`, `beyond`).
 */
 template< class Input_iterator >
-Apollonius_graph_hierarchy_2<Gt,Agds>(Input_iterator
+Apollonius_graph_hierarchy_2(Input_iterator first, Input_iterator beyond, Gt gt=Gt());
-first, Input_iterator beyond, Gt gt=Gt());
 
 /*!
-Copy constructor. All faces, vertices and inter-level pointers
+Copy constructor. All faces, vertices, and inter-level pointers
 are duplicated. After the construction, `agh` and `other` refer
 to two different Apollonius graph hierarchies: if
 `other` is modified, `agh` is not.
 */
-Apollonius_graph_hierarchy_2<Gt,Agds>
+Apollonius_graph_hierarchy_2(const Apollonius_graph_hierarchy_2<Gt,Agds>& other);
-(Apollonius_graph_hierarchy_2<Gt,Agds> other);
 
 /*!
 Assignment. All faces, vertices and inter-level pointers
@@ -112,7 +107,7 @@ site `s` in the Apollonius graph hierarchy. If `s`
 is visible then the vertex handle of `s` is returned, otherwise
 `Vertex_handle(nullptr)` is returned.
 */
-Vertex_handle insert(Site_2 s);
+Vertex_handle insert(const Site_2& s);
 
 /*!
 Inserts `s` in the Apollonius graph hierarchy using the
@@ -124,8 +119,7 @@ A call to this method is equivalent to `agh.insert(s);` and it has
 been added for the sake of conformity with the interface of the
 `Apollonius_graph_2<Gt,Agds>` class.
 */
-Vertex_handle insert(Site_2 s, Vertex_handle
+Vertex_handle insert(const Site_2& s, Vertex_handle vnear);
-vnear);
 
 /// @}
 
@@ -152,7 +146,7 @@ arbitrarily and one of the nearest neighbors of `p` is
 returned. If there are no visible sites in the Apollonius diagram
 `Vertex_handle(nullptr)` is returned.
 */
-Vertex_handle nearest_neighbor(Point p);
+Vertex_handle nearest_neighbor(const Point_2& p) const;
 
 /*!
 Finds the nearest neighbor of the point
@@ -163,8 +157,7 @@ A call to this method is equivalent to
 conformity with the interface of the
 `Apollonius_graph_2<Gt,Agds>` class.
 */
-Vertex_handle nearest_neighbor(Point p,
+Vertex_handle nearest_neighbor(const Point_2& p, Vertex_handle vnear) const;
-Vertex_handle vnear);
 
 /// @}
 
@@ -177,7 +170,7 @@ state of the Apollonius graph hierarchy to an output stream. In particular,
 all visible and hidden sites are written as well as the
 underlying combinatorial hierarchical data structure.
 */
-void file_output(std::ostream& os);
+void file_output(std::ostream& os) const;
 
 /*!
 Reads the state of the
@@ -189,7 +182,7 @@ void file_input(std::istream& is);
 Writes the current state of the Apollonius graph hierarchy to an
 output stream.
 */
-std::ostream& operator<<(std::ostream& os, Apollonius_graph_hierarchy_2<Gt,Agds> agh);
+std::ostream& operator<<(std::ostream& os, Apollonius_graph_hierarchy_2<Gt,Agds> agh) const;
 
 /*!
 Reads the state of the Apollonius graph hierarchy from an input stream.
@@ -209,7 +202,7 @@ is validated, as well as the inter-level pointers. If `level` is
 1, then the data structure at all levels is validated, the inter-level
 pointers are validated and all levels of the Apollonius graph
 hierarchy are also validated. Negative values of `level` always
-return `true`, and values greater then 1 are equivalent to
+return `true`, and values greater than 1 are equivalent to
 `level` being 1.
 */
 bool is_valid(bool verbose = false, int level = 1) const;
@@ -227,11 +220,10 @@ void clear();
 
 /*!
 The Apollonius graph hierarchies `other` and `agh` are
-swapped. `agh`.`swap(other)` should be preferred to `agh`` =
+swapped. `agh.swap(other)` should be preferred to `agh = other`
-other` or to `agh``(other)` if `other` is deleted afterwards.
+or to `agh(other)` if `other` is deleted afterwards.
 */
-void swap(Apollonius_graph_hierarchy_2<Gt,Agds>
+void swap(Apollonius_graph_hierarchy_2<Gt,Agds>& other);
-other);
 
 /// @}
 

Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_hierarchy_vertex_base_2.h

@@ -13,10 +13,9 @@ of the `ApolloniusGraphVertexBase_2` concept.
 
 \cgalModels `ApolloniusGraphHierarchyVertexBase_2`
 
-\sa `ApolloniusGraphVertexBase_2`
-\sa `ApolloniusGraphHierarchyVertexBase_2`
 \sa `CGAL::Apollonius_graph_vertex_base_2<Gt,StoreHidden>`
-
+\sa `CGAL::Triangulation_data_structure_2<Vb,Fb>`
+\sa `CGAL::Apollonius_graph_hierarchy_2<Gt,Agds>`
 */
 template< typename Agvb >
 class Apollonius_graph_hierarchy_vertex_base_2 : Agvb {
@@ -34,7 +33,7 @@ Apollonius_graph_hierarchy_vertex_base_2();
 Constructs a vertex associated with the site `s` and
 embedded at the center of `s`.
 */
-Apollonius_graph_hierarchy_vertex_base_2(Site_2 s);
+Apollonius_graph_hierarchy_vertex_base_2(const Site_2& s);
 
 /*!
 Constructs a vertex associated with
@@ -42,7 +41,7 @@ the site `s`, embedded at the center of `s`,
 and pointing to the face associated with the face
 handle `f`.
 */
-Apollonius_graph_vertex_base_2(Site_2 s, Face_handle f);
+Apollonius_graph_hierarchy_vertex_base_2(const Site_2& s, Face_handle f);
 
 /// @}
 

Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_traits_2.h

@@ -22,13 +22,8 @@ The way the predicates are evaluated is discussed in
 
 \cgalModels `ApolloniusGraphTraits_2`
 
-\sa `Kernel`
-\sa `ApolloniusGraphTraits_2`
-\sa `CGAL::Integral_domain_without_division_tag`
-\sa `CGAL::Field_with_sqrt_tag`
 \sa `CGAL::Apollonius_graph_2<Gt,Agds>`
 \sa `CGAL::Apollonius_graph_filtered_traits_2<CK,CM,EK,EM,FK,FM>`
-
 */
 template< typename K, typename Method_tag >
 class Apollonius_graph_traits_2 {
@@ -45,14 +40,13 @@ Apollonius_graph_traits_2<K,Method_tag>();
 /*!
 Copy constructor.
 */
-Apollonius_graph_traits_2<K,Method_tag>(Apollonius_graph_traits_2<K,Method_tag> other);
+Apollonius_graph_traits_2<K,Method_tag>(const Apollonius_graph_traits_2<K,Method_tag>& other);
 
 /*!
 Assignment operator.
 */
 Apollonius_graph_traits_2<K,Method_tag>
-operator=(Apollonius_graph_traits_2<K,Method_tag>
+operator=(const Apollonius_graph_traits_2<K,Method_tag>& other);
-other);
 
 /// @}
 

Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_graph_vertex_base_2.h

@@ -19,13 +19,8 @@ discarded. By default `StoreHidden` is set to `true`.
 
 \cgalModels `ApolloniusGraphVertexBase_2`
 
-\sa `ApolloniusGraphVertexBase_2`
-\sa `ApolloniusGraphDataStructure_2`
-\sa `ApolloniusGraphTraits_2`
 \sa `CGAL::Triangulation_data_structure_2<Vb,Fb>`
-\sa `CGAL::Apollonius_graph_traits_2<K,Method_tag>`
+\sa `CGAL::Apollonius_graph_hierarchy_vertex_base_2<Gt>`
-\sa `CGAL::Apollonius_graph_filtered_traits_2<CK,CM,EK,EM,FK,FM>`
-
 */
 template< typename Gt, typename StoreHidden >
 class Apollonius_graph_vertex_base_2 {
@@ -37,13 +32,13 @@ public:
 /*!
 %Default constructor.
 */
-Apollonius_graph_bertex_base_2();
+Apollonius_graph_vertex_base_2();
 
 /*!
 Constructs a vertex associated with the site `s` and
 embedded at the center of `s`.
 */
-Apollonius_graph_vertex_base_2(Site_2 s);
+Apollonius_graph_vertex_base_2(const Site_2& s);
 
 /*!
 Constructs a vertex associated with
@@ -51,7 +46,7 @@ the site `s`, embedded at the center of `s`,
 and pointing to the face associated with the face
 handle `f`.
 */
-Apollonius_graph_vertex_base_2(Site_2 s, Face_handle f);
+Apollonius_graph_vertex_base_2(const Site_2& s, Face_handle f);
 
 /// @}
 

Apollonius_graph_2/doc/Apollonius_graph_2/CGAL/Apollonius_site_2.h

@@ -22,12 +22,9 @@ The I/O operators are defined for `iostream`.
 The information output in the `iostream` is: the point of the
 Apollonius site and its weight.
 
-\sa `Kernel`
-\sa `ApolloniusSite_2`
 \sa `CGAL::Qt_widget`
 \sa `CGAL::Apollonius_graph_traits_2<K,Method_tag>`
 \sa `CGAL::Apollonius_graph_filtered_traits_2<CK,CM,EK,EM,FK,FM>`
-
 */
 template< typename K >
 class Apollonius_site_2 {
@@ -44,7 +41,7 @@ Apollonius_site_2(Point_2 p=Point_2(), Weight w= Weight(0));
 /*!
 Copy constructor.
 */
-Apollonius_site_2(Apollonius_site_2<K> other);
+Apollonius_site_2(const Apollonius_site_2<K>& other);
 
 /// @}
 
@@ -57,8 +54,7 @@ Apollonius site `s` into the stream `os`.
 \pre The insert operator must be defined for `Point_2` and `Weight`.
 \relates Apollonius_site_2
 */
-std::ostream& operator<<(std::ostream& os,
+std::ostream& operator<<(std::ostream& os, const Apollonius_site_2<K>& s) const;
-const Apollonius_site_2<K>& s);
 
 /*!
 Reads an Apollonius site from the stream `is` and assigns it
@@ -67,8 +63,7 @@ to `s`.
 \pre The extract operator must be defined for `Point_2` and `Weight`.
 \relates Apollonius_site_2
 */
-std::istream& operator>>(std::istream& is,
+std::istream& operator>>(std::istream& is, const Apollonius_site_2<K>& s);
-const Apollonius_site_2<K>& s);
 
 /*!
 Inserts the Apollonius site `s` into the `Qt_widget` stream `w`.
@@ -76,7 +71,6 @@ Inserts the Apollonius site `s` into the `Qt_widget` stream `w`.
 \pre The insert operator must be defined for `K::Circle_2`.
 \relates Apollonius_site_2
 */
-Qt_widget& operator<<(Qt_widget& w,
+Qt_widget& operator<<(Qt_widget& w, const Apollonius_site_2<K>& s) const;
-const Apollonius_site_2<K>& s);
 
 } /* end namespace CGAL */

Apollonius_graph_2/doc/Apollonius_graph_2/Concepts/ApolloniusGraphDataStructure_2.h

@@ -42,10 +42,10 @@ public:
 /// @{
 
 /*!
-Inserts
+inserts a degree two vertex and two faces adjacent to it that have two common edges.
-a degree two vertex and two faces adjacent to it that have two common
+
-edges. The edge defined by the face handle `f` and the integer
+The edge defined by the face handle `f` and the integer `i` is duplicated. It returns a handle
-`i` is duplicated. It returns a handle to the vertex created.
+to the vertex created.
 */
 Vertex_handle insert_degree_2(Face_handle f, int i);
 

Apollonius_graph_2/doc/Apollonius_graph_2/Concepts/ApolloniusGraphHierarchyVertexBase_2.h

@@ -19,17 +19,12 @@ next and previous level graphs.
 `ApolloniusGraphHierarchyVertexBase_2` does not introduce any
 types in addition to those of `ApolloniusGraphVertexBase_2`.
 
-\cgalHasModel CGAL::Apollonius_graph_hierarchy_vertex_base_2<CGAL::Apollonius_graph_vertex_base_2<Gt,StoreHidden> >
+\cgalHasModel `CGAL::Apollonius_graph_hierarchy_vertex_base_2<CGAL::Apollonius_graph_vertex_base_2<Gt,StoreHidden> >`
 
 \sa `ApolloniusGraphDataStructure_2`
-\sa `ApolloniusGraphVertexBase_2`
 \sa `CGAL::Apollonius_graph_hierarchy_2<Gt,Agds>`
 \sa `CGAL::Triangulation_data_structure_2<Vb,Fb>`
-\sa `CGAL::Apollonius_graph_vertex_base_2<Gt,StoreHidden>`
-\sa `CGAL::Apollonius_graph_hierarchy_vertex_base_2<Agvb>`
-
 */
-
 class ApolloniusGraphHierarchyVertexBase_2 {
 public:
 
@@ -37,8 +32,7 @@ public:
 /// @{
 
 /*!
-Default
+%Default constructor.
-constructor.
 */
 ApolloniusGraphHierarchyVertexBase_2();
 

Apollonius_graph_2/doc/Apollonius_graph_2/Concepts/ApolloniusGraphVertexBase_2.h

@@ -3,8 +3,6 @@
 \ingroup PkgApolloniusGraph2Concepts
 \cgalConcept
 
-\cgalRefines `TriangulationVertexBase_2`
-
 The concept `ApolloniusGraphVertexBase_2` describes the
 requirements for the vertex base class of the
 `ApolloniusGraphDataStructure_2` concept. A vertex stores an
@@ -12,14 +10,14 @@ Apollonius site and provides access to one of its incident faces
 through a `Face_handle`. In addition, it maintains a container of
 sites. The container stores the hidden sites related to the vertex.
 
+\cgalRefines `TriangulationVertexBase_2`
+
 \cgalHasModel `CGAL::Apollonius_graph_vertex_base_2<Gt,StoreHidden>`
 
 \sa `ApolloniusGraphDataStructure_2`
-\sa `ApolloniusGraphTraits_2`
+\sa `CGAL::Apollonius_graph_2<Gt,Agds>`
-\sa `CGAL::Apollonius_graph_vertex_base_2<Gt,StoreHidden>`
+\sa `CGAL::Triangulation_data_structure_2<Vb,Fb>`
-
 */
-
 class ApolloniusGraphVertexBase_2 {
 public:
 
@@ -77,7 +75,7 @@ typedef unspecified_type Hidden_sites_iterator;
 /// @{
 
 /*!
-Default constructor.
+%Default constructor.
 */
 ApolloniusGraphVertexBase_2();
 

Apollonius_graph_2/doc/Apollonius_graph_2/PackageDescription.txt

@@ -43,18 +43,18 @@ aforementioned concepts.
 \cgalCRPSection{Concepts}
 
 - `ApolloniusSite_2`
+- `ApolloniusGraphTraits_2`
 - `ApolloniusGraphDataStructure_2`
 - `ApolloniusGraphVertexBase_2`
-- `ApolloniusGraphTraits_2`
 - `ApolloniusGraphHierarchyVertexBase_2`
 
 \cgalCRPSection{Classes}
 
 - `CGAL::Apollonius_graph_2<Gt,Agds>`
 - `CGAL::Apollonius_site_2<K>`
-- `CGAL::Apollonius_graph_vertex_base_2<Gt,StoreHidden>`
 - `CGAL::Apollonius_graph_traits_2<K,Method_tag>`
 - `CGAL::Apollonius_graph_filtered_traits_2<CK,CM,EK,EM,FK,FM>`
+- `CGAL::Apollonius_graph_vertex_base_2<Gt,StoreHidden>`
 - `CGAL::Apollonius_graph_hierarchy_2<Gt,Agds>`
 - `CGAL::Apollonius_graph_hierarchy_vertex_base_2<Agvb>`
 

Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt

@@ -73,7 +73,7 @@ parameter must be substituted with a type that defines a set of
 geometric-object types, such as point and curve, and a set of
 operations on objects of these types (see Section \ref
 aos_sec-geom_traits); the `Dcel` parameter must be substituted with a
-type that represents a doubly-connected edge list (\sc{Dcel}) data
+type that represents a doubly-connected edge list (\dcel) data
 structure. It defines types of topological object, such as vertices,
 edges, and faces, and the operations required to maintain the
 incidence relations among objects of these types (see Section \ref
@@ -94,7 +94,7 @@ described above; the `TopologyTraits` parameter must be substituted
 with a type that deals with the topology of the surface (see Section
 \ref aos_sec-topol_traits). In particular, it maintains a
 representation of the arrangement graph embedded in the surface using
-a doubly-connected edge list (\sc{Dcel}) data-structure suitable for
+a doubly-connected edge list (\dcel) data-structure suitable for
 the particular topology.
 
 Several member functions and nested types defined in the
@@ -196,7 +196,7 @@ embedding surface plays a significant role. In Section \ref
 arr_ssecnotif we review the notification mechanism that allows
 external classes to keep track of the changes that an arrangement
 instance goes through. Section \ref arr_ssecex_dcel explains how to
-extend the \sc{Dcel} records, to store extra data with them, and to
+extend the \dcel records, to store extra data with them, and to
 efficiently update this data.  In Section \ref arr_ssecoverlay we
 introduce the fundamental operation of overlaying two arrangements.
 Section \ref arr_ssecarr_with_hist describes a class-template that
@@ -215,7 +215,7 @@ We start with a formal definition of two-dimensional arrangements, and
 proceed with an introduction to the data structure used to represent
 the incidence relations among features of two-dimensional
 arrangements, namely, the <em>doubly-connected edge list</em>, or
-\sc{Dcel} for short. In Section \ref aos_ssec-basic-arr_class we
+\dcel for short. In Section \ref aos_ssec-basic-arr_class we
 describe a central component in the \ref PkgArrangementOnSurface2
 package, namely, the `Arrangement_2` class-template, which can be used
 to represent arrangements in the plane.
@@ -267,19 +267,19 @@ C'')\f$. There are possibly more vertices in \f$\cal A(\cal C'')\f$
 than in \f$\cal A(\cal C)\f$---the vertices where curves were cut into
 \f$x\f$-monotone (non-intersecting) pieces; accordingly there may also
 be more edges in \f$\cal A(\cal C'')\f$. This graph can be represented
-using a <em>doubly-connected edge list</em> data-structure
+using a <em>doubly-connected edge list</em> data-structure (\dcel),
-(\sc{Dcel}), which consists of containers of vertices, edges and faces
+which consists of containers of vertices, edges and faces and
-and maintains the incidence relations among these cells. It is one of
+maintains the incidence relations among these cells. It is one of a
-a family of combinatorial data structures called <em>halfedge data
+family of combinatorial data structures called <em>halfedge data
-structures</em> (\sc{Hds}), which are edge-centered data structures
+structures</em> (<span class="textsc">Hds</span>), which are
-capable of maintaining incidence relations among cells of, for
+edge-centered data structures capable of maintaining incidence
-example, planar subdivisions, polyhedra, or other orientable,
+relations among cells of, for example, planar subdivisions, polyhedra,
-two-dimensional surfaces embedded in space of an arbitrary
+or other orientable, two-dimensional surfaces embedded in space of an
-dimension. Geometric interpretation is added by classes built on top
+arbitrary dimension. Geometric interpretation is added by classes
-of the halfedge data structure. In our implementation and in the reset
+built on top of the halfedge data structure. In our implementation and
-of this chapter we use the arrangement \f$\cal A(\cal C')\f$, which is
+in the reset of this chapter we use the arrangement \f$\cal A(\cal
-equal to \f$\cal A(\cal C'')\f$.  Note that \f$\cal A(\cal C) = \cal
+C')\f$, which is equal to \f$\cal A(\cal C'')\f$.  Note that \f$\cal
-A(\cal C')\f$ iff \f$\cal C' == \cal C''\f$.
+A(\cal C) = \cal A(\cal C')\f$ iff \f$\cal C' == \cal C''\f$.
 
 \cgalAdvancedBegin
 
@@ -300,7 +300,7 @@ details.
 
 \cgalAdvancedEnd
 
-The \sc{Dcel} data-structure represents each edge using a pair of
+The \dcel data-structure represents each edge using a pair of
 directed <em>halfedges</em>, one going from the
 \f$xy\f$-lexicographically smaller (left) endpoint of the curve
 towards the \f$xy\f$-lexicographically larger (right) endpoint, and
@@ -317,7 +317,7 @@ incident halfedges.)
 
 An <em>edge</em> of an arrangement is a maximal portion of a curve
 between two vertices of the arrangement. Each edge is represented in
-the \sc{Dcel} by a pair of twin halfedges. Each halfedge \f$e\f$
+the \dcel by a pair of twin halfedges. Each halfedge \f$e\f$
 stores a pointer to its <em>incident face</em>, which is the face lying
 to its left. Moreover, every halfedge is followed by another halfedge
 sharing the same incident face, such that the target vertex of the
@@ -342,13 +342,13 @@ it may contain several faces. Every face can have several inner CCBs
 in its interior, or may not contain inner CCBs at all. In addition,
 every face may contain isolated vertices in its interior.  See
 \cgalFigureRef{aos_fig-arr_segs} for an illustration of the various
-\sc{Dcel} features. For more details on the \sc{Dcel} data structure
+\dcel features. For more details on the \dcel data structure
 see \cgalCite{bkos-cgaa-00} Chapter 2.
 
 <!----------------------------------------------------------------------------->
 \cgalFigureBegin{aos_fig-arr_segs,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
+\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 of several faces. The halfedge \f$ e\f$ is directed
 from its source vertex \f$ v_1\f$ to its target vertex \f$
@@ -417,7 +417,7 @@ the `Arrangement_2` class template; their description follows.
   substituted with `Arr_default_dcel<Traits>` by default, and
   we use this default value in this and in the following three
   sections. However, in many applications it is necessary to
-  extend the \sc{Dcel} features. This is done by substituting the
+  extend the \dcel features. This is done by substituting the
   `Dcel` parameter with a different type; see Section \ref arr_ssecex_dcel
   for further explanations and examples.
 </UL>
@@ -505,7 +505,7 @@ The simplest and most fundamental arrangement operations are the
 various traversal methods, which allow users to systematically go over
 the relevant features of the arrangement at hand.
 
-As mentioned above, the arrangement is represented as a \sc{Dcel},
+As mentioned above, the arrangement is represented as a \dcel,
 which stores three containers of vertices, halfedges and faces; thus,
 the `Arrangement_2` class template supplies iterator types for these
 containers, respectively. For example, if `arr` is an `Arrangement_2`
@@ -841,7 +841,7 @@ examples.
 Illustrations of the various specialized insertion procedures. The
 inserted \f$x\f$-monotone curve is drawn as a dashed line, surrounded
 by two solid arrows that represent the pair of twin halfedges added to
-the \sc{Dcel}. Existing vertices are shown as black discs, while new
+the \dcel. Existing vertices are shown as black discs, while new
 vertices are shown as light discs. Existing halfedges that are
 affected by the insertion operations are drawn as dashed arrows.  (a)
 Inserting a curve as a new hole inside the face \f$f\f$.  (b)
@@ -1402,9 +1402,9 @@ vary according to the user choice.} for answering queries:
   of <em>landmark</em> points, the location of which in the
   arrangement is known. It employs the <em>landmark</em>
   strategy. Given a query point, it uses a nearest-neighbor
-  search-structure (a \sc{Kd}-tree is used by default) to find the
+  search-structure (a <span class="textsc">Kd</span>-tree is used by
-  nearest landmark, and then traverses the straight-line segment
+  default) to find the nearest landmark, and then traverses the
-  connecting this landmark to the query point.
+  straight-line segment connecting this landmark to the query point.
 
   There are various ways to select the landmark set in the
   arrangement. The selection is governed by the `Generator`
@@ -1476,23 +1476,24 @@ trapezoidal map RIC strategy. In addition, although both resulting
 data structures are asymptotically linear in size, the actual amount
 of memory consumed by the landmark algorithm is typically smaller than
 to the amount used by the trapezoidal map RIC algorithm, due to the
-space-efficient \sc{Kd}-tree used by the landmark algorithm as the
+space-efficient <span class="textsc">Kd</span>-tree used by the
-nearest-neighbor search-structure.  The trapezoidal map RIC algorithm
+landmark algorithm as the nearest-neighbor search-structure.  The
-has expected logarithmic query time, while the query time for the
+trapezoidal map RIC algorithm has expected logarithmic query time,
-landmark algorithm may be as large as linear. In practice however, the
+while the query time for the landmark algorithm may be as large as
-query times of both strategies are competitive. For a detailed
+linear. In practice however, the query times of both strategies are
-experimental comparison see \cgalCite{cgal:hh-eplca-05}.
+competitive. For a detailed experimental comparison see
+\cgalCite{cgal:hh-eplca-05}.
 
 Updating the auxiliary data structures of the trapezoidal map RIC
 algorithm is done very efficiently. On the other hand, updating the
 nearest-neighbor search-structure of the landmark algorithm may
 consume significant time when the arrangement changes frequently,
-especially when a \sc{Kd}-tree is used, as it must be rebuilt each
+especially when a <span class="textsc">Kd</span>-tree is used, as it
-time the arrangement changes. It is therefore recommended that the
+must be rebuilt each time the arrangement changes. It is therefore
-`Arr_landmarks_point_location` class template be used when the
+recommended that the `Arr_landmarks_point_location` class template be
-application frequently issues point-location queries on an arrangement
+used when the application frequently issues point-location queries on
-that only seldom changes. If the arrangement is more dynamic and is
+an arrangement that only seldom changes. If the arrangement is more
-frequently going through changes, the
+dynamic and is frequently going through changes, the
 `Arr_trapezoid_ric_point_location` class template should be the
 selected point-location strategy.
 
@@ -2013,7 +2014,7 @@ so it must be construct from scratch.
 (ii) The given arrangement `arr` is not empty.
 
 In the first case, we sweep over the input curves, compute their
-intersection points, and construct the \sc{Dcel} that represents their
+intersection points, and construct the \dcel that represents their
 arrangement. This process is performed in \f$O\left((n + k)\log
 n\right)\f$ time, where \f$k\f$ is the total number of intersection
 points. The running time is asymptotically better than the time needed
@@ -2301,7 +2302,7 @@ introduced.
 
 <!----------------------------------------------------------------------------->
 \cgalFigureBegin{aos_fig-unb_dcel,unb_dcel.png}
-A \sc{Dcel} representing an arrangement of four lines. Halfedges are
+A \dcel representing an arrangement of four lines. Halfedges are
 drawn as thin arrows. The vertices \f$v_1, \ldots, v_8\f$ lie at
 infinity, and are not associated with valid points. The halfedges that
 connect them are fictitious, and are not associated with concrete
@@ -2314,7 +2315,7 @@ represent the four corners of the imaginary bounding rectangle.
 <!----------------------------------------------------------------------------->
 
 Instead of an explicit approach, we use an implicit bounding rectangle
-embedded in the \sc{Dcel} structure. \cgalFigureRef{aos_fig-unb_dcel}
+embedded in the \dcel structure. \cgalFigureRef{aos_fig-unb_dcel}
 shows the arrangement of four lines that subdivide the plane into
 eight unbounded faces and two bounded ones. Notice that in this case
 portions of the the unbounded faces now have outer boundaries (those
@@ -2861,10 +2862,10 @@ one pinch point, is modeled by identifying the vertical and
 identifying the horizontal sides and, in addition, contracting one of
 the pairs. However, the croissant is excluded by our definitions. All
 surfaces supported by our framework are locally homeomorphic to a
-disk, and hence an \sc{Dcel} data-structure suffices for representing
+disk, and hence an \dcel data-structure suffices for representing
 arrangements on these surfaces. The croissant is, at the pinch point,
 not locally homeomorphic to a disk, and hence a more general
-cell-tuple data structure than an \sc{Dcel} would be needed.
+cell-tuple data structure than an \dcel would be needed.
 
 A curve \f$\gamma\f$ is a continuous function \f$\gamma: I \rightarrow
 \Phi\f$, where \f$I\f$ is an open, half-open, or closed interval with
@@ -3173,12 +3174,13 @@ class, thereby extending it.
 
 A hierarchy of related concepts can be viewed as a directed acyclic
 graph, where a node of the graph represents a concept and an arc
-represents a refinement relation. An arc directed from concept \sc{A}
+represents a refinement relation. An arc directed from concept <span
-to concept \sc{B} indicates that concept \sc{B} refines concept
+class="textsc">A</span> to concept <span class="textsc">B</span>
-\sc{A}.  A rather large direccted acyclic graph is required to capture
+indicates that concept <span class="textsc">B</span> refines concept
-the entire hierarchy of the geometry traits-class concepts. In the
+<span class="textsc">A</span>.  A rather large direccted acyclic graph
-following sections we review individual clusters of the graph and
+is required to capture the entire hierarchy of the geometry
-describe the relations between them.
+traits-class concepts. In the following sections we review individual
+clusters of the graph and describe the relations between them.
 \cgalFigureRef{aos_fig-central_concept_cluster} depicts the central
 cluster.
 
@@ -3555,7 +3557,7 @@ class that models the combined concept
 \cgalFigureRef{aos_fig-open_concept_hierarchy} can handle curves that
 are open in any direction. Recall that an arrangement that supports
 unbounded \f$x\f$-monotone curves maintains an implicit bounding
-rectangle in the \sc{Dcel} structure; see Section \ref
+rectangle in the \dcel structure; see Section \ref
 aos_sec-unbounded. If some curves inserted into an arrangement object
 are expected to be unbounded; namely, there exists \f$d \in \{0,1\}\f$
 such that \f$\lim_{t \rightarrow d}x(t) = \pm\infty\f$ or \f$\lim_{t
@@ -4648,9 +4650,9 @@ these types, solving quadratic equations, and extracting the real
 roots of polynomials with integer coefficients. The use of the
 `CORE_algebraic_number_traits` class, which is included in the
 arrangement package, is highly recommended. The traits class-template
-relies on the multi-precision number types implemented in the
+relies on the multi-precision number types implemented in the <span
-\sc{Core} library and performs exact computations on the number types
+class="textsc">Core</span> library and performs exact computations on
-it defines.
+the number types it defines.
 
 </UL>
 
@@ -4658,10 +4660,11 @@ The instantiation of the conic traits class-template is slightly more
 complicated than the instantiation of the traits classes you have
 encountered so far. This instantiation is exemplified in the header
 file `arr_conics.h`. Note how we first define the rational and
-algebraic kernels using the number types given by the \sc{Core} number
+algebraic kernels using the number types given by the <span
-type traits-class, then use them to define the conic traits
+class="textsc">Core</span> number type traits-class, then use them to
-class-template. Also note the types defined by the rational kernels,
+define the conic traits class-template. Also note the types defined by
-which we need for conveniently constructing conic arcs.
+the rational kernels, which we need for conveniently constructing
+conic arcs.
 
 The `Arr_conic_traits_2` models the `ArrangementTraits_2` and
 `ArrangementLandmarkTraits_2` concepts. Its \link
@@ -5351,7 +5354,7 @@ to the geometric objects (curves and to points). The data is
 automatically manipulated by the decorators and distributed to the
 constructed geometric entities. Additional information can
 alternatively be maintained by extending the vertex, halfedge, or face
-types provided by the \sc{Dcel} class used by the arrangement; see
+types provided by the \dcel class used by the arrangement; see
 Section \ref arr_ssecex_dcel for details. In many cases, however, it is
 convenient to attach the data to the curve itself, exploiting the
 automatic proliferation of the additional data fields from each curve
@@ -5526,7 +5529,7 @@ handle these topological entities, used by the
 `Arrangement_on_surface_2<GeometryTraits_2, TopologyTraits>` class
 template and by the peripheral modules. Every topology traits class
 must model the basic concept `ArrangementBasicTopologyTraits`. A model
-of this basic concept holds the (\sc{Dcel}) data structure used to
+of this basic concept holds the (\dcel) data structure used to
 represent the arrangement cells (i.e., vertices, edges, and facets)
 and the incidence relations between them. At this point we do not
 expose the concepts that refine the basic concept. The package
@@ -5714,7 +5717,7 @@ of \f$e_v\f$.
 
 \cgalExample{Arrangement_on_surface_2/observer.cpp}
 
-Observers are especially useful when the \sc{Dcel} records are
+Observers are especially useful when the \dcel records are
 extended and store additional data-fields, since they help update
 this data stored in these fields, as the following sections reveal.
 
@@ -5732,21 +5735,21 @@ Arrangement_on_surface_2::X_monotone_curve_2
 class. Extending the geometric traits-class types by using a
 traits-class decorator, as explained in Section \ref arr_ssecmeta_tr,
 might be a sufficient solution for some applications.  However, the
-\sc{Dcel} faces are not associated with any geometric object, so
+\dcel faces are not associated with any geometric object, so
-traits-class decorators cannot help here. Extending the \sc{Dcel} face
+traits-class decorators cannot help here. Extending the \dcel face
 records comes in handy is such cases. As a matter of fact, it is
-possible to conveniently extend all \sc{Dcel} records (namely
+possible to conveniently extend all \dcel records (namely
 vertices, halfedges, and faces), which is advantageous for some
 applications.
 
-All examples presented so far use the default \sc{Dcel}; namely, they
+All examples presented so far use the default \dcel; namely, they
 employ the `Arr_default_dcel<Traits>` instance. This is done
 implicitly, as an instance of this class template serves as the
 default parameter for the `Arrangement_2` class template; see Section
-\ref aos_ssec-basic-arr_class. The default \sc{Dcel} class associates
+\ref aos_ssec-basic-arr_class. The default \dcel class associates
 points with vertices and \f$x\f$-monotone curves with halfedges, but
 nothing more.  In this section we show how to use alternative
-\sc{Dcel} types to extend the desired \sc{Dcel} records.
+\dcel types to extend the desired \dcel records.
 
 <!----------------------------------------------------------------------------->
 \subsubsection arr_sssecex_dcel_face Extending the DCEL Faces
@@ -5754,8 +5757,8 @@ nothing more.  In this section we show how to use alternative
 
 The `Arr_face_extended_dcel<Traits, FaceData>` class-template is used
 to associate auxiliary data field of type `FaceData` to each face
-record in the \sc{Dcel}.  When the `Arrangement_2<Traits,Dcel>` class
+record in the \dcel.  When the `Arrangement_2<Traits,Dcel>` class
-template is instantiated, substituting the \sc{Dcel} parameter with an
+template is instantiated, substituting the \dcel parameter with an
 instance of this class template, the interface of the nested `Face`
 type is extended with the access function `data()` and with the
 modifier `set_data()`. Using these extra functions it is
@@ -5807,15 +5810,15 @@ crucial. Perhaps less common, but also important to satisfy, is the
 need to extend the vertex and halfedge records as well. The
 `Arr_extended_dcel<Traits, VertexData, HalfedgeData, FaceData>`
 class-template is used to associate auxiliary data fields of types
-`VertexData`, `HalfedgeData`, and `FaceData` with \sc{Dcel} vertex,
+`VertexData`, `HalfedgeData`, and `FaceData` with \dcel vertex,
 halfedge, and face record types, respectively.  When the
 `Arrangement_2<Traits,Dcel>` class template is instantiated,
-substituting the `Dcel` parameter with an instance of this \sc{Dcel}
+substituting the `Dcel` parameter with an instance of this \dcel
 class-template, the interfaces of the nested types Vertex, Halfedge,
 and Face are extended with the access function `data()` and with the
 modifier `set_data()`.
 
-The next example shows how to use a \sc{Dcel} with extended vertex,
+The next example shows how to use a \dcel with extended vertex,
 halfedge, and face records. In this example each vertex is associated
 with a color, which is either blue, red, or white, depending on whether
 the vertex is isolated, represents a segment endpoint, or represents
@@ -5840,19 +5843,19 @@ arrangement object.
 
 \cgalAdvancedBegin
 
-The various \sc{Dcel} classes presented in this section are well
+The various \dcel classes presented in this section are well
 suited for most applications based on the \ref
 PkgArrangementOnSurface2 package. They are all defined using helper
-constructs, and in particular the base \sc{Dcel} class-template
+constructs, and in particular the base \dcel class-template
 `Arr_dcel_base}`.  However, there are cases where special
-requirements, not addressed by these \sc{Dcel} classes, are needed.
+requirements, not addressed by these \dcel classes, are needed.
-In such cases you may explicitly extend the base \sc{Dcel}
+In such cases you may explicitly extend the base \dcel
 class-template, as described in the next paragraph, or implement your
-own \sc{Dcel} class from scratch and use the resulting \sc{Dcel} to
+own \dcel class from scratch and use the resulting \dcel to
 instantiate the `Arrangement_2` class template. In any case such a
 class must model the concept `ArrangementDcel` or its refinement
 `ArrangementDcelWithRebind`. The latter requires a `rebind` struct
-template, which implements a policy-clone idiom. Here, the \sc{Dcel}
+template, which implements a policy-clone idiom. Here, the \dcel
 class is the policy class and the `rebind` member template struct
 is used to pass a different traits type parameter to the policy class
 template.
@@ -5878,7 +5881,7 @@ due to compiler padding.\cgalFootnote{Compilers add pad bytes into
 user-defined constructs to comply with alignment restrictions imposed
 by target microprocessors.} Moreover, the code may look cumbersome.
 
-The extended \sc{Dcel} class that addresses the problem raised above
+The extended \dcel class that addresses the problem raised above
 is listed below. Here, each feature type is explicitly extended with
 two strings, namely, `name` and `type`, eliminating the data
 constructs.
@@ -5953,7 +5956,7 @@ efficient process. For example, monochromatic intersections are not
 computed.
 
 The plane-sweep visitor that concretizes the overlay operation needs
-to construct a \sc{Dcel} that properly represents the overlay of two
+to construct a \dcel that properly represents the overlay of two
 input arrangements. A face in the overlay arrangement corresponds to
 overlapping regions of the blue and red faces. An edge in the overlay
 arrangement is due to a blue edge, a red edge, or an overlap of two
@@ -5977,10 +5980,10 @@ same geometry-traits class.
 
 The `overlay()` function template is suitable for
 arrangements that do not store any additional data with their
-\sc{Dcel} records; namely, arrangements defined using an instance of
+\dcel records; namely, arrangements defined using an instance of
-the default \sc{Dcel} class-template `Arr_default_dcel`. Typically,
+the default \dcel class-template `Arr_default_dcel`. Typically,
 the overlay arrangement in this case does not store extra data with
-its \sc{Dcel} records as well (or if it does, the additional
+its \dcel records as well (or if it does, the additional
 data-fields cannot be computed by the overlay operation). The overlay
 arrangement is equivalent to the arrangement induced by all curves of
 `arr_r` and `arr_b`. Indeed, it is possible to obtain the same result
@@ -6022,7 +6025,7 @@ We distinguish between (i) an overlay of two arrangements that store
 additional data-fields only with their faces e.g., the geographic-map
 example given at the beginning of this section) and (ii) an overlay of
 two arrangements that store additional data fields with all their
-\sc{Dcel} records (or at least not only with their faces).  The
+\dcel records (or at least not only with their faces).  The
 arrangement that results from overlaying two face-extended
 arrangements typically also stores additional data-fields with its
 faces. The types of such arrangements, for example, could be instances
@@ -6033,8 +6036,8 @@ arr_sssecex_dcel_face). The data field that is attached to an overlay
 face can be computed from the data fields of the two faces (in `arr_r`
 and `arr_b`) that induce the overlay face. Similarly, the arrangement
 that results from overlaying two arrangements that store additional
-data fields with all their \sc{Dcel} records typically also stores
+data fields with all their \dcel records typically also stores
-additional data-fields with all its \sc{Dcel} records. The types of
+additional data-fields with all its \dcel records. The types of
 such arrangements, for example, could be instances of the
 `Arrangement_2<Traits,Dcel>` class template, where the `Dcel`
 parameters are substituted with instances of the `Arr_extended_dcel`
@@ -6043,7 +6046,7 @@ attached to an overlay feature can be computed from the data fields of
 the two features (in `arr_r` and `arr_b`) that induce the overlay
 feature.
 
-As mentioned in the previous paragraph, if any of the \sc{Dcel}
+As mentioned in the previous paragraph, if any of the \dcel
 records of your arrangements are extended, you can pass a fourth
 argument to the `overlay()` call, also referred to as the overlay
 traits, to control the generation of the extended data in the
@@ -6061,8 +6064,8 @@ overlay faces.
 
 The following example shows how to compute the intersection of two
 polygons using the `overlay()` function template. It uses a
-face-extended \sc{Dcel} type to instantiate the arrangement
+face-extended \dcel type to instantiate the arrangement
-classes. Each face of the the \sc{Dcel} is extended with a Boolean
+classes. Each face of the the \dcel is extended with a Boolean
 flag. A polygon is represented as a <em>marked</em> arrangement face
 (whose flag is set). The example uses an instance of the
 `Arr_face_overlay_traits<ArrR,ArrB,ArrO,OverlayFaceData>` class
@@ -6105,8 +6108,8 @@ into strings to produce the final labels.
 \cgalExample{Arrangement_on_surface_2/overlay_unbounded.cpp}
 
 If the red and blue arrangements store additional data-fields with all
-their \sc{dcel} records, and the data associated with the overlay
+their \dcel records, and the data associated with the overlay
-\sc{dcel} features should be computed from the red and blue \sc{dcel}
+\dcel features should be computed from the red and blue \dcel
 features that induce it, then an appropriate overlay-traits argument
 must be passed to the `overlay()` call. The overlay-traits type models
 the `OverlayTraits` concept, which requires the provision of ten
@@ -6249,7 +6252,7 @@ arbitrary two-dimensional curves, you end up with a collection \f$\cal
 C''\f$ of \f$x\f$-monotone subcurves of \f$\cal C\f$ that are pairwise
 disjoint in their interior; see Section \ref aos_sec-intro. These
 subcurves are associated with the arrangement edges (more precisely,
-with pairs of \sc{Dcel} halfedges). The connection between the
+with pairs of \dcel halfedges). The connection between the
 originating input curves and the arrangement edges is lost during the
 construction process. This loss might be acceptable for some
 applications. However, in many practical cases it is important to
@@ -6272,8 +6275,8 @@ its subdivision into \link
 ArrangementBasicTraits_2::X_monotone_curve_2
 `X_monotone_curve_2`\endlink objects, among the others.  The `Dcel`
 parameter must be substituted with a model of the `ArrangementDcel`
-concept. You can use either the default \sc{Dcel} class or an extended
+concept. You can use either the default \dcel class or an extended
-\sc{Dcel} class (see Section \ref arr_ssecex_dcel) based on your
+\dcel class (see Section \ref arr_ssecex_dcel) based on your
 needs. An arrangement that support the cross-mapping mentioned above
 is referred to as an arrangement with history. In the following we use
 the `Arrangement_with_history_2<>` class template to demonstrate
@@ -6354,7 +6357,7 @@ arrangement stores a consolidated container of input curves, and
 automatically preserves the cross-mapping between the arrangement
 edges and the consolidated curve-set. You may also employ an
 overlay-traits class to maintain any type of auxiliary data stored
-with the \sc{Dcel} cells; see Section \ref arr_ssecoverlay.
+with the \dcel cells; see Section \ref arr_ssecoverlay.
 
 <!----------------------------------------------------------------------------->
 \subsubsection arr_sssecmodif_traverse Modifying an Arrangement with History
@@ -6534,7 +6537,7 @@ the arrangement features. Thus, they are ideal for arrangements
 instantiated using the `Arr_default_dcel` class.
 However, as explained in Section \ref arr_ssecex_dcel, one can easily
 extend the arrangement faces by using the `Arr_face_extended_dcel`
-template, or extend all \sc{Dcel} records by using the `Arr_extended_dcel`
+template, or extend all \dcel records by using the `Arr_extended_dcel`
 template. In such cases, it might be crucial that the auxiliary data fields
 are written to the file and read from there.
 
@@ -6551,13 +6554,13 @@ auxiliary data that may be associated with the arrangement features.
 This is the default formatter used by the arrangement inserter and the
 arrangement extractor, as defined above.
 <LI>`Arr_face_extended_text_formatter<Arrangement>` operates on
-arrangements whose \sc{Dcel} representation is based on the
+arrangements whose \dcel representation is based on the
 `Arr_face_extended_dcel<Traits,FaceData>` class (see
 Section \ref arr_sssecex_dcel_face). It supports reading and writing
 the auxiliary data objects stored with the arrangement faces provided
 that the `FaceData` class supports an inserter and an extractor.
 <LI>`Arr_extended_dcel_text_formatter<Arrangement>` operates on
-arrangements whose \sc{Dcel} representation is based on the
+arrangements whose \dcel representation is based on the
 `Arr_extended_dcel<Traits,VertexData,HalfedgeData,FaceData>` class
 (see Section \ref arr_sssecex_dcel_all). It supports reading and writing
 the auxiliary data objects stored with the arrangement vertices, edges
@@ -6625,37 +6628,40 @@ and defines a simple textual input/output format.
 \section aos_sec-bgl Adapting to Boost Graphs
 <!--=========================================================================-->
 
-\sc{Boost}\cgalFootnote{See also \sc{Boost}'s homepage at:
+<span class="textsc">Boost</span>\cgalFootnote{See also <span
-<TT>www.boost.org</TT>.}  is a collection of portable \cpp libraries
+class="textsc">Boost</span>'s homepage at: <TT>www.boost.org</TT>.}
-that extend the \cpp Standard Library. The \sc{Boost} Graph Library
+is a collection of portable \cpp libraries that extend the \cpp
-(\sc{bgl}), which one of the libraries in the collection, offers an
+Standard Library. The <span class="textsc">Boost</span> Graph Library
-extensive set of generic graph algorithms parameterized through
+(<span class="textsc">bgl</span>), which one of the libraries in the
-templates.  As our arrangements are embedded as planar graphs, it is
+collection, offers an extensive set of generic graph algorithms
-only natural to extend the underlying data structure with the
+parameterized through templates.  As our arrangements are embedded as
-interface that the <\sc{bgl} expects, and gain the ability to perform
+planar graphs, it is only natural to extend the underlying data
-the operations that the \sc{bgl} supports, such as shortest-path
+structure with the interface that the <span class="textsc">bgl</span>
+expects, and gain the ability to perform the operations that the <span
+class="textsc">bgl</span> supports, such as shortest-path
 computation. This section describes how to apply the graph algorithms
-implemented in the \sc{bgl} to `Arrangement_2` instances.
+implemented in the <span class="textsc">bgl</span> to `Arrangement_2`
+instances.
 
-An instance of `Arrangement_2` is adapted to a \sc{Boost} graph
+An instance of `Arrangement_2` is adapted to a <span
-through the provision of a set of free functions that operate on the
+class="textsc">Boost</span> graph through the provision of a set of
-arrangement features and conform with the relevant BGL
+free functions that operate on the arrangement features and conform
-concepts. Besides the straightforward adaptation, which associates a
+with the relevant BGL concepts. Besides the straightforward
-vertex with each \sc{Dcel} vertex and an edge with each \sc{Dcel}
+adaptation, which associates a vertex with each \dcel vertex and an
-halfedge, the package also offer a <em>dual</em> adaptor, which
+edge with each \dcel halfedge, the package also offer a <em>dual</em>
-associates a graph vertex with each \sc{Dcel} face, such that two
+adaptor, which associates a graph vertex with each \dcel face, such
-vertices are connected, iff there is a \sc{Dcel} halfedge that
+that two vertices are connected, iff there is a \dcel halfedge that
 connects the two corresponding faces.
 
 <!----------------------------------------------------------------------------->
 \subsection arr_ssecbgl_primal The Primal Arrangement Representation
 <!----------------------------------------------------------------------------->
 
-Arrangement instances are adapted to \sc{Boost} graphs by specializing
+Arrangement instances are adapted to <span class="textsc">Boost</span>
-the \link BGLArgtGT `boost:graph_traits` \endlink template for
+graphs by specializing the \link BGLArgtGT `boost:graph_traits`
-`Arrangement_2` instances. The graph-traits states the graph concepts
+\endlink template for `Arrangement_2` instances. The graph-traits
-that the arrangement class models (see below) and defines the types
+states the graph concepts that the arrangement class models (see
-required by these concepts.
+below) and defines the types required by these concepts.
 
 In this specialization the `Arrangement_2` vertices correspond to the
 graph vertices, where two vertices are adjacent if there is at least
@@ -6668,13 +6674,13 @@ to be directed as well. Moreover, as several interior-disjoint
 \f$x\f$-monotone curves (say circular arcs) may share two common
 endpoints, inducing an arrangement with two vertices that are
 connected with several edges, we allow parallel edges in our
-\sc{Boost} graph.
+<span class="textsc">Boost</span> graph.
 
 Given an `Arrangement_2` instance, we can efficiently traverse its
 vertices and halfedges. Thus, the arrangement graph is a model of the
-concepts `VertexListGraph` and `EdgeListGraph` introduced by the
+concepts `VertexListGraph` and `EdgeListGraph` introduced by the <span
-\sc{bgl}.  At the same time, we use an iterator adapter of the
+class="textsc">bgl</span>.  At the same time, we use an iterator
-circulator over the halfedges incident to a vertex
+adapter of the circulator over the halfedges incident to a vertex
 (`Halfedge_around_vertex_circulator` - see Section \ref
 arr_sssectr_vertex), so it is possible to go over the ingoing and
 outgoing edges of a vertex in linear time. Thus, our arrangement graph
@@ -6685,24 +6691,26 @@ edges).
 It is important to notice that the vertex descriptors we use are \link
 Arrangement_2 Vertex_handle `Vertex_handle`\endlink objects and
 <em>not</em> vertex indices. However, in order to gain more efficiency
-in most \sc{bgl} algorithms, it is better to have them indexed \f$0,
+in most <span class="textsc">bgl</span> algorithms, it is better to
-1, \ldots, (n-1)\f$, where \f$n\f$ is the number of vertices. We
+have them indexed \f$0, 1, \ldots, (n-1)\f$, where \f$n\f$ is the
-therefore introduce the `Arr_vertex_index_map<Arrangement>`
+number of vertices. We therefore introduce the
-class-template, which maintains a mapping of vertex handles to
+`Arr_vertex_index_map<Arrangement>` class-template, which maintains a
-indices, as required by the \sc{bgl}. An instance of this class must
+mapping of vertex handles to indices, as required by the <span
-be attached to a valid arrangement vertex when it is created. It uses
+class="textsc">bgl</span>. An instance of this class must be attached
-the notification mechanism (see Section \ref arr_ssecnotif) to
+to a valid arrangement vertex when it is created. It uses the
+notification mechanism (see Section \ref arr_ssecnotif) to
 automatically maintain the mapping of vertices to indices, even when
 new vertices are inserted into the arrangement or existing vertices
 are removed.
 
-In most algorithms provided by the \sc{bgl}, the output is given by
+In most algorithms provided by the <span class="textsc">bgl</span>,
-<em>property maps</em>, such that each map entry corresponds to a
+the output is given by <em>property maps</em>, such that each map
-vertex.  For example, when we compute the shortest paths from a given
+entry corresponds to a vertex.  For example, when we compute the
-source vertex \f$s\f$ to all other vertices we can obtain a map of
+shortest paths from a given source vertex \f$s\f$ to all other
-distances and a map of predecessors - namely for each \f$v\f$ vertex
+vertices we can obtain a map of distances and a map of predecessors -
-we have its distance from \f$s\f$ and a descriptor of the vertex that
+namely for each \f$v\f$ vertex we have its distance from \f$s\f$ and a
-precedes \f$v\f$ in a shortest path from \f$s\f$.
+descriptor of the vertex that precedes \f$v\f$ in a shortest path from
+\f$s\f$.
 
 If the vertex descriptors are simply indices, boost supplies tools to
 easily represent property maps using vectors.  The
@@ -6714,8 +6722,8 @@ mapping from \link Arrangement_on_surface_2::Vertex_handle
 however, that unlike the `Arr_vertex_index_map` class template, the
 vertex property-map class is not kept synchronized with the number of
 vertices in the arrangement, so it should not be reused in calls to
-\sc{bgl} functions in case the arrangement is modified in between
+<span class="textsc">bgl</span> functions in case the arrangement is
-these calls.
+modified in between these calls.
 
 The first example of this section demonstrates the application of
 Dijkstra's shortest path algorithm to compute the shortest-path length
@@ -6724,8 +6732,9 @@ other vertices. The length of a path is defined as the sum of squared
 Euclidean lengths of its segments. It uses an instance of the functor
 template `Edge_length<Arrangement>}` to compute the squared Euclidean
 length of the linear curve associated with a given halfedge of the
-arrangement. The functor implements a \sc{Boost} property-map that
+arrangement. The functor implements a <span
-attaches square lengths to edges; when the \sc{bgl} algorithm queries
+class="textsc">Boost</span> property-map that attaches square lengths
+to edges; when the <span class="textsc">bgl</span> algorithm queries
 the property map for a squared length of an edge the property map
 computes and returns it. The functor template is defined in the header
 file `Edge_length.h`.
@@ -6765,15 +6774,16 @@ An arrangement of seven line segments, as constructed by
 
 In the following example we construct an arrangement of seven line
 segments, as shown in \cgalFigureRef{aos_fig-bgl_primal_adapter}.
-Then, it uses the \sc{bgl} generic implementation of Dijkstra's
+Then, it uses the <span class="textsc">bgl</span> generic
-shortest-paths algorithm to compute the sum of squared distances to
+implementation of Dijkstra's shortest-paths algorithm to compute the
-all vertices from the lexicographically smallest vertex \f$v_0\f$ in
+sum of squared distances to all vertices from the lexicographically
-the arrangement. Note the usage of the `Arr_vertex_property_map` class
+smallest vertex \f$v_0\f$ in the arrangement. Note the usage of the
-template in the call to `boost::dijkstra_shortest_paths()` and in the
+`Arr_vertex_property_map` class template in the call to
-definition of the distance property-map. We instantiate a property map
+`boost::dijkstra_shortest_paths()` and in the definition of the
-that attaches a number of type `Number_type` (which is a type of
+distance property-map. We instantiate a property map that attaches a
-unlimited precision) to each vertex. The number represents the sum of
+number of type `Number_type` (which is a type of unlimited precision)
-squared distances of the vertex from $v_0$.
+to each vertex. The number represents the sum of squared distances of
+the vertex from $v_0$.
 
 \cgalExample{Arrangement_on_surface_2/bgl_primal_adapter.cpp}
 
@@ -6792,15 +6802,16 @@ dual interpretation to an arrangement instance.
 
 In a dual representation, \link Arrangement_on_surface_2::Face_handle
 `Face_handle`\endlink is the graph-vertex type, while \link
-Arrangement_on_surface_2::Halfedge_handle `Halfedge_handle`\endlink is the
+Arrangement_on_surface_2::Halfedge_handle `Halfedge_handle`\endlink is
-graph-edge type. We treat the graph edges as directed, such that a
+the graph-edge type. We treat the graph edges as directed, such that a
 halfedge `e` is directed from \f$f_1\f$, which is its incident face,
 to \f$f_2\f$, which is the incident face of its twin halfedge. As two
 arrangement faces may share more than a single edge on their boundary,
-we allow parallel edges (loops) in our \sc{Boost} graph. As is the
+we allow parallel edges (loops) in our <span
-case in the primal graph, the dual arrangement graph is also a model
+class="textsc">Boost</span> graph. As is the case in the primal graph,
-of the concepts `VertexListGraph`, `EdgeListGraph` and
+the dual arrangement graph is also a model of the concepts
-`BidirectionalGraph` (thus also of `IncidenceGraph`).
+`VertexListGraph`, `EdgeListGraph` and `BidirectionalGraph` (thus also
+of `IncidenceGraph`).
 
 Since we use \link Arrangement_on_surface_2::Face_handle
 `Face_handle`\endlink objects as the vertex descriptors, we define the
@@ -6859,7 +6870,7 @@ the program coded in \ref
 Arrangement_on_surface_2/bgl_primal_adapter.cpp; see
 \cgalFigureRef{aos_fig-bgl_primal_adapter}. Then, it performs a
 breadth-first search traversal on the face graph, starting from the
-unbounded face. The \sc{Dcel} faces are extended with an unsigned
+unbounded face. The \dcel faces are extended with an unsigned
 integer indicating the discovered time of the face. The code uses a
 visitor that obtains the times and writes them into a property map
 that updates the faces
@@ -6889,7 +6900,7 @@ insertion-functions instead of the general ones; e.g., `insert()`.
 
 <LI>When the curves to be inserted into an arrangement are segments that
 are pairwise disjoint in their interior, it is more efficient to use
-the traits class `Arr_non_caching_segment_traits_2` rather then
+the traits class `Arr_non_caching_segment_traits_2` rather than
 the default one (`Arr_segment_traits_2`).
 
 If the segments may intersect each other, the default traits class
@@ -6900,7 +6911,8 @@ On rare occasions the traits class `Arr_non_caching_segment_traits_2`
 exhibits slightly better performance than the default one
 (`Arr_segment_traits_2` even when the segments intersect each other,
 due to the small overhead of the latter (optimized) traits class. (For
-example, when the so-called \sc{Leda} rational kernel is used.)
+example, when the so-called <span class="textsc">Leda</span> rational
+kernel is used.)
 
 <LI>Prior knowledge of the combinatorial structure of the arrangement
 can be used to accelerate operations that insert \f$x\f$-monotone
@@ -6912,7 +6924,7 @@ the arrangement. The specialized insertion functions, i.e.,
 `Arrangement_on_surface_2::insert_at_vertices()` can be used according
 to the available information. These functions hardly involve any
 geometric operations, if at all. They accept topologically related
-parameters, and use them to operate directly on the \sc{Dcel} records,
+parameters, and use them to operate directly on the \dcel records,
 thus saving algebraic operations, which are especially expensive when
 high-degree curves are involved.
 

Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_polycurve_traits_2.h

@@ -408,7 +408,7 @@ namespace CGAL {
       size_type number_of_subcurves() const;
 
       /*! Obtain the \f$ k\f$th subcurve of the polycurve.
-       * \pre \f$k\f$ is not greater then or equal to \f$n-1\f$, where
+       * \pre \f$k\f$ is not greater than or equal to \f$n-1\f$, where
        *      \f$n\f$ is the number of subcurves.
        */
       typename SubcurveTraits_2::X_monotone_curve_2

Arrangement_on_surface_2/include/CGAL/Arr_dcel_base.h

@@ -479,7 +479,18 @@ public:
   const Inner_ccb* inner_ccb() const
   {
     CGAL_precondition(is_on_inner_ccb());
-    return (reinterpret_cast<const Inner_ccb*>(_clean_pointer(this->p_comp)));
+
+    const Inner_ccb* out = reinterpret_cast<const Inner_ccb*>(_clean_pointer(this->p_comp));
+    if (out->is_valid())
+      return out;
+
+    // else reduce path and get valid iccb
+    const Inner_ccb* valid = out->next();
+    while (!valid->is_valid())
+      valid = valid->next();
+    const_cast<Inner_ccb*>(out)->set_next(const_cast<Inner_ccb*>(valid));
+    const_cast<Halfedge*>(this)->set_inner_ccb(valid);
+    return valid;
   }
 
   /*! Obtain an incident inner CCB (non-const version).
@@ -488,11 +499,28 @@ public:
   Inner_ccb* inner_ccb()
   {
     CGAL_precondition(is_on_inner_ccb());
-    return (reinterpret_cast<Inner_ccb*>(_clean_pointer(this->p_comp)));
+
+    Inner_ccb* out = reinterpret_cast<Inner_ccb*>(_clean_pointer(this->p_comp));
+    if (out->is_valid())
+      return out;
+
+    // else reduce path and get valid iccb
+    Inner_ccb* valid = out->next();
+    while (!valid->is_valid())
+      valid = valid->next();
+    out->set_next(valid);
+    set_inner_ccb(valid);
+    return valid;
+  }
+
+  Inner_ccb* inner_ccb_no_redirect()
+  {
+    CGAL_precondition(is_on_inner_ccb());
+    return reinterpret_cast<Inner_ccb*>(_clean_pointer(this->p_comp));
   }
 
   /*! Set the incident inner CCB. */
-  void set_inner_ccb(Inner_ccb *ic)
+  void set_inner_ccb(const Inner_ccb *ic)
   {
     // Set the component pointer and set its LSB.
     this->p_comp = _set_lsb(ic);
@@ -769,18 +797,29 @@ public:
   typedef typename Face::Inner_ccb_iterator  Inner_ccb_iterator;
 
 private:
-  Face* p_f;                  // The face the contains the CCB in its interior.
+  union
+  {
+    Face* f;                  // The face the contains the CCB in its interior.
+    Arr_inner_ccb* icc;       // next inner CCB in chain to valid icc
+  } f_or_icc;
   Inner_ccb_iterator  iter;   // The inner CCB identifier.
-  bool iter_is_not_singular;
+  enum
+  {
+    ITER_IS_SINGULAR,     // singular = default iterator, not initialized
+    ITER_IS_NOT_SINGULAR, // not singular = iterator was assigned and is valid
+    INVALID               // invalid = the inner CCB is invalid and
+                          //           only links to another inner CCB
+                          //           in chain to valid CCB
+  } status;
 
 public:
   /*! Default constructor. */
-  Arr_inner_ccb() : p_f(nullptr), iter_is_not_singular(false) {}
+  Arr_inner_ccb() : status(ITER_IS_SINGULAR) { f_or_icc.f = nullptr; }
 
   /*! Copy constructor. */
   Arr_inner_ccb(const Arr_inner_ccb& other) :
-    p_f(other.p_f), iter_is_not_singular(other.iter_is_not_singular)
+    f_or_icc(other.f_or_icc), status(other.status)
-  { if (other.iter_is_not_singular) iter = other.iter; }
+  { if (other.status == ITER_IS_NOT_SINGULAR) iter = other.iter; }
 
   /*! Obtain a halfedge along the component (const version). */
   const Halfedge* halfedge() const { return (*iter); }
@@ -789,7 +828,11 @@ public:
   Halfedge* halfedge() { return (*iter); }
 
   /*! Set a representative halfedge for the component. */
-  void set_halfedge(Halfedge *he) { *iter = he; }
+  void set_halfedge(Halfedge *he)
+  {
+    CGAL_assertion (is_valid());
+    *iter = he;
+  }
 
   /*! Obtain the incident face (const version). */
   const Face* face() const { return (p_f); }
@@ -798,28 +841,51 @@ public:
   Face* face() { return (p_f); }
 
   /*! Set the incident face. */
-  void set_face(Face* f) { p_f = f; }
+  void set_face(Face* f)
+  {
+    CGAL_assertion (status != INVALID);
+    f_or_icc.f = f;
+  }
 
   /*! Obtain the iterator (const version). */
   Inner_ccb_iterator iterator() const
   {
-    CGAL_assertion(iter_is_not_singular);
+    CGAL_assertion(status == ITER_IS_NOT_SINGULAR);
     return (iter);
   }
 
   /*! Obtain the iterator (non-const version). */
   Inner_ccb_iterator iterator()
   {
-    CGAL_assertion(iter_is_not_singular);
+    CGAL_assertion(status == ITER_IS_NOT_SINGULAR);
     return (iter);
   }
 
   /*! Set the inner CCB iterator. */
   void set_iterator(Inner_ccb_iterator it)
   {
+    CGAL_assertion (is_valid());
     iter = it;
-    iter_is_not_singular = true;
+    status = ITER_IS_NOT_SINGULAR;
   }
+
+  /*! Check validity */
+  bool is_valid() const { return (status != INVALID); }
+
+  /*! Get the next CCB to primary chain. */
+  Arr_inner_ccb* next() const
+  {
+    CGAL_assertion (status == INVALID);
+    return f_or_icc.icc;
+  }
+
+  /*! Set the next CCB to primary chain. */
+  void set_next(Arr_inner_ccb* next)
+  {
+    status = INVALID;
+    f_or_icc.icc = next;
+  }
+
 };
 
 /*! \class
@@ -943,6 +1009,7 @@ public:
   typedef typename Face_list::iterator                Face_iterator;
   typedef CGAL::N_step_adaptor_derived<Halfedge_iterator, 2>
                                                       Edge_iterator;
+  typedef typename Inner_ccb_list::iterator           Inner_ccb_iterator;
 
   // Definitions of const iterators.
   typedef typename Vertex_list::const_iterator        Vertex_const_iterator;
@@ -1019,6 +1086,9 @@ public:
   {
     return make_prevent_deref_range(edges_begin(), edges_end());
   }
+
+  Inner_ccb_iterator inner_ccbs_begin() { return in_ccbs.begin(); }
+  Inner_ccb_iterator inner_ccbs_end()   { return in_ccbs.end(); }
   //@}
 
   /// \name Obtaining constant iterators.

Arrangement_on_surface_2/include/CGAL/Arr_overlay_2.h

@@ -168,7 +168,7 @@ overlay(const Arrangement_on_surface_2<GeometryTraitsA_2, TopologyTraitsA>& arr1
   typedef Arrangement_on_surface_2<Rgt2, Rtt>                   Arr_res;
   typedef typename Arr_res::Allocator                           Allocator;
 
-  // some type assertions (not all, but better then nothing).
+  // some type assertions (not all, but better than nothing).
 #if !defined(CGAL_NO_ASSERTIONS)
   typedef typename Agt2::Point_2                                A_point;
   typedef typename Bgt2::Point_2                                B_point;

Arrangement_on_surface_2/include/CGAL/Arrangement_2/Arrangement_on_surface_2_impl.h

@@ -2781,14 +2781,24 @@ _insert_at_vertices(DHalfedge* he_to,
       he1->set_inner_ccb(ic1);
       he2->set_inner_ccb(ic1);
 
+      if (m_sweep_mode)
+      {
+        // Inner CCB are obtained using Halfedge::inner_ccb() which
+        // performs path reduction and always return valid iCCB
+        CGAL_assertion(ic1->is_valid());
+        CGAL_assertion(ic2->is_valid());
+        ic2->set_next(ic1);
+      }
+      else
+      {
         // Make all halfedges along ic2 to point to ic1.
         DHalfedge* curr;
-
         for (curr = he2->next(); curr != he1; curr = curr->next())
           curr->set_inner_ccb(ic1);
 
         // Delete the redundant inner CCB.
         _dcel().delete_inner_ccb(ic2);
+      }
 
       // Notify the observers that we have merged the two inner CCBs.
       _notify_after_merge_inner_ccb(fh, (Halfedge_handle(he1))->ccb());
@@ -4097,7 +4107,7 @@ _defines_outer_ccb_of_new_face(const DHalfedge* he_to,
     //   - No smallest has bin recorded so far, or
     //   - The current target vertex and the recorded vertex are the same and
     //       * The current curve is smaller than the recorded curve, or
-    //   - The current curve end is smaller then the recorded curve end.
+    //   - The current curve end is smaller than the recorded curve end.
     // smaller than its source, so we should check whether it is also smaller
     // Note that we compare the vertices lexicographically: first by the
     // indices, then by x, then by y.

Arrangement_on_surface_2/include/CGAL/Arrangement_on_surface_2.h

@@ -913,6 +913,14 @@ protected:
   bool                    m_own_traits;    // inidicates whether the geometry
                                            // traits should be freed up.
 
+  bool                    m_sweep_mode = false;
+                                           // sweep mode efficiently
+                                           // merges inner CCB but
+                                           // keeps invalid inner CCB
+                                           // and memory overhead that
+                                           // should be cleaned
+                                           // afterwards
+
 public:
   /// \name Constructors.
   //@{
@@ -943,6 +951,9 @@ public:
   /*! Destructor. */
   virtual ~Arrangement_on_surface_2();
 
+  /*! Change mode. */
+  void set_sweep_mode (bool mode) { m_sweep_mode = mode; }
+
   /*! Clear the arrangement. */
   virtual void clear();
   //@}
@@ -1520,6 +1531,39 @@ public:
 
   //@}
 
+  /*!
+   * Cleans the inner CCB if sweep mode was used, by removing all
+   * non-valid inner CCBs
+   */
+  void clean_inner_ccbs_after_sweep()
+  {
+    for (DHalfedge_iter he = _dcel().halfedges_begin();
+         he != _dcel().halfedges_end(); ++ he)
+    {
+      if (!he->is_on_inner_ccb())
+        continue;
+
+      DInner_ccb* ic1 = he->inner_ccb_no_redirect();
+      if (ic1->is_valid())
+        continue;
+
+      // Calling Halfedge::inner_ccb() reduces the path and makes the
+      // halfedge point to a correct CCB
+      DInner_ccb* ic2 = he->inner_ccb();
+      CGAL_USE(ic2);
+      CGAL_assertion (ic2->halfedge()->is_on_inner_ccb()
+                      && ic2->halfedge()->inner_ccb_no_redirect() == ic2);
+    }
+
+    typename Dcel::Inner_ccb_iterator it = _dcel().inner_ccbs_begin();
+    while (it != _dcel().inner_ccbs_end())
+    {
+      typename Dcel::Inner_ccb_iterator current = it ++;
+      if (!current->is_valid())
+        _dcel().delete_inner_ccb(&*current);
+    }
+  }
+
 protected:
   /// \name Determining the boundary-side conditions.
   //@{

Arrangement_on_surface_2/include/CGAL/Surface_sweep_2/Arr_construction_ss_visitor.h

@@ -154,6 +154,9 @@ public:
   /* A notification issued before the sweep process starts. */
   inline void before_sweep();
 
+  /* A notification issued after the sweep process stops. */
+  inline void after_sweep();
+
   /*!
    * A notification invoked before the sweep-line starts handling the given
    * event.
@@ -288,7 +291,21 @@ private:
 // Notifies the helper that the sweep process now starts.
 template <typename Hlpr, typename Vis>
 void Arr_construction_ss_visitor<Hlpr, Vis>::before_sweep()
-{ m_helper.before_sweep(); }
+{
+  m_helper.before_sweep();
+  m_arr->set_sweep_mode(true);
+}
+
+
+//-----------------------------------------------------------------------------
+// A notification issued after the sweep process stops.
+template <typename Hlpr, typename Vis>
+void Arr_construction_ss_visitor<Hlpr, Vis>::after_sweep()
+{
+  m_arr->clean_inner_ccbs_after_sweep();
+  m_arr->set_sweep_mode(false);
+}
+
 
 //-----------------------------------------------------------------------------
 // A notification invoked before the sweep-line starts handling the given

Arrangement_on_surface_2/include/CGAL/Surface_sweep_2/Arr_overlay_ss_visitor.h

@@ -552,6 +552,8 @@ Arr_overlay_ss_visitor<OvlHlpr, OvlTr, Vis>::update_event(Event* e,
 template <typename OvlHlpr, typename OvlTr, typename Vis>
 void Arr_overlay_ss_visitor<OvlHlpr, OvlTr, Vis>::after_sweep()
 {
+  Base::after_sweep();
+
   // Notify boundary vertices:
   typename Vertex_map::iterator it;
   for (it = m_vertices_map.begin(); it != m_vertices_map.end(); ++it) {

Arrangement_on_surface_2/test/Arrangement_on_surface_2/CMakeLists.txt

@@ -9,20 +9,6 @@ enable_testing()
 find_package(CGAL REQUIRED COMPONENTS Core)
 
 include(${CGAL_USE_FILE})
-
+# Since CMake-2.8.12: New CMake script, that defines the targets and
-if(COMMAND target_compile_options)
+# the CTest test cases.
-  # Since CMake-2.8.12: New CMake script, that defines the targets and
+include(${CMAKE_CURRENT_SOURCE_DIR}/cgal_test.cmake)
-  # the CTest test cases.
-  include(${CMAKE_CURRENT_SOURCE_DIR}/cgal_test.cmake)
-else()
-  # If CMake version is <= 2.8.11, use the usual CMake script.
-
-  # create a target per cppfile
-  file(
-    GLOB cppfiles
-    RELATIVE ${CMAKE_CURRENT_SOURCE_DIR}
-    ${CMAKE_CURRENT_SOURCE_DIR}/*.cpp)
-  foreach(cppfile ${cppfiles})
-    create_single_source_cgal_program("${cppfile}")
-  endforeach()
-endif()

Arrangement_on_surface_2/test/Arrangement_on_surface_2/cgal_test.cmake

@@ -1400,3 +1400,9 @@ compile_and_run(test_io)
 compile_and_run(test_sgm)
 
 compile_and_run(test_polycurve_intersection)
+if(CGAL_DISABLE_GMP)
+  get_directory_property(LIST_OF_TESTS TESTS)
+  foreach(_test ${LIST_OF_TESTS})
+    set_property(TEST ${_test} APPEND PROPERTY ENVIRONMENT CGAL_DISABLE_GMP=1)
+  endforeach()
+endif()

Arrangement_on_surface_2/test/Arrangement_on_surface_2/cgal_test_with_cmake

@@ -129,6 +129,19 @@ configure()
 {
   echo "Configuring... "
   rm -rf CMakeCache.txt CMakeFiles/
+  if [ -f "$INIT_FILE" ]
+  then
+    if eval 'cmake --no-warn-unused-cli ${INIT_FILE:+"-C${INIT_FILE}"} "$CMAKE_GENERATOR" -DRUNNING_CGAL_AUTO_TEST=TRUE  \
+                                        -DCGAL_DIR="$CGAL_DIR" \
+                                        -DCGAL_CXX_FLAGS:STRING="$CGAL_CXX_FLAGS $TESTSUITE_CXXFLAGS -I../../include" \
+                                        -DCGAL_EXE_LINKER_FLAGS="$CGAL_EXE_LINKER_FLAGS $TESTSUITE_LDFLAGS" \
+                                        .' ; then
+
+      echo "   successful configuration" >> $ERRORFILE
+    else
+      echo "   ERROR:    configuration" >> $ERRORFILE
+    fi
+  else
     echo "cmake --no-warn-unused-cli ${INIT_FILE:+"-C${INIT_FILE}"} "$CMAKE_GENERATOR" -DRUNNING_CGAL_AUTO_TEST=TRUE  \
    -DCGAL_DIR=\"$CGAL_DIR\" \
    -DCGAL_CXX_FLAGS:STRING=\"$TESTSUITE_CXXFLAGS -I../../include\" \
@@ -146,6 +159,7 @@ configure()
     else
       echo "   ERROR:    configuration" >> $ERRORFILE
     fi
+  fi
 }
 
 compile_test_with_flags()

BGL/doc/BGL/BGL.txt

@@ -16,9 +16,9 @@ faces as edges of the dual graph.
 The scope of \cgal is geometry and not graph algorithms. Nevertheless, this package
 provides the necessary classes and functions that enable using the
 algorithms of the <A HREF="https://www.boost.org/libs/graph/doc/index.html">Boost Graph Library</A> \cgalCite{cgal:sll-bgl-02}
-(\sc{Bgl} for short) with \cgal data structures.
+(\bgl for short) with \cgal data structures.
 
-Furthermore, this package extends the \sc{Bgl}
+Furthermore, this package extends the \bgl
 by introducing concepts such as `HalfedgeGraph` and `FaceGraph`
 allowing to handle *halfedges* and *faces*.
 These concepts reflect the design of the halfedge data structure described
@@ -26,7 +26,7 @@ in Chapter \ref PkgHalfedgeDS, with opposite halfedges and circular
 sequences of halfedges around vertices and around faces.
 
 This chapter is organized as follows:
-- The first section, Section \ref BGLA, summarizes the main ideas of the \sc{Bgl}.
+- The first section, Section \ref BGLA, summarizes the main ideas of the \bgl.
 - Section \ref BGLHeader then explains where to find header files and the chosen naming conventions, as we blend two
 different libraries.
 - The four following sections give examples on how to use CGAL graph and mesh data structures
@@ -34,13 +34,13 @@ such as
 \link PkgSurfaceMesh Surface_mesh \endlink,
 \link PkgPolyhedron Polyhedron \endlink,
 \link PkgArrangementOnSurface2 Arrangement_2 \endlink, and the
-\link PkgTriangulation2 2D triangulation \endlink classes as models of the \sc{Bgl} concepts.
+\link PkgTriangulation2 2D triangulation \endlink classes as models of the \bgl concepts.
 - Starting with Section \ref BGLExtensions, we introduce new graph concepts, classes,
-and functions that extend the functionalities of the \sc{Bgl}.
+and functions that extend the functionalities of the \bgl.
 
 \section BGLA A Short Introduction to the Boost Graph Library
 
-The algorithms of the \sc{Bgl} operate on models of various <I>graph concepts</I>.
+The algorithms of the \bgl operate on models of various <I>graph concepts</I>.
 The <I>traits class</I> `boost::graph_traits` enable algorithms to determine the types of vertices and edges
 (similar to `std::iterator_traits` for iterators).
 <I>Free functions</I> that operate on graphs enable algorithms to obtain,
@@ -53,7 +53,7 @@ arbitrary order.
 
 \subsection BGLGraphConcepts Graph Concepts
 
-The \sc{Bgl} introduces several <a href="https://www.boost.org/libs/graph/doc/graph_concepts.html">graph concepts</a>,
+The \bgl introduces several <a href="https://www.boost.org/libs/graph/doc/graph_concepts.html">graph concepts</a>,
 which have different sets of characteristics and requirements.
 For example, iterating through all vertices or all edges in a graph, obtaining the outgoing
 or in-going edges of a vertex, inserting vertices and edges into a graph,
@@ -101,16 +101,16 @@ std::pair<vertex_iterator,vertex_iterator> vertices(const Graph& g);
 
 \subsection BGLPropertyMaps Property Maps
 
-Another feature extensively used in the \sc{Bgl} is the *property map*,
+Another feature extensively used in the \bgl is the *property map*,
 which is offered by the <a href="https://www.boost.org/libs/property_map/doc/property_map.html">Boost Property Map Library</a>. Property maps
 are a general purpose interface for mapping key objects to
 corresponding value objects.
 
-The \sc{Bgl} uses property maps to associate information with vertices and edges.
+The \bgl uses property maps to associate information with vertices and edges.
 This mechanism uses a traits class (`boost::property_traits`) and free
 functions to read (`get`) and write (`put`) information in vertices,
 edges, and also in halfedges and faces for models of the \cgal graph concepts.
-For example, the \sc{Bgl}
+For example, the \bgl
 Dijksta's shortest path algorithm writes the predecessor of each vertex, as
 well as the distance to the source in such a property map.
 
@@ -138,14 +138,14 @@ Examples of such event points in graph algorithms are when a vertex is traversed
 or when all outgoing edges of a vertex have been traversed.<BR>
 
 See also Section <A HREF="https://www.boost.org/libs/graph/doc/visitor_concepts.html">Visitor Concepts</A>
-in the \sc{Bgl} manual.
+in the \bgl manual.
 
 \subsection BGLNamedParameters Named Parameters
 
-The notion of <I>named parameters</I> was introduced in the \sc{Bgl},
+The notion of <I>named parameters</I> was introduced in the \bgl,
 and allow the user to specify only those parameters which are really needed, by name, making the parameter ordering unimportant.
 See also <a href="https://www.boost.org/libs/graph/doc/bgl_named_params.html">this page</a>
-in the manual of the \sc{Bgl} for more information.
+in the manual of the \bgl for more information.
 
 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.
@@ -186,32 +186,32 @@ refine(pmesh,
 \section BGLHeader Header Files, Namespaces, and Naming Conventions
 
 This package provides the necessary classes and functions that enable using
-\cgal data structures as models of the \sc{Bgl} graph concepts.
+\cgal data structures as models of the \bgl graph concepts.
 To this end, we offer partial specializations of the `boost::graph_traits<Graph>` for various \cgal packages.
 For each such package, denoted `PACKAGE`, the partial specializations live in
 the namespace `boost` and are located in the header file `CGAL/boost/graph/graph_traits_PACKAGE.h`.
 Free functions are in the namespace `CGAL`, and the compiler uses argument-dependent lookup to find them.
 %Euler operations, described in Section \ref BGLEulerOperations, are in the namespace `CGAL::Euler`, as the function `remove_face()` is at
 the same time a low-level and an %Euler operation.
-Concerning the naming conventions, we have to use those of the \sc{Bgl},
+Concerning the naming conventions, we have to use those of the \bgl,
-as to fulfill the requirements of the concepts defined in the \sc{Bgl}.
+as to fulfill the requirements of the concepts defined in the \bgl.
 
 Note that these partial specializations are often providing more than
 is required, making these classes not only models of the graph concepts
-of the \sc{Bgl}, but also models of the CGAL graph concepts, that will be
+of the \bgl, but also models of the CGAL graph concepts, that will be
 described in detail in Section \ref BGLExtensions. Correspondence tables
-between the types of a \cgal data structure and their \sc{Bgl} equivalents
+between the types of a \cgal data structure and their \bgl equivalents
 can be found in the \ref PkgBGLTraits documentation page.
 
 We present in the following sections some examples of utilization of some
-\cgal data structures as \sc{Bgl} graphs.
+\cgal data structures as \bgl graphs.
 
 \section BGLSurface_mesh The Class Surface_mesh as Model of the Boost Graph Concept
 
-The class `Surface_mesh` is a model of most of the graph concepts of the \sc{Bgl}
+The class `Surface_mesh` is a model of most of the graph concepts of the \bgl
 as well as the concepts provided by \cgal. A complete list can
 be found in the documentation of \link BGLSMGT boost::graph_traits \endlink.
-The examples show how to use some of the \sc{Bgl} algorithms with `Surface_mesh` and show how to use
+The examples show how to use some of the \bgl algorithms with `Surface_mesh` and show how to use
 the concepts provided by \cgal to implement a simple algorithm.
 
 \subsection BGLExampleMinimumSpanningTreeofaSurfaceMesh Example: Minimum Spanning Tree of a Surface_mesh
@@ -221,16 +221,16 @@ More examples can be found in Chapters
 \ref PkgSurfaceMeshSimplification, \ref PkgSurfaceMeshSegmentation, and \ref PkgSurfaceMeshDeformation.
 
 The surface mesh class uses integer indices to address vertices and edges,
-and it comes with a built-in property mechanism that maps nicely on the \sc{Bgl}.
+and it comes with a built-in property mechanism that maps nicely on the \bgl.
 
 \cgalExample{BGL_surface_mesh/prim.cpp}
 
 \section BGLPolyhedral The Class Polyhedron_3 as Model of the Boost Graph Concept
 
-The class `Polyhedron_3` is a model of most of the graph concepts of the \sc{Bgl}
+The class `Polyhedron_3` is a model of most of the graph concepts of the \bgl
 as well as the concepts provided by \cgal. A complete list can
 be found in the documentation of \link BGLPolyGT boost::graph_traits \endlink.
-The examples show how to use some of the \sc{Bgl} algorithms with `Polyhedron_3` and show how to use
+The examples show how to use some of the \bgl algorithms with `Polyhedron_3` and show how to use
 the concepts provided by \cgal to implement a simple algorithm.
 
 \subsection BGLExampleMinimumSpanningTreeofaPolyhedral Example: Minimum Spanning Tree of a Polyhedral Surface
@@ -243,7 +243,7 @@ More examples can be found in the Chapter
 
 \subsection BGLExampleUsingVerticesandEdgeswithanID Example: Using Vertices, and Edges with an ID
 
-The following example program shows a call to the \sc{Bgl}
+The following example program shows a call to the \bgl
 Kruskal's minimum spanning tree algorithm accessing the `id()`
 field stored in a polyhedron vertex.
 
@@ -275,7 +275,7 @@ integers in the range `[0, t.number_of_vertices())`.
 
 \subsection BGLExampleStoringtheVertexIDintheVertex Example: Storing the Vertex ID in the Vertex
 
-The algorithms of the \sc{Bgl} extensively use of the indices of
+The algorithms of the \bgl extensively use of the indices of
 vertices. In the previous example we stored the indices in a `std::map`
 and turned that map in a property map. This property map was then
 passed as argument to the shortest path function.
@@ -316,7 +316,7 @@ edges in our <I>boost</I> graph.
 
 Given an `Arrangement_2` instance, we can efficiently traverse its
 vertices and halfedges. Thus, the arrangement graph is a model of the concepts
-`VertexListGraph` and `EdgeListGraph` introduced by the \sc{Bgl}.
+`VertexListGraph` and `EdgeListGraph` introduced by the \bgl.
 At the same time, we use an iterator adapter of the circulator over the
 halfedges incident to a vertex (`Halfedge_around_target_circulator` - see
 Section \ref arr_sssectr_vertex "Traversal Methods for an Arrangement Vertex"
@@ -327,11 +327,11 @@ is a model of the concept `BidirectionalGraph` (this concept refines
 
 It is important to notice that the vertex descriptors we use are
 `Vertex_handle` objects and <I>not</I> vertex indices. However, in order
-to gain more efficiency in most \sc{Bgl} algorithm, it is better to have them
+to gain more efficiency in most \bgl algorithm, it is better to have them
 indexed \f$ 0, 1, \ldots, (n-1)\f$, where \f$ n\f$ is the number of vertices. We
 therefore introduce the `Arr_vertex_index_map<Arrangement>` class-template,
 which maintains a mapping of vertex handles to indices, as required by the
-\sc{Bgl}. An instance of this class must be attached to a valid arrangement
+\bgl. An instance of this class must be attached to a valid arrangement
 vertex when it is created. It uses the notification mechanism (see
 Section \ref arr_ssecnotif) to automatically maintain the mapping of vertices
 to indices, even when new vertices are inserted into the arrangement or
@@ -340,7 +340,7 @@ existing vertices are removed.
 A complete description of the types correspondences
 can be found in the documentation of \link BGLArgtGT boost::graph_traits \endlink.
 
-In most algorithm provided by the \sc{Bgl}, the output is given by
+In most algorithm provided by the \bgl, the output is given by
 <I>property maps</I>, such that each map entry corresponds to a vertex.
 For example, when we compute the shortest paths from a given source vertex
 \f$ s\f$ to all other vertices we can obtain a map of distances and a map of
@@ -353,7 +353,7 @@ template allows for an efficient mapping of `Vertex_handle` objects to
 properties of type `Type`. Note however that unlike the
 `Arr_vertex_index_map` class, the vertex property-map class is not
 kept synchronized with the number of vertices in the arrangement, so it
-should not be reused in calls to the \sc{Bgl} functions in case the arrangement
+should not be reused in calls to the \bgl functions in case the arrangement
 is modified in between these calls.
 
 \cgalFigureBegin{figex_bgl,ex_bgl.png}
@@ -364,7 +364,7 @@ faces, starting from the unbounded face \f$ f_0\f$, are shown in brackets.
 
 In the following example we construct an arrangement of 7 line segments,
 as shown in \cgalFigureRef{figex_bgl},
-then use the \sc{Bgl} Dijkstra's shortest-paths algorithm to compute
+then use the \bgl Dijkstra's shortest-paths algorithm to compute
 the graph distance of all vertices from the leftmost vertex in the
 arrangement \f$ v_0\f$. Note the usage of the `Arr_vertex_index_map` and
 the `Arr_vertex_property_map` classes. The latter one, instantiated by
@@ -413,9 +413,9 @@ these times and update the faces accordingly:
 
 The previous sections introduced partial specializations
 and free functions so that several \cgal data structures are adapted as models of some
-of the \sc{Bgl} graph concepts.
+of the \bgl graph concepts.
 In this section, we introduce new concepts, iterators, and property maps inspired
-by the functionalities of the \sc{Bgl}.
+by the functionalities of the \bgl.
 
 \subsection BGLExtensionsGraphConcepts Graph concepts
 
@@ -487,7 +487,7 @@ stored in the vertex record.)
 \subsubsection BGLExampleNormalHalfedgeGraph Example: Calculating Facet Normals using HalfedgeGraph
 
 The following example program shows a simple algorithm for calculating
-facet normals for a polyhedron using the \sc{Bgl} API. A
+facet normals for a polyhedron using the \bgl API. A
 <a href="https://www.boost.org/libs/property_map/doc/vector_property_map.html">boost::vector_property_map</a>
 is used to to store the calculated normals instead of changing the Polyhedron items class.
 
@@ -581,13 +581,13 @@ as shown in the following example.
 \subsection BGLSeamMesh The Seam Mesh
 
 The class `Seam_mesh` allows to mark edges of a mesh as <em>seam edges</em>
-so that they <em>virtually</em> become border edges when exploring a seam mesh with the \sc{Bgl} API.
+so that they <em>virtually</em> become border edges when exploring a seam mesh with the \bgl API.
 The input mesh is referred to as <em>underlying</em> mesh of the seam mesh.
 We denote `tm` and `sm` the underlying mesh and the seam mesh respectively.
 
 Figure \cgalFigureRef{fig_Seam_mesh_1} shows an example of mesh on which two
 edges, defined by the halfedge pairs `h2-h3` and `h6-h7`, are marked as seams.
-The introduction of virtual borders modifies the elementary \sc{Bgl} graph traversal
+The introduction of virtual borders modifies the elementary \bgl graph traversal
 operations: when we circulate around the target of `h7` in the underlying mesh,
 we traverse `h7`, `h1`, `h3`, `h5`, before arriving at `h7` again.
 However, when we circulate in the seam mesh, we traverse `h7`, `h1`, `h3*`,

BGL/doc/BGL/CGAL/HalfedgeDS_face_max_base_with_id.h

@@ -9,7 +9,7 @@ concept.
 
 It is equivalent to `HalfedgeDS_face_base< Refs, Tag_true>`
 with an added integer field which can be used to index faces
-in \sc{Bgl} algorithms.
+in \bgl algorithms.
 The class contains support for the incident halfedge pointer
 and the required type definitions.
 It can be used for deriving own faces.

BGL/doc/BGL/CGAL/HalfedgeDS_halfedge_max_base_with_id.h

@@ -7,7 +7,7 @@ namespace CGAL {
 The class `HalfedgeDS_halfedge_max_base_with_id` is a model of the `HalfedgeDSHalfedge`
 concept.
 It is equivalent to `HalfedgeDS_halfedge_base< Refs, Tag_true, Tag_true, Tag_true>` with an added integer
-field which can be used to index halfedges in \sc{Bgl} algorithms.
+field which can be used to index halfedges in \bgl algorithms.
 The class contains support for the previous, next, opposite, vertex and
 face pointers and the required type definitions.
 It can be used for deriving own halfedges.

BGL/doc/BGL/CGAL/HalfedgeDS_vertex_max_base_with_id.h

@@ -8,7 +8,7 @@ The class `HalfedgeDS_vertex_max_base_with_id` is a model of the `HalfedgeDSVert
 concept.  It is
 equivalent to `HalfedgeDS_vertex_base< Refs, Tag_true>`
 with an added integer field which can be used to index vertices
-in \sc{Bgl} algorithms..
+in \bgl algorithms..
 The class contains support for the point and the required type definitions.
 It can be used for deriving own vertices.
 

BGL/doc/BGL/CGAL/Polyhedron_items_with_id_3.h

@@ -7,7 +7,7 @@ namespace CGAL {
 The class `Polyhedron_items_with_id_3` is a model of the `PolyhedronItems_3`
 concept. It provides definitions for vertices with points, halfedges,
 and faces with plane equations, all of them with an additional integer
-field which can be used to index the items in a \sc{Bgl} algorithm.
+field which can be used to index the items in a \bgl algorithm.
 The polyhedron traits class must provide the respective types for
 the point and the plane equation.
 Vertices and facets both contain a halfedge handle to an incident

BGL/doc/BGL/CGAL/Triangulation_face_base_with_id_2.h

@@ -6,7 +6,7 @@ namespace CGAL {
 The class `Triangulation_face_base_with_id_2` is a model of the
 concept `TriangulationFaceBase_2`, the base face of a
 2D-triangulation. It provides an integer field that can be used to
-index faces for \sc{Bgl} algorithms.
+index faces for \bgl algorithms.
 
 Note that the user is in charge of setting indices correctly before
 running a graph algorithm, by calling the function

BGL/doc/BGL/CGAL/Triangulation_vertex_base_with_id_2.h

@@ -6,7 +6,7 @@ namespace CGAL {
 The class `Triangulation_vertex_base_with_id_2` is a model of the
 concept `TriangulationVertexBase_2`, the base vertex of a
 2D-triangulation.  It provides an integer field that can be used to
-index vertices for \sc{Bgl} algorithms.
+index vertices for \bgl algorithms.
 
 Note that the user is in charge of setting indices correctly before
 running a graph algorithm, by calling the function

BGL/doc/BGL/CGAL/boost/graph/properties.h

@@ -4,7 +4,7 @@ namespace CGAL {
 /// \ingroup PkgBGLProperties
 /// @{
 
-/// The constant `vertex_index` is a property tag which identifies the <i>index</i> property of a vertex of a \sc{Bgl}
+/// The constant `vertex_index` is a property tag which identifies the <i>index</i> property of a vertex of a \bgl
 /// <a href="https://www.boost.org/libs/graph/doc/Graph.html"><code>Graph</code></a>.
 /// \cgalModels <a href="https://www.boost.org/libs/graph/doc/PropertyTag.html"><code>PropertyTag</code></a>
 enum vertex_index_t { vertex_index };
@@ -15,7 +15,7 @@ enum vertex_index_t { vertex_index };
 /// \cgalModels <a href="https://www.boost.org/libs/graph/doc/PropertyTag.html"><code>PropertyTag</code></a>
 enum halfedge_index_t { halfedge_index };
 
-/// The constant `edge_index` is a property tag which identifies the <i>index</i> property of an edge of a \sc{Bgl}
+/// The constant `edge_index` is a property tag which identifies the <i>index</i> property of an edge of a \bgl
 /// <a href="https://www.boost.org/libs/graph/doc/Graph.html"><code>Graph</code></a>.
 /// \cgalModels <a href="https://www.boost.org/libs/graph/doc/PropertyTag.html"><code>PropertyTag</code></a>
 enum edge_index_t { edge_index };

BGL/doc/BGL/Concepts/HalfedgeGraph.h

@@ -2,7 +2,7 @@
 \ingroup PkgBGLConcepts
 \cgalConcept
 
-The concept `HalfedgeGraph` is a refinement of the \sc{Bgl} concept
+The concept `HalfedgeGraph` is a refinement of the \bgl concept
 `IncidenceGraph` and adds the notion of a *halfedge*: Each edge is
 associated with two *opposite* halfedges with source and target vertices swapped.
 Furthermore, halfedges have a *successor* and *predecessor*,

BGL/doc/BGL/NamedParameters.txt

@@ -2,7 +2,7 @@
 \defgroup bgl_namedparameters Named Parameters
 \ingroup PkgBGLRef
 
-The algorithms of the Boost Graph Library (\sc{Bgl}) often have many parameters with default
+The algorithms of the Boost Graph Library (\bgl) often have many parameters with default
 values that are appropriate for most cases. In general, when no
 special treatment is applied, the values of such parameters are passed
 as a sequence. Deviating from the default for a certain parameter
@@ -18,7 +18,7 @@ vertex_descriptor s = vertex(A, g);
 dijkstra_shortest_paths(g, s, predecessor_map(&p[0]).distance_map(&d[0]));
 \endcode
 
-In the \sc{Bgl} manual, this is called
+In the \bgl manual, this is called
 <a href="https://www.boost.org/libs/graph/doc/bgl_named_params.html">named parameters</a>.
 The named parameters in the snippet use the tags `predecessor_map` and `distance_map`
 and they are concatenated using the dot operator.<BR>
@@ -26,7 +26,7 @@ and they are concatenated using the dot operator.<BR>
 A similar mechanism was introduced in \cgal, with the small difference that the named parameters
 tag live in the `CGAL::parameters::` namespace and `CGAL::parameters::all_default()` can be used to indicate
 that default values of optional named parameters must be used.
-As in the \sc{BGL}, named parameters in \cgal are also concatenated using
+As in the \bgl, named parameters in \cgal are also concatenated using
 the dot operator, and a typical usage is thus:
 
 \code {.cpp}

BGL/doc/BGL/PackageDescription.txt

@@ -3,9 +3,9 @@
 /*! \defgroup PkgBGLConcepts Concepts
  \ingroup PkgBGLRef
 
- We extend the Boost Graph Library (\sc{Bgl} for short) with a set of new concepts.
+ We extend the Boost Graph Library (\bgl for short) with a set of new concepts.
  In order to make this documentation self-contained we here also document
- concepts that are defined in the original version of the \sc{Bgl}.
+ concepts that are defined in the original version of the \bgl.
  The documentation of the concepts lists at the same time the functions
  related to it. Models of the concept and their related functions
  must be in the same namespace (they will be found by Koenig lookup).
@@ -586,9 +586,9 @@ Methods to read and write graphs.
 \cgalPkgSummaryBegin
 \cgalPkgAuthors{Andreas Fabri, Fernando Cacciola, Philipp Moeller, and Ron Wein}
 \cgalPkgDesc{This package provides a framework for interfacing \cgal data structures
-             with the algorithms of the Boost Graph Library, or \sc{BGL} for short.
+             with the algorithms of the Boost Graph Library, or \bgl for short.
              It allows to run graph algorithms directly on \cgal data structures which are model
-             of the \sc{BGL} graph concepts, for example the shortest path algorithm
+             of the \bgl graph concepts, for example the shortest path algorithm
              on a Delaunay triangulation in order to compute the Euclidean minimum spanning tree.
              Furthermore, it introduces several new graph concepts describing halfedge data structures.}
 \cgalPkgManuals{Chapter_CGAL_and_the_Boost_Graph_Library,PkgBGLRef}
@@ -621,7 +621,7 @@ Methods to read and write graphs.
 
 \cgalCRPSection{%CGAL Classes Adapted for the Graph API}
 
-A number of \cgal structures have been adapted as graphs for the \sc{Bgl}. All
+A number of \cgal structures have been adapted as graphs for the \bgl. All
 adapted types are listed here. The pages document which concepts they
 model, the properties they support, and any possible caveats that a
 user might encounter.

BGL/doc/BGL/graph_traits.txt

@@ -3,7 +3,7 @@
 
 \ingroup PkgBGLRef
 
-The \sc{Bgl} defines the class template
+The \bgl defines the class template
 <A HREF="https://www.boost.org/libs/graph/doc/graph_traits.html">`boost::graph_traits`</A>
 as a uniform interface to the properties and types of %graph types.
 
@@ -156,7 +156,7 @@ vertex, or walking through the faces container.
 
 The mapping between vertices, edges, and faces of the triangulation and the
 graph is rather straightforward, but there are some subtleties. The
-value type of the \sc{Bgl} iterators is the vertex or edge descriptor,
+value type of the \bgl iterators is the vertex or edge descriptor,
 whereas in \cgal all iterators and circulators are also handles and
 hence have as value type Vertex or Edge.
 

BGL/include/CGAL/boost/graph/selection.h

@@ -561,6 +561,9 @@ regularize_face_selection_borders(
 /// \endcond
 
 /// \cond SKIP_IN_MANUAL
+
+namespace experimental {
+
 // TODO: improve and document if useful
 //
 // Variant of regularization without graphcut but with brut-force
@@ -703,6 +706,8 @@ regularize_face_selection_borders(
       put(is_selected, fd, true);
   }
 }
+
+}
 /// \endcond
 
 

Box_intersection_d/include/CGAL/Box_intersection_d/Box_d.h

@@ -24,6 +24,7 @@
 #include <CGAL/atomic.h>
 
 #include <algorithm>
+#include <array>
 
 namespace CGAL {
 
@@ -63,8 +64,9 @@ class Box_d;
 template<class NT_, int N>
 class Box_d< NT_, N, ID_NONE> {
 protected:
-    NT_ lo[N];
+    std::array<NT_,N> lo;
-    NT_ hi[N];
+    std::array<NT_,N> hi;
+
 public:
     typedef NT_         NT;
     typedef std::size_t ID;
@@ -72,8 +74,8 @@ public:
     Box_d() {}
     Box_d(bool complete) { init(complete); }
     Box_d(NT l[N], NT h[N]) {
-        std::copy( l, l + N, lo );
+        std::copy( l, l + N, &lo[0] );
-        std::copy( h, h + N, hi );
+        std::copy( h, h + N, &hi[0] );
     }
     void init (bool complete = false) {
         NT inf = box_limits<NT>::inf();

Convex_hull_2/include/CGAL/Convex_hull_2/convexity_check_2_impl.h

@@ -18,7 +18,6 @@
 
 #include <CGAL/algorithm.h>
 #include <algorithm>
-#include <boost/bind.hpp>
 
 namespace CGAL {
 
@@ -139,8 +138,6 @@ ch_brute_force_check_2(ForwardIterator1 first1, ForwardIterator1 last1,
                             ForwardIterator2 first2, ForwardIterator2 last2,
                             const Traits&  ch_traits)
 {
-  using namespace boost;
-
   typedef    typename Traits::Left_turn_2    Left_of_line;
   ForwardIterator1 iter11;
   ForwardIterator2 iter21;
@@ -165,12 +162,13 @@ ch_brute_force_check_2(ForwardIterator1 first1, ForwardIterator1 last1,
   while (iter22 != last2)
   {
       iter11 = std::find_if( first1, last1,
-                             bind(left_turn, *iter22++, *iter21++, _1) );
+                             [left_turn, iter22, iter21](const auto& p){ return left_turn(*iter22, *iter21, p); } );
+      ++iter22; ++iter21;
       if (iter11 != last1 ) return false;
   }
 
   iter11 = std::find_if( first1, last1,
-                         bind(left_turn, *first2, *iter21, _1) );
+                         [left_turn, first2, iter21](const auto& p){ return left_turn(*first2, *iter21, p); } );
   if (iter11 != last1 ) return false;
   return true;
 }
@@ -203,7 +201,8 @@ ch_brute_force_chain_check_2(ForwardIterator1 first1,
   while (iter22 != last2)
   {
       iter11 = std::find_if( first1, last1,
-                             bind(left_turn, *iter22++, *iter21++, _1) );
+                             [left_turn, iter22, iter21](const auto& p){ return left_turn(*iter22, *iter21, p); } );
+      ++iter22; ++iter21;
       if (iter11 != last1 ) return false;
   }
 

Distance_2/include/CGAL/squared_distance_2_1.h

@@ -234,7 +234,7 @@ namespace internal {
 
       c2s = CGAL::abs(wcross(seg1.source(), seg1.target(), seg2.source(), k));
       c2e = CGAL::abs(wcross(seg1.source(), seg1.target(), seg2.target(), k));
-      Comparison_result dm = compare(c2s,c2e);
+      Comparison_result dm = CGAL::compare(c2s,c2e);
 
       if (dm == SMALLER) {
         return internal::squared_distance(seg2.source(), seg1, k);
@@ -249,7 +249,7 @@ namespace internal {
     } else {
       c1s = CGAL::abs(wcross(seg2.source(), seg2.target(), seg1.source(), k));
       c1e = CGAL::abs(wcross(seg2.source(), seg2.target(), seg1.target(), k));
-      Comparison_result dm = compare(c1s,c1e);
+      Comparison_result dm = CGAL::compare(c1s,c1e);
       if (crossing2) {
         if (dm == SMALLER) {
           return internal::squared_distance(seg1.source(), seg2, k);
@@ -272,7 +272,7 @@ namespace internal {
 
         c2s = CGAL::abs(wcross(seg1.source(), seg1.target(), seg2.source(), k));
         c2e = CGAL::abs(wcross(seg1.source(), seg1.target(), seg2.target(), k));
-        dm = compare(c2s,c2e);
+        dm = CGAL::compare(c2s,c2e);
 
         if (dm == EQUAL)  // should not happen.
           return internal::squared_distance_parallel(seg1, seg2, k);

Distance_3/include/CGAL/squared_distance_3.h

@@ -21,5 +21,6 @@
 #include <CGAL/squared_distance_3_0.h>
 #include <CGAL/squared_distance_3_1.h>
 #include <CGAL/squared_distance_3_2.h>
+#include <CGAL/squared_distance_3_3.h>
 
 #endif

Distance_3/include/CGAL/squared_distance_3_2.h

@@ -225,6 +225,7 @@ squared_distance_to_triangle(
     const typename K::Point_3 & t0,
     const typename K::Point_3 & t1,
     const typename K::Point_3 & t2,
+    bool & inside,
     const K& k)
 {
   typename K::Construct_vector_3 vector;
@@ -239,6 +240,7 @@ squared_distance_to_triangle(
      && on_left_of_triangle_edge(pt, normal, t2, t0, k))
       {
         // the projection of pt is inside the triangle
+        inside = true;
         return squared_distance_to_plane(normal, vector(t0, pt), k);
       }
       else {
@@ -267,10 +269,12 @@ squared_distance(
     const K& k)
 {
   typename K::Construct_vertex_3 vertex;
+  bool inside = false;
   return squared_distance_to_triangle(pt,
                                       vertex(t, 0),
                                       vertex(t, 1),
                                       vertex(t, 2),
+                                      inside,
                                       k);
 }
 

Distance_3/include/CGAL/squared_distance_3_3.h

@@ -0,0 +1,126 @@
+// Copyright (c) 1998-2021
+// Utrecht University (The Netherlands),
+// ETH Zurich (Switzerland),
+// INRIA Sophia-Antipolis (France),
+// Max-Planck-Institute Saarbruecken (Germany),
+// and Tel-Aviv University (Israel).  All rights reserved.
+//
+// This file is part of CGAL (www.cgal.org)
+//
+// $URL$
+// $Id$
+// SPDX-License-Identifier: LGPL-3.0-or-later OR LicenseRef-Commercial
+//
+//
+// Author(s)     : Geert-Jan Giezeman, Andreas Fabri
+
+
+#ifndef CGAL_DISTANCE_3_3_H
+#define CGAL_DISTANCE_3_3_H
+
+#include <CGAL/squared_distance_3_2.h>
+
+#include <CGAL/Point_3.h>
+#include <CGAL/Tetrahedron_3.h>
+
+namespace CGAL {
+
+namespace internal {
+
+template <class K>
+inline
+typename K::FT
+squared_distance(const typename K::Tetrahedron_3 & t,
+                 const typename K::Point_3 & pt,
+                 const K& k)
+{
+  bool on_bounded_side = true;
+  const typename K::Point_3 t0 = t[0];
+  const typename K::Point_3 t1 = t[1];
+  const typename K::Point_3 t2 = t[2];
+  const typename K::Point_3 t3 = t[3];
+
+  bool dmin_initialized = false;
+  typename K::FT dmin;
+  bool inside = false;
+  if(orientation(t0,t1,t2, pt) == NEGATIVE){
+    on_bounded_side = false;
+    dmin = squared_distance_to_triangle(pt, t0, t1, t2, inside, k);
+    dmin_initialized = true;
+    if(inside){
+      return dmin;
+    }
+  }
+
+  if(orientation(t0,t3,t1, pt) == NEGATIVE){
+    on_bounded_side = false;
+    const typename K::FT d = squared_distance_to_triangle(pt, t0, t3, t1, inside, k);
+    if(inside){
+      return d;
+    }
+    if(! dmin_initialized){
+      dmin = d;
+      dmin_initialized = true;
+    }else{
+      dmin = (std::min)(d,dmin);
+    }
+  }
+
+  if(orientation(t1,t3,t2, pt) == NEGATIVE){
+    on_bounded_side = false;
+    const typename K::FT d = squared_distance_to_triangle(pt, t1, t3, t2, inside, k);
+    if(inside){
+      return d;
+    }
+    if(! dmin_initialized){
+      dmin = d;
+      dmin_initialized = true;
+    }else{
+      dmin = (std::min)(d,dmin);
+    }
+  }
+
+  if(orientation(t2,t3,t0, pt) == NEGATIVE){
+    on_bounded_side = false;
+    const typename K::FT d = squared_distance_to_triangle(pt, t2, t3, t0, inside, k);
+    if(inside){
+      return d;
+    }
+    if(! dmin_initialized){
+      dmin = d;
+      dmin_initialized = true;
+    }else{
+      dmin = (std::min)(d,dmin);
+    }
+  }
+
+  if(on_bounded_side){
+    return typename K::FT(0);
+  }
+  return dmin;
+}
+
+} // namespace internal
+
+
+template <class K>
+typename K::FT
+squared_distance(const Tetrahedron_3<K> & t,
+                 const Point_3<K> & pt)
+{
+  return internal::squared_distance(t,pt,K());
+}
+
+
+template <class K>
+typename K::FT
+squared_distance(const Point_3<K> & pt,
+                 const Tetrahedron_3<K> & t)
+{
+  return internal::squared_distance(t,pt,K());
+}
+
+} //namespace CGAL
+
+
+#endif

Distance_3/test/Distance_3/test_distance_3.cpp

@@ -56,6 +56,7 @@ struct Test {
   typedef CGAL::Triangle_3< K >       T;
   typedef CGAL::Plane_3< K >          Pl;
   typedef CGAL::Iso_cuboid_3< K >     Cub;
+  typedef CGAL::Tetrahedron_3< K >    Tet;
 
 
   template < typename Type >
@@ -109,10 +110,19 @@ struct Test {
 
   void P_T()
   {
-    std::cout << "Point - Segment\n";
+    std::cout << "Point - Triangle\n";
     check_squared_distance (p(0, 1, 2), T(p(0, 0, 0), p( 2, 0, 0), p( 0, 2, 0)), 4);
   }
 
+  void P_Tet()
+  {
+    std::cout << "Point - Tetrahedron\n";
+    check_squared_distance (p(0, 0, 0), Tet(p(0, 0, 0), p( 1, 0, 0), p( 0, 1, 0), p( 0, 0, 1)), 0);
+    check_squared_distance (p(0, 0, 2), Tet(p(0, 0, 0), p( 1, 0, 0), p( 0, 1, 0), p( 0, 0, 1)), 1);
+    check_squared_distance (p(0, 0, -1), Tet(p(0, 0, 0), p( 1, 0, 0), p( 0, 1, 0), p( 0, 0, 1)), 1);
+    check_squared_distance (p(5, 0, 0), Tet(p(0, 0, 0), p( 1, 0, 0), p( 0, 1, 0), p( 4, 0, 1)), 2);
+  }
+
   void S_S()
   {
     std::cout << "Segment - Segment\n";
@@ -238,6 +248,7 @@ struct Test {
     P_P();
     P_S();
     P_T();
+    P_Tet();
     S_S();
     P_R();
     R_R();

Documentation/doc/CMakeLists.txt

@@ -27,7 +27,7 @@ else()
 endif()
 
 find_package(Doxygen)
-find_package(PythonInterp 2.6.7)
+find_package(PythonInterp)
 
 if(NOT DOXYGEN_FOUND)
   message(WARNING "Cannot build the documentation without Doxygen!")

Documentation/doc/Documentation/Developer_manual/Chapter_debugging.txt

@@ -101,7 +101,7 @@ named `Traits1` and `Traits2`, and a third parameter named
 other is (presumably) a traits class that always gives the right answer.
 The `Adapter` is needed since the `X_curve` types
 for `Traits1` and `Traits2` might be different.
-This cross-checker does nothing other then asserting that the two traits
+This cross-checker does nothing other than asserting that the two traits
 classes return the same values by calling the
 the counterparts in the member traits classes
 (`tr1`,`tr2`) and comparing the results.

Documentation/doc/Documentation/Developer_manual/cmakelist_script.txt

@@ -26,7 +26,7 @@ source file</B>.
 libraries (i.e.\ "Core", "ImageIO", and "Qt5"). An example is `-c Core`.
 
 <DT><B>`-b boost1:boost2:...`</B><DD> Lists components ("boost1",
-"boost2") of \sc{Boost} to which the executable(s) should be
+"boost2") of \boost to which the executable(s) should be
 linked. Valid options are, for instance, "filesystem" or "program_options".
 
 </DL>

Documentation/doc/Documentation/Third_party.txt

@@ -11,11 +11,11 @@ supporting <a href="https://isocpp.org/wiki/faq/cpp14">C++14</a> or later.
 
 | Operating System | Compiler |
 | :------- | :--------------- |
-| Linux | \sc{Gnu} `g++` 6.3 or later\cgalFootnote{<A HREF="http://gcc.gnu.org/">`http://gcc.gnu.org/`</A>} |
+| Linux | \gnu `g++` 6.3 or later\cgalFootnote{<A HREF="http://gcc.gnu.org/">`http://gcc.gnu.org/`</A>} |
 |       | `Clang` \cgalFootnote{<A HREF="http://clang.llvm.org/">`http://clang.llvm.org/`</A>} compiler version 8.0.0 |
-| \sc{MS} Windows | \sc{Gnu} `g++` 6.3 or later\cgalFootnote{<A HREF="http://gcc.gnu.org/">`http://gcc.gnu.org/`</A>} |
+| \ms Windows | \gnu `g++` 6.3 or later\cgalFootnote{<A HREF="http://gcc.gnu.org/">`http://gcc.gnu.org/`</A>} |
-|                 | \sc{MS} Visual `C++` 14.0, 15.9, 16.0 (\sc{Visual Studio} 2015, 2017, and 2019)\cgalFootnote{<A HREF="https://visualstudio.microsoft.com/">`https://visualstudio.microsoft.com/`</A>} |
+|                 | \ms Visual `C++` 14.0, 15.9, 16.0 (\visualstudio 2015, 2017, and 2019)\cgalFootnote{<A HREF="https://visualstudio.microsoft.com/">`https://visualstudio.microsoft.com/`</A>} |
-| MacOS X | \sc{Gnu} `g++` 6.3 or later\cgalFootnote{<A HREF="http://gcc.gnu.org/">`http://gcc.gnu.org/`</A>} |
+| MacOS X | \gnu `g++` 6.3 or later\cgalFootnote{<A HREF="http://gcc.gnu.org/">`http://gcc.gnu.org/`</A>} |
 |         | Apple `Clang` compiler versions 7.0.2 and 10.0.1 |
 
 <!-- Windows supported version are also listed on windows.html (must change both) -->
@@ -58,38 +58,38 @@ The \stl comes with the compiler, and as such no installation is required.
 \subsection thirdpartyBoost Boost
 <b>Version 1.66 or later</b>
 
-The \sc{Boost} libraries are a set of portable C++ source libraries.
+The \boost libraries are a set of portable C++ source libraries.
-Most of \sc{Boost} libraries are header-only, but a few of them need to be compiled or
+Most of \boost libraries are header-only, but a few of them need to be compiled or
 installed as binaries.
 
-\cgal only requires the headers of the \sc{Boost} libraries, but some demos and examples
+\cgal only requires the headers of the \boost libraries, but some demos and examples
 depend on the binary library `Boost.Program_options`.
 
-In case the \sc{Boost} libraries are not installed on your system already, you
+In case the \boost libraries are not installed on your system already, you
 can obtain them from <A HREF="https://www.boost.org">`https://www.boost.org/`</A>.
 For Visual C++ you can download precompiled libraries
 from <A HREF="https://sourceforge.net/projects/boost/files/boost-binaries/">`https://sourceforge.net/projects/boost/files/boost-binaries/`</A>.
 
-As there is no canonical directory for where to find \sc{Boost} on Windows,
+As there is no canonical directory for where to find \boost on Windows,
 we recommend that you define the environment variable
-`BOOST_ROOT` and set it to where you have installed \sc{Boost}, e.g., `C:\boost\boost_1_69_0`.
+`BOOST_ROOT` and set it to where you have installed \boost, e.g., `C:\boost\boost_1_69_0`.
 
 \subsection thirdpartyMPFR GNU Multiple Precision Arithmetic (GMP) and GNU Multiple Precision Floating-Point Reliably (MPFR) Libraries
 <b>GMP Version 4.2 or later, MPFR Version 2.2.1 or later</b>
 
 The components `libCGAL`, `libCGAL_Core`, and `libCGAL_Qt5` require
-\sc{Gmp} and \sc{Mpfr} which are libraries for multi precision integers and rational numbers,
+\gmp and \mpfr which are libraries for multi precision integers and rational numbers,
 and for multi precision floating point numbers.
 
 \cgal combines floating point arithmetic with exact arithmetic
 in order to be efficient and reliable. \cgal has a built-in
-number type for that, but \sc{Gmp} and \sc{Mpfr} provide a faster
+number type for that, but \gmp and \mpfr provide a faster
 solution, and we recommend to use them.
 
 These libraries can be obtained from <A HREF="https://gmplib.org/">`https://gmplib.org/`</A>
 and <A HREF="https://www.mpfr.org/">`https://www.mpfr.org/`</A>.
-Since Visual \cpp is not properly supported by the \sc{Gmp} and \sc{Mpfr} projects,
+Since Visual \cpp is not properly supported by the \gmp and \mpfr projects,
-we provide precompiled versions of \sc{Gmp} and \sc{Mpfr}, which can be downloaded with the installer
+we provide precompiled versions of \gmp and \mpfr, which can be downloaded with the installer
 <a href="https://github.com/CGAL/cgal/releases">`CGAL-\cgalReleaseNumber``-Setup.exe`</a>.
 
 \section secoptional3rdpartysoftware Optional Third Party Libraries
@@ -108,51 +108,51 @@ the location of third-party software during configuration.
 Qt is a cross-platform application and UI framework.
 
 The component libCGAL_Qt5 is essential to run the \cgal demos and basic viewers.
-It requires \sc{Qt}5 installed on your system.
+It requires \qt5 installed on your system.
-In case \sc{Qt} is not yet installed on your system, you can download
+In case \qt is not yet installed on your system, you can download
 it from <A HREF="https://www.qt-project.org/">`https://www.qt-project.org/`</A>.
 
-The exhaustive list of \sc{Qt}5 components used in demos is:
+The exhaustive list of \qt5 components used in demos is:
 `Core`, `Gui`, `Help`, `OpenGL`, `Script`, `ScriptTools`, `Svg`, `Widgets`,
 `qcollectiongenerator` (with `sqlite` driver plugin), and `Xml`.
 
 \subsection thirdpartyEigen Eigen
 <b>Version 3.1 or later</b>
 
-\sc{Eigen} is a `C++` template library for linear algebra. \sc{Eigen} supports all
+\eigen is a `C++` template library for linear algebra. \eigen supports all
 matrix sizes, various matrix decomposition methods and sparse linear solvers.
 
-In \cgal, \sc{Eigen} is used in many packages such as \ref
+In \cgal, \eigen is used in many packages such as \ref
 PkgPoissonSurfaceReconstruction3 or \ref PkgJetFitting3, providing
 sparse linear solvers and singular value decompositions.  A package
-dependency over \sc{Eigen} is marked on the <a
+dependency over \eigen is marked on the <a
 href="https://doc.cgal.org/latest/Manual/packages.html">Package
 Overview</a> page. In order to use Eigen in \cgal programs, the
 executables should be linked with the CMake imported target
 `CGAL::Eigen3_support` provided in `CGAL_Eigen3_support.cmake`.
 
-The \sc{Eigen} web site is <A HREF="http://eigen.tuxfamily.org/index.php?title=Main_Page">`http://eigen.tuxfamily.org`</A>.
+The \eigen web site is <A HREF="http://eigen.tuxfamily.org/index.php?title=Main_Page">`http://eigen.tuxfamily.org`</A>.
 
 \subsection thirdpartyOpenGR OpenGR
 
-\sc{OpenGR} is a set C++ libraries for 3D Global Registration released under the terms of the APACHE V2 licence.
+\opengr is a set C++ libraries for 3D Global Registration released under the terms of the APACHE V2 licence.
 
-\cgal provides wrappers for the Super4PCS algorithm of \sc{OpenGR} in the \ref PkgPointSetProcessing3Ref
+\cgal provides wrappers for the Super4PCS algorithm of \opengr in the \ref PkgPointSetProcessing3Ref
-packages. In order to use \sc{OpenGR} in \cgal programs, the executables should be linked with the CMake imported target `CGAL::OpenGR_support` provided in `CGAL_OpenGR_support.cmake`.
+packages. In order to use \opengr in \cgal programs, the executables should be linked with the CMake imported target `CGAL::OpenGR_support` provided in `CGAL_OpenGR_support.cmake`.
 
-The \sc{OpenGR} web site is <A HREF="https://github.com/STORM-IRIT/OpenGR">`https://github.com/STORM-IRIT/OpenGR`</A>.
+The \opengr web site is <A HREF="https://github.com/STORM-IRIT/OpenGR">`https://github.com/STORM-IRIT/OpenGR`</A>.
 
 \subsection thirdpartylibpointmatcher PointMatcher
 
-\sc{libpointmatcher} is a modular library implementing the Iterative Closest Point (ICP) algorithm for aligning point clouds, released under a permissive BSD license.
+\libpointmatcher is a modular library implementing the Iterative Closest Point (ICP) algorithm for aligning point clouds, released under a permissive BSD license.
 
-\cgal provides wrappers for the ICP algorithm of \sc{libpointmatcher} in the \ref PkgPointSetProcessing3Ref
+\cgal provides wrappers for the ICP algorithm of \libpointmatcher in the \ref PkgPointSetProcessing3Ref
-packages. In order to use \sc{libpointmatcher} in \cgal programs, the
+packages. In order to use \libpointmatcher in \cgal programs, the
 executables should be linked with the CMake imported target
 `CGAL::pointmatcher_support` provided in
 `CGAL_pointmatcher_support.cmake`.
 
-The \sc{libpointmatcher} web site is <A
+The \libpointmatcher web site is <A
 HREF="https://github.com/ethz-asl/libpointmatcher">`https://github.com/ethz-asl/libpointmatcher`</A>.
 \attention On Windows, we only support version 1.3.1 of PointMatcher with version 3.3.7 of Eigen, with some changes to the recipe at
 `https://github.com/ethz-asl/libpointmatcher/blob/master/doc/CompilationWindows.md`:`NABO_INCLUDE_DIR` becomes `libnabo_INCLUDE_DIRS`
@@ -163,104 +163,104 @@ and `NABO_LIBRARY` becomes `libnabo_LIBRARIES` in the "Build libpointmatcher" se
 <b>Version 6.2 or later</b>
 
 \leda is a library of efficient data structures and
-algorithms. Like \sc{Core}, \leda offers a real number data type.
+algorithms. Like \core, \leda offers a real number data type.
 
 In \cgal this library is optional, and its number types can
-be used as an alternative to \sc{Gmp}, \sc{Mpfr}, and \sc{Core}.
+be used as an alternative to \gmp, \mpfr, and \core.
 
 Free and commercial editions of \leda are available from <A HREF="https://www.algorithmic-solutions.com">`https://www.algorithmic-solutions.com`</A>.
 
 \subsection thirdpartyMPFI Multiple Precision Floating-point Interval (MPFI)
 <b>Version 1.4 or later</b>
 
-\sc{Mpfi} provides arbitrary precision interval arithmetic with intervals
+\mpfi provides arbitrary precision interval arithmetic with intervals
-represented using \sc{Mpfr} reliable floating-point numbers.
+represented using \mpfr reliable floating-point numbers.
-It is based on the libraries \sc{Gmp} and \sc{Mpfr}.
+It is based on the libraries \gmp and \mpfr.
 In the setting of \cgal, this library is
 optional: it is used by some models of the
 \ref PkgAlgebraicKernelD "Algebraic Kernel".
 
-\sc{Mpfi} can be downloaded from <A HREF="https://mpfi.gforge.inria.fr/">`https://mpfi.gforge.inria.fr/`</A>.
+\mpfi can be downloaded from <A HREF="https://mpfi.gforge.inria.fr/">`https://mpfi.gforge.inria.fr/`</A>.
 
 \subsection thirdpartyRS3 RS and RS3
 
-\sc{Rs} (Real Solutions) is devoted to the study of the real roots of
+\rs (Real Solutions) is devoted to the study of the real roots of
 polynomial systems with a finite number of complex roots (including
-univariate polynomials). In \cgal, \sc{Rs} is used by one model of the
+univariate polynomials). In \cgal, \rs is used by one model of the
 \ref PkgAlgebraicKernelD "Algebraic Kernel".
 
-\sc{Rs} is freely distributable for non-commercial use. You can download it
+\rs is freely distributable for non-commercial use. You can download it
-from <a href="http://vegas.loria.fr/rs/">`http://vegas.loria.fr/rs/`</a>. Actually, the \sc{Rs} package also includes \sc{Rs3}, the
+from <a href="http://vegas.loria.fr/rs/">`http://vegas.loria.fr/rs/`</a>. Actually, the \rs package also includes \rs3, the
-successor of \sc{Rs}, which is used in conjunction with it.
+successor of \rs, which is used in conjunction with it.
 
-The libraries \sc{Rs} and \sc{Rs3} need \sc{Mpfi}, which can be downloaded from
+The libraries \rs and \rs3 need \mpfi, which can be downloaded from
 <A HREF="https://mpfi.gforge.inria.fr/">`https://mpfi.gforge.inria.fr/`</A>.
 
 \subsection thirdpartyNTL NTL
 <b>Version 5.1 or later</b>
 
-\sc{Ntl} provides data structures and algorithms for signed, arbitrary
+\ntl provides data structures and algorithms for signed, arbitrary
 length integers, and for vectors, matrices, and polynomials over the
-integers and over finite fields. The optional library \sc{Ntl} is used by \cgal
+integers and over finite fields. The optional library \ntl is used by \cgal
-to speed up operations of the Polynomial package, such as GCDs. It is recommended to install \sc{Ntl} with support from \sc{Gmp}.
+to speed up operations of the Polynomial package, such as GCDs. It is recommended to install \ntl with support from \gmp.
 
-\sc{Ntl} can be downloaded from <A HREF="https://www.shoup.net/ntl/">`https://www.shoup.net/ntl/`</A>.
+\ntl can be downloaded from <A HREF="https://www.shoup.net/ntl/">`https://www.shoup.net/ntl/`</A>.
 
 \subsection thirdpartyESBTL ESBTL
 
-The \sc{Esbtl} (Easy Structural Biology Template Library) is a library that allows
+The \esbtl (Easy Structural Biology Template Library) is a library that allows
-the handling of \sc{Pdb} data.
+the handling of \pdb data.
 
-In \cgal, the \sc{Esbtl} is used in an example of the \ref PkgSkinSurface3 package.
+In \cgal, the \esbtl is used in an example of the \ref PkgSkinSurface3 package.
 
 It can be downloaded from <A HREF="http://esbtl.sourceforge.net/">`http://esbtl.sourceforge.net/`</A>.
 
 \subsection thirdpartyTBB Intel TBB
 
-\sc{Tbb} (Threading Building Blocks) is a library developed by Intel Corporation for writing software
+\tbb (Threading Building Blocks) is a library developed by Intel Corporation for writing software
 programs that take advantage of multi-core processors.
 
-In \cgal, \sc{Tbb} is used by the packages that offer parallel
+In \cgal, \tbb is used by the packages that offer parallel
-code. In order to use \sc{Tbb} in \cgal programs, the executables
+code. In order to use \tbb in \cgal programs, the executables
 should be linked with the CMake imported target `CGAL::TBB_support`
 provided in `CGAL_TBB_support.cmake`.
 
-The \sc{Tbb} web site is <A HREF="https://www.threadingbuildingblocks.org">`https://www.threadingbuildingblocks.org`</A>.
+The \tbb web site is <A HREF="https://www.threadingbuildingblocks.org">`https://www.threadingbuildingblocks.org`</A>.
 
 \subsection thirdpartyLASlib LASlib
 
-\sc{LASlib} is a `C++` library for handling LIDAR data sets stored in
+\laslib is a `C++` library for handling LIDAR data sets stored in
 the LAS format (or the compressed LAZ format).
 
-In \cgal, \sc{LASlib} is used to provide input and output functions in
+In \cgal, \laslib is used to provide input and output functions in
-the \ref PkgPointSetProcessing3 package. In order to use \sc{LASlib}
+the \ref PkgPointSetProcessing3 package. In order to use \laslib
 in \cgal programs, the executables should be linked with the CMake
 imported target `CGAL::LASLIB_support` provided in
 `CGAL_LASLIB_support.cmake`.
 
-The \sc{LASlib} web site is <a
+The \laslib web site is <a
-href="https://rapidlasso.com/lastools/">`https://rapidlasso.com/lastools/`</a>. \sc{LASlib}
+href="https://rapidlasso.com/lastools/">`https://rapidlasso.com/lastools/`</a>. \laslib
 is usually distributed along with LAStools: for simplicity, \cgal
 provides <a href="https://github.com/CGAL/LAStools">a fork with a
 CMake based install procedure</a>.
 
 \subsection thirdpartyOpenCV OpenCV
 
-\sc{OpenCV} (Open Computer Vision) is a library designed for computer
+\opencv (Open Computer Vision) is a library designed for computer
 vision, computer graphics and machine learning.
 
-In \cgal, \sc{OpenCV} is used by the \ref PkgClassification
+In \cgal, \opencv is used by the \ref PkgClassification
-package. In order to use \sc{OpenCV} in \cgal programs, the
+package. In order to use \opencv in \cgal programs, the
 executables should be linked with the CMake imported target
 `CGAL::OpenCV_support` provided in `CGAL_OpenCV_support.cmake`.
 
-The \sc{OpenCV} web site is <A HREF="https://opencv.org/">`https://opencv.org/`</A>.
+The \opencv web site is <A HREF="https://opencv.org/">`https://opencv.org/`</A>.
 
 \subsection thirdpartyTensorFlow TensorFlow
 
-\sc{TensorFlow} is a library designed for machine learning and deep learning.
+\tensorflow is a library designed for machine learning and deep learning.
 
-In \cgal, the C++ API of \sc{TensorFlow} is used by the \ref
+In \cgal, the C++ API of \tensorflow is used by the \ref
 PkgClassification package for neural network. The C++ API can be
 compiled using CMake: it is distributed as part of the official
 package and is located in `tensorflow/contrib/cmake`. Be sure to
@@ -270,20 +270,20 @@ enable and compile the following targets:
 - `tensorflow_BUILD_PYTHON_BINDINGS`
 - `tensorflow_BUILD_SHARED_LIB`.
 
-In order to use \sc{TensorFlow} in \cgal programs, the executables
+In order to use \tensorflow in \cgal programs, the executables
 should be linked with the CMake imported target
 `CGAL::TensorFlow_support` provided in
 `CGAL_TensorFlow_support.cmake`.
 
-The \sc{TensorFlow} web site is <A HREF="https://www.tensorflow.org/">`https://www.tensorflow.org/`</A>.
+The \tensorflow web site is <A HREF="https://www.tensorflow.org/">`https://www.tensorflow.org/`</A>.
 
 \subsection thirdpartyMETIS METIS
 <b>Version 5.1 or later</b>
 
-\sc{METIS} is a library developed by the <A HREF="http://glaros.dtc.umn.edu/gkhome/">Karypis Lab</A>
+\metis is a library developed by the <A HREF="http://glaros.dtc.umn.edu/gkhome/">Karypis Lab</A>
 and designed to partition graphs and produce fill-reducing matrix orderings.
 
-\cgal offers wrappers around some of the methods of the \sc{METIS} library
+\cgal offers wrappers around some of the methods of the \metis library
 to allow the partitioning of graphs that are models of the concepts of the
 <A HREF="https://www.boost.org/libs/graph/doc/index.html">Boost Graph Library</A>,
 and, by extension, of surface meshes (see Section \ref BGLPartitioning of the package \ref PkgBGL).
@@ -293,7 +293,7 @@ at <A HREF="http://glaros.dtc.umn.edu/gkhome/metis/metis/overview">`http://glaro
 
 \subsection thirdpartyzlib zlib
 
-\sc{zlib} is a data compression library, and is essential for the component libCGAL_ImageIO.
+\zlib is a data compression library, and is essential for the component libCGAL_ImageIO.
 
 In \cgal, this library is used in the examples of the \ref PkgSurfaceMesher3 package.
 
@@ -302,9 +302,9 @@ for instance, on Windows, you can download it from <A HREF="https://www.zlib.net
 
 \subsection thirdpartyCeres Ceres Solver
 
-\sc{Ceres} is an open source C++ library for modeling and solving large, complicated optimization problems.
+\ceres is an open source C++ library for modeling and solving large, complicated optimization problems.
 
-In \cgal, \sc{Ceres} is used by the \ref PkgPolygonMeshProcessingRef package for mesh smoothing, which
+In \cgal, \ceres is used by the \ref PkgPolygonMeshProcessingRef package for mesh smoothing, which
 requires solving complex non-linear least squares problems.
 
 Visit the official website of the library at <A HREF="http://ceres-solver.org/index.html">`ceres-solver.org`</A>
@@ -312,26 +312,26 @@ for more information.
 
 \subsection thirdpartyGLPK GLPK
 
-\sc{GLPK} (GNU Linear Programming Kit) is a library for solving linear programming (LP), mixed integer programming (MIP), and other related problems.
+\glpk (GNU Linear Programming Kit) is a library for solving linear programming (LP), mixed integer programming (MIP), and other related problems.
 
-In \cgal, \sc{GLPK} provides an optional linear integer program solver
+In \cgal, \glpk provides an optional linear integer program solver
 in the \ref PkgPolygonalSurfaceReconstruction package. In order to use
-\sc{GLPK} in \cgal programs, the executables should be linked with the
+\glpk in \cgal programs, the executables should be linked with the
 CMake imported target `CGAL::GLPK_support` provided in
 `CGAL_GLPK_support.cmake`.
 
-The \sc{GLPK} web site is <A HREF="https://www.gnu.org/software/glpk/">`https://www.gnu.org/software/glpk/`</A>.
+The \glpk web site is <A HREF="https://www.gnu.org/software/glpk/">`https://www.gnu.org/software/glpk/`</A>.
 
 \subsection thirdpartySCIP SCIP
 
-\sc{SCIP} (Solving Constraint Integer Programs) is currently one of the fastest open source solvers for mixed integer programming (MIP) and mixed integer nonlinear programming (MINLP).
+\scip (Solving Constraint Integer Programs) is currently one of the fastest open source solvers for mixed integer programming (MIP) and mixed integer nonlinear programming (MINLP).
 
-In \cgal, \sc{SCIP} provides an optional linear integer program solver
+In \cgal, \scip provides an optional linear integer program solver
 in the \ref PkgPolygonalSurfaceReconstruction package. In order to use
-\sc{SCIP} in \cgal programs, the executables should be linked with the
+\scip in \cgal programs, the executables should be linked with the
 CMake imported target `CGAL::SCIP_support` provided in
 `CGAL_SCIP_support.cmake`.
 
-The \sc{SCIP} web site is <A HREF="http://scip.zib.de/">`http://scip.zib.de/`</A>.
+The \scip web site is <A HREF="http://scip.zib.de/">`http://scip.zib.de/`</A>.
 
 */

Documentation/doc/Documentation/Tutorials/Tutorial_GIS.txt

@@ -276,7 +276,7 @@ classifier currently available in \cgal is the %random forest from
 ETHZ. As it is a supervised classifier, a training set is needed.
 
 The following snippet shows how to use some manually selected training
-set to train a %fandom rorest classifier and compute a classification
+set to train a %random forest classifier and compute a classification
 regularized by a graph cut algorithm:
 
 \snippet Classification/gis_tutorial_example.cpp Classification

Documentation/doc/Documentation/Usage.txt

@@ -83,9 +83,9 @@ contains the following subdirectories:
 
 | Directory                  | Contents   |
 | :------------------------- | :----------|
-| `auxiliary` (Windows only) | precompiled \sc{Gmp} and \sc{Mpfr} for Windows |
+| `auxiliary` (Windows only) | precompiled \gmp and \mpfr for Windows |
 | `cmake/modules`            | modules for finding and using libraries |
-| `demo`                     | demo programs (most of them need \sc{Qt}, geomview or other third-party products) |
+| `demo`                     | demo programs (most of them need \qt, geomview or other third-party products) |
 | `doc_html`                 | documentation (HTML) |
 | `examples`                 | example programs |
 | `include`                  | header files |
@@ -94,13 +94,13 @@ contains the following subdirectories:
 
 The directories `include/CGAL/CORE` and `src/CGALCore` contain a
 distribution of the <a href="https://cs.nyu.edu/exact/">Core library</a> version 1.7 for
-dealing with algebraic numbers. Note that \sc{Core} is not part of \cgal and has its
+dealing with algebraic numbers. Note that \core is not part of \cgal and has its
 own license.
 
 The directory `include/CGAL/OpenNL` contains a distribution of the
 <a href="http://alice.loria.fr/index.php/software/4-library/23-opennl.html">Open Numerical Library</a>,
 which provides solvers for sparse linear systems, especially designed for the Computer Graphics community.
-\sc{OpenNL} is not part of \cgal and has its own license.
+\opennl is not part of \cgal and has its own license.
 
 The only documentation shipped within \cgal sources is the present manual.
 The \cgal manual can also be accessed online at
@@ -123,7 +123,7 @@ a standard location (such as `/usr/local/include`):
 For more advanced installations, we refer to Section \ref installation_configwithcmake.
 
 Note that even though \cgal is a header-only library, not all its dependencies
-are header-only. The libraries \sc{Gmp} and \sc{Mpfr}, for example, are not
+are header-only. The libraries \gmp and \mpfr, for example, are not
 header-only. As such, these dependencies must be built or installed independently.
 
 \section usage_configuring Configuring your Program
@@ -235,7 +235,7 @@ The results of a successful configuration are build files that control the build
 The nature of the build files depends on the generator used during configuration, but in most cases
 they contain several <I>targets</I>, such as all the examples of the Triangulation_2 package.
 
-In a \sc{Unix}-like environment the default generator produces makefiles.
+In a \unix-like environment the default generator produces makefiles.
 You can use the `make` command-line tool for the succeeding build step as follows:
 
     cd CGAL-\cgalReleaseNumber/examples/Triangulation_2

Documentation/doc/Documentation/advanced/Configuration_variables.txt

@@ -103,30 +103,30 @@ other but never both.
 
 \subsection installation_boost Boost Libraries
 
-In most cases, if \sc{Boost} is not automatically found, setting the `BOOST_ROOT`
+In most cases, if \boost is not automatically found, setting the `BOOST_ROOT`
 variable is enough. If it is not, you can specify the header and library
 directories individually. You can also provide the full pathname to a specific compiled library
 if it cannot be found in the library directory or its name is non-standard.
 
-By default, when \sc{Boost} binary libraries are needed, the shared versions
+By default, when \boost binary libraries are needed, the shared versions
 are used if present. You can set the variable
 `CGAL_Boost_USE_STATIC_LIBS` to `ON` if you want to link
 with static versions explicitly.
 
-On Windows, if you link with \sc{Boost} shared libraries, you must ensure that
+On Windows, if you link with \boost shared libraries, you must ensure that
 the `.dll` files are found by the dynamic linker, at run time.
-For example, you can add the path to the \sc{Boost} `.dll` to the
+For example, you can add the path to the \boost `.dll` to the
 `PATH` environment variable.
 
 | Variable              | Description                                                           | Type        |
 | :-                    | :-                    | :-             |
-| `BOOST_ROOT`\cgalFootnote{The environment variable can be spelled either `BOOST_ROOT` or `BOOSTROOT`} | Root directory of your \sc{Boost} installation | Either CMake or Environment |
+| `BOOST_ROOT`\cgalFootnote{The environment variable can be spelled either `BOOST_ROOT` or `BOOSTROOT`} | Root directory of your \boost installation | Either CMake or Environment |
 | `Boost_INCLUDE_DIR`   | Directory containing the `boost/version.hpp` file  | CMake |
 | `BOOST_INCLUDEDIR`    | Idem | Environment |
-| `Boost_LIBRARY_DIRS`  | Directory containing the compiled \sc{Boost} libraries  | CMake |
+| `Boost_LIBRARY_DIRS`  | Directory containing the compiled \boost libraries  | CMake |
 | `BOOST_LIBRARYDIR`    | Idem | Environment |
-| `Boost_(xyz)_LIBRARY_RELEASE`  | Full pathname to a release build of the compiled 'xyz' \sc{Boost} library | CMake |
+| `Boost_(xyz)_LIBRARY_RELEASE`  | Full pathname to a release build of the compiled 'xyz' \boost library | CMake |
-| `Boost_(xyz)_LIBRARY_DEBUG` | Full pathname to a debug build of the compiled 'xyz' \sc{Boost} library | CMake |
+| `Boost_(xyz)_LIBRARY_DEBUG` | Full pathname to a debug build of the compiled 'xyz' \boost library | CMake |
 
 
 \subsection installation_gmp GMP and MPFR Libraries
@@ -136,42 +136,42 @@ containing the libraries is needed and you would specify `GMP|MPFR_LIBRARY_DIR`
 `GMP|MPFR_LIBRARIES`. On the other hand, under Linux the actual library filename is needed.
 Thus you would specify `GMP|MPFR_LIBRARIES`. In no case you need to specify both.
 
-\cgal uses both \sc{Gmp} and \sc{Mpfr} so both need to be supported. If either of them is unavailable the
+\cgal uses both \gmp and \mpfr so both need to be supported. If either of them is unavailable the
-usage of \sc{Gmp} and of \sc{Mpfr} will be disabled.
+usage of \gmp and of \mpfr will be disabled.
 
 
 | Variable              | Description                                                           | Type        |
 | :-                    | :-                    | :-             |
-| `CGAL_DISABLE_GMP`    | Indicates whether to search and use \sc{Gmp}/\sc{Mpfr} or not  | CMake |
+| `CGAL_DISABLE_GMP`    | Indicates whether to search and use \gmp/\mpfr or not  | CMake |
-| `GMP_DIR`  | Directory of \sc{Gmp} default installation  | Environment |
+| `GMP_DIR`  | Directory of \gmp default installation  | Environment |
 | `GMP_INCLUDE_DIR`  | Directory containing the `gmp.h` file  | CMake |
 | `GMP_INC_DIR` | Idem | Environment |
-| `GMP_LIBRARIES_DIR`  | Directory containing the compiled \sc{Gmp} library | CMake |
+| `GMP_LIBRARIES_DIR`  | Directory containing the compiled \gmp library | CMake |
 | `GMP_LIB_DIR` | Idem | Environment |
-| `GMP_LIBRARIES` | Full pathname of the compiled \sc{Gmp} library  | CMake |
+| `GMP_LIBRARIES` | Full pathname of the compiled \gmp library  | CMake |
 | `MPFR_INCLUDE_DIR` | Directory containing the `mpfr.h` file | CMake |
 | `MPFR_INC_DIR`  | Idem | Environment |
-| `MPFR_LIBRARIES_DIR` | Directory containing the compiled \sc{Mpfr} library | CMake |
+| `MPFR_LIBRARIES_DIR` | Directory containing the compiled \mpfr library | CMake |
 | `MPFR_LIB_DIR` | Idem | Environment |
-| `MPFR_LIBRARIES`  | Full pathname of the compiled \sc{Mpfr} library | CMake |
+| `MPFR_LIBRARIES`  | Full pathname of the compiled \mpfr library | CMake |
 
 
 
-Under Linux, the \sc{Gmpxx} is also searched for, and you may specify the following variables:
+Under Linux, the \gmpxx is also searched for, and you may specify the following variables:
 
 
 | Variable              | Description                                                           | Type        |
 | :-                    | :-                    | :-             |
-| `GMPXX_DIR` | Directory of \sc{gmpxx} default installation | Environment |
+| `GMPXX_DIR` | Directory of \gmpxx default installation | Environment |
 | `GMPXX_INCLUDE_DIR`  | Directory containing the `gmpxx.h` file  | CMake |
-| `GMPXX_LIBRARIES`  | Full pathname of the compiled \sc{Gmpxx} library  | CMake |
+| `GMPXX_LIBRARIES`  | Full pathname of the compiled \gmpxx library  | CMake |
 
 
 
 \subsection installation_qt5 Qt5 Library
 
 You must set the cmake or environment variable `Qt5_DIR` to point to the path
-to the directory containing the file `Qt5Config.cmake` created by your \sc{Qt}5 installation. If you are
+to the directory containing the file `Qt5Config.cmake` created by your \qt5 installation. If you are
 using the open source edition it should be `<path>/qt-everywhere-opensource-src-<version>/qtbase/lib/cmake/Qt5`.
 
 \subsection installation_leda LEDA Library
@@ -188,7 +188,7 @@ The variables specifying definitions and flags can be left undefined if they are
 | Variable               | Description           | Type        |
 | :-                     | :-                    | :-             |
 | `WITH_LEDA`            | Indicates whether to search and use \leda or not | CMake |
-| `LEDA_DIR`             | Directory of \sc{LEDA} default installation | Environment |
+| `LEDA_DIR`             | Directory of \leda default installation | Environment |
 | `LEDA_INCLUDE_DIR`     | Directory containing the file `LEDA/system/basic.h` | CMake |
 | `LEDA_LIBRARIES`       | Directory containing the compiled \leda libraries | CMake |
 | `LEDA_INC_DIR`         | Directory containing the file `LEDA/system/basic.h` | Environment |
@@ -203,21 +203,21 @@ The variables specifying definitions and flags can be left undefined if they are
 \subsection installation_mpfi MPFI Library
 
 \cgal provides a number type based on this library, but the \cgal library
-itself does not depend on \sc{Mpfi}. This means that this library must be
+itself does not depend on \mpfi. This means that this library must be
 configured when compiling an application that uses the above number type.
 
-When \sc{Mpfi} files are not on the standard path, the locations of the headers
+When \mpfi files are not on the standard path, the locations of the headers
 and library files must be specified by using environment variables.
 
 
 | Variable             | Description           | Type        |
 | :-                   | :-                    | :-             |
-| `MPFI_DIR`           |Directory of \sc{MPFI} default installation | Environment |
+| `MPFI_DIR`           |Directory of \mpfi default installation | Environment |
 | `MPFI_INCLUDE_DIR`   | Directory containing the `mpfi.h` file | CMake |
 | `MPFI_INC_DIR`       | Idem | Environment |
-| `MPFI_LIBRARIES_DIR` | Directory containing the compiled \sc{Mpfi} library | CMake |
+| `MPFI_LIBRARIES_DIR` | Directory containing the compiled \mpfi library | CMake |
 | `MPFI_LIB_DIR`       | Idem | Environment |
-| `MPFI_LIBRARIES`     | Full pathname of the compiled \sc{Mpfi} library | CMake |
+| `MPFI_LIBRARIES`     | Full pathname of the compiled \mpfi library | CMake |
 
 
 
@@ -231,55 +231,55 @@ CMake will try to find Rs in the standard header and library
 directories. When it is not automatically detected, the locations of the
 headers and library files must be specified using environment variables.
 
-Rs needs \sc{Gmp} 4.2 or later and \sc{Mpfi} 1.3.4 or later. The variables
+Rs needs \gmp 4.2 or later and \mpfi 1.3.4 or later. The variables
 related to the latter library may also need to be defined.
 
 
 | Variable             | Description           | Type        |
 | :-                   | :-                    | :-             |
-| `RS_DIR` | Directory of \sc{Rs} default installation | Environment |
+| `RS_DIR` | Directory of \rs default installation | Environment |
 | `RS_INCLUDE_DIR` | Directory containing the `rs_exports.h` file | CMake |
 | `RS_INC_DIR` | Idem | Environment |
-| `RS_LIBRARIES_DIR`  | Directory containing the compiled \sc{Rs} library | CMake |
+| `RS_LIBRARIES_DIR`  | Directory containing the compiled \rs library | CMake |
 | `RS_LIB_DIR` | Idem | Environment |
-| `RS_LIBRARIES` | Full pathname of the compiled \sc{Rs} library | CMake |
+| `RS_LIBRARIES` | Full pathname of the compiled \rs library | CMake |
 
-Similar variables exist for \sc{Rs3}.
+Similar variables exist for \rs3.
 
 | Variable             | Description           | Type        |
 | :-                   | :-                    | :-
-| `RS3_DIR` | Directory of \sc{Rs3} default installation | Environment |
+| `RS3_DIR` | Directory of \rs3 default installation | Environment |
 | `RS3_INCLUDE_DIR` | Directory containing the file `rs3_fncts.h` file | CMake |
 | `RS3_INC_DIR` | Idem | Environment |
-| `RS3_LIBRARIES_DIR` | Directory containing the compiled \sc{Rs3} library | CMake |
+| `RS3_LIBRARIES_DIR` | Directory containing the compiled \rs3 library | CMake |
 | `RS3_LIB_DIR` | Idem | Environment |
-| `RS3_LIBRARIES` | Full pathname of the compiled \sc{Rs3} library | CMake |
+| `RS3_LIBRARIES` | Full pathname of the compiled \rs3 library | CMake |
 
 
 \subsection installation_ntl NTL Library
 
 Some polynomial computations in \cgal's algebraic kernel
-are speed up when \sc{Ntl} is available.
+are speed up when \ntl is available.
 As the algebraic kernel is not compiled as a part of the \cgal
 library, this library is not detected nor configured at installation time.
 
-CMake will try to find \sc{Ntl} in the standard header and library
+CMake will try to find \ntl in the standard header and library
 directories. When it is not automatically detected, the locations of the
 headers and library files must be specified using environment variables.
 
 | Variable             | Description           | Type        |
 | :-                   | :-                    | :-             |
-| `NTL_DIR` | Directory of \sc{NTL} default installation | Environment |
+| `NTL_DIR` | Directory of \ntl default installation | Environment |
 | `NTL_INCLUDE_DIR` | Directory containing the `NTL/ZZX.h` file | CMake |
 | `NTL_INC_DIR` | Idem | Environment |
-| `NTL_LIBRARIES_DIR` | Directory containing the compiled \sc{Ntl} library | CMake |
+| `NTL_LIBRARIES_DIR` | Directory containing the compiled \ntl library | CMake |
 | `NTL_LIB_DIR` | Idem | Environment |
-| `NTL_LIBRARIES` | Full pathname of the compiled \sc{Ntl} library | CMake |
+| `NTL_LIBRARIES` | Full pathname of the compiled \ntl library | CMake |
 
 \subsection installation_eigen Eigen Library
 
-\sc{Eigen} is a header-only template library.
+\eigen is a header-only template library.
-Only the <I>directory</I> containing the header files of \sc{Eigen} 3.1 (or greater) is needed.
+Only the <I>directory</I> containing the header files of \eigen 3.1 (or greater) is needed.
 
 
 | Variable             | Description           | Type        |
@@ -289,35 +289,35 @@ Only the <I>directory</I> containing the header files of \sc{Eigen} 3.1 (or grea
 
 \subsection installation_esbtl ESBTL Library
 
-One skin surface example requires the \sc{Esbtl} library in order to read \sc{Pdb} files.
+One skin surface example requires the \esbtl library in order to read \pdb files.
 
-If \sc{Esbtl} is not automatically found, setting the `ESBTL_INC_DIR`
+If \esbtl is not automatically found, setting the `ESBTL_INC_DIR`
 environment variable is sufficient.
 
 
 | Variable             | Description           | Type        |
 | :-                   | :-                    | :-             |
-| `ESBTL_DIR` | Directory of \sc{ESBTL} default installation | Environment |
+| `ESBTL_DIR` | Directory of \esbtl default installation | Environment |
 | `ESBTL_INC_DIR` | Directory containing the `ESBTL/default.h` file | Environment |
 | `ESBTL_INCLUDE_DIR` | Directory containing the `ESBTL/default.h` file | CMake |
 
 \subsection installation_metis METIS Library
 
-Some BGL examples require the \sc{Metis} library in order to partition \sc{Metis} meshes.
+Some BGL examples require the \metis library in order to partition \metis meshes.
 
-If \sc{Metis} is not automatically found, setting the `METIS_INCLUDE_DIR` and `METIS_LIBRARY`
+If \metis is not automatically found, setting the `METIS_INCLUDE_DIR` and `METIS_LIBRARY`
 cmake variables is necessary.
 
 
 | Variable             | Description           | Type        |
 | :-                   | :-                    | :-             |
-| `METIS_INCLUDE_DIR` | Directory of \sc{Metis} default installation | CMAKE |
+| `METIS_INCLUDE_DIR` | Directory of \metis default installation | CMAKE |
 | `METIS_LIBRARY` | Directory containing the `libmetis.so or .lib` file | CMAKE |
 
 
 \subsection installation_tbb TBB Library
 
-If \sc{Tbb} is not automatically found, the user must set the `TBB_ROOT`
+If \tbb is not automatically found, the user must set the `TBB_ROOT`
 environment variable. The environment variable `TBB_ARCH_PLATFORM=<arch>/<compiler>` must be set.
 `<arch>` is `ia32` or `intel64`. `<compiler>` describes the Linux kernel, gcc version or Visual Studio version
 used. It should be set to what is used in `$TBB_ROOT/lib/<arch>`.
@@ -328,7 +328,7 @@ Note that the variables in the table below are being used.
 
 | Variable             | Description           | Type        |
 | :-                   | :-                    | :-             |
-| `TBB_ROOT` | Directory of \sc{Tbb} default installation | Environment |
+| `TBB_ROOT` | Directory of \tbb default installation | Environment |
 | `TBB_INCLUDE_DIRS` | Directory containing the `tbb/tbb.h` file | CMake |
 | `TBB_LIBRARY_DIRS` | Directory(ies) containing the compiled TBB libraries | CMake |
 | `TBB_LIBRARIES` | Full pathnames of the compiled TBB libraries (both release and debug versions, using "optimized" and "debug" CMake keywords). Note that if the debug versions are not found, the release versions will be used instead for the debug mode. | CMake |

Documentation/doc/Documentation/advanced/Installation.txt

@@ -60,10 +60,10 @@ Note that some libraries have specific dependencies in addition to the essential
 
 | Library   | CMake Variable | Functionality | Dependencies |
 | :-------- | :------------- | :------------ | :----------- |
-| `%CGAL`   | none           | Main library  | \sc{Gmp}, \sc{Mpfr}, \sc{Boost} (headers) |
+| `%CGAL`   | none           | Main library  | \gmp, \mpfr, \boost (headers) |
-| `CGAL_Core` | `WITH_CGAL_Core`  | The %CORE library for algebraic numbers.\cgalFootnote{CGAL_Core is not part of \cgal, but a custom version of the \sc{Core} library distributed by \cgal for the user convenience and it has it's own license.}  | \sc{Gmp} and \sc{Mpfr} |
+| `CGAL_Core` | `WITH_CGAL_Core`  | The %CORE library for algebraic numbers.\cgalFootnote{CGAL_Core is not part of \cgal, but a custom version of the \core library distributed by \cgal for the user convenience and it has it's own license.}  | \gmp and \mpfr |
-| `CGAL_ImageIO` | `WITH_CGAL_ImageIO` | Utilities to read and write image files  | \sc{zlib}, \sc{Vtk} (optional) |
+| `CGAL_ImageIO` | `WITH_CGAL_ImageIO` | Utilities to read and write image files  | \zlib, \vtk (optional) |
-| `CGAL_Qt5`  | `WITH_CGAL_Qt5` | `QGraphicsView` support for \sc{Qt}5-based demos | \sc{Qt}5 |
+| `CGAL_Qt5`  | `WITH_CGAL_Qt5` | `QGraphicsView` support for \qt5-based demos | \qt5 |
 
 Shared libraries, also called <I>dynamic-link libraries</I>, are built by default
 (`.so` on Linux, `.dylib` on macOS). You
@@ -77,7 +77,7 @@ the \cgal libraries, unless you set the variables `WITH_examples=ON` and/or `WIT
 Additionally, even when configured with \cgal, they are not automatically built along with the libraries.
 You must build the `examples` or `demos` targets (or IDE projects) explicitly.
 
-If you do not plan to compile any demos, you may skip some of the dependencies (such as \sc{Qt}),
+If you do not plan to compile any demos, you may skip some of the dependencies (such as \qt),
 as the corresponding \cgal-libraries will not be used. Note, however, that your own demos
 might need these \cgal-libraries and thus their dependencies. See the page
 \ref secessential3rdpartysoftware for more information.
@@ -215,7 +215,7 @@ The nature of the build files depends on the generator used during configuration
 contain several <I>targets</I>, one per library, and a default global target corresponding
 to all the libraries.
 
-For example, in a \sc{Unix}-like environment the default generator produces makefiles.
+For example, in a \unix-like environment the default generator produces makefiles.
 You can use the `make` command-line tool for the succeeding build step as follows:
 
     # build all the selected libraries at once
@@ -277,7 +277,7 @@ the installation simply amounts to:
 
 \cgalAdvancedBegin
 The files are copied into a directory tree relative to the <I>installation directory</I> determined by the
-CMake variable `CMAKE_INSTALL_PREFIX`. This variable defaults to `/usr/local` under \sc{Unix}-like operating systems.
+CMake variable `CMAKE_INSTALL_PREFIX`. This variable defaults to `/usr/local` under \unix-like operating systems.
 If you want to install to a different location, you must override that CMake
 variable explicitly <I>at the configuration time</I> and not when executing the install step.
 \cgalAdvancedEnd

Documentation/doc/Documentation/manual.txt

@@ -11,7 +11,7 @@ of computational geometry.
 Each part consists of several chapters,
 and each chapter is split into a *User Manual*  and a *Reference
 Manual*. The User Manual gives the general idea and comes with examples.
-The Reference Manual presents the \sc{Api} of the various classes
+The Reference Manual presents the \api of the various classes
 and functions.
 
 The manual has a \ref packages  with a short paragraph explaining

Documentation/doc/Documentation/windows.txt

@@ -2,8 +2,8 @@
 \page windows Using %CGAL on Windows (with Visual C++)
 \cgalAutoToc
 
-\cgal \cgalReleaseNumber is supported for the following \sc{MS} Visual `C++` compilers:
+\cgal \cgalReleaseNumber is supported for the following \ms Visual `C++` compilers:
-14.0, 15.9, 16.0 (\sc{Visual Studio} 2015, 2017, and 2019).
+14.0, 15.9, 16.0 (\visualstudio 2015, 2017, and 2019).
 
 \cgal is a library that has mandatory dependencies that must be first installed:
 \ref thirdpartyBoost and \ref thirdpartyMPFR.
@@ -16,9 +16,9 @@ installation instructions.
 
 If you choose to use `vcpkg`, you might have to bootstrap and download
 and compile it, but from then on `vcpkg` will make your life easier.
-On the other hand, if you need to specify a specific version, or have already installed
+On the other hand, if you need to use a specific version, or have already installed
 a certain version of a dependency and do not wish to potentially have multiple versions installed,
-you will want to use the \cgal Installer.
+you will want to use the \cgal source archive.
 
 We explain the two approaches in the next two sections.
 
@@ -43,12 +43,16 @@ We refer to the
 <a href="https://github.com/microsoft/vcpkg/blob/master/docs/examples/installing-and-using-packages.md#step-2-use">official documentation</a>
 of `vcpkg` if you want to compile for an older version of a compiler.
 
+Because of a bug with gmp in vcpkg for windows, you need to install `yasm-tool` in 32 bits to be able to correctly build gmp 64bits, needed for cgal:
+
+    C:\dev\vcpkg> ./vcpkg.exe install yasm-tool:x86-windows
+
 You are now ready to install \cgal:
 
     C:\dev\vcpkg> ./vcpkg.exe install cgal
 
-This will take several minutes as it downloads \mpir (a fork of \gmp),
+This will take several minutes as it downloads  \gmp,
-\mpfr, all boost header files, and it will compile \mpir and \mpfr, as well
+\mpfr, all boost header files, and it will compile \gmp and \mpfr, as well
 as several boost libraries.
 Afterwards, you will find the include files, libraries, and dlls in the
 subdirectory `C:\dev\vcpkg\installed\x64-windows`.
@@ -146,11 +150,19 @@ you are advised to look at the `CMakeLists.txt` files in the example
 folder of the package(s) that you are using to learn how to specify \cgal and additional third party
 dependencies.
 
-\section install-with-installer Installing with the CGAL Installer
+\section install-from-source Installing from the Source Archive
+
+You can download and extract `CGAL-\cgalReleaseNumber``.zip` from https://www.cgal.org/download/windows.html.
+
+\subsection ssect-installer-gmp-mpfr Installing GMP and MPFR
+
+Precompiled version of \gmp and \mpfr are provided in the asset <i>GMP and MPFR libraries, for Windows 64bits</i>
+from https://github.com/CGAL/cgal/releases.
+If you only install those libraries to use \cgal, then you should extract this archive inside the directory
+`CGAL-\cgalReleaseNumber` created when extracting the \cgal zip source archive.
+That way those dependencies will be automatically detected by cmake
+(you should then get the directory `CGAL-\cgalReleaseNumber``\``auxiliary``\``gmp`).
 
-You can download and run `CGAL-\cgalReleaseNumber``-Setup.exe` from https://www.cgal.org/download/windows.html.
-It is a self-extracting executable that downloads the \cgal header files, and optionally the source code of the
-examples and demos. Additionally, it can download precompiled versions of \gmp and \mpfr.
 
 \subsection ssect-installer-boost Installing Boost
 
@@ -267,9 +279,4 @@ you are advised to look at the `CMakeLists.txt` files in the example
 folder of the package(s) that you are using to learn how to specify \cgal and additional third party
 dependencies.
 
-\section install-with-tarball Installing from the Source Archive
-
-Instead of the installer you can also download release tarballs. The sole difference
-is that the installer also downloads precompiled \gmp and \mpfr libraries.
-
 */

Documentation/doc/biblio/cgal_manual.bib

@@ -659,6 +659,25 @@ Mourrain and Monique Teillaud"
   keywords = "Convex hull problem, Frame, Linear programming, Data envelopment analysis, Redundancy"
 }
 
+@article{cgal:dl-cginc-19,
+  author = {Despr\'{e}, Vincent and Lazarus, Francis},
+  title = {Computing the Geometric Intersection Number of Curves},
+  year = {2019},
+  issue_date = {December 2019},
+  publisher = {Association for Computing Machinery},
+  address = {New York, NY, USA},
+  volume = {66},
+  number = {6},
+  issn = {0004-5411},
+  url = {https://doi.org/10.1145/3363367},
+  doi = {10.1145/3363367},
+  journal = {J. ACM},
+  month = nov,
+  articleno = {45},
+  numpages = {49},
+  keywords = {combinatorial geodesic, Computational topology, intersection number, curves on surfaces}
+}
+
 @unpublished{cgal:dl-cosfa-08,
   author = "J.H. Dul\'a and F.J. L\'opez",
   title = "Competing Output-Sensitive Frame Algorithms",

Documentation/doc/resources/1.8.13/BaseDoxyfile.in

@@ -228,19 +228,53 @@ TAB_SIZE               = 4
 # "Side Effects:". You can put \n's in the value part of an alias to insert
 # newlines.
 
-ALIASES                = "sc{1}=<span style=\"font-variant: small-caps;\">\1</span>" \
+ALIASES                = "cgal=CGAL" \
-                         "cgal=\sc{%CGAL}" \
+                         "protocgal=C++gal" \
-                         "protocgal=\sc{C++gal}" \
+                         "plageo=Plageo" \
-                         "plageo=\sc{Plageo}" \
+                         "stl=STL" \
-                         "stl=\sc{STL}" \
+                         "gmp=GMP" \
-                         "gmp=\sc{GMP}" \
+                         "gmpxx=GMPXX" \
-                         "mpir=\sc{MPIR}" \
+                         "mpir=MPIR" \
-                         "mpfr=\sc{MPFR}" \
+                         "mpfr=MPFR" \
-                         "leda=\sc{LEDA}" \
+                         "leda=LEDA" \
-                         "gcc=\sc{GCC}" \
+                         "gcc=GCC" \
-                         "cpp=\sc{C++}" \
+                         "dcel=DCEL" \
-                         "cpp11=\sc{C++11}" \
+                         "bgl=BGL" \
-                         "CC=\sc{C++}" \
+                         "boost=Boost" \
+                         "gnu=GNU" \
+                         "ms=MS" \
+                         "qt=Qt" \
+                         "qt5=Qt5" \
+                         "eigen=Eigen" \
+                         "opengr=OpenGR" \
+                         "libpointmatcher=libpointmatcher" \
+                         "core=Core" \
+                         "mpfi=MPFI" \
+                         "ntl=NTL" \
+                         "pdb=PDB" \
+                         "esbtl=ESBTL" \
+                         "tbb=TBB" \
+                         "laslib=LASlib" \
+                         "opencv=OpenCV" \
+                         "tensorflow=TensorFlow" \
+                         "metis=METIS" \
+                         "zlib=zlib" \
+                         "ceres=Ceres" \
+                         "glpk=GLPK" \
+                         "scip=SCIP" \
+                         "rs=RS" \
+                         "rs3=RS3" \
+                         "unix=Unix" \
+                         "api=API" \
+                         "vtk=VTK" \
+                         "visualstudio=Visual Studio" \
+                         "taucs=TAUCS" \
+                         "lapack=LAPACK" \
+                         "blas=BLAS" \
+                         "opennl=OpenNL" \
+                         "cpp=C++" \
+                         "cpp11=C++11" \
+                         "CC=C++" \
                          "cgalExample{1}=<br><b>File</b> \ref \1 \include \1" \
                          "cgalFigureAnchor{1}=\anchor fig__\1" \
                          "cgalFigureRef{1}=\ref fig__\1" \

Documentation/doc/resources/1.8.14/BaseDoxyfile.in

@@ -229,19 +229,53 @@ TAB_SIZE               = 4
 # newlines (in the resulting output). You can put ^^ in the value part of an
 # alias to insert a newline as if a physical newline was in the original file.
 
-ALIASES                = "sc{1}=<span style=\"font-variant: small-caps;\">\1</span>" \
+ALIASES                = "cgal=CGAL" \
-                         "cgal=\sc{%CGAL}" \
+                         "protocgal=C++gal" \
-                         "protocgal=\sc{C++gal}" \
+                         "plageo=Plageo" \
-                         "plageo=\sc{Plageo}" \
+                         "stl=STL" \
-                         "stl=\sc{STL}" \
+                         "gmp=GMP" \
-                         "gmp=\sc{GMP}" \
+                         "gmpxx=GMPXX" \
-                         "mpir=\sc{MPIR}" \
+                         "mpir=MPIR" \
-                         "mpfr=\sc{MPFR}" \
+                         "mpfr=MPFR" \
-                         "leda=\sc{LEDA}" \
+                         "leda=LEDA" \
-                         "gcc=\sc{GCC}" \
+                         "gcc=GCC" \
-                         "cpp=\sc{C++}" \
+                         "dcel=DCEL" \
-                         "cpp11=\sc{C++11}" \
+                         "bgl=BGL" \
-                         "CC=\sc{C++}" \
+                         "boost=Boost" \
+                         "gnu=GNU" \
+                         "ms=MS" \
+                         "qt=Qt" \
+                         "qt5=Qt5" \
+                         "eigen=Eigen" \
+                         "opengr=OpenGR" \
+                         "libpointmatcher=libpointmatcher" \
+                         "core=Core" \
+                         "mpfi=MPFI" \
+                         "ntl=NTL" \
+                         "pdb=PDB" \
+                         "esbtl=ESBTL" \
+                         "tbb=TBB" \
+                         "laslib=LASlib" \
+                         "opencv=OpenCV" \
+                         "tensorflow=TensorFlow" \
+                         "metis=METIS" \
+                         "zlib=zlib" \
+                         "ceres=Ceres" \
+                         "glpk=GLPK" \
+                         "scip=SCIP" \
+                         "rs=RS" \
+                         "rs3=RS3" \
+                         "unix=Unix" \
+                         "api=API" \
+                         "vtk=VTK" \
+                         "visualstudio=Visual Studio" \
+                         "taucs=TAUCS" \
+                         "lapack=LAPACK" \
+                         "blas=BLAS" \
+                         "opennl=OpenNL" \
+                         "cpp=C++" \
+                         "cpp11=C++11" \
+                         "CC=C++" \
                          "cgalExample{1}=<br><b>File</b> \ref \1 \include \1" \
                          "cgalFigureAnchor{1}=\anchor fig__\1" \
                          "cgalFigureRef{1}=\ref fig__\1" \

Documentation/doc/resources/1.8.20/BaseDoxyfile.in

@@ -93,14 +93,6 @@ ALLOW_UNICODE_NAMES    = NO
 
 OUTPUT_LANGUAGE        = English
 
-# The OUTPUT_TEXT_DIRECTION tag is used to specify the direction in which all
-# documentation generated by doxygen is written. Doxygen will use this
-# information to generate all generated output in the proper direction.
-# Possible values are: None, LTR, RTL and Context.
-# The default value is: None.
-
-OUTPUT_TEXT_DIRECTION  = None
-
 # If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member
 # descriptions after the members that are listed in the file and class
 # documentation (similar to Javadoc). Set to NO to disable this.
@@ -259,19 +251,53 @@ TAB_SIZE               = 4
 # commands \{ and \} for these it is advised to use the version @{ and @} or use
 # a double escape (\\{ and \\})
 
-ALIASES                = "sc{1}=<span style=\"font-variant: small-caps;\">\1</span>" \
+ALIASES                = "cgal=CGAL" \
-                         "cgal=\sc{%CGAL}" \
+                         "protocgal=C++gal" \
-                         "protocgal=\sc{C++gal}" \
+                         "plageo=Plageo" \
-                         "plageo=\sc{Plageo}" \
+                         "stl=STL" \
-                         "stl=\sc{STL}" \
+                         "gmp=GMP" \
-                         "gmp=\sc{GMP}" \
+                         "gmpxx=GMPXX" \
-                         "mpir=\sc{MPIR}" \
+                         "mpir=MPIR" \
-                         "mpfr=\sc{MPFR}" \
+                         "mpfr=MPFR" \
-                         "leda=\sc{LEDA}" \
+                         "leda=LEDA" \
-                         "gcc=\sc{GCC}" \
+                         "gcc=GCC" \
-                         "cpp=\sc{C++}" \
+                         "dcel=DCEL" \
-                         "cpp11=\sc{C++11}" \
+                         "bgl=BGL" \
-                         "CC=\sc{C++}" \
+                         "boost=Boost" \
+                         "gnu=GNU" \
+                         "ms=MS" \
+                         "qt=Qt" \
+                         "qt5=Qt5" \
+                         "eigen=Eigen" \
+                         "opengr=OpenGR" \
+                         "libpointmatcher=libpointmatcher" \
+                         "core=Core" \
+                         "mpfi=MPFI" \
+                         "ntl=NTL" \
+                         "pdb=PDB" \
+                         "esbtl=ESBTL" \
+                         "tbb=TBB" \
+                         "laslib=LASlib" \
+                         "opencv=OpenCV" \
+                         "tensorflow=TensorFlow" \
+                         "metis=METIS" \
+                         "zlib=zlib" \
+                         "ceres=Ceres" \
+                         "glpk=GLPK" \
+                         "scip=SCIP" \
+                         "rs=RS" \
+                         "rs3=RS3" \
+                         "unix=Unix" \
+                         "api=API" \
+                         "vtk=VTK" \
+                         "visualstudio=Visual Studio" \
+                         "taucs=TAUCS" \
+                         "lapack=LAPACK" \
+                         "blas=BLAS" \
+                         "opennl=OpenNL" \
+                         "cpp=C++" \
+                         "cpp11=C++11" \
+                         "CC=C++" \
                          "cgalExample{1}=<br><b>File</b> \ref \1 \include \1" \
                          "cgalFigureAnchor{1}=\anchor fig__\1" \
                          "cgalFigureRef{1}=\ref fig__\1" \

Documentation/doc/resources/1.8.4/BaseDoxyfile.in

@@ -197,19 +197,54 @@ TAB_SIZE               = 4
 # will result in a user-defined paragraph with heading "Side Effects:".
 # You can put \n's in the value part of an alias to insert newlines.
 
-ALIASES = "sc{1}=<span style=\"font-variant: small-caps;\">\1</span>"
+ALIASES = "cgal=CGAL"
-ALIASES += "cgal=\sc{%CGAL}"
+ALIASES += "protocgal=C++gal"
-ALIASES += "protocgal=\sc{C++gal}"
+ALIASES += "plageo=Plageo"
-ALIASES += "plageo=\sc{Plageo}"
+ALIASES += "stl=STL"
-ALIASES += "gmp=\sc{GMP}"
+ALIASES += "gmp=GMP"
-ALIASES += "mpir=\sc{MPIR}"
+ALIASES += "gmpxx=GMPXX"
-ALIASES += "mpfr=\sc{MPFR}"
+ALIASES += "mpir=MPIR"
-ALIASES += "stl=\sc{STL}"
+ALIASES += "mpfr=MPFR"
-ALIASES += "leda=\sc{LEDA}"
+ALIASES += "leda=LEDA"
-ALIASES += "gcc=\sc{GCC}"
+ALIASES += "gcc=GCC"
-ALIASES += "cpp=\sc{C++}"
+ALIASES += "dcel=DCEL"
-ALIASES += "cpp11=\sc{C++11}"
+ALIASES += "bgl=BGL"
-ALIASES += "CC=\sc{C++}"
+ALIASES += "boost=Boost"
+ALIASES += "gnu=GNU"
+ALIASES += "ms=MS"
+ALIASES += "qt=Qt"
+ALIASES += "qt5=Qt5"
+ALIASES += "eigen=Eigen"
+ALIASES += "opengr=OpenGR"
+ALIASES += "libpointmatcher=libpointmatcher"
+ALIASES += "core=Core"
+ALIASES += "mpfi=MPFI"
+ALIASES += "ntl=NTL"
+ALIASES += "pdb=PDB"
+ALIASES += "esbtl=ESBTL"
+ALIASES += "tbb=TBB"
+ALIASES += "laslib=LASlib"
+ALIASES += "opencv=OpenCV"
+ALIASES += "tensorflow=TensorFlow"
+ALIASES += "metis=METIS"
+ALIASES += "zlib=zlib"
+ALIASES += "ceres=Ceres"
+ALIASES += "glpk=GLPK"
+ALIASES += "scip=SCIP"
+ALIASES += "rs=RS"
+ALIASES += "rs3=RS3"
+ALIASES += "unix=Unix"
+ALIASES += "api=API"
+ALIASES += "vtk=VTK"
+ALIASES += "visualstudio=Visual Studio"
+ALIASES += "taucs=TAUCS"
+ALIASES += "lapack=LAPACK"
+ALIASES += "blas=BLAS"
+ALIASES += "opennl=OpenNL"
+ALIASES += "cpp=C++"
+ALIASES += "cpp11=C++11"
+ALIASES += "CC=C++"
+
 ALIASES += "cgalExample{1}=<br><b>File</b> \ref \1 \include \1"
 ALIASES += "cgalFigureAnchor{1}=\anchor fig__\1"
 ALIASES += "cgalFigureRef{1}=\ref fig__\1"

Documentation/doc/scripts/generate_how_to_cite.py

@@ -1,4 +1,4 @@
-#!/usr/bin/env python2
+#!/usr/bin/env python
 # coding: utf8
 
 import re

Documentation/doc/scripts/html_output_post_processing.py

@@ -1,4 +1,4 @@
-#!/usr/bin/env python2
+#!/usr/bin/env python
 # Copyright (c) 2012 GeometryFactory (France). All rights reserved.
 # All rights reserved.
 #

Documentation/doc/scripts/pkglist_filter.py

@@ -1,4 +1,4 @@
-#!/usr/bin/env python3
+#!/usr/bin/env python
 
 import codecs
 import re

Documentation/doc/scripts/testsuite.py

@@ -1,4 +1,4 @@
-#!/usr/bin/env python2
+#!/usr/bin/env python
 # Copyright (c) 2012 GeometryFactory (France). All rights reserved.
 # All rights reserved.
 # 

Envelope_3/doc/Envelope_3/Envelope_3.txt

@@ -58,7 +58,7 @@ both these diagrams as <I>envelope diagrams</I>.
 
 It is easy to see that an envelope diagram is no more than a planar
 arrangement (see Chapter \ref chapterArrangement_on_surface_2 "2D Arrangements"), represented
-using an extended \sc{Dcel} structure, such that every \sc{Dcel}
+using an extended \dcel structure, such that every \dcel
 record (namely each face, halfedge and vertex) stores an additional
 container of it originators: the \f$ xy\f$-monotone surfaces that induce
 this feature.

Filtered_kernel/include/CGAL/Filtered_predicate.h

@@ -37,6 +37,10 @@ namespace CGAL {
 //   not, or we let all this up to the compiler optimizer to figure out ?
 // - Some caching could be done at the Point_2 level.
 
+// Protection is undocumented and currently always true, meaning that it
+// assumes a default rounding mode of round-to-nearest. false would correspond
+// to a default of round-towards-infinity, so interval arithmetic does not
+// require protection but regular code may.
 
 template <class EP, class AP, class C2E, class C2A, bool Protection = true>
 class Filtered_predicate

Filtered_kernel/include/CGAL/Lazy.h

@@ -874,7 +874,7 @@ struct Lazy_construction_bbox
 
 
 template <typename LK, typename AC, typename EC>
-struct Lazy_construction_optional
+struct Lazy_construction_optional_for_polygonal_envelope
 {
   static const bool Protection = true;
   typedef typename LK::Approximate_kernel AK;

Filtered_kernel/include/CGAL/Lazy_kernel.h

@@ -178,7 +178,7 @@ private:
   // The case distinction goes as follows:
   // result_type == FT                              => NT
   // result_type == Object                          => Object
-  // result_type == boost::optional                 => OPTIONAL_
+  // result_type == boost::optional                 => OPTIONAL_    Only for Intersect_point_3_for_polyhedral_envelope which returns a handle for a singleton
   // result_type == Bbox_2 || result_type == Bbox_3 => BBOX
   // default                                        => NONE
   // no result_type                                 => NONE
@@ -214,7 +214,7 @@ private:
 
   CGAL_WRAPPER_TRAIT(Intersect_2, VARIANT)
   CGAL_WRAPPER_TRAIT(Intersect_3, VARIANT)
-  CGAL_WRAPPER_TRAIT(Intersect_point_3, OPTIONAL_)
+  CGAL_WRAPPER_TRAIT(Intersect_point_3_for_polyhedral_envelope, OPTIONAL_)
   CGAL_WRAPPER_TRAIT(Compute_squared_radius_2, NT)
   CGAL_WRAPPER_TRAIT(Compute_x_3, NT)
   CGAL_WRAPPER_TRAIT(Compute_y_3, NT)
@@ -258,7 +258,7 @@ private:
   template <typename Construction>
   struct Select_wrapper_impl<Construction, OPTIONAL_> {
     template<typename Kernel, typename AKC, typename EKC>
-    struct apply { typedef Lazy_construction_optional<Kernel, AKC, EKC> type; };
+    struct apply { typedef Lazy_construction_optional_for_polygonal_envelope<Kernel, AKC, EKC> type; };
   };
 
   template <typename Construction>

GraphicsView/demo/L1_Voronoi_diagram_2/include/CGAL/L1_voronoi_traits_2.h

@@ -88,7 +88,7 @@ public:
 
     // Walk on the horizontal edge of the rectangle and then on the vertical.
 
-    // There is a chance that the width of the rectangle is smaller then the mid-dist.
+    // There is a chance that the width of the rectangle is smaller than the mid-dist.
     FT walk_x = (CGAL::min)(abs_x, dist);
     mid_x += sign_x * walk_x;
     dist -= walk_x;

GraphicsView/doc/GraphicsView/PackageDescription.txt

@@ -18,7 +18,7 @@
 \cgalPkgSummaryEnd
 \cgalPkgShortInfoBegin
 \cgalPkgSince{3.4}
-\cgalPkgDependsOn{\sc{Qt} 5}
+\cgalPkgDependsOn{\qt 5}
 \cgalPkgBib{cgal:fr-cqgvf}
 \cgalPkgLicense{\ref licensesGPL  "GPL"}
 \cgalPkgShortInfoEnd

GraphicsView/include/CGAL/Basic_shaders.h

@@ -0,0 +1,285 @@
+// Copyright (c) 2018  GeometryFactory Sarl (France).
+// All rights reserved.
+//
+// This file is part of CGAL (www.cgal.org).
+//
+// $URL$
+// $Id$
+// SPDX-License-Identifier: GPL-3.0-or-later OR LicenseRef-Commercial
+//
+//
+// Author(s)     : Guillaume Damiand <guillaume.damiand@liris.cnrs.fr>
+
+#ifndef CGAL_BASIC_SHADERS_H
+#define CGAL_BASIC_SHADERS_H
+
+#include <CGAL/license/GraphicsView.h>
+
+namespace CGAL
+{
+
+//------------------------------------------------------------------------------
+const char vertex_source_color[]=R"DELIM(
+#version 150
+in highp vec4 vertex;
+in highp vec3 normal;
+in highp vec3 color;
+
+uniform highp mat4 mvp_matrix;
+uniform highp mat4 mv_matrix;
+uniform highp float point_size;
+
+out highp vec4 fP;
+out highp vec3 fN;
+out highp vec4 fColor;
+out highp vec4 m_vertex;
+
+void main(void)
+{
+  fP = mv_matrix * vertex;
+  fN = mat3(mv_matrix)* normal;
+  fColor = vec4(color, 1.0);
+  gl_PointSize = point_size;
+
+  m_vertex = vertex;
+
+  gl_Position = mvp_matrix * vertex;
+}
+)DELIM";
+
+const char fragment_source_color[]=R"DELIM(
+#version 150
+in highp vec4 fP;
+in highp vec3 fN;
+in highp vec4 fColor;
+in highp vec4 m_vertex;
+
+uniform highp vec4 light_pos;
+uniform highp vec4 light_diff;
+uniform highp vec4 light_spec;
+uniform highp vec4 light_amb;
+uniform highp float spec_power;
+
+uniform highp vec4 clipPlane;
+uniform highp vec4 pointPlane;
+uniform highp float rendering_mode;
+uniform highp float rendering_transparency;
+
+out highp vec4 out_color;
+
+void main(void)
+{
+  highp vec3 L = light_pos.xyz - fP.xyz;
+  highp vec3 V = -fP.xyz;
+
+  highp vec3 N = normalize(fN);
+  L = normalize(L);
+  V = normalize(V);
+
+  highp vec3 R = reflect(-L, N);
+  highp vec4 diffuse = vec4(max(dot(N,L), 0.0) * light_diff.rgb * fColor.rgb, 1.0);
+  highp vec4 ambient = vec4(light_amb.rgb * fColor.rgb, 1.0);
+  highp vec4 specular = pow(max(dot(R,V), 0.0), spec_power) * light_spec;
+
+  // onPlane == 1: inside clipping plane, should be solid;
+  // onPlane == -1: outside clipping plane, should be transparent;
+  // onPlane == 0: on clipping plane, whatever;
+  float onPlane = sign(dot((m_vertex.xyz-pointPlane.xyz), clipPlane.xyz));
+
+  // rendering_mode == -1: draw all solid;
+  // rendering_mode == 0: draw solid only;
+  // rendering_mode == 1: draw transparent only;
+  if (rendering_mode == (onPlane+1)/2) {
+    // discard other than the corresponding half when rendering
+    discard;
+  }
+
+  // draw corresponding part
+  out_color = rendering_mode < 1 ? (diffuse + ambient) :
+                      vec4(diffuse.rgb + ambient.rgb, rendering_transparency);
+}
+)DELIM";
+
+const char vertex_source_p_l[]=R"DELIM(
+#version 150
+in highp vec4 vertex;
+in highp vec3 color;
+
+uniform highp mat4 mvp_matrix;
+uniform highp float point_size;
+
+out highp vec4 fColor;
+out highp vec4 m_vertex;
+
+void main(void)
+{
+  gl_PointSize = point_size;
+  fColor = vec4(color, 1.0);
+  m_vertex = vertex;
+  gl_Position = mvp_matrix * vertex;
+}
+)DELIM";
+
+const char fragment_source_p_l[]=R"DELIM(
+#version 150
+in highp vec4 fColor;
+in highp vec4 m_vertex;
+
+uniform highp vec4 clipPlane;
+uniform highp vec4 pointPlane;
+uniform highp float rendering_mode;
+
+out highp vec4 out_color;
+
+void main(void)
+{
+  // onPlane == 1: inside clipping plane, should be solid;
+  // onPlane == -1: outside clipping plane, should be transparent;
+  // onPlane == 0: on clipping plane, whatever;
+  float onPlane = sign(dot((m_vertex.xyz-pointPlane.xyz), clipPlane.xyz));
+
+  // rendering_mode == -1: draw both inside and outside;
+  // rendering_mode == 0: draw inside only;
+  // rendering_mode == 1: draw outside only;
+  if (rendering_mode == (onPlane+1)/2) {
+    // discard other than the corresponding half when rendering
+    discard;
+  }
+
+  out_color = fColor;
+}
+)DELIM";
+
+const char vertex_source_clipping_plane[]=R"DELIM(
+#version 150
+in highp vec4 vertex;
+
+uniform highp mat4 vp_matrix;
+uniform highp mat4 m_matrix;
+
+void main(void)
+{
+  gl_Position = vp_matrix * m_matrix * vertex;
+}
+)DELIM";
+
+const char fragment_source_clipping_plane[]=R"DELIM(
+#version 150
+out highp vec4 out_color;
+void main(void)
+{
+  out_color = vec4(0.0, 0.0, 0.0, 1.0);
+}
+)DELIM";
+
+//------------------------------------------------------------------------------
+//  compatibility shaders
+
+const char vertex_source_color_comp[]=R"DELIM(
+in highp vec4 vertex;
+in highp vec3 normal;
+in highp vec3 color;
+
+uniform highp mat4 mvp_matrix;
+uniform highp mat4 mv_matrix;
+uniform highp float point_size;
+
+out highp vec4 fP;
+out highp vec3 fN;
+out highp vec4 fColor;
+
+void main(void)
+{
+  fP = mv_matrix * vertex;
+  highp mat3 mv_matrix_3;
+  mv_matrix_3[0] = mv_matrix[0].xyz;
+  mv_matrix_3[1] = mv_matrix[1].xyz;
+  mv_matrix_3[2] = mv_matrix[2].xyz;
+  fN = mv_matrix_3* normal;
+  fColor = vec4(color, 1.0);
+  gl_PointSize = point_size;
+
+  gl_Position = mvp_matrix * vertex;
+}
+)DELIM";
+
+const char fragment_source_color_comp[]=R"DELIM(
+in highp vec4 fP;
+in highp vec3 fN;
+in highp vec4 fColor;
+
+uniform highp vec4 light_pos;
+uniform highp vec4 light_diff;
+uniform highp vec4 light_spec;
+uniform highp vec4 light_amb;
+uniform highp float spec_power ;
+
+out highp vec4 out_color;
+
+void main(void)
+{
+  highp vec3 L = light_pos.xyz - fP.xyz;
+  highp vec3 V = -fP.xyz;
+
+  highp vec3 N = normalize(fN);
+  L = normalize(L);
+  V = normalize(V);
+
+  highp vec3 R = reflect(-L, N);
+  highp vec4 diffuse = max(dot(N,L), 0.0) * light_diff * fColor;
+  highp vec4 specular = pow(max(dot(R,V), 0.0), spec_power) * light_spec;
+
+  out_color = light_amb*fColor + diffuse;
+}
+)DELIM";
+
+const char vertex_source_p_l_comp[]=R"DELIM(
+in highp vec4 vertex;
+in highp vec3 color;
+
+uniform highp mat4 mvp_matrix;
+uniform highp float point_size;
+
+out highp vec4 fColor;
+
+void main(void)
+{
+  gl_PointSize = point_size;
+  fColor = vec4(color, 1.0);
+  gl_Position = mvp_matrix * vertex;
+}
+)DELIM";
+
+const char fragment_source_p_l_comp[]=R"DELIM(
+in highp vec4 fColor;
+out highp vec4 out_color;
+void main(void)
+{
+  out_color = fColor;
+}
+)DELIM";
+
+/* const char vertex_source_clipping_plane_comp[]=R"DELIM(
+attribute highp vec4 vertex;
+
+uniform highp mat4 vp_matrix;
+uniform highp mat4 m_matrix;
+
+void main(void)
+{
+  gl_Position = vp_matrix * m_matrix * vertex;
+}
+)DELIM";
+
+const char fragment_source_clipping_plane_comp[]=R"DELIM(
+out highp vec4 out_color;
+void main(void)
+{
+  out_color = vec4(0.0, 0.0, 0.0, 1.0);
+}
+)DELIM";
+*/
+
+}
+
+#endif // CGAL_BASIC_SHADERS_H

GraphicsView/include/CGAL/Buffer_for_vao.h

@@ -908,7 +908,7 @@ protected:
   bool m_zero_y; /// True iff all points have y==0
   bool m_zero_z; /// True iff all points have z==0
 
-  bool m_inverse_normal;;
+  bool m_inverse_normal;
 
   // Local variables, used when we started a new face.g
   bool m_face_started;