More minor markup edits.

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

diff --git a/deal.II/examples/step-4/step-4.cc b/deal.II/examples/step-4/step-4.cc
index 1790130c281df0b2eb511ca316bcf59815e05a29..5cde37c13b64aa7fae34833a1df35bbff2f532df 100644 (file)
--- a/deal.II/examples/step-4/step-4.cc
+++ b/deal.II/examples/step-4/step-4.cc
@@ -289,7 +289,8 @@ double BoundaryValues<dim>::value (const Point<dim> &p,
                                 // triangulation just as in the previous
                                 // example program, step-3:
 template <int dim>
-LaplaceProblem<dim>::LaplaceProblem () :
+LaplaceProblem<dim>::LaplaceProblem ()
+               :
                 fe (1),
                dof_handler (triangulation)
 {}
@@ -297,23 +298,20 @@ LaplaceProblem<dim>::LaplaceProblem () :
 
                                  // @sect4{LaplaceProblem::make_grid_and_dofs}
 
-                                // Grid creation is something
-                                // inherently dimension
-                                // dependent. However, as long as the
-                                // domains are sufficiently similar
-                                // in 2D or 3D, the library can
-                                // abstract for you. In our case, we
-                                // would like to again solve on the
-                                // square [-1,1]x[-1,1] in 2D, or on
-                                // the cube [-1,1]x[-1,1]x[-1,1] in
-                                // 3D; both can be termed
-                                // <code>hyper_cube</code>, so we may use the
-                                // same function in whatever
-                                // dimension we are. Of course, the
-                                // functions that create a hypercube
-                                // in two and three dimensions are
-                                // very much different, but that is
-                                // something you need not care
+                                // Grid creation is something inherently
+                                // dimension dependent. However, as long as
+                                // the domains are sufficiently similar in 2D
+                                // or 3D, the library can abstract for
+                                // you. In our case, we would like to again
+                                // solve on the square $[-1,1]\times [-1,1]$
+                                // in 2D, or on the cube $[-1,1] \times
+                                // [-1,1] \times [-1,1]$ in 3D; both can be
+                                // termed <code>hyper_cube</code>, so we may
+                                // use the same function in whatever
+                                // dimension we are. Of course, the functions
+                                // that create a hypercube in two and three
+                                // dimensions are very much different, but
+                                // that is something you need not care
                                 // about. Let the library handle the
                                 // difficult things.
                                 //