From: Wolfgang Bangerth <bangerth@math.tamu.edu>
Date: Tue, 8 Aug 2000 13:48:40 +0000 (+0000)
Subject: Change many @p's to @refs and assorted small doc updates.
X-Git-Tag: v8.0.0~20193
X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=908cb9099806cc286eb9daadaee0b5d445036e3a;p=dealii.git

Change many @p's to @refs and assorted small doc updates.


git-svn-id: https://svn.dealii.org/trunk@3236 0785d39b-7218-0410-832d-ea1e28bc413d
---

diff --git a/deal.II/deal.II/include/dofs/dof_accessor.h b/deal.II/deal.II/include/dofs/dof_accessor.h
index f0d191b362..c32820885c 100644
--- a/deal.II/deal.II/include/dofs/dof_accessor.h
+++ b/deal.II/deal.II/include/dofs/dof_accessor.h
@@ -41,10 +41,10 @@ template <int dim> class DoFHandler;
  * result in a strange kind of behaviour, though every reasonable
  * operating system should disallow access through that pointer.
  * The reason we do not check for the null pointer in the
- * constructor which gets passed the @p{DoFHandler} pointer is that
+ * constructor which gets passed the @ref{DoFHandler} pointer is that
  * if we did we could not make dof iterators member of other classes
- * (like in the @p{FEValues} class) if we did not know about the
- * @p{DoFHandler} object to be used upon construction of that object.
+ * (like in the @ref{FEValues} class) if we did not know about the
+ * @ref{DoFHandler} object to be used upon construction of that object.
  * Through the way this class is implemented here, we allow the
  * creation of a kind of virgin object which only gets useful if
  * assigned to from another object before first usage.
@@ -85,7 +85,7 @@ class DoFAccessor
 
 				     /**
 				      * Return a handle on the
-				      * @p{DoFHandler} object which we
+				      * @ref{DoFHandler} object which we
 				      * are using.
 				      */
     const DoFHandler<dim> &
@@ -120,7 +120,7 @@ class DoFAccessor
 
   protected:
 				     /**
-				      * Store the address of the @p{DoFHandler} object
+				      * Store the address of the @ref{DoFHandler} object
 				      * to be accessed.
 				      */
     DoFHandler<dim> *dof_handler;  
@@ -131,13 +131,13 @@ class DoFAccessor
 
 /**
  * This is a switch class which only declares a @p{typedef}. It is meant to
- * determine which class a @p{DoFObjectAccessor} class is to be derived
+ * determine which class a @ref{DoFObjectAccessor} class is to be derived
  * from. By default, @p{DoFObjectAccessor<celldim,dim>} derives from
  * the @p{typedef} in the general @p{DoFObjectAccessor_Inheritance<celldim,dim>}
  * class, which is @p{TriaObjectAccessor<celldim,dim>},
  * but if @p{celldim==dim}, then the specialization @p{DoFObjectAccessor_Inheritance<dim,dim>}
  * is used which declares its local type to be @p{CellAccessor<dim>}. Therefore,
- * the inheritance is automatically chosen to be from @p{CellAccessor} if the
+ * the inheritance is automatically chosen to be from @ref{CellAccessor} if the
  * object under consideration has full dimension, i.e. constitutes a cell.
  *
  * @author Wolfgang Bangerth, 1999
@@ -156,13 +156,13 @@ class DoFObjectAccessor_Inheritance
 
 /**
  * This is a switch class which only declares a @p{typedef}. It is meant to
- * determine which class a @p{DoFObjectAccessor} class is to be derived
+ * determine which class a @ref{DoFObjectAccessor} class is to be derived
  * from. By default, @p{DoFObjectAccessor<celldim,dim>} derives from
  * the @p{typedef} in the general @p{DoFObjectAccessor_Inheritance<celldim,dim>}
  * class, which is @p{TriaObjectAccessor<celldim,dim>},
  * but if @p{celldim==dim}, then the specialization @p{DoFObjectAccessor_Inheritance<dim,dim>}
  * is used which declares its local type to be @p{CellAccessor<dim>}. Therefore,
- * the inheritance is automatically chosen to be from @p{CellAccessor} if the
+ * the inheritance is automatically chosen to be from @ref{CellAccessor} if the
  * object under consideration has full dimension, i.e. constitutes a cell.
  *
  * @author Wolfgang Bangerth, 1999
@@ -243,7 +243,7 @@ class DoFObjectAccessor : public DoFAccessor<dim>,
     				     /**
 				      * Constructor. The @p{local_data}
 				      * argument is assumed to be a pointer
-				      * to a @p{DoFHandler<dim>} object.
+				      * to a @ref{DoFHandler} object.
 				      */
     DoFObjectAccessor (Triangulation<dim> *tria,
 		    const int           level,
@@ -309,8 +309,8 @@ class DoFObjectAccessor : public DoFAccessor<dim>,
 				      *
 				      * The input vector may be either
 				      * a @p{Vector<float>},
-				      * @p{Vector<double>}, or a
-				      * @p{BlockVector<...,double>}. It
+				      * @ref{Vector}@p{<double>}, or a
+				      * @ref{BlockVector}@p{<...,double>}. It
 				      * is in the responsibility of
 				      * the caller to assure that the
 				      * types of the numbers stored in
@@ -346,9 +346,9 @@ class DoFObjectAccessor : public DoFAccessor<dim>,
 				      * to this function.
 				      *
 				      * The output vector may be either
-				      * a @p{Vector<float>},
-				      * @p{Vector<double>}, or a
-				      * @p{BlockVector<...,double>}. It
+				      * a @ref{Vector}@p{<float>},
+				      * @ref{Vector}@p{<double>}, or a
+				      * @ref{BlockVector}@p{<...,double>}. It
 				      * is in the responsibility of
 				      * the caller to assure that the
 				      * types of the numbers stored in
@@ -375,7 +375,7 @@ class DoFObjectAccessor : public DoFAccessor<dim>,
     quad (const unsigned int i) const;
     
 				     /**
-				      * @p{i}th child as a @p{DoFObjectAccessor}
+				      * @p{i}th child as a @ref{DoFObjectAccessor}
 				      * iterator. This function is needed since
 				      * the child function of the base
 				      * class returns a hex accessor without
@@ -400,7 +400,7 @@ class DoFObjectAccessor : public DoFAccessor<dim>,
 
 				     /**
 				      * This function does much the same as the
-				      * @p{distribute_local_to_global(dVector,dVector)}
+				      * @p{distribute_local_to_global(Vector<double>,Vector<double>)}
 				      * function, but operates on matrices
 				      * instead of vectors. The sparse matrix
 				      * is supposed to have non-zero entry
@@ -497,7 +497,7 @@ class DoFObjectAccessor<1, dim> :  public DoFAccessor<dim>,
     				     /**
 				      * Constructor. The @p{local_data}
 				      * argument is assumed to be a pointer
-				      * to a @p{DoFHandler<dim>} object.
+				      * to a @ref{DoFHandler} object.
 				      */
     DoFObjectAccessor (Triangulation<dim> *tria,
 		       const int           level,
@@ -559,9 +559,9 @@ class DoFObjectAccessor<1, dim> :  public DoFAccessor<dim>,
 				      * cells.
 				      *
 				      * The input vector may be either
-				      * a @p{Vector<float>},
-				      * @p{Vector<double>}, or a
-				      * @p{BlockVector<...,double>}. It
+				      * a @ref{Vector}@p{<float>},
+				      * @ref{Vector}@p{<double>}, or a
+				      * @ref{BlockVector}@p{<...,double>}. It
 				      * is in the responsibility of
 				      * the caller to assure that the
 				      * types of the numbers stored in
@@ -596,9 +596,9 @@ class DoFObjectAccessor<1, dim> :  public DoFAccessor<dim>,
 				      * have the right size beforehand.
 				      *
 				      * The output vector may be either
-				      * a @p{Vector<float>},
-				      * @p{Vector<double>}, or a
-				      * @p{BlockVector<...,double>}. It
+				      * a @ref{Vector}@p{<float>},
+				      * @ref{Vector}@p{<double>}, or a
+				      * @ref{BlockVector}@p{<...,double>}. It
 				      * is in the responsibility of
 				      * the caller to assure that the
 				      * types of the numbers stored in
@@ -636,7 +636,7 @@ class DoFObjectAccessor<1, dim> :  public DoFAccessor<dim>,
 
 				     /**
 				      * This function does much the same as the
-				      * @p{distribute_local_to_global(dVector,dVector)}
+				      * @p{distribute_local_to_global(Vector<double>,Vector<double>)}
 				      * function, but operates on matrices
 				      * instead of vectors. The sparse matrix
 				      * is supposed to have non-zero entry
@@ -685,7 +685,7 @@ class DoFObjectAccessor<2, dim> :  public DoFAccessor<dim>,
     				     /**
 				      * Constructor. The @p{local_data}
 				      * argument is assumed to be a pointer
-				      * to a @p{DoFHandler<dim>} object.
+				      * to a @ref{DoFHandler} object.
 				      */
     DoFObjectAccessor (Triangulation<dim> *tria,
 		     const int           level,
@@ -748,9 +748,9 @@ class DoFObjectAccessor<2, dim> :  public DoFAccessor<dim>,
 				      * cells.
 				      *
 				      * The input vector may be either
-				      * a @p{Vector<float>},
-				      * @p{Vector<double>}, or a
-				      * @p{BlockVector<...,double>}. It
+				      * a @ref{Vector}@p{<float>},
+				      * @ref{Vector}@p{<double>}, or a
+				      * @ref{BlockVector}@p{<...,double>}. It
 				      * is in the responsibility of
 				      * the caller to assure that the
 				      * types of the numbers stored in
@@ -785,9 +785,9 @@ class DoFObjectAccessor<2, dim> :  public DoFAccessor<dim>,
 				      * have the right size beforehand.
 				      *
 				      * The output vector may be either
-				      * a @p{Vector<float>},
-				      * @p{Vector<double>}, or a
-				      * @p{BlockVector<...,double>}. It
+				      * a @ref{Vector}@p{<float>},
+				      * @ref{Vector}@p{<double>}, or a
+				      * @ref{BlockVector}@p{<...,double>}. It
 				      * is in the responsibility of
 				      * the caller to assure that the
 				      * types of the numbers stored in
@@ -833,7 +833,7 @@ class DoFObjectAccessor<2, dim> :  public DoFAccessor<dim>,
 
 				     /**
 				      * This function does much the same as the
-				      * @p{distribute_local_to_global(dVector,dVector)}
+				      * @p{distribute_local_to_global(Vector<double>,Vector<double>)}
 				      * function, but operates on matrices
 				      * instead of vectors. The sparse matrix
 				      * is supposed to have non-zero entry
@@ -882,7 +882,7 @@ class DoFObjectAccessor<3, dim> :  public DoFAccessor<dim>,
     				     /**
 				      * Constructor. The @p{local_data}
 				      * argument is assumed to be a pointer
-				      * to a @p{DoFHandler<dim>} object.
+				      * to a @ref{DoFHandler} object.
 				      */
     DoFObjectAccessor (Triangulation<dim> *tria,
 		    const int           level,
@@ -945,9 +945,9 @@ class DoFObjectAccessor<3, dim> :  public DoFAccessor<dim>,
 				      * cells.
 				      *
 				      * The input vector may be either
-				      * a @p{Vector<float>},
-				      * @p{Vector<double>}, or a
-				      * @p{BlockVector<...,double>}. It
+				      * a @ref{Vector}@p{<float>},
+				      * @ref{Vector}@p{<double>}, or a
+				      * @ref{BlockVector}@p{<...,double>}. It
 				      * is in the responsibility of
 				      * the caller to assure that the
 				      * types of the numbers stored in
@@ -982,9 +982,9 @@ class DoFObjectAccessor<3, dim> :  public DoFAccessor<dim>,
 				      * have the right size beforehand.
 				      *
 				      * The output vector may be either
-				      * a @p{Vector<float>},
-				      * @p{Vector<double>}, or a
-				      * @p{BlockVector<...,double>}. It
+				      * a @ref{Vector}@p{<float>},
+				      * @ref{Vector}@p{<double>}, or a
+				      * @ref{BlockVector}@p{<...,double>}. It
 				      * is in the responsibility of
 				      * the caller to assure that the
 				      * types of the numbers stored in
@@ -1036,7 +1036,7 @@ class DoFObjectAccessor<3, dim> :  public DoFAccessor<dim>,
 
 				     /**
 				      * This function does much the same as the
-				      * @p{distribute_local_to_global(dVector,dVector)}
+				      * @p{distribute_local_to_global(Vector<double>,Vector<double>)}
 				      * function, but operates on matrices
 				      * instead of vectors. The sparse matrix
 				      * is supposed to have non-zero entry
@@ -1053,6 +1053,7 @@ class DoFObjectAccessor<3, dim> :  public DoFAccessor<dim>,
 };
 
 
+
 /**
  * Grant access to the degrees of freedom on a cell. In fact, since all
  * access to the degrees of freedom has been enabled by the classes
@@ -1060,14 +1061,14 @@ class DoFObjectAccessor<3, dim> :  public DoFAccessor<dim>,
  * one and two, respectively, this class only collects the pieces
  * together by deriving from the appropriate @p{DoF*Accessor} and the
  * right @p{CellAccessor<dim>} and finally adding two functions which give
- * access to the neighbors and children as @p{DoFCellAccessor} objects
- * rather than @p{CellAccessor} objects (the latter function was inherited
+ * access to the neighbors and children as @ref{DoFCellAccessor} objects
+ * rather than @ref{CellAccessor} objects (the latter function was inherited
  * from the @p{CellAccessor<dim>} class).
  *
  * Note that since for the class we derive from, i.e. @p{DoFObjectAccessor<dim,dim>},
  * the two template parameters are equal, the base class is actually derived from
- * @p{CellAccessor}, which makes the functions of this class available to the
- * @p{DoFCellAccessor} class as well.
+ * @ref{CellAccessor}, which makes the functions of this class available to the
+ * @ref{DoFCellAccessor} class as well.
  *
  * @author Wolfgang Bangerth, 1998
  */
@@ -1233,9 +1234,9 @@ class DoFCellAccessor :  public DoFObjectAccessor<dim, dim>
 				      * objects.
 				      *
 				      * The output vector may be either
-				      * a @p{Vector<float>},
-				      * @p{Vector<double>}, or a
-				      * @p{BlockVector<...,double>}. It
+				      * a @ref{Vector}@p{<float>},
+				      * @ref{Vector}@p{<double>}, or a
+				      * @ref{BlockVector}@p{<...,double>}. It
 				      * is in the responsibility of
 				      * the caller to assure that the
 				      * types of the numbers stored in
diff --git a/deal.II/deal.II/include/dofs/dof_constraints.h b/deal.II/deal.II/include/dofs/dof_constraints.h
index c599e6407e..a44c9bcd14 100644
--- a/deal.II/deal.II/include/dofs/dof_constraints.h
+++ b/deal.II/deal.II/include/dofs/dof_constraints.h
@@ -44,7 +44,7 @@ template <int n_blocks> class BlockIndices;
  * operation.
  *
  * Condensation is done in four steps: first the large matrix sparsity pattern
- * is created (e.g. using @p{DoFHandler::create_sparsity_pattern}), then the
+ * is created (e.g. using @ref{DoFHandler}@p{::create_sparsity_pattern}), then the
  * sparsity pattern of the condensed matrix is made out of the large sparsity
  * pattern and the constraints. After that the global matrix is assembled and
  * finally condensed. To do these steps, you have (at least) two possibilities:
@@ -286,9 +286,9 @@ class ConstraintMatrix : public Subscriptor
 				      * entries of @p{condensed} be zero!
 				      *
 				      * The @p{VectorType} may be a
-				      * @p{Vector<float>},
-				      * @p{Vector<double>},
-				      * @p{BlockVector<...>}, or any
+				      * @ref{Vector}@p{<float>},
+				      * @ref{Vector}@p{<double>},
+				      * @ref{BlockVector}@p{<...>}, or any
 				      * other type having the same
 				      * interface.
 				      */
@@ -299,9 +299,9 @@ class ConstraintMatrix : public Subscriptor
 				     /**
 				      * Condense the given vector
 				      * in-place. The @p{VectorType} may
-				      * be a @p{Vector<float>},
-				      * @p{Vector<double>},
-				      * @p{BlockVector<...>}, or any
+				      * be a @ref{Vector}@p{<float>},
+				      * @ref{Vector}@p{<double>},
+				      * @ref{BlockVector}@p{<...>}, or any
 				      * other type having the same
 				      * interface.
 				      */
@@ -323,9 +323,9 @@ class ConstraintMatrix : public Subscriptor
 				      * @p{condense}.
 				      *
 				      * The @p{VectorType} may be a
-				      * @p{Vector<float>},
-				      * @p{Vector<double>},
-				      * @p{BlockVector<...>}, or any
+				      * @ref{Vector}@p{<float>},
+				      * @ref{Vector}@p{<double>},
+				      * @ref{BlockVector}@p{<...>}, or any
 				      * other type having the same
 				      * interface.
 				      */
@@ -337,9 +337,9 @@ class ConstraintMatrix : public Subscriptor
 				      * Re-distribute the elements of
 				      * the vector in-place. The
 				      * @p{VectorType} may be a
-				      * @p{Vector<float>},
-				      * @p{Vector<double>},
-				      * @p{BlockVector<...>}, or any
+				      * @ref{Vector}@p{<float>},
+				      * @ref{Vector}@p{<double>},
+				      * @ref{BlockVector}@p{<...>}, or any
 				      * other type having the same
 				      * interface.
 				      */
@@ -351,9 +351,9 @@ class ConstraintMatrix : public Subscriptor
 				      * vector.  Sets all hanging node
 				      * values to zero. The
 				      * @p{VectorType} may be a
-				      * @p{Vector<float>},
-				      * @p{Vector<double>},
-				      * @p{BlockVector<...>}, or any
+				      * @ref{Vector}@p{<float>},
+				      * @ref{Vector}@p{<double>},
+				      * @ref{BlockVector}@p{<...>}, or any
 				      * other type having the same
 				      * interface.
 				      */
@@ -443,7 +443,7 @@ class ConstraintMatrix : public Subscriptor
 					  * For the reason why we use a vector
 					  * instead of a map and the consequences
 					  * thereof, the same applies as what is
-					  * said for @p{ConstraintMatrix::lines}.
+					  * said for @ref{ConstraintMatrix}@p{::lines}.
 					  */
 	vector<pair<unsigned int,double> > entries;
 
diff --git a/deal.II/deal.II/include/dofs/dof_handler.h b/deal.II/deal.II/include/dofs/dof_handler.h
index a344be7c04..edbf9d2dc0 100644
--- a/deal.II/deal.II/include/dofs/dof_handler.h
+++ b/deal.II/deal.II/include/dofs/dof_handler.h
@@ -48,7 +48,8 @@ class DoFDimensionInfo;
  *
  * The types have the same meaning as those declared in @ref{TriaDimensionInfo<2>}.
  */
-class DoFDimensionInfo<1> {
+class DoFDimensionInfo<1>
+{
   public:
     typedef TriaRawIterator<1,DoFCellAccessor<1> >    raw_line_iterator;
     typedef TriaIterator<1,DoFCellAccessor<1> >       line_iterator;
@@ -72,12 +73,14 @@ class DoFDimensionInfo<1> {
 };
 
 
+
 /**
  * Define some types for the DoF handling in two dimensions.
  *
  * The types have the same meaning as those declared in @ref{TriaDimensionInfo<2>}.
  */
-class DoFDimensionInfo<2> {
+class DoFDimensionInfo<2>
+{
   public:
     typedef TriaRawIterator<2,DoFObjectAccessor<1, 2> >    raw_line_iterator;
     typedef TriaIterator<2,DoFObjectAccessor<1, 2> >       line_iterator;
@@ -101,12 +104,14 @@ class DoFDimensionInfo<2> {
 };
 
 
+
 /**
  * Define some types for the DoF handling in two dimensions.
  *
  * The types have the same meaning as those declared in @ref{TriaDimensionInfo<3>}.
  */
-class DoFDimensionInfo<3> {
+class DoFDimensionInfo<3>
+{
   public:
     typedef TriaRawIterator<3,DoFObjectAccessor<1, 3> >    raw_line_iterator;
     typedef TriaIterator<3,DoFObjectAccessor<1, 3> >       line_iterator;
@@ -130,6 +135,7 @@ class DoFDimensionInfo<3> {
 };
 
 
+
 /**
  * Manage the distribution and numbering of the degrees of freedom for
  * non-multigrid algorithms.
@@ -149,7 +155,7 @@ class DoFDimensionInfo<3> {
  * by offering @p{begin()} and @p{end()} functions which return iterators
  * to walk on the DoF structures as well as the triangulation data.
  * These iterators work much like those described in the documentation
- * of the @p{Triangulation} class and of the iterator classes themselved,
+ * of the @ref{Triangulation} class and of the iterator classes themselved,
  * but offer more functionality than pure triangulation iterators. The
  * order in which dof iterators are presented by the @p{++} and @p{--} operators
  * is the same as that for the alike triangulation iterators.
@@ -175,14 +181,14 @@ class DoFDimensionInfo<3> {
  *
  * This numbering implies very large bandwiths of the resulting matrices and
  * is thus vastly suboptimal for some solution algorithms. For this reason,
- * the @p{DoFRenumbering} class offers the function @p{renumber_dofs} which reorders
+ * the @ref{DoFRenumbering} class offers the function @p{renumber_dofs} which reorders
  * the dof numbering according to some scheme. See there for a discussion of
  * the implemented algorithms.
  *
  *
  * @sect3{User defined renumbering schemes}
  *
- * The @p{DoFRenumbering} class offers a fixed number of renumbering
+ * The @ref{DoFRenumbering} class offers a fixed number of renumbering
  * schemes like the Cuthill-McKey scheme. Basically, the function sets
  * up an array in which for each degree of freedom the index is stored
  * which is to be assigned by the renumbering. Using this array, the
@@ -250,7 +256,7 @@ class DoFDimensionInfo<3> {
  * Lagrange elements this is the point where it has the function value @p{1}), is
  * located on the boundary. We do not check this directly, the criterion is
  * rather defined through the information the finite element class gives: the
- * @p{FiniteElementBase} class defines the numbers of basis functions per vertex,
+ * @ref{FiniteElementBase} class defines the numbers of basis functions per vertex,
  * per line, and so on and the basis functions are numbered after this
  * information; a basis function is to be considered to be on the face of a
  * cell (and thus on the boundary if the cell is at the boundary) according
@@ -405,7 +411,7 @@ class DoFHandler  :  public Subscriptor,
 				      * This is the maximum number of entries
 				      * per line in the system matrix; this
 				      * information can therefore be used upon
-				      * construction of the @p{SparsityPattern}
+				      * construction of the @ref{SparsityPattern}
 				      * object.
 				      *
 				      * The returned number is not really the
diff --git a/deal.II/deal.II/include/dofs/dof_levels.h b/deal.II/deal.II/include/dofs/dof_levels.h
index f8e52e8cf9..40a3cf92de 100644
--- a/deal.II/deal.II/include/dofs/dof_levels.h
+++ b/deal.II/deal.II/include/dofs/dof_levels.h
@@ -21,6 +21,8 @@
  * Store the indices of the degrees of freedom which are located on the lines.
  * Declare it to have a template parameter, but do not actually declare
  * other types than those explicitely instantiated.
+ *
+ * @author Wolfgang Bangerth, 1998
  */
 template <int N>
 class DoFLevel
@@ -37,9 +39,9 @@ class DoFLevel
 /**
  * Store the indices of the degrees of freedom which are located on the lines.
  *
- * @sect3{Information for all @p{DoFLevel} classes}
+ * @sect3{Information for all @ref{DoFLevel} classes}
  *
- * The @p{DoFLevel<N>} classes 
+ * The @ref{DoFLevel}@p{<N>} classes 
  * store the global indices of the degrees of freedom for each cell on a
  * certain level. The index or number of a degree of freedom is the zero-based
  * index of the according value in the solution vector and the row and column
@@ -57,25 +59,27 @@ class DoFLevel
  * $\ldots, u_1^m, u_2^m, u_1^{m+1}, u_2^{m+1},\ldots$ with $m$ denoting the
  * $m$th basis function, or $\ldots, u_1^m, u_1^{m+1}, u_1^{m+2}, \ldots,
  * u_2^m, u_2^{m+1}, u_2^{m+2}, \ldots$, respectively). Likewise, the
- * constraint matrix returned by @p{DoFHandler::make_hanging_node_constraints ()}
+ * constraint matrix returned by @ref{DoFHandler}@p{::make_hanging_node_constraints ()}
  * is then
  * to be understood as a block matrix.
  *
  * The storage format of the degrees of freedom indices (short: DoF indices) is
  * somewhat like a mirror of the data structures of the triangulation classes.
- * There is a hierarchy of @p{DoFLevel<dim>} classes for the different dimensions
+ * There is a hierarchy of @ref{DoFLevel}@p{<dim>} classes for the different dimensions
  * which have objects named @p{line_dofs}, @p{quad_dofs} and so on, in which the
  * indices of DoFs located on lines and quads, respectively, are stored. The
  * indices are stored levelwise. The layout in
  * these arrays is as follows: if for a selected finite element (use
- * @p{DoFHandler::distribute_dofs()} to select a finite element) the number of
+ * @ref{DoFHandler}@p{::distribute_dofs()} to select a finite element) the number of
  * DoFs on each line (without those in the vertices) is @p{N}, then the length
  * of the @p{line_dofs} array is @p{N} times the number of lines on this level. The
  * DoF indices for the @p{i}th line are at the positions @p{N*i...(N+1)*i-1}.
  *
  * The DoF indices for vertices are not stored this way, since they need
  * different treatment in multigrid environments. If no multigrid is used, the
- * indices are stored in the @p{vertex_dofs} array of the @p{DoFHandler} class.
+ * indices are stored in the @p{vertex_dofs} array of the @ref{DoFHandler} class.
+ *
+ * @author Wolfgang Bangerth, 1998
  */
 class DoFLevel<1>
 {
@@ -89,11 +93,15 @@ class DoFLevel<1>
 };
 
 
+
 /**
  * Store the indices of the degrees of freedom which are located on quads.
  * See @ref{DoFLevel<1>} for more information.
+ *
+ * @author Wolfgang Bangerth, 1998
  */
-class DoFLevel<2> : public DoFLevel<1> {
+class DoFLevel<2> : public DoFLevel<1>
+{
   public:
 				     /**
 				      * Store the global indices of the degrees
@@ -104,11 +112,15 @@ class DoFLevel<2> : public DoFLevel<1> {
 };
 
 
+
 /**
  * Store the indices of the degrees of freedom which are located on hexhedra.
  * See @ref{DoFLevel<1>} for more information.
+ *
+ * @author Wolfgang Bangerth, 1998
  */
-class DoFLevel<3> : public DoFLevel<2> {
+class DoFLevel<3> : public DoFLevel<2>
+{
   public:
 				     /**
 				      * Store the global indices of the degrees
diff --git a/deal.II/deal.II/include/dofs/dof_tools.h b/deal.II/deal.II/include/dofs/dof_tools.h
index 0ed2a26456..2ac82095cb 100644
--- a/deal.II/deal.II/include/dofs/dof_tools.h
+++ b/deal.II/deal.II/include/dofs/dof_tools.h
@@ -33,7 +33,7 @@ template <template <int> class GridClass, int dim> class InterGridMap;
  * documentation stating some commonalities.
  *
  * All member functions are static, so there is no need to create an
- * object of class @p{DoFTools}.
+ * object of class @ref{DoFTools}.
  *
  * @sect3{Setting up sparsity patterns}
  *
@@ -99,17 +99,17 @@ class DoFTools
 				      * of hanging nodes.  They have
 				      * to be taken care of by a call
 				      * to
-				      * @p{ConstraintMatrix::condense()}
+				      * @ref{ConstraintMatrix}@p{::condense()}
 				      * afterwards.
 				      *
 				      * Remember using
-				      * @p{SparsityPattern::compress()}
+				      * @ref{SparsityPattern}@p{::compress()}
 				      * after generating the pattern.
 				      *
 				      * The actual type of the
 				      * sparsity pattern may be
-				      * @p{SparsityPattern},
-				      * @p{BlockSparsityPattern}, or any
+				      * @ref{SparsityPattern},
+				      * @ref{BlockSparsityPattern}, or any
 				      * other class that satisfies
 				      * similar requirements.
 				      */
@@ -138,7 +138,7 @@ class DoFTools
 				      *
 				      * in two space dimensions,
 				      * using stable Q2/Q1 mixed
-				      * elements (using the @p{FESystem}
+				      * elements (using the @ref{FESystem}
 				      * class), then you don't want
 				      * all degrees of freedom to
 				      * couple in each equation. You
@@ -153,14 +153,14 @@ class DoFTools
 				      * @end{verbatim}
 				      * where "1" indicates that two
 				      * variables (i.e. components of
-				      * the @p{FESystem}) couple in the
+				      * the @ref{FESystem}) couple in the
 				      * respective equation, and a "0"
 				      * means no coupling, in which
 				      * case it is not necessary to
 				      * allocate space in the matrix
 				      * structure. Obviously, the mask
 				      * refers to components of the
-				      * composed @p{FESystem}, rather
+				      * composed @ref{FESystem}, rather
 				      * than to the degrees of freedom
 				      * contained in there.
 				      *
@@ -179,8 +179,8 @@ class DoFTools
 				      *
 				      * The actual type of the
 				      * sparsity pattern may be
-				      * @p{SparsityPattern},
-				      * @p{BlockSparsityPattern}, or any
+				      * @ref{SparsityPattern},
+				      * @ref{BlockSparsityPattern}, or any
 				      * other class that satisfies
 				      * similar requirements.
 				      */
@@ -201,14 +201,14 @@ class DoFTools
 				      * nodes.  The sparsity pattern
 				      * is not compressed, since if
 				      * you want to call
-				      * @p{ConstraintMatrix::condense(1)}
+				      * @ref{ConstraintMatrix}@p{::condense(1)}
 				      * afterwards, new entries have
 				      * to be added. However, if you
 				      * don't want to call
-				      * @p{ConstraintMatrix::condense(1)},
+				      * @ref{ConstraintMatrix}@p{::condense(1)},
 				      * you have to compress the
 				      * matrix yourself, using
-				      * @p{SparsityPattern::compress()}.
+				      * @ref{SparsityPattern}@p{::compress()}.
 				      *
 				      * Since this function is
 				      * obviously useless in one
@@ -327,7 +327,7 @@ class DoFTools
 				      * function.
 				      *
 				      * To condense a given sparsity pattern,
-				      * use @p{ConstraintMatrix::condense}.
+				      * use @ref{ConstraintMatrix}@p{::condense}.
 				      * Before doing so, you need to close
 				      * the constraint object, which must be
 				      * done after all constraints are entered.
@@ -351,8 +351,8 @@ class DoFTools
 				      * continuous at hanging nodes. This can,
 				      * however, easily be arranged by calling
 				      * the appropraite @p{distribute} function
-				      * of a @p{ConstraintMatrix} object created
-				      * for this @p{DoFHandler} object.
+				      * of a @ref{ConstraintMatrix} object created
+				      * for this @ref{DoFHandler} object.
 				      *
 				      * It is assumed that the number of
 				      * elements in @p{cell_data} equals the
@@ -395,8 +395,8 @@ class DoFTools
 				      * of freedom belonging to certain
 				      * components. The bit vector @p{select}
 				      * defines, which components of an
-				      * @p{FESystem} are to be extracted
-				      * from the DoFHandler @p{dof}. The
+				      * @ref{FESystem} are to be extracted
+				      * from the @ref{DoFHandler} @p{dof}. The
 				      * respective entries in @p{selected_dofs}
 				      * are then flagged @p{true}, while all
 				      * others are set to @p{false}.
@@ -668,7 +668,7 @@ class DoFTools
 				      * to the variable ``q''; zero
 				      * would be ``u'', two would be
 				      * ``lambda''). Furthermore, an
-				      * object of type @p{IntergridMap}
+				      * object of type @ref{IntergridMap}
 				      * is needed; this could in
 				      * principle be generated by the
 				      * function itself from the two
@@ -680,7 +680,7 @@ class DoFTools
 				      * it. Finally, the computed
 				      * constraints are entered into a
 				      * variable of type
-				      * @p{ConstraintMatrix}; the
+				      * @ref{ConstraintMatrix}; the
 				      * constraints are added,
 				      * i.e. previous contents which
 				      * may have, for example, be
diff --git a/deal.II/deal.II/include/fe/fe.h b/deal.II/deal.II/include/fe/fe.h
index bd9c7b70a7..438c4c6350 100644
--- a/deal.II/deal.II/include/fe/fe.h
+++ b/deal.II/deal.II/include/fe/fe.h
@@ -842,7 +842,7 @@ class FiniteElementBase : public Subscriptor,
  *
  * The faces of a hexahedron are arranged in a way such that
  * some must be viewed from the inside and some from the outside of the cell to
- * show this order; refer to the documentation of the @p{Triangulation} class for
+ * show this order; refer to the documentation of the @ref{Triangulation} class for
  * the definition of this.
  *
  * If of the cells adjacent to one line more than one is refined and there is
@@ -995,7 +995,7 @@ class FiniteElementBase : public Subscriptor,
  *   of this class.
  *
  *   This also is used in some sense in the
- *   @p{DoFHandler::distribute_cell_to_dof_vector} where it is assumed that
+ *   @ref{DoFHandler}@p{::distribute_cell_to_dof_vector} where it is assumed that
  *   the degrees of freedom denote function values and not derivatives or
  *   the like.
  *
@@ -1007,9 +1007,9 @@ class FiniteElementBase : public Subscriptor,
  *
  *   This assumption is used in the @p{VectorTools::project_boundary_values},
  *   @p{MatrixCreator::create_boundary_mass_matrix},
- *   @p{DoFHandler::make_boundary_sparsity_pattern},
- *   @p{DoFHandler::map_dof_to_boundary_indices} and may be a few other places.
- *   The places in the @p{DoFHandler} class are probably not that dangerous,
+ *   @ref{DoFHandler}@p{::make_boundary_sparsity_pattern},
+ *   @ref{DoFHandler}@p{::map_dof_to_boundary_indices} and may be a few other places.
+ *   The places in the @ref{DoFHandler} class are probably not that dangerous,
  *   since wrong results will most likely lead to internal errors through
  *   the @p{Assert} mechanism, but the first places will lead to undiscovered
  *   errors if not thought of properly.
@@ -1020,7 +1020,7 @@ class FiniteElementBase : public Subscriptor,
  *   constrained nodes happens with the face nodes on the large call. If
  *   the assumption does not hold, then the distribution has to happen
  *   with all nodes on the small and the large cells. This is not
- *   implemented in the @p{DoFHandler} class as of now.
+ *   implemented in the @ref{DoFHandler} class as of now.
  * @end{itemize}
  *
  * @author Wolfgang Bangerth, 1998
@@ -1269,7 +1269,7 @@ class FiniteElement : public FiniteElementBase<dim>
 				      * quadrature points which also
 				      * use the standard direction of
 				      * faces as laid down by the
-				      * @p{Triangulation} class.
+				      * @ref{Triangulation} class.
 				      *
 				      * There is a standard
 				      * implementation for dimensions
@@ -1702,15 +1702,15 @@ class FiniteElement : public FiniteElementBase<dim>
 				      * is declared.
 				      *
 				      * The function takes a
-				      * @p{DoFHandler} iterator, which
+				      * @ref{DoFHandler} iterator, which
 				      * provides a superset of
 				      * information to the geometrical
 				      * information needed for the
 				      * computations.  The additional
 				      * data should not be used,
-				      * however a @p{DoFHandler}
+				      * however a @ref{DoFHandler}
 				      * iterator was preferred over a
-				      * @p{Triangulation} iterator
+				      * @ref{Triangulation} iterator
 				      * since this is what usually is
 				      * available in places where this
 				      * function is called.
diff --git a/deal.II/deal.II/include/fe/fe_tools.h b/deal.II/deal.II/include/fe/fe_tools.h
index 2917c7fe8a..cdf6f9a159 100644
--- a/deal.II/deal.II/include/fe/fe_tools.h
+++ b/deal.II/deal.II/include/fe/fe_tools.h
@@ -106,7 +106,7 @@ class FETools
 				    * Gives the interpolation of a the
 				    * @p{dof1}-function @p{u1} to a
 				    * @p{dof2}-function @p{u2}. @p{dof1} and
-				    * @p{dof2} need to be @p{DoFHandler}s
+				    * @p{dof2} need to be @ref{DoFHandler}s
 				    * based on the same triangulation.
 				    *
 				    * If the elements @p{fe1} and @p{fe2}
@@ -168,7 +168,7 @@ class FETools
 				    * extrapolation of a @p{dof1}
 				    * function @p{z1} to a @p{dof2}
 				    * function @p{z2}.  @p{dof1} and
-				    * @p{dof2} need to be @p{DoFHandler}
+				    * @p{dof2} need to be @ref{DoFHandler}
 				    * based on the same triangulation.
 				    *
 				    * This function is interesting for
diff --git a/deal.II/deal.II/include/fe/fe_values.h b/deal.II/deal.II/include/fe/fe_values.h
index be5fa082b9..d85ab1d674 100644
--- a/deal.II/deal.II/include/fe/fe_values.h
+++ b/deal.II/deal.II/include/fe/fe_values.h
@@ -174,7 +174,7 @@ template <int dim> class Quadrature;
  *    the need to pass the cell iterator again to these two functions,
  *    which guarantees that the cell used here is in sync with that used
  *    for the @p{reinit} function. You should, however, make sure that
- *    nothing substantial happens to the @p{DoFHandler} object or any
+ *    nothing substantial happens to the @ref{DoFHandler} object or any
  *    other involved instance between the @p{reinit} and the @p{get_function_*}
  *    functions are called.
  *
@@ -884,7 +884,7 @@ class FEValues : public FEValuesBase<dim>
  *  the convention is used that the unit cell/face be the tensor product of the
  *  interval $[-1,1]$, which is to distinguished properly. A subface is the
  *  child of a face; they are numbered in the way laid down in the
- *  @p{Triangulation} class.
+ *  @ref{Triangulation} class.
  *
  *  Just like in the @p{FEValues} class, function values and gradients on the unit
  *  face or subface are evaluated at the quadrature points only once, and stored
diff --git a/deal.II/deal.II/include/grid/geometry_info.h b/deal.II/deal.II/include/grid/geometry_info.h
index b9ed710ac5..38d0e45252 100644
--- a/deal.II/deal.II/include/grid/geometry_info.h
+++ b/deal.II/deal.II/include/grid/geometry_info.h
@@ -19,7 +19,7 @@
 template <int _dim> struct GeometryInfo;
 
 /**
- * Pseudo-class for recursive functions in @p{GeometryInfo<dim>}.
+ * Pseudo-class for recursive functions in @ref{GeometryInfo}@p{<dim>}.
  */
 struct GeometryInfo<0>
 {
@@ -31,11 +31,12 @@ struct GeometryInfo<0>
 };
 
 
+
 /**
  * Topological description of cells.
  *
  * This class contains as static members information on vertices and
- * faces of a @p{dim}-dimensinal grid cell. The interface is the same
+ * faces of a @p{dim}-dimensional grid cell. The interface is the same
  * for all dimensions. If a value is of no use in a low dimensional
  * cell, it is (correctly) set to zero, e.g. @p{sub_faces_per_cell} in
  * 1d.
@@ -182,7 +183,7 @@ struct GeometryInfo
 				      * For three spatial dimensions,
 				      * the exact order of the children is
 				      * laid down in the documentation of
-				      * the @p{Triangulation} class.
+				      * the @ref{Triangulation} class.
 				      */
     static unsigned int child_cell_on_face (unsigned int face,
 					    unsigned int subface);
diff --git a/deal.II/deal.II/include/grid/grid_in.h b/deal.II/deal.II/include/grid/grid_in.h
index 5aca63e999..5d3f729f51 100644
--- a/deal.II/deal.II/include/grid/grid_in.h
+++ b/deal.II/deal.II/include/grid/grid_in.h
@@ -76,7 +76,7 @@ template <int dim> class Triangulation;
  * the middle line would get the direction @p{1->4} when viewed from both cells.
  * The numbering (0 1 4 3) and (5 4 1 2) would not be allowed, since the left
  * quad would give the common line the direction @p{1->4}, while the right one
- * would want to use @p{4->1}, leading to ambiguity. The @p{Triangulation} object
+ * would want to use @p{4->1}, leading to ambiguity. The @ref{Triangulation} object
  * is capable of detecting this special case, which can be eliminated by
  * rotating the indices of the right quad by two. However, it would not
  * know what to do if you gave the vertex indices (4 1 2 5), since then it
diff --git a/deal.II/deal.II/include/grid/grid_out.h b/deal.II/deal.II/include/grid/grid_out.h
index 516d5790bb..cb9638ab80 100644
--- a/deal.II/deal.II/include/grid/grid_out.h
+++ b/deal.II/deal.II/include/grid/grid_out.h
@@ -27,8 +27,8 @@ template <int dim> class Triangulation;
  * the different output functions based on a parameter given, e.g., through
  * a parameter file, thus making user programs invariant of the number and
  * names of the file formats implemented in this class. The main advantage of
- * this class over the @p{DataOut} class is that it does not have to mess around
- * with actual data vectors and that no @p{DoFHandler} object is needed to
+ * this class over the @ref{DataOut} class is that it does not have to mess around
+ * with actual data vectors and that no @ref{DoFHandler} object is needed to
  * write the pure geometrical information involved here.
  *
  * Available output formats can be found in the functions with names @p{write_...}
@@ -48,9 +48,9 @@ template <int dim> class Triangulation;
  *   GridOut().write (tria, output_file, output_format);
  * @end{verbatim}
  * The function @p{get_output_format_names()} provides a list of possible names of
- * output formats in a string that is understandable by the @p{ParameterHandler} class.
+ * output formats in a string that is understandable by the @ref{ParameterHandler} class.
  *
- * Note that here, we have created an unnamed object of type @p{GridOut} and called
+ * Note that here, we have created an unnamed object of type @ref{GridOut} and called
  * one of its @p{write_*} functions. This looks like as if the respective function
  * could really be made @p{static}. This was not done in order to allow for
  * parameters to be passed to the different output functions in a way compatible
@@ -66,9 +66,9 @@ template <int dim> class Triangulation;
  * output format supported which it may then pass on to the respective output
  * function.
  *
- * Rather, we have chosen to let each object of this class @p{GridOut} have a
+ * Rather, we have chosen to let each object of this class @ref{GridOut} have a
  * set of parameters for each supported output format. These are collected
- * in structures @p{EpsFlags}, @p{GnuplotFlags}, etc and you can set your preferred
+ * in structures @ref{EpsFlags}, @ref{GnuplotFlags}, etc and you can set your preferred
  * flags like this:
  * @begin{verbatim}
  *   GridOut grid_out;
@@ -358,7 +358,7 @@ class GridOut
 				      * flags controlling the output
 				      * can be found in the
 				      * documentation of the
-				      * @p{GridOut::GnuplotFlags} class.
+				      * @ref{GridOut::GnuplotFlags} class.
 				      */
     template <int dim>
     void write_gnuplot (const Triangulation<dim> &tria,
@@ -377,7 +377,7 @@ class GridOut
 				      * only, you can decide through
 				      * additional flags (see below,
 				      * and the documentation of the
-				      * @p{GridOut::UcdFlags} class)
+				      * @ref{GridOut::UcdFlags} class)
 				      * whether boundary faces with
 				      * non-zero boundary indicator
 				      * shall be written to the file
@@ -397,7 +397,7 @@ class GridOut
 				      * flags controlling the output
 				      * can be found in the
 				      * documentation of the
-				      * @p{GridOut::UcdFlags} class.
+				      * @ref{GridOut::UcdFlags} class.
 				      */
     template <int dim>
     void write_ucd (const Triangulation<dim> &tria,
@@ -420,7 +420,7 @@ class GridOut
 				      * shall fit into is determined
 				      * by the output flags (see
 				      * below, and the documentation
-				      * of the @p{GridOut::EpsFlags}
+				      * of the @ref{GridOut::EpsFlags}
 				      * class).
 				      *
 				      * The bounding box is close to
@@ -447,7 +447,7 @@ class GridOut
 				      * flags controlling the output
 				      * can be found in the
 				      * documentation of the
-				      * @p{GridOut::EpsFlags}
+				      * @ref{GridOut::EpsFlags}
 				      * class. Especially the
 				      * viewpoint for three
 				      * dimensional grids is of
@@ -533,7 +533,7 @@ class GridOut
 				      *
 				      * To get a list of presently available
 				      * format names, e.g. to give it to the
-				      * @p{ParameterHandler} class, use the
+				      * @ref{ParameterHandler} class, use the
 				      * function @p{get_output_format_names ()}.
 				      */
     static OutputFormat parse_output_format (const string &format_name);
@@ -542,7 +542,7 @@ class GridOut
 				      * Return a list of implemented output
 				      * formats. The different names are
 				      * separated by vertical bar signs (@p{`|'})
-				      * as used by the @p{ParameterHandler}
+				      * as used by the @ref{ParameterHandler}
 				      * classes.
 				      */
     static string get_output_format_names ();
diff --git a/deal.II/deal.II/include/grid/intergrid_map.h b/deal.II/deal.II/include/grid/intergrid_map.h
index ecad3db476..788d472d4e 100644
--- a/deal.II/deal.II/include/grid/intergrid_map.h
+++ b/deal.II/deal.II/include/grid/intergrid_map.h
@@ -60,7 +60,7 @@ template <class T> class SmartPointer;
  *
  * The implementation of this class is such that not only cell iterators
  * into triangulations can be mapped, but also iterators into objects of
- * type @p{DoFHandler} and @p{MGDoFHandler}. The extension to other classes
+ * type @ref{DoFHandler} and @ref{MGDoFHandler}. The extension to other classes
  * offering iterator functions and some minor additional requirements is
  * simple.
  *
@@ -100,7 +100,7 @@ template <class T> class SmartPointer;
  * Note that the template parameters to this class have to be given as
  * @p{InterGridMap<DoFHandler,2>}, i.e. the dimension is given explicitely and
  * no dimension is attributed to the first parameter, which here is
- * @p{DoFHandler} (and could equally well be @p{Triangulation} or @p{MGDoFHandler}).
+ * @ref{DoFHandler} (and could equally well be @ref{Triangulation} or @ref{MGDoFHandler}).
  *
  * @author Wolfgang Bangerth, 1999
  */
diff --git a/deal.II/deal.II/include/grid/persistent_tria.h b/deal.II/deal.II/include/grid/persistent_tria.h
index 16bc88e00e..82c83753c5 100644
--- a/deal.II/deal.II/include/grid/persistent_tria.h
+++ b/deal.II/deal.II/include/grid/persistent_tria.h
@@ -28,7 +28,7 @@
  * of cell numbers to the geometrical cells.
  *
  * Basically, this is a drop-in replacement for the triangulation. Since it
- * is derived from the @p{Triangulation<dim>} class, it shares all the
+ * is derived from the @ref{Triangulation} class, it shares all the
  * functionality, but it overrides some virtual functions and adds some
  * functions, too. The main change to the base class is that it overrides
  * the @p{execute_coarsening_and_refinement} function, where the new version
@@ -40,7 +40,7 @@
  *
  * We note that since the triangulation is created in exactly the same state
  * as it was before, other objects working on it should result in the same
- * state as well. This holds in particular for the @p{DoFHandler} object, which
+ * state as well. This holds in particular for the @ref{DoFHandler} object, which
  * will assign the same degrees of freedom to the original cells and the ones
  * after reconstruction of the triangulation. You can therefore safely use data
  * vectors computed on the original grid on the reconstructed grid as well.
@@ -48,7 +48,7 @@
  *
  * @sect3{Usage}
  * You can use objects of this class almost in the same way as objects of the
- * @p{Triangulation} class. One of the few differences is that you can only
+ * @ref{Triangulation} class. One of the few differences is that you can only
  * construct such an object by giving a coarse grid to the constructor. The
  * coarse grid will be used to base the triangulation on, and therefore the
  * lifetime of the coarse grid has to be longer than the lifetime of the
@@ -86,11 +86,11 @@
  *     };
  * @end{verbatim}
  *
- * Note that initially, the @p{PersistentTriangulation} object does not
+ * Note that initially, the @ref{PersistentTriangulation} object does not
  * constitute a triangulation; it only becomes one after @p{restore} is first
  * called. Note also that the @p{execute_coarsening_and_refinement} stores
  * all necessary flags for later reconstruction using the @p{restore} function.
- * @p{Triangulation<dim>::clear ()} resets the underlying triangulation to a
+ * @ref{Triangulation}@p{<dim>::clear ()} resets the underlying triangulation to a
  * virgin state, but does not affect the stored refinement flags needed for
  * later reconstruction and does also not touch the coarse grid which is
  * used withing @p{restore()}.
diff --git a/deal.II/deal.II/include/grid/tria.h b/deal.II/deal.II/include/grid/tria.h
index d9df9075a6..8b3282dde9 100644
--- a/deal.II/deal.II/include/grid/tria.h
+++ b/deal.II/deal.II/include/grid/tria.h
@@ -450,7 +450,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
 
 
 /**
- *  @p{Triangulation}s denote a hierarchy of levels of elements which together
+ *  @ref{Triangulation}s denote a hierarchy of levels of elements which together
  *  form a region in @p{dim} spatial dimensions.
  *
  *  This class is written to be as independent of the dimension as possible
@@ -463,7 +463,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *
  *  @sect3{Structure and iterators}
  *
- *  The actual data structure of a @p{Triangulation} object is rather complex
+ *  The actual data structure of a @ref{Triangulation} object is rather complex
  *  and quite inconvenient if one attempted to operate on it directly, since
  *  data is spread over quite a lot of arrays and other places. However,
  *  there are ways powerful enough to work on these data structures
@@ -476,7 +476,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *  is reasonable for a cell in the respective dimension, i.e. a @p{Line} in
  *  one dimension, a @p{Quad} in two dimensions, and so on.
  *
- *  The @p{Triangulation} class provides iterator which enable looping over all
+ *  The @ref{Triangulation} class provides iterator which enable looping over all
  *  lines, cells,
  *  etc without knowing the exact representation used to describe them. Their
  *  names are typedefs in the @ref{TriaDimensionInfo} base class (thus making them
@@ -523,12 +523,12 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *  cell is be a vertex in 1D and a line in 2D; however, vertices are
  *  handled in a different way and therefore lines have no faces.
  *
- *  The @p{Triangulation} class offers functions like @p{begin_active} which gives
+ *  The @ref{Triangulation} class offers functions like @p{begin_active} which gives
  *  you an iterator to the first active cell. There are quite a lot of functions
  *  returning iterators. Take a look at the class doc to get an overview.
  *
  *  Usage of these iterators works mostly like with the STL iterators. Some
- *  examples taken from the @p{Triangulation} source code follow.
+ *  examples taken from the @ref{Triangulation} source code follow.
  *  @begin{itemize}
  *  @item @em{Counting the number of cells on a specific level}
  *    @begin{verbatim}
@@ -573,7 +573,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *
  *  @sect3{Usage}
  *
- *  Usage of a @p{Triangulation} is mainly done through the use of iterators.
+ *  Usage of a @ref{Triangulation} is mainly done through the use of iterators.
  *  An example probably shows best how to use it:
  *  @begin{verbatim}
  *  void main () {
@@ -795,7 +795,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   @p{execute_*} stand for @p{execute_coarsening_and_refinement}.
  *
  *   For the purpose of smoothing, the
- *   @p{Triangulation} constructor takes an argument specifying whether a
+ *   @ref{Triangulation} constructor takes an argument specifying whether a
  *   smoothing step shall be performed on the grid each time @p{execute_*}
  *   is called. The default is that such a step not be done, since this results
  *   in additional cells being produced, which may not be necessary in all
@@ -1087,7 +1087,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   boundary, this function is used to compute where it will be
  *   placed. The boundary indicator of the face will be used to
  *   determine the proper component. See @ref{Boundary} for the
- *   details. Usage with the @p{Triangulation} object is then like this
+ *   details. Usage with the @ref{Triangulation} object is then like this
  *   (let @p{Ball} be a class derived from @ref{Boundary}@p{<2>}):
  * 
  *   @begin{verbatim}
diff --git a/deal.II/deal.II/include/grid/tria_accessor.h b/deal.II/deal.II/include/grid/tria_accessor.h
index 816e9c9a87..293e1d4b83 100644
--- a/deal.II/deal.II/include/grid/tria_accessor.h
+++ b/deal.II/deal.II/include/grid/tria_accessor.h
@@ -249,6 +249,7 @@ class TriaAccessor
 };
 
 
+
 /**
  * Common template for line, quad, hex accessors.
  * According to @p{celldim} objects of this class represent lines,
@@ -286,11 +287,13 @@ class TriaObjectAccessor :  public TriaAccessor<dim>
 				      */
 
     void set (const Line&) const;
+    
 				     /**
 				      *  Copy the data of the given quad. Only
 				      * implemented for @p{celldim==2}.
 				      */
     void set (const Quad&) const;
+    
 				     /**
 				      *  Copy the data of the given hex. Only
 				      * implemented for @p{celldim==3}.
@@ -301,7 +304,7 @@ class TriaObjectAccessor :  public TriaAccessor<dim>
 				      *  Index of vertex. The convention regarding the
 				      *  numbering of vertices is laid down
 				      *  in the documentation of the
-				      *  @p{Triangulation} class.
+				      *  @ref{Triangulation} class.
 				      */ 
     int vertex_index (const unsigned int i) const;
 
@@ -515,7 +518,7 @@ class TriaObjectAccessor :  public TriaAccessor<dim>
 				      * the use of this function is only
 				      * possible for @p{dim>celldim};
 				      * however, for @p{dim==celldim}, an object is
-				      * a cell and the @p{CellAccessor} class
+				      * a cell and the @ref{CellAccessor} class
 				      * offers another possibility to
 				      * determine whether a cell is at the
 				      * boundary or not.
@@ -634,6 +637,7 @@ class TriaObjectAccessor :  public TriaAccessor<dim>
 };
 
 
+
 /**
  * Closure class to stop induction of classes. Should never be called and thus
  * producesan error when created.
@@ -663,6 +667,7 @@ class TriaObjectAccessor<0, dim> : public TriaAccessor<dim>
 };
 
 
+
 /**
  *   Accessor to dereference the data of lines. This accessor is used to
  *   point to lines in @p{dim} space dimensions. There is a derived class
@@ -876,7 +881,7 @@ class TriaObjectAccessor<1, dim> :  public TriaAccessor<dim>
 				      * interior of the domain. Obviously,
 				      * this is only possible for @p{dim>1};
 				      * however, for @p{dim==1}, a line is
-				      * a cell and the @p{CellAccessor} class
+				      * a cell and the @ref{CellAccessor} class
 				      * offers another possibility to
 				      * determine whether a cell is at the
 				      * boundary or not.
@@ -997,6 +1002,7 @@ class TriaObjectAccessor<1, dim> :  public TriaAccessor<dim>
 };
 
 
+
 /**
  *   Accessor to dereference the data of quads. This accessor is used to
  *   point to quads in @p{dim} space dimensions (only @p{dim>=2} seems reasonable
@@ -1047,7 +1053,7 @@ class TriaObjectAccessor<2, dim> :  public TriaAccessor<dim>
 
 				     /**
 				      *  Return a pointer to the @p{i}th line
-				      *  bounding this @p{Quad}.
+				      *  bounding this @ref{Quad}.
 				      */
     TriaIterator<dim,TriaObjectAccessor<1, dim> >
     line (const unsigned int i) const;
@@ -1231,7 +1237,7 @@ class TriaObjectAccessor<2, dim> :  public TriaAccessor<dim>
 				      * interior of the domain. Obviously,
 				      * this function is only useful for @p{dim>2};
 				      * however, for @p{dim==2}, a quad is
-				      * a cell and the @p{CellAccessor} class
+				      * a cell and the @ref{CellAccessor} class
 				      * offers another possibility to
 				      * determine whether a cell is at the
 				      * boundary or not.
@@ -1369,6 +1375,7 @@ class TriaObjectAccessor<2, dim> :  public TriaAccessor<dim>
 };
 
 
+
 /**
  *   Accessor to dereference the data of hexahedra. This accessor is used to
  *   point to hexs in @p{dim} space dimensions (only @p{dim>=3} seems reasonable
@@ -1407,7 +1414,7 @@ class TriaObjectAccessor<3, dim> :  public TriaAccessor<dim>
 				      *  a hex. The convention regarding the
 				      *  numbering of vertices is laid down
 				      *  in the documentation of the
-				      *  @p{Triangulation} class.
+				      *  @ref{Triangulation} class.
 				      */ 
     int vertex_index (const unsigned int i) const;
 
@@ -1619,7 +1626,7 @@ class TriaObjectAccessor<3, dim> :  public TriaAccessor<dim>
 				      * the use of this function is only
 				      * possible for @p{dim>3};
 				      * however, for @p{dim==3}, a hex is
-				      * a cell and the @p{CellAccessor} class
+				      * a cell and the @ref{CellAccessor} class
 				      * offers another possibility to
 				      * determine whether a cell is at the
 				      * boundary or not.
@@ -1745,6 +1752,7 @@ class TriaObjectAccessor<3, dim> :  public TriaAccessor<dim>
 };
 
 
+
 /**
  * This class allows access to a cell: a line in one dimension, a quad
  * in two dimension, etc.
@@ -1956,6 +1964,7 @@ class CellAccessor :  public TriaObjectAccessor<dim,dim>
 };
 
 
+
 // if in optimized mode: include more templates
 #ifndef DEBUG
 #  include "tria_accessor.templates.h"
diff --git a/deal.II/deal.II/include/grid/tria_boundary.h b/deal.II/deal.II/include/grid/tria_boundary.h
index 61dbfd3bdf..163948978c 100644
--- a/deal.II/deal.II/include/grid/tria_boundary.h
+++ b/deal.II/deal.II/include/grid/tria_boundary.h
@@ -62,15 +62,16 @@ template <int dim> class Triangulation;
  *   about boundary indicators and the like, as well as all other information
  *   provided by these objects.
  *
- *   There are specialisations, @p{StraightBoundary<dim>}, which places
+ *   There are specialisations, @ref{StraightBoundary}, which places
  *   the new point right into the middle of the given points, and
- *   @p{HyperBallBoundary<dim>} creating a hyperball with given radius
+ *   @ref{HyperBallBoundary} creating a hyperball with given radius
  *   around a given center point.
  *
  *   @author Wolfgang Bangerth, 1999
  */
 template <int dim>
-class Boundary : public Subscriptor {
+class Boundary : public Subscriptor
+{
   public:
 				     /**
 				      * Destructor. Does nothing here, but
@@ -123,6 +124,7 @@ class Boundary : public Subscriptor {
 };
 
 
+
 /**
  *   Specialisation of @ref{Boundary}<dim>, which places the new point right
  *   into the middle of the given points. The middle is defined as the
@@ -163,6 +165,7 @@ class StraightBoundary : public Boundary<dim> {
 };
 
 
+
 /*----------------------------   boundary-function.h     ---------------------------*/
 
 #endif
diff --git a/deal.II/deal.II/include/grid/tria_boundary_lib.h b/deal.II/deal.II/include/grid/tria_boundary_lib.h
index 501272620b..b647a406e3 100644
--- a/deal.II/deal.II/include/grid/tria_boundary_lib.h
+++ b/deal.II/deal.II/include/grid/tria_boundary_lib.h
@@ -26,9 +26,9 @@
  *   The center of the ball and its radius may be given upon construction of
  *   an object of this type. They default to the origin and a radius of 1.0.
  *
- *   This class is derived from @p{StraightBoundary} rather than from
- *   @p{Boundary}, which would seem natural, since this way we can use the
- *   @p{StraightBoundary<dim>::in_between(neighbors)} function.
+ *   This class is derived from @ref{StraightBoundary} rather than from
+ *   @ref{Boundary}, which would seem natural, since this way we can use the
+ *   @ref{StraightBoundary}@p{<dim>::in_between(neighbors)} function.
  *
  * @author Wolfgang Bangerth, 1998
  */
@@ -83,7 +83,7 @@ class HyperBallBoundary : public StraightBoundary<dim>
 
 
 /**
- * Variant of @p{HyperBallBoundary} which denotes a half hyper ball
+ * Variant of @ref{HyperBallBoundary} which denotes a half hyper ball
  * where the first coordinate is restricted to the range $x>=0$ (or
  * $x>=center(0)$). In two dimensions, this equals the right half
  * circle, in three space dimensions it is a half ball. This class
@@ -162,7 +162,7 @@ class HyperShellBoundary : public StraightBoundary<dim>
 
 
 /**
- * Variant of @p{HyperShellBoundary} which denotes a half hyper shell
+ * Variant of @ref{HyperShellBoundary} which denotes a half hyper shell
  * where the first coordinate is restricted to the range $x>=0$ (or
  * $x>=center(0)$). In two dimensions, this equals the right half arc,
  * in three space dimensions it is a half shell. This class might be
diff --git a/deal.II/deal.II/include/grid/tria_hex.h b/deal.II/deal.II/include/grid/tria_hex.h
index 71011ae334..86f8e18fa8 100644
--- a/deal.II/deal.II/include/grid/tria_hex.h
+++ b/deal.II/deal.II/include/grid/tria_hex.h
@@ -28,11 +28,12 @@
  *   of the triangulation.
  *
  *   For conventions on the numbering of faces, lines and vertices within a
- *   hexahedron, refer to the documentation of the @p{Triangulation} class.
+ *   hexahedron, refer to the documentation of the @ref{Triangulation} class.
  *
  *   @author Wolfgang Bangerth, 1998
  */
-class Hexahedron {
+class Hexahedron
+{
   public:
 
 				     /**
@@ -81,7 +82,8 @@ class Hexahedron {
 inline
 Hexahedron::Hexahedron (const int i0, const int i1,
 			const int i2, const int i3,
-			const int i4, const int i5) {
+			const int i4, const int i5)
+{
   quads[0] = i0;
   quads[1] = i1;
   quads[2] = i2;
@@ -91,16 +93,20 @@ Hexahedron::Hexahedron (const int i0, const int i1,
 };
 
 
+
 inline
-int Hexahedron::quad (const int i) const {
+int Hexahedron::quad (const int i) const
+{
   Assert ((i>=0) && (i<6),
 	  ExcRange(i));
   return quads[i];
 };
 
 
+
 inline
-void Hexahedron::set_quad (const int i, const int index) {
+void Hexahedron::set_quad (const int i, const int index)
+{
   Assert ((i>=0) && (i<6),
 	  ExcRange(i));
   quads[i] = index;
diff --git a/deal.II/deal.II/include/grid/tria_iterator.h b/deal.II/deal.II/include/grid/tria_iterator.h
index 5827115f5a..87d88a2a0d 100644
--- a/deal.II/deal.II/include/grid/tria_iterator.h
+++ b/deal.II/deal.II/include/grid/tria_iterator.h
@@ -60,17 +60,17 @@ template <int dim> class Triangulation;
  *   the creation and copying of these iterators is rather expensive
  *   compared to normal pointers.
  *   
- *   The objects pointed to by iterators are @p{TriangulationLevel<1>::LinesData},
- *   @p{TriangulationLevel<2>::LinesData}
- *   and @p{TriangulationLevel<2>::QuadsData}. To chose which of those, the
+ *   The objects pointed to by iterators are @ref{TriangulationLevel<1>}@p{::LinesData},
+ *   @ref{TriangulationLevel<2>}@p{::LinesData}
+ *   and @ref{TriangulationLevel<2>}@p{::QuadsData}. To chose which of those, the
  *   template parameter @p{Pointee} is used.
  *
- *   Since the names as is are quite unhandy, the @p{Triangulation<>} class which
+ *   Since the names as is are quite unhandy, the @ref{Triangulation} class which
  *   uses these iterators declares typedef'd versions. See there for more
  *   information.
  *
- *   The objects pointed to are, as mentioned, @p{LinesData} etc. To be
- *   more exact, when dereferencing an iterator, you do not get a @p{LineData}
+ *   The objects pointed to are, as mentioned, @ref{LinesData} etc. To be
+ *   more exact, when dereferencing an iterator, you do not get a @ref{LineData}
  *   object (or the like, but we will assume that you have a @p{line_iterator}
  *   in the following), but a @em{virtual} object (called @em{accessor}) which
  *   behaves as if it stored the data of a line. It does not contain any data
@@ -79,7 +79,7 @@ template <int dim> class Triangulation;
  *
  *   Since the data of one line is splitted to
  *   several arrays (@p{lines}, @p{children} and @p{used}) for performance reasons
- *   rather than keeping all information in a @p{Line} struct, access through
+ *   rather than keeping all information in a @ref{Line} struct, access through
  *   an accessor is usually much simpler than handling the exact data structure
  *   and also less error prone since the data structure itself can be changed
  *   in an arbitrary way while the only pieces of code which access these
@@ -152,18 +152,18 @@ template <int dim> class Triangulation;
  *   your own version (non-virtual, since we use templates) to add functionality.
  *
  *   There is a standard implementation, using classes which are derived from
- *   @ref{TriaAccessor}. These classes point to @p{Line}s, @p{Quad}s and the like.
+ *   @ref{TriaAccessor}. These classes point to @ref{Line}s, @ref{Quad}s and the like.
  *   For advanced use of the iterator classes, derive classes from
  *   @p{{Line|Quad|Cell}Accessor} which also dereference data structures in other
  *   objects, e.g. in a finite element context. An iterator with such an accessor
  *   then simultaneously points to (for example) a cell in the triangulation and
  *   the data stored on it in the finite element class.
  *
- *   Derived accessor classes may need additional data (e.g. the @p{DoFAccessor}
- *   needs a pointer to the @p{DoFHandler} to work on). This data can be
+ *   Derived accessor classes may need additional data (e.g. the @ref{DoFAccessor}
+ *   needs a pointer to the @ref{DoFHandler} to work on). This data can be
  *   set upon construction through the last argument of the constructors.
  *   The data type of this additional data is given by the local data type
- *   @p{AccessorData} explained above. The iterator classes take a pointer to
+ *   @ref{AccessorData} explained above. The iterator classes take a pointer to
  *   an object of that data type; by default, this parameter equals the
  *   @p{NULL} pointer.
  *   
@@ -189,7 +189,7 @@ template <int dim> class Triangulation;
  *   past the end; in all other cases, the iterator is considered invalid.
  *   You can check this by calling the @p{state()} function.
  *
- *   An iterator is also invalid, if the pointer pointing to the @p{Triangulation}
+ *   An iterator is also invalid, if the pointer pointing to the @ref{Triangulation}
  *   object is invalid or zero.
  *
  *   Finally, an iterator is invalid, if the element pointed to by
@@ -286,13 +286,13 @@ class TriaRawIterator : public bidirectional_iterator<Accessor,int>
 				      * class of this object. One such path
 				      * would be derived class to base class,
 				      * which for example may be used to get
-				      * a @p{Triangulation::raw_cell_iterator} from
-				      * a @p{DoFHandler::raw_cell_iterator}, since
-				      * the @p{DoFAccessor} class is derived from
-				      * the @p{TriaAccessor} class.
+				      * a @ref{Triangulation}@p{::raw_cell_iterator} from
+				      * a @ref{DoFHandler}@p{::raw_cell_iterator}, since
+				      * the @ref{DoFAccessor} class is derived from
+				      * the @ref{TriaAccessor} class.
 				      *
-				      * Since @p{TriaIterator} and
-				      * @p{TriaActiveIterator} are derived classes
+				      * Since @ref{TriaIterator} and
+				      * @ref{TriaActiveIterator} are derived classes
 				      * of this class, this constructor also
 				      * serves to convert these iterators with
 				      * other accessor classes.
@@ -560,12 +560,12 @@ class TriaIterator : public TriaRawIterator<dim,Accessor> {
 				      * class of this object. One such path
 				      * would be derived class to base class,
 				      * which for example may be used to get
-				      * a @p{Triangulation::cell_iterator} from
-				      * a @p{DoFHandler::cell_iterator}, since
-				      * the @p{DoFAccessor} class is derived from
-				      * the @p{TriaAccessor} class.
+				      * a @ref{Triangulation}@p{::cell_iterator} from
+				      * a @ref{DoFHandler}@p{::cell_iterator}, since
+				      * the @ref{DoFAccessor} class is derived from
+				      * the @ref{TriaAccessor} class.
 				      *
-				      * Since @p{TriaActiveIterator} is a derived
+				      * Since @ref{TriaActiveIterator} is a derived
 				      * class of this class, this constructor
 				      * also serves to convert these iterators 
 				      * with other accessor classes.
@@ -718,10 +718,10 @@ class TriaActiveIterator : public TriaIterator<dim,Accessor> {
 				      * class of this object. One such path
 				      * would be derived class to base class,
 				      * which for example may be used to get
-				      * a @p{Triangulation::active_cell_iterator} from
-				      * a @p{DoFHandler::active_cell_iterator}, since
-				      * the @p{DoFAccessor} class is derived from
-				      * the @p{TriaAccessor} class.
+				      * a @ref{Triangulation}@p{::active_cell_iterator} from
+				      * a @ref{DoFHandler}@p{::active_cell_iterator}, since
+				      * the @ref{DoFAccessor} class is derived from
+				      * the @ref{TriaAccessor} class.
 				      */
     template <typename OtherAccessor>
     TriaActiveIterator (const TriaActiveIterator<dim,OtherAccessor> &i);
diff --git a/deal.II/deal.II/include/grid/tria_levels.h b/deal.II/deal.II/include/grid/tria_levels.h
index 9a51881824..a8dac0f8a4 100644
--- a/deal.II/deal.II/include/grid/tria_levels.h
+++ b/deal.II/deal.II/include/grid/tria_levels.h
@@ -36,7 +36,7 @@ class TriangulationLevel;
 /**
  *  Store all information which belongs to one level of the multilevel hierarchy.
  *
- *  In @p{TriangulationLevel<0>} all data is stored which is not
+ *  In @ref{TriangulationLevel<0>} all data is stored which is not
  *  dependant on the dimension, e.g. a field to store the
  *  refinement flag for the cells (what a cell actually is
  *  is declared elsewhere), etc. Actually, it is only cell-based
@@ -150,7 +150,7 @@ class TriangulationLevel<0>
 				      *  called with the prepro flag @p{DEBUG}
 				      *  set. The function should be called from
 				      *  the functions of the higher
-				      *  @p{TriangulationLevel} classes.
+				      *  @ref{TriangulationLevel} classes.
 				      */
     void monitor_memory (const unsigned int true_dimension) const;
 
@@ -182,7 +182,7 @@ class TriangulationLevel<0>
  *  
  *  In one dimension, this is a list of the lines associated with this level,
  *  as well as a list with the indices of the children of these lines.
- *  The @p{TriangulationsLevel} objects of higher dimensions are derived from
+ *  The @ref{TriangulationsLevel} objects of higher dimensions are derived from
  *  this one.
  *
  *  @author Wolfgang Bangerth, 1998
@@ -223,7 +223,7 @@ class TriangulationLevel<1> : public TriangulationLevel<0>
 					  *  stored in this list. A line is
 					  *  called active if it has no
 					  *  children. The function
-					  *  @p{TriaIterator::active()}
+					  *  @ref{TriaIterator}@p{::active()}
 					  *  tests for this.
 					  */
 	vector<int>  children;
@@ -251,7 +251,7 @@ class TriangulationLevel<1> : public TriangulationLevel<0>
 					  *  already been processed.
 					  *
 					  *  You can clear all used flags using
-					  *  @p{Triangulation<>::clear_user_flags()}.
+					  *  @ref{Triangulation}@p{::clear_user_flags()}.
 					  */
 	vector<bool> user_flags;
 
@@ -306,7 +306,7 @@ class TriangulationLevel<1> : public TriangulationLevel<0>
 				      *  between the number of new quads and
 				      *  the number of new lines, etc.). Also
 				      *  don't forget to call the
-				      *  @p{TriangulationLevel<0>::reserve_space}
+				      *  @ref{TriangulationLevel<0>}@p{::reserve_space}
 				      *  function.
 				      */
     void reserve_space (const unsigned int new_lines);
@@ -317,7 +317,7 @@ class TriangulationLevel<1> : public TriangulationLevel<0>
 				      *  called with the prepro flag @p{DEBUG}
 				      *  set. The function should be called from
 				      *  the functions of the higher
-				      *  @p{TriangulationLevel} classes.
+				      *  @ref{TriangulationLevel} classes.
 				      */
     void monitor_memory (const unsigned int true_dimension) const;
 };
@@ -332,7 +332,7 @@ class TriangulationLevel<1> : public TriangulationLevel<0>
  *  information about the children of these lines and quads.
  *
  *  The vector of lines and their children is derived from
- *  @p{TriangulationLevel<1>}.
+ *  @ref{TriangulationLevel<1>}.
  *
  *  @author Wolfgang Bangerth, 1998
  */
@@ -345,8 +345,8 @@ class TriangulationLevel<2> :  public TriangulationLevel<1>
 				      *  level.
 				      *
 				      *  It is fully analogous to the
-				      *  @p{LinesData} structure inherited from
-				      *  @p{Triangulation<1>}.
+				      *  @ref{TriangulationLevel<1>::LinesData} structure inherited from
+				      *  @ref{Triangulation}@p{<1>}.
 				      */
     struct QuadsData
     {
@@ -355,7 +355,7 @@ class TriangulationLevel<2> :  public TriangulationLevel<1>
 					  */
 	vector<Quad> quads;
 					 /**
-					  *  Same as for the @p{LineData::chilren}
+					  *  Same as for the @ref{TriangulationLevel<1>::LinesData}@p{::chilren}
 					  *  array, but since there are four
 					  *  children, the index points to the
 					  *  first while the other three are
@@ -364,12 +364,12 @@ class TriangulationLevel<2> :  public TriangulationLevel<1>
 	vector<int>  children;
 
 					 /**
-					  *  Same as for @p{LineData::used}.
+					  *  Same as for @ref{TriangulationLevel<1>::LinesData}@p{::used}.
 					  */
 	vector<bool> used;
 
 					 /**
-					  *  Same as for @p{LineData::used}.
+					  *  Same as for @ref{TriangulationLevel<1>::LinesData}@p{::used}.
 					  */
 	vector<bool> user_flags;
 
@@ -424,7 +424,7 @@ class TriangulationLevel<2> :  public TriangulationLevel<1>
 				      *  called with the prepro flag @p{DEBUG}
 				      *  set. The function should be called from
 				      *  the functions of the higher
-				      *  @p{TriangulationLevel} classes.
+				      *  @ref{TriangulationLevel} classes.
 				      */
     void monitor_memory (const unsigned int true_dimension) const;
 };
@@ -439,7 +439,7 @@ class TriangulationLevel<2> :  public TriangulationLevel<1>
  *  information about the children of these lines, quads and hexs.
  *
  *  The vectors of lines and quads and their children are derived from
- *  @p{TriangulationLevel<2>}.
+ *  @ref{TriangulationLevel<2>}.
  *
  *  @author Wolfgang Bangerth, 1998
  */
@@ -452,8 +452,8 @@ class TriangulationLevel<3> :  public TriangulationLevel<2>
 				      *  level.
 				      *
 				      *  It is fully analogous to the
-				      *  @p{LinesData} structure inherited from
-				      *  @p{Triangulation<1>}.
+				      *  @ref{TriangulationLevel<1>::LinesData} structure inherited from
+				      *  @ref{Triangulation<1>}.
 				      */
     struct HexesData
     {
@@ -462,7 +462,7 @@ class TriangulationLevel<3> :  public TriangulationLevel<2>
 					  */
 	vector<Hexahedron> hexes;
 					 /**
-					  *  Same as for the @p{LineData::chilren}
+					  *  Same as for the @ref{TriangulationLevel<1>::LinesData}@p{::chilren}
 					  *  array, but since there are four
 					  *  children, the index points to the
 					  *  first while the other three are
@@ -471,12 +471,12 @@ class TriangulationLevel<3> :  public TriangulationLevel<2>
 	vector<int>  children;
 
 					 /**
-					  *  Same as for @p{LineData::used}.
+					  *  Same as for @ref{TriangulationLevel<1>::LinesData}@p{::used}.
 					  */
 	vector<bool> used;
 
 					 /**
-					  *  Same as for @p{LineData::used}.
+					  *  Same as for @ref{TriangulationLevel<1>::LinesData}@p{::used}.
 					  */
 	vector<bool> user_flags;
 
@@ -531,7 +531,7 @@ class TriangulationLevel<3> :  public TriangulationLevel<2>
 				      *  called with the prepro flag @p{DEBUG}
 				      *  set. The function should be called from
 				      *  the functions of the higher
-				      *  @p{TriangulationLevel} classes.
+				      *  @ref{TriangulationLevel} classes.
 				      */
     void monitor_memory (const unsigned int true_dimension) const;
 };
diff --git a/deal.II/deal.II/include/grid/tria_line.h b/deal.II/deal.II/include/grid/tria_line.h
index d04bbe2808..ba4afc90ce 100644
--- a/deal.II/deal.II/include/grid/tria_line.h
+++ b/deal.II/deal.II/include/grid/tria_line.h
@@ -28,7 +28,8 @@
  *
  *   @author Wolfgang Bangerth, 1998
  */
-class Line {
+class Line
+{
   public:
 				     /**
 				      *  Construct a line with end point
@@ -71,22 +72,27 @@ class Line {
 
 
 inline                               // wahrlich inline hier!
-Line::Line (const int i0, const int i1) {
+Line::Line (const int i0, const int i1)
+{
   end_points[0] = i0;
   end_points[1] = i1;
 };
 
 
+
 inline
-int Line::vertex (const int i) const {
+int Line::vertex (const int i) const
+{
   Assert ((i==0) || (i==1),
 	  ExcRange(i));
   return end_points[i];
 };
 
 
+
 inline
-void Line::set_vertex (const int i, const int index) {
+void Line::set_vertex (const int i, const int index)
+{
   Assert ((i==0) || (i==1),
 	  ExcRange(i));
   end_points[i] = index;
diff --git a/deal.II/deal.II/include/grid/tria_quad.h b/deal.II/deal.II/include/grid/tria_quad.h
index 3a3e7323a6..56820e999d 100644
--- a/deal.II/deal.II/include/grid/tria_quad.h
+++ b/deal.II/deal.II/include/grid/tria_quad.h
@@ -30,7 +30,8 @@
  *
  *   @author Wolfgang Bangerth, 1998
  */
-class Quad {
+class Quad
+{
   public:
 
 				     /**
@@ -75,7 +76,8 @@ class Quad {
 
 
 inline
-Quad::Quad (const int i0, const int i1, const int i2, const int i3) {
+Quad::Quad (const int i0, const int i1, const int i2, const int i3)
+{
   lines[0] = i0;
   lines[1] = i1;
   lines[2] = i2;
@@ -83,16 +85,20 @@ Quad::Quad (const int i0, const int i1, const int i2, const int i3) {
 };
 
 
+
 inline
-int Quad::line (const int i) const {
+int Quad::line (const int i) const
+{
   Assert ((i>=0) && (i<4),
 	  ExcRange(i));
   return lines[i];
 };
 
 
+
 inline
-void Quad::set_line (const int i, const int index) {
+void Quad::set_line (const int i, const int index)
+{
   Assert ((i>=0) && (i<4),
 	  ExcRange(i));
   lines[i] = index;
diff --git a/deal.II/deal.II/include/multigrid/mg_dof_accessor.h b/deal.II/deal.II/include/multigrid/mg_dof_accessor.h
index c09d075ac2..a0d2e3fea0 100644
--- a/deal.II/deal.II/include/multigrid/mg_dof_accessor.h
+++ b/deal.II/deal.II/include/multigrid/mg_dof_accessor.h
@@ -27,10 +27,10 @@ template <int dim> class MGDoFHandler;
  * result in a strange kind of behaviour, though every reasonable
  * operating system should disallow access through that pointer.
  * The reason we do not check for the null pointer in the
- * constructor which gets passed the @p{DoFHandler} pointer is that
+ * constructor which gets passed the @ref{DoFHandler} pointer is that
  * if we did we could not make dof iterators member of other classes
  * (like in the @p{FEValues} class) if we did not know about the
- * @p{DoFHandler} object to be used upon construction of that object.
+ * @ref{DoFHandler} object to be used upon construction of that object.
  * Through the way this class is implemented here, we allow the
  * creation of a kind of virgin object which only gets useful if
  * assigned to from another object before first usage.
@@ -353,7 +353,7 @@ class MGDoFObjectAccessor<2, dim> :  public MGDoFAccessor<dim>,
     				     /**
 				      * Constructor. The @p{local_data}
 				      * argument is assumed to be a pointer
-				      * to a @p{DoFHandler<dim>} object.
+				      * to a @ref{DoFHandler} object.
 				      */
     MGDoFObjectAccessor (Triangulation<dim> *tria,
 		       const int           level,
@@ -478,7 +478,7 @@ class MGDoFObjectAccessor<3, dim> :  public MGDoFAccessor<dim>,
     				     /**
 				      * Constructor. The @p{local_data}
 				      * argument is assumed to be a pointer
-				      * to a @p{DoFHandler<dim>} object.
+				      * to a @ref{DoFHandler} object.
 				      */
     MGDoFObjectAccessor (Triangulation<dim> *tria,
 		      const int           level,
diff --git a/deal.II/deal.II/include/multigrid/mg_dof_handler.h b/deal.II/deal.II/include/multigrid/mg_dof_handler.h
index 4a6abcc1c6..f8ec5145e9 100644
--- a/deal.II/deal.II/include/multigrid/mg_dof_handler.h
+++ b/deal.II/deal.II/include/multigrid/mg_dof_handler.h
@@ -173,7 +173,7 @@ class MGDoFHandler : public DoFHandler<dim>
 				      * distribute the degrees of freedoms
 				      * needed for the given finite element
 				      * according to the given distribution
-				      * method. We first call the @p{DoFHandler}'s
+				      * method. We first call the @ref{DoFHandler}'s
 				      * function and then distribute the
 				      * levelwise numbers.
 				      *
@@ -927,7 +927,7 @@ class MGDoFHandler : public DoFHandler<dim>
     				     /**
 				      * Space to store the DoF numbers for the
 				      * different levels. Unlike the @p{levels}
-				      * object in the @p{DoFHandler}, these are
+				      * object in the @ref{DoFHandler}, these are
 				      * not global numbers but rather are
 				      * numbers which start from zero on each
 				      * level.
diff --git a/deal.II/deal.II/include/multigrid/mg_dof_tools.h b/deal.II/deal.II/include/multigrid/mg_dof_tools.h
index 37e7a0105c..533d669bf8 100644
--- a/deal.II/deal.II/include/multigrid/mg_dof_tools.h
+++ b/deal.II/deal.II/include/multigrid/mg_dof_tools.h
@@ -20,7 +20,7 @@
  * This is a collection of functions operating on, and manipulating
  * the numbers of degrees of freedom in a multilevel triangulation. It
  * is similar in purpose and function to the @p{DoFTools} class, but
- * operates on @p{MGDoFHandler} objects instead of @p{DoFHandler}
+ * operates on @p{MGDoFHandler} objects instead of @ref{DoFHandler}
  * objects. See there and the documentation of the member functions
  * for more information.
  *
diff --git a/deal.II/deal.II/include/numerics/data_io.h b/deal.II/deal.II/include/numerics/data_io.h
index 93db1b6f2a..b96140fe24 100644
--- a/deal.II/deal.II/include/numerics/data_io.h
+++ b/deal.II/deal.II/include/numerics/data_io.h
@@ -33,7 +33,7 @@ class EpsOutputData;
  * Encapsulated Postscript supports Q1-Elements only.
  *
  * It allows the user to attach a degree of freedom handler object
- * (@p{DoFHandler}) which also gives access to the geometry data of the
+ * (@ref{DoFHandler}) which also gives access to the geometry data of the
  * underlying triangulation and to add data vectors of which the values
  * are to be written.
  *
diff --git a/deal.II/deal.II/include/numerics/data_out.h b/deal.II/deal.II/include/numerics/data_out.h
index 8c3e462290..9934b77827 100644
--- a/deal.II/deal.II/include/numerics/data_out.h
+++ b/deal.II/deal.II/include/numerics/data_out.h
@@ -23,7 +23,7 @@ template <int dim> class DoFHandler;
 /**
  * This is an abstract class which provides the functionality to generate
  * patches for output by base classes from data vectors on a grid. It alloes
- * to store a pointer to a @p{DoFHandler} object and one or more pointers to
+ * to store a pointer to a @ref{DoFHandler} object and one or more pointers to
  * node and cell data denoting functions on the grid which shall later
  * be written in any of the implemented data formats.
  *
@@ -31,7 +31,7 @@ template <int dim> class DoFHandler;
  * @sect3{User visible interface}
  *
  * The user visible interface of this class consists of functions which allow
- * a user to make a @p{DoFHandler} object known to this class and to add data
+ * a user to make a @ref{DoFHandler} object known to this class and to add data
  * vectors which will later be written to a file in some format. Instead of
  * pondering about the different functions, an example is probably the best
  * way:
@@ -61,7 +61,7 @@ template <int dim> class DoFHandler;
  * @end{verbatim}
  *
  * @p{attach_dof_handler} tells this class that all future operations are to take
- * place with the @p{DoFHandler} object and the triangulation it lives on. We then
+ * place with the @ref{DoFHandler} object and the triangulation it lives on. We then
  * add the solution vector and the error estimator; note that they have different
  * dimensions, because the solution is a nodal vector, here consisting of two
  * components ("x-displacement" and "y-displacement") while the error estimator
@@ -69,7 +69,7 @@ template <int dim> class DoFHandler;
  * to give a name to each component of the vector, which is done through an object
  * of type @p{vector<string>} as second argument; if only one component is in the
  * vector, for example if we are adding cell data as in the second case, or if
- * the finite element used by the @p{DoFHandler} has only one component, then you
+ * the finite element used by the @ref{DoFHandler} has only one component, then you
  * can use the second @p{add_data_vector} function which takes a @p{string} instead
  * of the @p{vector<string>}.
  *
@@ -87,12 +87,12 @@ template <int dim> class DoFHandler;
  * to a file and may want to clear this object as soon as possible to reduce
  * memory requirements.
  *
- * Please note, that in the example above, an object of type @p{DataOut} was
+ * Please note, that in the example above, an object of type @ref{DataOut} was
  * used, i.e. an object of a derived class. This is necessary since this
  * class does not provide means to actually generate the patches, only aids to
  * store and access data.
  *
- * Note that the base class of this class, @p{DataOutInterface} offers several
+ * Note that the base class of this class, @ref{DataOutInterface} offers several
  * functions to ease programming with run-time determinable output formats
  * (i.e. you need not use a fixed format by calling @p{write_xxx} in the above
  * example, but you can select it by a run-time parameter without having
@@ -227,7 +227,7 @@ class DataOut_DoFData : public DataOutInterface<dim>
 				      * output of a new set of vectors
 				      * without supplying the DoF
 				      * handler again. Therefore, the
-				      * @p{DataOut} object can be used
+				      * @ref{DataOut} object can be used
 				      * in an algebraic context. Note
 				      * that besides the data vectors
 				      * also the patches already
@@ -386,7 +386,7 @@ class DataOut_DoFData : public DataOutInterface<dim>
 
 /**
  * This class is an actual implementation of the functionality proposed by
- * the @p{DataOut_DoFData} class. It offers a function @p{build_patches} that
+ * the @ref{DataOut_DoFData} class. It offers a function @p{build_patches} that
  * generates the patches to be written in some graphics format from the data
  * stored in the base class. Most of the interface and an example of its
  * use is described in the documentation of the base class.
@@ -409,13 +409,13 @@ class DataOut_DoFData : public DataOutInterface<dim>
  *
  * @sect3{User interface information}
  *
- * The base classes of this class, @p{DataOutBase}, @p{DataOutInterface} and
- * @p{DataOut_DoFData} offer several interfaces of their own. Refer to the
- * @p{DataOutBase} class's documentation for a discussion of the different
- * output formats presently supported, @p{DataOutInterface} for ways of
+ * The base classes of this class, @ref{DataOutBase}, @ref{DataOutInterface} and
+ * @ref{DataOut_DoFData} offer several interfaces of their own. Refer to the
+ * @ref{DataOutBase} class's documentation for a discussion of the different
+ * output formats presently supported, @ref{DataOutInterface} for ways of
  * selecting which format to use upon output at run-time and without
  * the need to adapt your program when new formats become available, as
- * well as for flags to determine aspects of output. The @p{DataOut_DoFData}
+ * well as for flags to determine aspects of output. The @ref{DataOut_DoFData}
  * class's documentation has an example of using nodal data to generate
  * output.
  *
diff --git a/deal.II/deal.II/include/numerics/data_out_stack.h b/deal.II/deal.II/include/numerics/data_out_stack.h
index d438ae5516..b76d66bd99 100644
--- a/deal.II/deal.II/include/numerics/data_out_stack.h
+++ b/deal.II/deal.II/include/numerics/data_out_stack.h
@@ -30,7 +30,7 @@ template <int dim> class DoFHandler;
  * space-time output file, or for example to connect the results of
  * solutions of a parameter dependent equation for several parameter
  * value together into one. The interface is mostly modelled after the
- * @p{DataOut} class.
+ * @ref{DataOut} class.
  *
  * We will explain the concept for a time dependent problem, but
  * instead of the time any parameter can be substituted. In our
@@ -58,7 +58,7 @@ template <int dim> class DoFHandler;
  * is named @p{solution} and that a vector @p{error} is computed which
  * contains an error indicator for each spatial cell.
  *
- * Note that unlike for the @p{DataOut} class it is necessary to first
+ * Note that unlike for the @ref{DataOut} class it is necessary to first
  * declare data vectors and the names of the components before first
  * use. This is because on all time levels the same data should be
  * present to produce reasonable time-space output. The output is
@@ -148,7 +148,7 @@ class DataOutStack : public DataOutInterface<dim+1>
 				      *
 				      * This version may be called if the
 				      * finite element presently used by the
-				      * @p{DoFHandler} (and previously attached
+				      * @ref{DoFHandler} (and previously attached
 				      * to this object) has only one component
 				      * and therefore only one name needs to
 				      * be given.
@@ -164,7 +164,7 @@ class DataOutStack : public DataOutInterface<dim+1>
 				      *
 				      * This version must be called if the
 				      * finite element presently used by the
-				      * @p{DoFHandler} (and previously attached
+				      * @ref{DoFHandler} (and previously attached
 				      * to this object) has more than one
 				      * component and therefore more than one
 				      * name needs to be given. However, you
@@ -183,7 +183,7 @@ class DataOutStack : public DataOutInterface<dim+1>
 				      *
 				      * This version may be called if the
 				      * finite element presently used by the
-				      * @p{DoFHandler} (and previously attached
+				      * @ref{DoFHandler} (and previously attached
 				      * to this object) has only one component
 				      * and therefore only one name needs to
 				      * be given.
@@ -211,7 +211,7 @@ class DataOutStack : public DataOutInterface<dim+1>
 				      *
 				      * This version must be called if the
 				      * finite element presently used by the
-				      * @p{DoFHandler} (and previously attached
+				      * @ref{DoFHandler} (and previously attached
 				      * to this object) has more than one
 				      * component and therefore more than one
 				      * name needs to be given. However, you
@@ -241,7 +241,7 @@ class DataOutStack : public DataOutInterface<dim+1>
 				      * Actually build the patches for output
 				      * by the base classes from the data
 				      * stored in the data vectors and using
-				      * the previously attached @p{DoFHandler}
+				      * the previously attached @ref{DoFHandler}
 				      * object.
 				      *
 				      * By @p{n_subdivisions} you can decide
@@ -390,8 +390,8 @@ class DataOutStack : public DataOutInterface<dim+1>
 				      * This is the function through
 				      * which derived classes propagate
 				      * preprocessed data in the form of
-				      * @p{Patch} structures (declared in
-				      * the base class @p{DataOutBase}) to
+				      * @ref{Patch} structures (declared in
+				      * the base class @ref{DataOutBase}) to
 				      * the actual output function.
 				      */
     virtual const vector<DataOutBase::Patch<dim+1> > & get_patches () const;
diff --git a/deal.II/deal.II/include/numerics/derivative_approximation.h b/deal.II/deal.II/include/numerics/derivative_approximation.h
index bdff13656b..6cb21363bd 100644
--- a/deal.II/deal.II/include/numerics/derivative_approximation.h
+++ b/deal.II/deal.II/include/numerics/derivative_approximation.h
@@ -75,7 +75,7 @@
  * the values of the finite element field at the centers of the cells
  * are taken. It might therefore only be useful to use this class for
  * discontinuous, piecewise constant elements (i.e. using the
- * @p{FEDG_Q0} class), since all other finite elements can approximate
+ * @ref{FEDG_Q0} class), since all other finite elements can approximate
  * gradients themselves.
  *
  *
@@ -256,7 +256,7 @@ class DerivativeApproximation
 	typedef double        ProjectedDerivative;
 
 					 /**
-					  * Given an @p{FEValues} object
+					  * Given an @ref{FEValues} object
 					  * initialized to a cell, and a
 					  * solution vector, extract the
 					  * desired derivative at the
@@ -335,7 +335,7 @@ class DerivativeApproximation
 	typedef Tensor<1,dim> ProjectedDerivative;
 
 					 /**
-					  * Given an @p{FEValues} object
+					  * Given an @ref{FEValues} object
 					  * initialized to a cell, and a
 					  * solution vector, extract the
 					  * desired derivative at the
diff --git a/deal.II/deal.II/include/numerics/dof_print_solver_step.h b/deal.II/deal.II/include/numerics/dof_print_solver_step.h
index 8016801e2e..2797893b6b 100644
--- a/deal.II/deal.II/include/numerics/dof_print_solver_step.h
+++ b/deal.II/deal.II/include/numerics/dof_print_solver_step.h
@@ -20,11 +20,13 @@
 #include <iomanip>
 #include <fstream>
 
+
+
 /**
  * Print intermediate solutions in solvers.
  * This is derived from a solver class provided as template argument.
  * It implements the @p{print_vector} function of the solver using a
- * @ref DoFHandler. This way, the intermediate vectors can be viewed as
+ * @ref{DoFHandler}. This way, the intermediate vectors can be viewed as
  * finite element functions.
  *
  * This class may produce enormous amounts of data!
diff --git a/deal.II/deal.II/include/numerics/dof_renumbering.h b/deal.II/deal.II/include/numerics/dof_renumbering.h
index ec0cb6f14c..c9810428ba 100644
--- a/deal.II/deal.II/include/numerics/dof_renumbering.h
+++ b/deal.II/deal.II/include/numerics/dof_renumbering.h
@@ -74,11 +74,11 @@
  *
  * The renumbering algorithms need quite a lot of memory, since they have
  * to store for each dof with which other dofs it couples. This is done
- * using a @p{SparsityPattern} object used to store the sparsity pattern of
+ * using a @ref{SparsityPattern} object used to store the sparsity pattern of
  * matrices. It
  * is not useful for the user to do anything between distributing the dofs
- * and renumbering, i.e. the calls to @p{DoFHandler::distribute_dofs} and
- * @p{DoFHandler::renumber_dofs} should follow each other immediately. If
+ * and renumbering, i.e. the calls to @ref{DoFHandler}@p{::distribute_dofs} and
+ * @ref{DoFHandler}@p{::renumber_dofs} should follow each other immediately. If
  * you try to create a sparsity pattern or anything else in between, these
  * will be invalid afterwards.
  *
@@ -141,7 +141,7 @@
  *
  * @sect2{Component-wise numbering}
  *
- * For finite elements composed of several base elements using the @p{FESystem}
+ * For finite elements composed of several base elements using the @ref{FESystem}
  * class, or for elements which provide several components themselves, it
  * may be of interest to sort the DoF indices by component. This will then
  * bring out the block matrix structure, since otherwise the degrees of freedom
diff --git a/deal.II/deal.II/include/numerics/error_estimator.h b/deal.II/deal.II/include/numerics/error_estimator.h
index f391330082..b88fc3ed46 100644
--- a/deal.II/deal.II/include/numerics/error_estimator.h
+++ b/deal.II/deal.II/include/numerics/error_estimator.h
@@ -46,7 +46,7 @@ template <int dim> class FESubfaceValues;
  *  the conormal derivative $a\frac{du}{dn} = g$.
  *
  *  The error estimator returns a vector of estimated errors per cell which
- *  can be used to feed the @p{Triangulation<dim>::refine_*} functions. This
+ *  can be used to feed the @ref{Triangulation}@p{<dim>::refine_*} functions. This
  *  vector contains elements of data type @p{float}, rather than @p{double},
  *  since accuracy is not so important here, and since this can save rather
  *  a lot of memory, when using many cells.
@@ -66,8 +66,8 @@ template <int dim> class FESubfaceValues;
  *  is considered, but may lead to wrong results. You may scale the vector
  *  appropriately afterwards.
  *
- *  To perform the integration, use is made of the @p{FEFaceValues} and
- *  @p{FESubfaceValues} classes. The integration is performed by looping
+ *  To perform the integration, use is made of the @ref{FEFaceValues} and
+ *  @ref{FESubfaceValues} classes. The integration is performed by looping
  *  over all cells and integrating over faces that are not yet treated.
  *  This way we avoid integration on faces twice, once for each time we
  *  visit one of the adjacent cells. In a second loop over all cells, we
@@ -75,8 +75,8 @@ template <int dim> class FESubfaceValues;
  *  square of the jumps) of each cell and take the square root.
  *
  *  The integration is done using a quadrature formula on the face.
- *  For linear trial functions (@p{FELinear}), the @p{Gauss2} or even the
- *  @p{Midpoint} rule will suffice. For higher order elements, it is
+ *  For linear trial functions (@ref{FEQ1}), the @ref{QGauss2} or even the
+ *  @ref{QMidpoint} rule will suffice. For higher order elements, it is
  *  necessary to utilize higher order quadrature formulae as well.
  *
  *  We store the contribution of each face in a @p{map}, as provided by the
@@ -158,7 +158,7 @@ template <int dim> class FESubfaceValues;
  *  
  *  The integration along faces with hanging nodes is quite tricky, since one
  *  of the elements has to be shifted one level up or down. See the
- *  documentation for the @p{FESubfaceValues} class for more information about
+ *  documentation for the @ref{FESubFaceValues} class for more information about
  *  technical issues regarding this topic.
  *
  *  In praxi, since we integrate over each face only once, we do this when we
@@ -220,7 +220,7 @@ class KellyErrorEstimator
 				      * components you want to
 				      * evaluate, in case the finite
 				      * element used by the
-				      * @p{DoFHandler} object is
+				      * @ref{DoFHandler} object is
 				      * vector-valued. You then have
 				      * to set those entries to true
 				      * in the bit-vector
diff --git a/deal.II/deal.II/include/numerics/matrices.h b/deal.II/deal.II/include/numerics/matrices.h
index 28d12b55bf..1ff5eedb3e 100644
--- a/deal.II/deal.II/include/numerics/matrices.h
+++ b/deal.II/deal.II/include/numerics/matrices.h
@@ -42,9 +42,9 @@ template <int dim> class Equation;
  *
  * All functions take a sparse matrix object to hold the matrix to be
  * created. The functions assume that the matrix is initialized with a
- * sparsity pattern (@p{SparsityPattern}) corresponding to the given degree
+ * sparsity pattern (@ref{SparsityPattern}) corresponding to the given degree
  * of freedom handler, i.e. the sparsity structure is already as needed.
- * You can do this by calling the @p{DoFHandler<dim>::make_sparsity_pattern}
+ * You can do this by calling the @ref{DoFHandler}@p{<dim>::make_sparsity_pattern}
  * function.
  *
  * Furthermore it is assumed that no relevant data is in the matrix. All
@@ -61,14 +61,14 @@ template <int dim> class Equation;
  * @item @p{create_mass_matrix}: create the matrix with entries
  *   $m_{ij} = \int_\Omega \phi_i(x) \phi_j(x) dx$. Here, the $\phi_i$
  *   are the basis functions of the finite element space given.
- *   This function uses the @p{MassMatrix} class.
+ *   This function uses the @ref{MassMatrix} class.
  *
  *   Two ways to create this matrix are offered. The first one uses
- *   numerical quadrature and the @p{MassMatrix} class. In this case,
+ *   numerical quadrature and the @ref{MassMatrix} class. In this case,
  *   a coefficient may be given to evaluate
  *   $m_{ij} = \int_\Omega a(x) \phi_i(x) \phi_j(x) dx$ instead.
  *   This way of setting up the mass matrix is quite general, but has
- *   some drawbacks, see the documentation of the @p{MassMatrix} class.
+ *   some drawbacks, see the documentation of the @ref{MassMatrix} class.
  *
  *   The other way uses exact integration, as offered by the finite
  *   element class used. This way you can avoid quadrature errors and
@@ -80,26 +80,26 @@ template <int dim> class Equation;
  *   composed of several subelements. In this case, using the
  *   quadrature free way (without coefficient) results in a matrix
  *   which does not couple the subelements, as described in the
- *   @p{FESystem::get_local_mass_matrix} documentation, while the
+ *   @ref{FESystem}@p{::get_local_mass_matrix} documentation, while the
  *   way using quadrature sets up the full matrix, i.e. with the
  *   cross coupling of shape functions belonging to different subelements.
  *
  *   If the finite element for which the mass matrix is to be built
  *   has more than one component, the resulting matrix will not couple
  *   the different components. It will furthermore accept a single
- *   coefficient through the @p{Function} parameter for all
+ *   coefficient through the @ref{Function} parameter for all
  *   components. If you want different coefficients for the different
  *   parameters, you need to pass a function object representing the
  *   respective number of components.
  *
  * @item @p{create_laplace_matrix}: there are two versions of this; the
- *   one which takes the @p{Function<dim>} object creates
+ *   one which takes the @ref{Function} object creates
  *   $a_{ij} = \int_\Omega a(x) \nabla\phi_i(x) \nabla\phi_j(x) dx$,
  *   $a$ being the given function, while the other one assumes that
  *   $a=1$ which enables some optimizations. In fact the two versions
  *   are in one function, the coefficient being given as a defaulted
  *   argument, which is a pointer to a function and defaults to zero.
- *   This function uses the @p{LaplaceMatrix} class.
+ *   This function uses the @ref{LaplaceMatrix} class.
  *
  *   If the finite element in use presently has more than only one
  *   component, this function may not be overly useful and presently
@@ -111,7 +111,7 @@ template <int dim> class Equation;
  * several matrices and could then condense afterwards only once,
  * instead of for every matrix. To actually do computations with these
  * matrices, you have to condense the matrix using the
- * @p{ConstraintMatrix::condense} function; you also have to condense the
+ * @ref{ConstraintMatrix}@p{::condense} function; you also have to condense the
  * right hand side accordingly and distribute the solution afterwards.
  *
  * In all cases, the elements of the matrix to be assembled are simply
@@ -145,7 +145,7 @@ template <int dim> class Equation;
  * This function needs to get passed a matrix object to hold the resulting sparse
  * matrix. This object is supposed to be initialized with a suitable sparsity
  * pattern, which can be created using the
- * @p{DoFHandler<>::make_boundary_sparsity_pattern} function.
+ * @ref{DoFHandler}@p{::make_boundary_sparsity_pattern} function.
  *
  * The object describing the exact form of the boundary is obtained from the
  * triangulation object.
@@ -159,7 +159,7 @@ template <int dim> class Equation;
  * building the right hand side vector. (The @p{create_mass_matrix} function
  * which does not use quadrature does not offer a version to evaluate a right
  * hand side also, since this needs quadrature anyway. Take look at the
- * @p{VectorTools} class to find a function to set up a right hand side vector
+ * @ref{VectorTools} class to find a function to set up a right hand side vector
  * only.)
  *
  * Creation of the right hand side
@@ -175,7 +175,7 @@ template <int dim> class Equation;
  *
  *
  * All functions in this collection use the finite elemen given to the
- * @p{DoFHandler} object the last time that the degrees of freedom were
+ * @ref{DoFHandler} object the last time that the degrees of freedom were
  * distributed on the triangulation.
  *
  * @author Wolfgang Bangerth, 1998
@@ -274,7 +274,7 @@ class MatrixCreator
 				      *
 				      * The matrix is assumed to already be
 				      * initialized with a suiting sparsity
-				      * pattern (the @p{DoFHandler} provides an
+				      * pattern (the @ref{DoFHandler} provides an
 				      * appropriate function).
 				      *
 				      * See the general doc of this class
@@ -348,7 +348,7 @@ class MatrixCreator
  * into a system of equations.  To actually do this you have to specify
  * a list of degree of freedom indices along with the values these degrees of
  * freedom shall assume. To see how to get such a list, see the discussion
- * of the @p{VectorTools::interpolate_boundary_values} function.
+ * of the @ref{VectorTools}@p{::interpolate_boundary_values} function.
  *
  * The inclusion into the assemblage process is as follows: when the matrix and
  * vectors are set up, a list of nodes subject to dirichlet bc is made and
@@ -484,7 +484,7 @@ class MatrixTools : public MatrixCreator<dim>
 
 
 /**
- * Equation class to be passed to the @p{Assembler} if you want to make up the
+ * Equation class to be passed to the @ref{Assembler} if you want to make up the
  * mass matrix for your problem. The mass matrix is the matrix with
  * $m_{ij} = \int_\Omega \phi_i(x) \phi_j(x) dx$.
  *
@@ -510,7 +510,7 @@ class MatrixTools : public MatrixCreator<dim>
  * You will usually want to use this object only if you have coefficients
  * which vary over each cell. If you have coefficients which are constant
  * on each cell or even on the whole domain, you can get the local mass
- * matrix easier by calling the @p{FiniteElement::get_local_mass_matrix} and
+ * matrix easier by calling the @ref{FiniteElement}@p{::get_local_mass_matrix} and
  * then scaling this one on each cell. This has the additional benefit that
  * the mass matrix is evaluated exactly, i.e. not using a quadrature formula
  * and is normally much faster since it can be precomputed and needs only
@@ -519,7 +519,7 @@ class MatrixTools : public MatrixCreator<dim>
  * The useful use of this object is therefore probable one of the following
  * cases:
  * @begin{itemize}
- * @item Mass lumping: use an @p{Assembler} object and a special quadrature
+ * @item Mass lumping: use an @ref{Assembler} object and a special quadrature
  *   formula to voluntarily evaluate the mass matrix incorrect. For example
  *   by using the trapezoidal formula, the mass matrix will become a
  *   diagonal (at least if no hanging nodes are considered). However, there
@@ -545,7 +545,7 @@ class MatrixTools : public MatrixCreator<dim>
  *    occurs in the discretization of the heat and the wave equation, amoung
  *    others), once could conceive an equation object in which the @p{assemble}
  *    functions do nothing but sum up the contributions delivered by the
- *    @p{assemble} functions of the @p{MassMatrix} and @p{LaplaceMatrix} classes.
+ *    @p{assemble} functions of the @ref{MassMatrix} and @ref{LaplaceMatrix} classes.
  *    Since numerical quadrature is necessary here anyway, this way is
  *    justifyable to quickly try something out. In the further process it
  *    may be useful to replace this behaviour by more sophisticated methods,
@@ -636,7 +636,7 @@ class MassMatrix :  public Equation<dim> {
 
 
 /**
- * Equation class to be passed to the @p{Assembler} if you want to make up the
+ * Equation class to be passed to the @ref{Assembler} if you want to make up the
  * laplace matrix for your problem. The laplace matrix is the matrix with
  * $a_{ij} = \int_\Omega \nabla\phi_i(x) \cdot \nabla\phi_j(x) dx$.
  *
diff --git a/deal.II/deal.II/include/numerics/solution_transfer.h b/deal.II/deal.II/include/numerics/solution_transfer.h
index d9067d437b..4aa3240009 100644
--- a/deal.II/deal.II/include/numerics/solution_transfer.h
+++ b/deal.II/deal.II/include/numerics/solution_transfer.h
@@ -93,7 +93,7 @@
  * solution vector on the current (original) grid.
  * Each entry of this vector belongs to one of the
  * DoFs of the discretisation. If we now refine the grid then the calling of
- * @p{DoFHandler::distribute_dofs(...)} will change at least some of the
+ * @ref{DoFHandler}@p{::distribute_dofs(...)} will change at least some of the
  * DoF indices. Hence we need to store the DoF indices of all active cells
  * before the refinement. The @p{user_pointer} of each active cell
  * is used to point to the vector of these DoF indices of that cell, all other
@@ -111,11 +111,11 @@
  * arbitrary many discrete functions (solution vectors) on the original grid. 
  *
  * @item Solution transfer while coarsening and refinement. After 
- * calling @p{Triangulation::prepare_coarsening_and_refinement} the
+ * calling @ref{Triangulation}@p{::prepare_coarsening_and_refinement} the
  * coarsen flags of either all or none of the children of a 
  * (father-)cell are set. While coarsening 
- * (@p{Triangulation::execute_coarsening_and_refinement})
- * the cells that are not needed any more will be deleted from the @p{Triangulation}.
+ * (@ref{Triangulation}@p{::execute_coarsening_and_refinement})
+ * the cells that are not needed any more will be deleted from the @ref{Triangulation}.
  * 
  * For the interpolation from the (to be coarsenend) children to their father
  * the children cells are needed. Hence this interpolation
@@ -163,7 +163,7 @@ class SolutionTransfer
   public:
     
 				     /**
-				      * Constructor, takes the current @p{DoFHandler}
+				      * Constructor, takes the current @ref{DoFHandler}
 				      * as argument.
 				      */
     SolutionTransfer(const DoFHandler<dim> &dof);
@@ -254,11 +254,11 @@ class SolutionTransfer
 				      *
 				      * Calling this function is
 				      * allowed only if first
-				      * @p{Triangulation::prepare_coarsening_and_refinement},
+				      * @ref{Triangulation}@p{::prepare_coarsening_and_refinement},
 				      * second
 				      * @p{SolutionTransfer::prepare_for_coarsening_and_refinement},
 				      * an then third
-				      * @p{Triangulation::execute_coarsening_and_refinement}
+				      * @ref{Triangulation}@p{::execute_coarsening_and_refinement}
 				      * are called before. Multiple
 				      * calling of this function is
 				      * NOT allowed. Interpolating
diff --git a/deal.II/deal.II/include/numerics/time_dependent.h b/deal.II/deal.II/include/numerics/time_dependent.h
index 9cc5e757dc..c04a07d827 100644
--- a/deal.II/deal.II/include/numerics/time_dependent.h
+++ b/deal.II/deal.II/include/numerics/time_dependent.h
@@ -210,8 +210,8 @@
  *       timestep_manager.run_sweep (sweep);
  *   };
  * @end{verbatim}
- * Here, @p{timestep_manager} is an object of type @p{TimeDependent_Wave}, which
- * is a class derived from @p{TimeDependent}. @p{start_sweep}, 
+ * Here, @p{timestep_manager} is an object of type @ref{TimeDependent_Wave}, which
+ * is a class derived from @ref{TimeDependent}. @p{start_sweep}, 
  * @p{solve_primal_problem}, @p{solve_dual_problem}, @p{postprocess} and @p{end_sweep}
  * are functions inherited from this class. They all do a loop over all 
  * timesteps within this object and call the respective function on each of
@@ -253,7 +253,7 @@
  * invoked (@p{solve_primal_problem}, @p{solve_dual_problem}, @p{postprocess},
  * @p{refine_grids} and @p{write_statistics} all have this form, where the
  * latter two give functions of the derived timestep class, rather than
- * from the base class). The function @p{TimeStepBase::init_for_primal_problem}
+ * from the base class). The function @ref{TimeStepBase}@p{::init_for_primal_problem}
  * and the respective ones for the other operations defined by that class
  * are only used to store the type of operation which the loop presently
  * performed will do.
@@ -281,7 +281,7 @@
  *            TimeDependent::TimeSteppingData (0,1),
  *            TimeDependent::forward);
  * @end{verbatim}
- * @p{TimeStepBase_Wave<dim>::refine_grid} is a function taking an argument, unlike
+ * @ref{TimeStepBase_Wave}@p{::refine_grid} is a function taking an argument, unlike
  * all the other functions used above within the loops. However, in this special
  * case the parameter was the same for all timesteps and known before the loop
  * was started, so we fixed it and made a function object which to the outside
@@ -455,7 +455,7 @@ class TimeDependent
 				      *
 				      * Note that by giving an object
 				      * to this function, the
-				      * @p{TimeDependent} object assumes
+				      * @ref{TimeDependent} object assumes
 				      * ownership of the object; it will
 				      * therefore also take care of
 				      * deletion of the objects its manages.
@@ -522,7 +522,7 @@ class TimeDependent
 				      * Solve the primal problem; uses the
 				      * functions @p{init_for_primal_problem}
 				      * and @p{solve_primal_problem} of the
-				      * @p{TimeStepBase} class through the
+				      * @ref{TimeStepBase} class through the
 				      * @p{do_loop} function of this class.
 				      *
 				      * Look ahead and look back are
@@ -535,7 +535,7 @@ class TimeDependent
 				      * Solve the dual problem; uses the
 				      * functions @p{init_for_dual_problem}
 				      * and @p{solve_dual_problem} of the
-				      * @p{TimeStepBase} class through the
+				      * @ref{TimeStepBase} class through the
 				      * @p{do_loop} function of this class.
 				      *
 				      * Look ahead and look back are
@@ -548,7 +548,7 @@ class TimeDependent
 				      * Do a postprocessing round; uses the
 				      * functions @p{init_for_postprocessing}
 				      * and @p{postprocess} of the
-				      * @p{TimeStepBase} class through the
+				      * @ref{TimeStepBase} class through the
 				      * @p{do_loop} function of this class.
 				      *
 				      * Look ahead and look back are
@@ -575,16 +575,16 @@ class TimeDependent
 				      *
 				      * Note also, that the given class from which
 				      * the two functions are taken needs not
-				      * necessarily be @p{TimeStepBase}, but it
+				      * necessarily be @ref{TimeStepBase}, but it
 				      * could also be a derived class, that is
-				      * @p{static_cast}able from a @p{TimeStepBase}.
+				      * @p{static_cast}able from a @ref{TimeStepBase}.
 				      * The function may be a virtual function
 				      * (even a pure one) of that class, which
 				      * should help if the actual class where it
 				      * is implemented is one which is derived
 				      * through virtual base classes and thus
 				      * unreachable by @p{static_cast} from the
-				      * @p{TimeStepBase} class.
+				      * @ref{TimeStepBase} class.
 				      *
 				      * Instead of using the above form, you can
 				      * equally well use
@@ -1102,8 +1102,9 @@ class TimeStepBase : public Subscriptor
 };
 
 
+
 /**
- * Specialisation of @p{TimeStepBase} which addresses some aspects of grid handling.
+ * Specialisation of @ref{TimeStepBase} which addresses some aspects of grid handling.
  * In particular, this class is thought to make handling of grids available that
  * are adaptively refined on each time step separately or with a loose coupling
  * between time steps. It also takes care of deleting and rebuilding grids when
@@ -1381,8 +1382,9 @@ class TimeStepBase_Tria :  public TimeStepBase
 };
 
 
+
 /**
- * This structure is used to tell the @p{TimeStepBase_Tria} class how grids should
+ * This structure is used to tell the @ref{TimeStepBase_Tria} class how grids should
  * be handled. It has flags defining the moments where grids shall be
  * re-made and when they may be deleted. Also, one variable states whether
  * grids should be kept in memory or should be deleted between to uses to
@@ -1456,8 +1458,9 @@ struct TimeStepBase_Tria<dim>::Flags
 };
 
 
+
 /**
- * This structure is used to tell the @p{TimeStepBase_Tria} class how grids should
+ * This structure is used to tell the @ref{TimeStepBase_Tria} class how grids should
  * be refined. Before we explain all the different variables, fist some terminology:
  * @begin{itemize}
  * @item Correction: after having flagged some cells of the triangulation for
@@ -1709,6 +1712,7 @@ struct TimeStepBase_Tria<dim>::RefinementFlags
 };
 
 
+
 /**
  * Structure given to the actual refinement function, telling it which
  * thresholds to take for coarsening and refinement. The actual refinement
diff --git a/deal.II/deal.II/include/numerics/vectors.h b/deal.II/deal.II/include/numerics/vectors.h
index 3f51c7e1fb..718489b4cd 100644
--- a/deal.II/deal.II/include/numerics/vectors.h
+++ b/deal.II/deal.II/include/numerics/vectors.h
@@ -95,11 +95,11 @@ enum NormType {
  *   given function onto the finite element space restricted to the boundary
  *   of the domain, then taking this information and using it to eliminate
  *   the boundary nodes from the mass matrix of the whole domain, using the
- *   @p{MatrixTools::apply_boundary_values} function. The projection of the
+ *   @ref{MatrixTools}@p{::apply_boundary_values} function. The projection of the
  *   trace of the function to the boundary is done with the
- *   @p{VectorTools::project_boundary_values} (see below) function, which is
+ *   @ref{VectorTools}@p{::project_boundary_values} (see below) function, which is
  *   called with a map of boundary functions in which all boundary indicators
- *   from zero to 254 (255 is used for other purposes, see the @p{Triangulation}
+ *   from zero to 254 (255 is used for other purposes, see the @ref{Triangulation}
  *   class documentation) point to the function to be projected. The projection
  *   to the boundary takes place using a second quadrature formula on the
  *   boundary given to the @p{project} function. The first quadrature formula is
@@ -145,11 +145,11 @@ enum NormType {
  * @item Creation of right hand side vectors:
  *   The @p{create_right_hand_side} function computes the vector
  *   $f_i = \int_\Omega f(x) \phi_i(x) dx$. This is the same as what the
- *   @p{MatrixCreator::create_*} functions which take a right hand side do,
+ *   @ref{MatrixCreator}@p{::create_*} functions which take a right hand side do,
  *   but without assembling a matrix.
  *
  * @item Interpolation of boundary values:
- *   The @p{MatrixTools::apply_boundary_values} function takes a list
+ *   The @ref{MatrixTools}@p{::apply_boundary_values} function takes a list
  *   of boundary nodes and their values. You can get such a list by interpolation
  *   of a boundary function using the @p{interpolate_boundary_values} function.
  *   To use it, you have to
@@ -165,7 +165,7 @@ enum NormType {
  *   Within this function, boundary values are interpolated, i.e. a node is given
  *   the point value of the boundary function. In some cases, it may be necessary
  *   to use the L2-projection of the boundary function or any other method. For
- *   this purpose to the @p{VectorTools::project_boundary_values}
+ *   this purpose to the @ref{VectorTools}@p{::project_boundary_values}
  *   function below.
  *
  *   You should be aware that the boundary function may be evaluated at nodes
@@ -192,7 +192,7 @@ enum NormType {
  *   The projection takes place on all boundary parts with boundary indicators
  *   listed in the map of boundary functions. These boundary parts may or may
  *   not be contiguous. For these boundary parts, the mass matrix is assembled
- *   using the @p{MatrixTools::create_boundary_mass_matrix} function, as well as
+ *   using the @ref{MatrixTools}@p{::create_boundary_mass_matrix} function, as well as
  *   the appropriate right hand side. Then the resulting system of equations is
  *   solved using a simple CG method (without preconditioning), which is in most
  *   cases sufficient for the present purpose.
@@ -209,9 +209,9 @@ enum NormType {
  *   is the same as a @p{cell_iterator} takes when started with @p{begin_active} and
  *   promoted with the @p{++} operator.
  * 
- *   You can use the @p{distribute_cell_to_dof_vector} function of the @p{DoFHandler}
+ *   You can use the @p{distribute_cell_to_dof_vector} function of the @ref{DoFHandler}
  *   class to convert cell based data to a data vector with values on the degrees
- *   of freedom, which can then be attached to a @p{DataOut} object to be printed.
+ *   of freedom, which can then be attached to a @ref{DataOut} object to be printed.
  * 
  *   Presently, there is the possibility to compute the following values from the
  *   difference, on each cell: @p{mean}, @p{L1_norm}, @p{L2_norm}, @p{Linfty_norm},
@@ -241,23 +241,25 @@ enum NormType {
  *   The $H_1$ seminorm is the $L_2$ norm of the gradient of the difference. The
  *   full $H_1$ norm is the sum of the seminorm and the $L_2$ norm.
  * 
- *   To get the @em{global} $L_1$ error, you have to sum up the entries in
- *   @p{difference}, e.g. using @p{Vector<double>::l1_norm} function.
- *   For the global $L_2$ difference, you have to sum up the squares of the
- *   entries and take the root of the sum, e.g. using @p{Vector<double>::l2_norm}.
- *   These two operations represent the
- *   $l_1$ and $l_2$ norms of the vectors, but you need not take the absolute
- *   value of each entry, since the cellwise norms are already positive.
+ *   To get the @em{global} $L_1$ error, you have to sum up the
+ *   entries in @p{difference}, e.g. using
+ *   @ref{Vector}@p{<double>::l1_norm} function.  For the global $L_2$
+ *   difference, you have to sum up the squares of the entries and
+ *   take the root of the sum, e.g. using
+ *   @ref{Vector}@p{<double>::l2_norm}.  These two operations
+ *   represent the $l_1$ and $l_2$ norms of the vectors, but you need
+ *   not take the absolute value of each entry, since the cellwise
+ *   norms are already positive.
  *  
  *   To get the global mean difference, simply sum up the elements as above.
  *   To get the $L_\infty$ norm, take the maximum of the vector elements, e.g.
- *   using the @p{Vector<double>::linfty_norm} function.
+ *   using the @ref{Vector}@p{<double>::linfty_norm} function.
  *
  *   For the global $H_1$ norm and seminorm, the same rule applies as for the
  *   $L_2$ norm: compute the $l_2$ norm of the cell error vector.
  * @end{itemize}
  *
- * All functions use the finite element given to the @p{DoFHandler} object the last
+ * All functions use the finite element given to the @ref{DoFHandler} object the last
  * time that the degrees of freedom were distributed over the triangulation. Also,
  * if access to an object describing the exact form of the boundary is needed, the
  * pointer stored within the triangulation object is accessed.
@@ -329,7 +331,7 @@ class VectorTools
 				      * present grid. To this end, the mass
 				      * matrix is assembled exactly using the
 				      * @p{create_mass_matrix} function in the
-				      * @p{MatrixTools} collection. This function
+				      * @ref{MatrixTools} collection. This function
 				      * uses the @p{get_local_mass_matrix}
 				      * function of the finite element; however,
 				      * this function is not supported by all