Merge branch 'master' into feature/issue_7395

# Conflicts:
#	Polyhedron/doc/Polyhedron/Concepts/PolyhedronItems_3.h

.github/workflows/reuse.yml

@@ -0,0 +1,35 @@
+# SPDX-FileCopyrightText: 2020 Free Software Foundation Europe e.V. <https://fsfe.org>
+#
+# SPDX-License-Identifier: GPL-3.0-or-later
+
+name: REUSE Compliance Check
+
+on: [push, pull_request]
+
+jobs:
+  reuse:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v3
+    - name: REUSE version
+      uses: fsfe/reuse-action@v1
+      with:
+        args: --version
+    - name: REUSE lint
+      uses: fsfe/reuse-action@v1
+      with:
+        args: --include-submodules lint
+    - name: REUSE SPDX SBOM
+      uses: fsfe/reuse-action@v1
+      with:
+        args: spdx
+    - name: install dependencies
+      run: sudo apt-get install -y cmake
+    - name: Create CGAL internal release
+      run: |
+        mkdir -p ./release
+        cmake -DDESTINATION=./release -DCGAL_VERSION=9.9 -P ./Scripts/developer_scripts/cgal_create_release_with_cmake.cmake
+    - name: REUSE lint release tarball
+      uses: fsfe/reuse-action@v1
+      with:
+        args: --root ./release/CGAL-9.9 --include-submodules lint

.reuse/dep5

@@ -0,0 +1,12 @@
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: CGAL
+Upstream-Contact: CGAL Editorial Board <[email protected]>
+Source: https://github.com/CGAL/cgal
+
+Files: .* *.cmake *.md .github/* Maintenance/* */TODO */doc/* */deb/* */applications/* */doc_html/* */scripts/* */developer_scripts/* */demo/* */examples/* */src/* */test/* */benchmarks/* */benchmark/* */package_info/* */data/* */cmake/*
+Copyright: 1995-2023 The CGAL Project
+License: CC0-1.0
+
+Files: CMakeLists.txt GraphicsView/include/CGAL/Qt/ImageInterface.ui GraphicsView/include/CGAL/Qt/resources/qglviewer-icon.xpm Installation/AUTHORS Installation/CMakeLists.txt Installation/README Installation/auxiliary/cgal_create_cmake_script.1 Installation/auxiliary/gmp/README Installation/include/CGAL/license/gpl_package_list.txt MacOSX/auxiliary/cgal_app.icns copyright
+Copyright: 1995-2023 The CGAL Project
+License: CC0-1.0

AABB_tree/include/CGAL/AABB_halfedge_graph_segment_primitive.h

@@ -33,7 +33,7 @@ namespace CGAL {
 
 /*!
  * \ingroup PkgAABBTreeRef
- * Primitive type for a edge of a polyhedral surface.
+ * Primitive type for an edge of a polyhedral surface.
  * It wraps an `edge_descriptor` into a 3D segment.
  * The class model of `HalfedgeGraph` from which the primitive is built should not be deleted
  * while the AABB tree holding the primitive is in use.

AABB_tree/include/CGAL/AABB_tree.h

@@ -142,7 +142,7 @@ namespace CGAL {
     /// An explicit call to `build()` must be made to ensure that the next call to
     /// a query function will not trigger the construction of the data structure.
     /// A call to `AABBTraits::set_shared_data(t...)` is made using the internally stored traits.
-    /// This procedure has a complexity of \f$O(n log(n))\f$, where \f$n\f$ is the number of
+    /// This procedure has a complexity of \cgalBigO{n log(n)}, where \f$n\f$ is the number of
     /// primitives of the tree.
     template<typename ... T>
     void build(T&& ...);

Alpha_shapes_2/doc/Alpha_shapes_2/CGAL/Alpha_shape_2.h

@@ -80,7 +80,7 @@ use binary search.
 `Alpha_shape_2::number_of_solid_components()` performs a graph traversal and takes time
 linear in the number of faces of the underlying triangulation.
 `Alpha_shape_2::find_optimal_alpha()` uses binary search and takes time
-\f$ O(n \log n)\f$, where \f$ n\f$ is the number of points.
+\cgalBigO{n \log n}, where \f$ n\f$ is the number of points.
 
 */
 template< typename Dt, typename ExactAlphaComparisonTag >

Alpha_shapes_3/doc/Alpha_shapes_3/CGAL/Alpha_shape_3.h

@@ -77,7 +77,7 @@ use binary search.
 `Alpha_shape_3::number_of_solid_components()` performs a graph traversal and takes time
 linear in the number of cells of the underlying triangulation.
 `Alpha_shape_3::find_optimal_alpha()` uses binary search and takes time
-\f$ O(n \log n)\f$, where \f$ n\f$ is the number of points.
+\cgalBigO{n \log n}, where \f$ n\f$ is the number of points.
 
 */
 template< typename Dt, typename ExactAlphaComparisonTag >

Alpha_wrap_3/include/CGAL/Alpha_wrap_3/internal/Alpha_wrap_3.h

@@ -173,7 +173,7 @@ class Alpha_wrap_3
   using Alpha_PQ = Modifiable_priority_queue<Gate, Less_gate, Gate_ID_PM<Dt>, CGAL_BOOST_PAIRING_HEAP>;
 
 protected:
-  const Oracle& m_oracle;
+  const Oracle m_oracle;
   SC_Iso_cuboid_3 m_bbox;
 
   FT m_alpha, m_sq_alpha;
@@ -1343,6 +1343,7 @@ class Alpha_wrap_3
     return true;
   }
 
+public:
   // Not the best complexity, but it's very cheap compared to the rest of the algorithm.
   void make_manifold()
   {

Arrangement_on_surface_2/demo/Arrangement_on_surface_2/AlgebraicCurveParser.cpp

@@ -12,7 +12,7 @@
 // This file is provided AS IS with NO WARRANTY OF ANY KIND, INCLUDING THE
 // WARRANTY OF DESIGN, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 //
-// SPDX-License-Identifier: GPL-3.0+
+// SPDX-License-Identifier: GPL-3.0-or-later
 //
 // Author(s): Saurabh Singh <[email protected]>
 //            Ahmed Essam <[email protected]>

Arrangement_on_surface_2/demo/Arrangement_on_surface_2/AlgebraicCurveParser.h

@@ -12,7 +12,7 @@
 // This file is provided AS IS with NO WARRANTY OF ANY KIND, INCLUDING THE
 // WARRANTY OF DESIGN, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 //
-// SPDX-License-Identifier: GPL-3.0+
+// SPDX-License-Identifier: GPL-3.0-or-later
 //
 // Author(s): Saurabh Singh <[email protected]>
 //            Ahmed Essam <[email protected]>

Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt

@@ -1223,10 +1223,10 @@ halfedge \f$e_{\mathrm{pred}}\f$ directed toward \f$v\f$, such that
 \f$c\f$ is located between the curves associated with
 \f$e_{\mathrm{pred}}\f$ and the next halfedge in the clockwise order
 in the circular list of halfedges around \f$v\f$; see
-\cgalFigureRef{aos_fig-insert}. This search may take \f$O(d)\f$ time,
+\cgalFigureRef{aos_fig-insert}. This search may take \cgalBigO{d} time,
 where \f$d\f$ is the degree of the vertex \f$v\f$. \cgalFootnote{We
 can store the handles to the halfedges incident to \f$v\f$ in an efficient
-search structure to obtain \f$O(\log d)\f$ access time. However, as
+search structure to obtain \cgalBigO{\log d} access time. However, as
 \f$d\f$ is usually very small, this may lead to a waste of storage
 space without a meaningful improvement in running time in practice.}
 However, if the halfedge \f$e_{\mathrm{pred}}\f$ is known in advance,
@@ -1488,9 +1488,9 @@ keep up-to-date as this arrangement changes.
 As mentioned above, the triangulation strategy is provided only for
 educational purposes, and thus we do not elaborate on this strategy.
 The data structure needed by the landmark and the trapezoidal map RIC
-strategies can be constructed in \f$O(N \log N)\f$ time, where \f$N\f$
+strategies can be constructed in \cgalBigO{N \log N} time, where \f$N\f$
 is the overall number of edges in the arrangement, but the constant
-hidden in the \f$O()\f$ notation for the trapezoidal map RIC strategy
+hidden in the \cgalBigO{ } notation for the trapezoidal map RIC strategy
 is much larger. Thus, construction needed by the landmark algorithm is
 in practice significantly faster than the construction needed by the
 trapezoidal map RIC strategy. In addition, although both resulting
@@ -1647,7 +1647,7 @@ Section \ref arr_ssecpl. The output pairs are sorted in increasing
 \f$xy\f$-lexicographical order of the query point.
 
 The batched point-location operation is carried out by sweeping the
-arrangement. Thus, it takes \f$O((m+N)\log{(m+N)})\f$ time, where
+arrangement. Thus, it takes \cgalBigO{(m+N)\log{(m+N)}} time, where
 \f$N\f$ is the number of edges in the arrangement. Issuing separate
 queries exploiting a point-location strategy with logarithmic query
 time per query, such as the trapezoidal map RIC strategy (see Section
@@ -2037,11 +2037,11 @@ so it must be construct from scratch.
 
 In the first case, we sweep over the input curves, compute 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
+arrangement. This process is performed in \cgalBigO{left((n + k)\log
+n\right} time, where \f$k\f$ is the total number of intersection
 points. The running time is asymptotically better than the time needed
 for incremental insertion if the arrangement is relatively sparse
-(when \f$k\f$ is \f$O(\frac{n^2}{\log n}\f$)), but it is recommended
+(when \f$k\f$ is \cgalBigO{\frac{n^2}{\log n}}), but it is recommended
 that this aggregate construction process be used even for dense
 arrangements, since the plane-sweep algorithm performs fewer geometric
 operations compared to the incremental insertion algorithms, and hence
@@ -4346,7 +4346,7 @@ a point with respect to an \f$x\f$-monotone polyline, we use binary
 search to locate the relevant segment that contains the point in its
 \f$x\f$-range. Then, we compute the position of the point with respect
 to this segment. Thus, operations on \f$x\f$-monotone polylines of
-size \f$m\f$ typically take \f$O(\log m)\f$ time.
+size \f$m\f$ typically take \cgalBigO{\log m} time.
 
 You are free to choose the underlying segment traits class. Your
 decision could be based, for example, on the number of expected

Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_trapezoid_ric_point_location.h

@@ -12,9 +12,9 @@ Seidel \cgalCite{s-sfira-91} (see also [\cgalCite{bkos-cgaa-00} Chapter 6).
 It subdivides each arrangement face to pseudo-trapezoidal cells, each
 of constant complexity, and constructs and maintains a linear-size search
 structure on top of these cells, such that each query can be answered
-in \f$ O(\log n)\f$ time, where \f$ n\f$ is the complexity of the arrangement.
+in \cgalBigO{\log n} time, where \f$ n\f$ is the complexity of the arrangement.
 
-Constructing the search structures takes \f$ O(n \log n)\f$ expected time
+Constructing the search structures takes \cgalBigO{n \log n} expected time
 and may require a small number of rebuilds \cgalCite{hkh-iiplgtds-12}. Therefore
 attaching a trapezoidal point-location object to an existing arrangement
 may incur some overhead in running times. In addition, the point-location

Arrangement_on_surface_2/include/CGAL/Arr_polycurve_basic_traits_2.h

@@ -2419,7 +2419,7 @@ class Arr_polycurve_basic_traits_2 {
   /*! Obtain the index of the subcurve in the polycurve that contains the
    * point q in its x-range. The function performs a binary search, so if the
    * point q is in the x-range of the polycurve with n subcurves, the subcurve
-   * containing it can be located in O(log n) operations.
+   * containing it can be located in \cgalBigO{log n} operations.
    * \param cv The polycurve curve.
    * \param q The point.
    * \return An index i such that q is in the x-range of cv[i].

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

@@ -42,7 +42,7 @@ namespace CGAL {
    * <a href="https://www.boost.org/doc/libs/release/libs/graph/doc/filtered_graph.html"><code>boost::filtered_graph</code></a>,
    * this class only requires a way to access the selected faces and will automatically select the
    * edges/halfedges and vertices present in the adapted graph. A vertex is selected if it is incident to at least one
-   * selected face. A edge is selected if it is incident to at least a selected face. A halfedge is selected if its edge
+   * selected face. An edge is selected if it is incident to at least a selected face. A halfedge is selected if its edge
    * is selected.
    *
    * Since this class is a model of the `FaceGraph` concept, there is a restriction on the set of selected faces:

Barycentric_coordinates_2/doc/Barycentric_coordinates_2/Barycentric_coordinates_2.txt

@@ -451,10 +451,10 @@ To fix the problem, we modify the weights \f$w_i\f$ as
 </center>
 
 After the above normalization, this gives us the precise algorithm to compute Wachspress coordinates
-but with \f$O(n^2)\f$ performance only. The max speed \f$O(n)\f$ algorithm uses the standard
+but with \cgalBigO{n^2} performance only. The max speed \cgalBigO{n} algorithm uses the standard
 weights \f$w_i\f$. Note that mathematically this modification does not change the coordinates. One should
 be cautious when using the unnormalized Wachspress weights. In that case, you must choose the
-\f$O(n)\f$ type.
+\cgalBigO{n} type.
 
 It is known that for strictly convex polygons the denominator's zero set of the
 Wachspress coordinates (\f$W^{wp} = 0~\f$) is a curve, which (in many cases) lies quite
@@ -507,10 +507,10 @@ To fix the problem, similarly to the previous subsection, we modify the weights
 </center>
 
 After the above normalization, this yields the precise algorithm to compute discrete harmonic coordinates
-but with \f$O(n^2)\f$ performance only. The max speed \f$O(n)\f$ algorithm uses the standard
+but with \cgalBigO{n^2} performance only. The max speed \cgalBigO{n} algorithm uses the standard
 weights \f$w_i\f$. Again, mathematically this modification does not change the coordinates,
 one should be cautious when using the unnormalized discrete harmonic weights. In that case,
-you must choose the \f$O(n)\f$ type.
+you must choose the \cgalBigO{n} type.
 
 \b Warning: as for Wachspress coordinates, we do not recommend using discrete harmonic coordinates
 for exterior points, because the curve \f$W^{dh} = 0\f$ may have several components,
@@ -563,7 +563,7 @@ After the normalization of these weights as before
 \f$b_i = \frac{w_i}{W^{mv}}\qquad\f$ with \f$\qquad W^{mv} = \sum_{j=1}^n w_j\f$
 </center>
 
-we obtain the max precision \f$O(n^2)\f$ algorithm. The max speed \f$O(n)\f$ algorithm computes the
+we obtain the max precision \cgalBigO{n^2} algorithm. The max speed \cgalBigO{n} algorithm computes the
 weights \f$w_i\f$ using the pseudocode from <a href="https://www.inf.usi.ch/hormann/nsfworkshop/presentations/Hormann.pdf">here</a>.
 These weights
 
@@ -575,7 +575,7 @@ with \f$\qquad t_i = \frac{\text{det}(d_i, d_{i+1})}{r_ir_{i+1} + d_id_{i+1}}\f$
 are also normalized. Note that they are unstable if a query point is closer than \f$\approx 1.0e-10\f$
 to the polygon boundary, similarly to Wachspress and discrete harmonic coordinates and
 one should be cautious when using the unnormalized mean value weights. In that case, you must choose the
-\f$O(n)\f$ type.
+\cgalBigO{n} type.
 
 
 \anchor compute_hm_coord
@@ -654,17 +654,17 @@ The resulting timings for all closed-form coordinates can be found in the figure
 
 \cgalFigureBegin{analytic_timings, analytic_timings.png}
 Time in seconds to compute \f$n\f$ coordinate values for a polygon with \f$n\f$ vertices
-at 1 million query points with the max speed \f$O(n)\f$ algorithms (dashed) and
+at 1 million query points with the max speed \cgalBigO{n} algorithms (dashed) and
 the max precision \f$0(n^2)\f$ algorithms (solid) for Wachspress (blue), discrete
 harmonic (red), and mean value (green) coordinates.
 \cgalFigureEnd
 
-From the figure above we observe that the \f$O(n^2)\f$ algorithm is as fast
-as the \f$O(n)\f$ algorithm if we have a polygon with a small number of vertices.
+From the figure above we observe that the \cgalBigO{n^2} algorithm is as fast
+as the \cgalBigO{n} algorithm if we have a polygon with a small number of vertices.
 But as the number of vertices is increased, the linear algorithm outperforms the squared one,
 as expected. One of the reasons for this behavior is that for a small number of vertices
-the multiplications of \f$n-2\f$ elements inside the \f$O(n^2)\f$ algorithm take almost the
-same time as the corresponding divisions in the \f$O(n)\f$ algorithm. For a polygon with
+the multiplications of \f$n-2\f$ elements inside the \cgalBigO{n^2} algorithm take almost the
+same time as the corresponding divisions in the \cgalBigO{n} algorithm. For a polygon with
 many vertices, these multiplications are substantially slower.
 
 To benchmark harmonic coordinates, we used a MacBook Pro 2018 with 2.2 GHz Intel Core i7 processor (6 cores)

Bounding_volumes/doc/Bounding_volumes/CGAL/Approximate_min_ellipsoid_d.h

@@ -119,7 +119,7 @@ We implement Khachyian's algorithm for rounding
 polytopes \cgalCite{cgal:k-rprnm-96}. Internally, we use
 `double`-arithmetic and (initially a single)
 Cholesky-decomposition. The algorithm's running time is
-\f$ {\cal O}(nd^2(\epsilon^{-1}+\ln d + \ln\ln(n)))\f$, where \f$ n=|P|\f$ and
+\cgalBigO{nd^2(\epsilon^{-1}+\ln d + \ln\ln(n))}, where \f$ n=|P|\f$ and
 \f$ 1+\epsilon\f$ is the desired approximation ratio.
 
 \cgalHeading{Example}

Bounding_volumes/doc/Bounding_volumes/CGAL/Min_sphere_of_spheres_d.h

@@ -76,7 +76,7 @@ We implement two algorithms, the LP-algorithm and a
 heuristic \cgalCite{msw-sblp-92}. As described in the documentation of
 concept `MinSphereOfSpheresTraits`, each has its advantages and
 disadvantages: Our implementation of the LP-algorithm has maximal
-expected running time \f$ O(2^d n)\f$, while the heuristic comes without
+expected running time \cgalBigO{2^d n}, while the heuristic comes without
 any complexity guarantee. In particular, the LP-algorithm runs in
 linear time for fixed dimension \f$ d\f$. (These running times hold for the
 arithmetic model, so they count the number of operations on

Bounding_volumes/doc/Bounding_volumes/CGAL/rectangular_p_center_2.h

@@ -245,7 +245,7 @@ must be a model for `RectangularPCenterTraits_2`.
 \cgalHeading{Implementation}
 
 The runtime is linear for \f$ p \in \{2,\,3\}\f$ and
-\f$ \mathcal{O}(n \cdot \log n)\f$ for \f$ p = 4\f$ where \f$ n\f$ is the number of
+\cgalBigO{n \cdot \log n} for \f$ p = 4\f$ where \f$ n\f$ is the number of
 input points. These runtimes are worst case optimal. The \f$ 3\f$-center
 algorithm uses a prune-and-search technique described in
 \cgalCite{cgal:h-slacr-99}. The \f$ 4\f$-center implementation uses sorted matrix

Bounding_volumes/doc/Bounding_volumes/Concepts/MinSphereOfSpheresTraits.h

@@ -79,7 +79,7 @@ The recommended choice is the first, which is a synonym to the one
 of the other two methods which we consider "the best in practice."
 In case of `CGAL::LP_algorithm`, the minsphere will be computed
 using the LP-algorithm \cgalCite{msw-sblp-92}, which in our
-implementation has maximal expected running time \f$ O(2^d n)\f$ (in the
+implementation has maximal expected running time \cgalBigO{2^d n} (in the
 number of operations on the number type `FT`). In case of
 `CGAL::Farthest_first_heuristic`, a simple heuristic will be
 used instead which seems to work fine in practice, but comes without

Box_intersection_d/doc/Box_intersection_d/Box_intersection_d.txt

@@ -350,12 +350,12 @@ parameter the function switches from the streamed segment-tree
 algorithm to the two-way-scan algorithm, see \cgalCite{cgal:ze-fsbi-02}
 for the details.
 
-The streamed segment-tree algorithm needs \f$ O(n \log^d (n) + k)\f$
-worst-case running time and \f$ O(n)\f$ space, where \f$ n\f$ is the number of
+The streamed segment-tree algorithm needs \cgalBigO{n \log^d (n) + k}
+worst-case running time and \cgalBigO{n} space, where \f$ n\f$ is the number of
 boxes in both input sequences, \f$ d\f$ the (constant) dimension of the
 boxes, and \f$ k\f$ the output complexity, i.e., the number of pairwise
-intersections of the boxes. The two-way-scan algorithm needs \f$ O(n \log
-(n) + l)\f$ worst-case running time and \f$ O(n)\f$ space, where \f$ l\f$ is the
+intersections of the boxes. The two-way-scan algorithm needs \cgalBigO{n \log
+(n) + l} worst-case running time and \cgalBigO{n} space, where \f$ l\f$ is the
 number of pairwise overlapping intervals in one dimensions (the
 dimension where the algorithm is used instead of the segment tree).
 Note that \f$ l\f$ is not necessarily related to \f$ k\f$ and using the