Avoid automatic referencing

diff --git a/examples/step-49/doc/intro.dox b/examples/step-49/doc/intro.dox
index 46829fc9b555b62de254069982d90f0cf94c1475..f6d7c1481332b8d986d581a564999ab7c73e27a0 100644 (file)
--- a/examples/step-49/doc/intro.dox
+++ b/examples/step-49/doc/intro.dox
@@ -76,28 +76,28 @@ documentation of GridIn for more information. The problem is that deal.II
 needs meshes that only consist of quadrilaterals and hexahedra -- tetrahedral
 meshes won't work (this means tools like tetgen can not be used directly).
 
-We will describe a possible workflow using Gmsh. Gmsh is the smallest and
+We will describe a possible workflow using %Gmsh. %Gmsh is the smallest and
 most quickly set up open source tool we are aware of. It can generate
 unstructured 2d quad meshes. In 3d, it can extrude 2d meshes to
 get hexahedral meshes; 3D meshing of unstructured geometry into hexahedra is
 possible, though there are some issues with the quality of these meshes
 that imply that these meshes only sometimes work in deal.II.
 
-In Gmsh, a mesh is fundamentally described in a text-based
+In %Gmsh, a mesh is fundamentally described in a text-based
 <code>.geo</code> file whose format can
 contain computations, loops, variables, etc. This format is quite flexible
 in allowing the description of complex geometries. The mesh is then
 generated from a surface representation, which is built from a list of line
 loops, which is built from a list of lines, which are in turn built from
 points. The <code>.geo</code> script can be written and edited by hand or it
-can be generated automatically by creating objects graphically inside Gmsh. In
+can be generated automatically by creating objects graphically inside %Gmsh. In
 many cases it is best to combine both approaches. The file can be easily
 reloaded by pressing "reload" under the "Geometry" tab if you want to write
 it by hand and see the effects in the graphical user interface of gmsh.
 
 This tutorial contains an example <code>.geo</code> file that describes a box
 with two objects cut out in the interior. This is how
-<code>example.geo</code> looks like in Gmsh (displaying the boundary
+<code>example.geo</code> looks like in %Gmsh (displaying the boundary
 indicators as well as the mesh discussed further down below):
 
 <img src="https://www.dealii.org/images/steps/developer/step-49.gmsh_picture.png" alt="">
@@ -116,7 +116,7 @@ boundary indicator (see @ref GlossBoundaryIndicator "this glossary entry").
   deal.II.
 
 deal.II's GridIn class can read the <code>.msh</code> format written by
-Gmsh and that contains a mesh created for the geometry described by the
+%Gmsh and that contains a mesh created for the geometry described by the
 <code>.geo</code> file. You generate the <code>.msh</code> from the
 <code>.geo</code> by running the commands
 
@@ -124,14 +124,14 @@ Gmsh and that contains a mesh created for the geometry described by the
 gmsh -2 example.geo
 @endcode
 
-on the command line, or by clicking "Mesh" and then "2D" inside Gmsh after
+on the command line, or by clicking "Mesh" and then "2D" inside %Gmsh after
 loading the file.  Now this is the mesh read from the <code>.msh</code> file
 and saved again by deal.II as an image (see the <code>grid_1</code> function
 of the current program):
 
 <img src="https://www.dealii.org/images/steps/developer/step-49.grid-1.png" alt="">
 
-@note gmsh has a number of other interfaces by which one can describe
+@note %Gmsh has a number of other interfaces by which one can describe
   geometries to it. In particular, it has the ability to interface with
   scripting languages like Python and Julia, but it can also be scripted
   from C++. These interfaces are useful if one doesn't just want to generate