- Documentation
  - Ron suggests to keep the "2D Arrangements" (which is long enough as it
    is, but maybe it should be renamed to "2D Planar Arrangements"), and have
    another chapter on "2D Arrangements on General Surfaces".
    This chapter can be much shorter, as all you can do with arrangements was
    explained and demonstrated in the "2D Arrangements" chapter. We should
    however intorduce the concept of TopologyTraits, and re-interpret the
    functionality of the GeometryTraits.

  - Incoorporate:
      BasicSweepLineVisitor_2.tex
      Surface_sweep_2.tex
      SweepLineVisitor_2.tex
      Basic_surface_sweep_2.tex
     Into the documentation

- Test RIC trapezoidal point locatoin

- Test all landmark sub-strategies

- Get rid of the prefix 'get_' from all functions and methods:
    get_all_inner_nodes()
    get_bbox()
    	Bezier_point_2.h,
	Bezier_x_monotone_2.h)
    get_boundary_in_x()
    get_boundary_in_y()
    get_coefficient()
	Bezier_cache.h
	Bezier_curve_2.h
	Rational_arc_2.h
	CORE_algebraic_number_traits.h
    get_data()
    	Td_dag.h
    get_depth_threshold()
    	Trapezoidal_decomposition_2.h
    get_double()
	Arr_lm_random_generator.h
	Arr_point_location/Arr_lm_random_generator.h
    get_index()
	Arr_circle_segment_traits_2.h
	Arr_conic_traits_2.h
    get_intersections()
    get_lb()
	Td_X_trapezoid.h
	Trapezoidal_decomposition_2.h
    get_level()
	Arr_qdx_topology_traits_2_impl.h
	Arr_torus_topology_traits_2_impl.h
    get_lt()
	Td_X_trapezoid.h
	Trapezoidal_decomposition_2.h
    get_mode()
    get_node()
	Td_X_trapezoid.h
	Trapezoidal_decomposition_2.h
    get_originator()
    get_painter()
    get_parent()
	Arr_trapezoid_ric_pl_impl.h
	Trapezoidal_decomposition_2.h
	Arr_trapezoid_ric_point_location.h
    get_rb()
	Td_X_trapezoid.h
	Trapezoidal_decomposition_2.h
    get_rt()
	Td_X_trapezoid.h
	Trapezoidal_decomposition_2.h
    get_size_threshold()
    	Trapezoidal_decomposition_2.h
    get_t_at_x()
    get_t_at_y()
    get_traits()
    get_vertical_tangencies()

- Add insert_* functions back for backward compatibility.
  Keep the old interface for backward complatibility (at least for CGAL 3.4,
  then we can remove it). The "old" functions can just call the "new"
  functions, with a #warning in the code saying that they are deprecated.

- Change the interface of Envelope_2 (and Envelope_3):
  to lower_envelope_2 and upper_envelope_2 (lower_envelope_3 and
  upper_envelope_3) and remove lower_envelope_x_monotone_2 and
  upper_envelope_x_monotone_2 (lower_envelope_xy_monotone_3 and
  upper_envelope_xy_monotone_3).
  We can use the value-type of the input iterator to determine which
  operation to perform (just like we do now in insert() ).

- Spherical arcs
  - The insertion helper and the batched point-location helper seem to have
    been copied from the planar helpers with minor changes. That is, I
    expect to face problem while aggregately inserting new curves into a
    non-empty arrangement on a sphere, or while running a batched
    point-location query on such an arrangement.
    So, there is some work here ... (not much though; these visitors are far
    less complicated than the construction visitor).

  - The "planar" zone visitor is also used here. I believe this should work,
    as it is generic enough (I hope).
    Can you test it by trying to incrementally insert curves to an
    arrrangement on a sphere.

  - We can think of adding a test for the spherical topology, similar to the
    construction test developed by Baruch: Namely read n curves from a file,
    construct their arrangement incrementally; construct it aggregately;
    construct an arrangement of n/2 curves then add the rest of the curves;
    construct two arrangement of n/2 curves each and overlay them. In all
    cases, the arrangement dimensions (V, E, F) must be the same ...

  - Add an example/test for I/O with arrangement of arcs of great circles.

- CORE related examples and test fail on the platforms below with a bus error
  - Darwin-8.10_g++-4.0.1_debug
  - powerpc_Darwin-8.10_g++-4.0.1

- Arrangement with history is defficient in 2 ways: 1. It restricted to
  curves that do not result with (isolated) vertices, as the interface allows
  a user to obtain the induced edges only. 2. The induced edges of an
  x-monotone curve can be returned to the user in some predetermined order,
  for example left to right, so that the user can exploit it and avoid
  sorting these edges.

  The first problem can be fixed by either adding another pair of begin/end
  functions that can be used to obtain the range of points, or the current
  pair of begin/end functions can be changed, so that they return a range of
  objects that represent either edges or vertices.

  The second problem can be fixed by introducing a heirarchy of 2 layers
  to the arrangement with history. The top layer represent the split of
  general curves into x-monotone curves, and the one below represents the
  split at intersection points. As a response to a user request for the items
  induced by a general curve, the range of either edges or points are
  returned in arbitrary order. However, as a response to a user request for
  the edges induced by an x-monote curve, the range of edges are returned in
  order from left to right.

  In the meantime we could disallow the insertion of curves that contain
  isolated points.

- Change insert_point() to point() and keep the former deprecated. Reflect
  the change in the documentation.

- Arrangement_on_surface_2 demo
  Cannot change the background color

- Boolean_set_operations_2 demo
  Enter a red polygon.
  Enter a blue polygon.
  Perform a Boolean operation.
  Now zoom in, and oops, you see the two input objects again.
  I would expect to zoom into the intersection.

- The arrangement demo fails with conics.

- There is a warning coming from Cartesian/function_objects.h line 3113
  about returning a reference to a temporary variable (which seems to be
  a good warning; perhaps it is the source of some segmentation faults we
  encounter). A "kernel expert" should look into this.

- In the example dual_lines.cpp we use the function rand().
  We should include <stdlib.h> to avoid a compilation error.

- The example circular_line_arcs.cpp does not compile under many platforms,
  or at least issues warnings about returning a reference to temporary
  variable. Can you prompt the INRIA people to fix this?
  (I personally think that we should remove this example from our test-suite,
   but if the INRIA people believe that it's place is there, they should at
   least properly maintain it ...)
- There is a problem with the examples that use CORE on Darwin (platform #10).
  Other Darwin platforms seem fine. Do we want to investigate? (perhaps it's
  just something wrong with the installation ...)
- There is a segmentation fault in the examples that use overlay on platforms
  #10 and #12. Here I don't have a clue ...
- There are still some mysterious crashes of the test-suite on some platforms.
  Again, I don't have a clue ...

- compute_intersection_points (InputIterator curves_begin,
                               InputIterator curves_end,
                               OutputIterator points,
                               bool report_endpoints = false,
                               Traits traits = Default_traits())
  Allow the traits to be a model of ArrangementXMonotoneTraits_2 and the
  value type of the input iterator to be X_monotone_curve_2 (and not the
  general Curve_2). This requires the introduction of a new visitor that
  does not call the make_x_monotone().

- The callback functions of the observers are const referenced. However,
  the documentation generator automatically removes the const reference when
  it generates the cods. The result is very misleading!

- The documentation of ParameterSpaceInX_2 and ParameterSpaceInY_2 are
missing the requirement for an operator that accepts a point. Is it really
needed? Seems like it for isolated points.

- _offset_polygon() defined in Approx_offset_base_2.h has a local variable
  of type kernel. There should be an overloaded function that accepts a
  kernel as a parameter.

- Make the Arr_circle_segment_traits_2 a model of the landmark concept. Need
  to add 2 required operations, which seems possible.

- Support Minkowski sum of a degenerate polygons (using convolution)
  * A polygon and a point
  * A polygon and a line
  Define precisely what type of polygons are valid as summands.

- Add non_const_handle(e), where e is an edge handle.

- (Nick Simon) Is there a polygon validation method that will tell me if a
  general polygon with holes is weakly simple or not -- in particular,
  whether a hole intersects the boundary?