Fix cross-references in tutorials.

This is not 100%. There are still class attributes that don't seem to be
able to be linked.

Author: QuLogic

doc/missing-references.json

@@ -5,7 +5,7 @@
 
 Defining paths in your Matplotlib visualization.
 
-The object underlying all of the :mod:`matplotlib.patch` objects is
+The object underlying all of the :mod:`matplotlib.patches` objects is
 the :class:`~matplotlib.path.Path`, which supports the standard set of
 moveto, lineto, curveto commands to draw simple and compound outlines
 consisting of line segments and splines.  The ``Path`` is instantiated
@@ -169,7 +169,7 @@
 #     verts[3::5, 1] = bottom
 #
 # All that remains is to create the path, attach it to a
-# :class:`~matplotlib.patch.PathPatch`, and add it to our axes::
+# :class:`~matplotlib.patches.PathPatch`, and add it to our axes::
 #
 #     barpath = path.Path(verts, codes)
 #     patch = patches.PathPatch(barpath, facecolor='green',

tutorials/advanced/path_tutorial.py

@@ -5,16 +5,16 @@
 
 Like any graphics packages, Matplotlib is built on top of a
 transformation framework to easily move between coordinate systems,
-the userland `data` coordinate system, the `axes` coordinate system,
-the `figure` coordinate system, and the `display` coordinate system.
+the userland *data* coordinate system, the *axes* coordinate system,
+the *figure* coordinate system, and the *display* coordinate system.
 In 95% of your plotting, you won't need to think about this, as it
 happens under the hood, but as you push the limits of custom figure
 generation, it helps to have an understanding of these objects so you
 can reuse the existing transformations Matplotlib makes available to
 you, or create your own (see :mod:`matplotlib.transforms`).  The table
 below summarizes the some useful coordinate systems, the transformation
 object you should use to work in that coordinate system, and the
-description of that system. In the `Transformation Object` column,
+description of that system. In the ``Transformation Object`` column,
 ``ax`` is a :class:`~matplotlib.axes.Axes` instance, and ``fig`` is a
 :class:`~matplotlib.figure.Figure` instance.
 
@@ -52,37 +52,36 @@
 +----------------+-----------------------------+-----------------------------------+
 
 All of the transformation objects in the table above take inputs in
-their coordinate system, and transform the input to the ``display``
-coordinate system.  That is why the ``display`` coordinate system has
+their coordinate system, and transform the input to the *display*
+coordinate system.  That is why the *display* coordinate system has
 ``None`` for the ``Transformation Object`` column -- it already is in
-display coordinates.  The transformations also know how to invert
-themselves, to go from ``display`` back to the native coordinate system.
+*display* coordinates.  The transformations also know how to invert
+themselves, to go from *display* back to the native coordinate system.
 This is particularly useful when processing events from the user
 interface, which typically occur in display space, and you want to
-know where the mouse click or key-press occurred in your data
+know where the mouse click or key-press occurred in your *data*
 coordinate system.
 
-Note that specifying objects in ``display`` coordinates will change their
+Note that specifying objects in *display* coordinates will change their
 location if the ``dpi`` of the figure changes.  This can cause confusion when
 printing or changing screen resolution, because the object can change location
 and size.  Therefore it is most common
 for artists placed in an axes or figure to have their transform set to
 something *other* than the `~.transforms.IdentityTransform()`; the default when
-an artist is placed on an axes using `~.Axes.axes.add_artist` is for the
+an artist is placed on an axes using `~.axes.Axes.add_artist` is for the
 transform to be ``ax.transData``.
 
 .. _data-coords:
 
 Data coordinates
 ================
 
-Let's start with the most commonly used coordinate, the `data`
-coordinate system.  Whenever you add data to the axes, Matplotlib
-updates the datalimits, most commonly updated with the
-:meth:`~matplotlib.axes.Axes.set_xlim` and
-:meth:`~matplotlib.axes.Axes.set_ylim` methods.  For example, in the
-figure below, the data limits stretch from 0 to 10 on the x-axis, and
--1 to 1 on the y-axis.
+Let's start with the most commonly used coordinate, the *data* coordinate
+system.  Whenever you add data to the axes, Matplotlib updates the datalimits,
+most commonly updated with the :meth:`~matplotlib.axes.Axes.set_xlim` and
+:meth:`~matplotlib.axes.Axes.set_ylim` methods.  For example, in the figure
+below, the data limits stretch from 0 to 10 on the x-axis, and -1 to 1 on the
+y-axis.
 """
 
 import numpy as np
@@ -101,7 +100,7 @@
 
 ###############################################################################
 # You can use the ``ax.transData`` instance to transform from your
-# `data` to your `display` coordinate system, either a single point or a
+# *data* to your *display* coordinate system, either a single point or a
 # sequence of points as shown below:
 #
 # .. sourcecode:: ipython
@@ -118,7 +117,7 @@
 #            [ 132.435,  642.2  ]])
 #
 # You can use the :meth:`~matplotlib.transforms.Transform.inverted`
-# method to create a transform which will take you from display to data
+# method to create a transform which will take you from *display* to *data*
 # coordinates:
 #
 # .. sourcecode:: ipython
@@ -132,7 +131,7 @@
 #     Out[43]: array([ 5.,  0.])
 #
 # If your are typing along with this tutorial, the exact values of the
-# display coordinates may differ if you have a different window size or
+# *display* coordinates may differ if you have a different window size or
 # dpi setting.  Likewise, in the figure below, the display labeled
 # points are probably not the same as in the ipython session because the
 # documentation figure size defaults are different.
@@ -170,14 +169,14 @@
 # .. note::
 #
 #   If you run the source code in the example above in a GUI backend,
-#   you may also find that the two arrows for the `data` and `display`
+#   you may also find that the two arrows for the *data* and *display*
 #   annotations do not point to exactly the same point.  This is because
 #   the display point was computed before the figure was displayed, and
 #   the GUI backend may slightly resize the figure when it is created.
 #   The effect is more pronounced if you resize the figure yourself.
-#   This is one good reason why you rarely want to work in display
+#   This is one good reason why you rarely want to work in *display*
 #   space, but you can connect to the ``'on_draw'``
-#   :class:`~matplotlib.backend_bases.Event` to update figure
+#   :class:`~matplotlib.backend_bases.Event` to update *figure*
 #   coordinates on figure draws; see :ref:`event-handling-tutorial`.
 #
 # When you change the x or y limits of your axes, the data limits are
@@ -210,7 +209,7 @@
 # Axes coordinates
 # ================
 #
-# After the `data` coordinate system, `axes` is probably the second most
+# After the *data* coordinate system, *axes* is probably the second most
 # useful coordinate system.  Here the point (0, 0) is the bottom left of
 # your axes or subplot, (0.5, 0.5) is the center, and (1.0, 1.0) is the
 # top right.  You can also refer to points outside the range, so (-0.1,
@@ -230,16 +229,16 @@
 plt.show()
 
 ###############################################################################
-# You can also make lines or patches in the axes coordinate system, but
+# You can also make lines or patches in the *axes* coordinate system, but
 # this is less useful in my experience than using ``ax.transAxes`` for
 # placing text.  Nonetheless, here is a silly example which plots some
-# random dots in `data` space, and overlays a semi-transparent
+# random dots in data space, and overlays a semi-transparent
 # :class:`~matplotlib.patches.Circle` centered in the middle of the axes
 # with a radius one quarter of the axes -- if your axes does not
 # preserve aspect ratio (see :meth:`~matplotlib.axes.Axes.set_aspect`),
 # this will look like an ellipse.  Use the pan/zoom tool to move around,
 # or manually change the data xlim and ylim, and you will see the data
-# move, but the circle will remain fixed because it is not in `data`
+# move, but the circle will remain fixed because it is not in *data*
 # coordinates and will always remain at the center of the axes.
 
 fig, ax = plt.subplots()
@@ -257,7 +256,7 @@
 # Blended transformations
 # =======================
 #
-# Drawing in `blended` coordinate spaces which mix `axes` with `data`
+# Drawing in *blended* coordinate spaces which mix *axes* with *data*
 # coordinates is extremely useful, for example to create a horizontal
 # span which highlights some region of the y-data but spans across the
 # x-axis regardless of the data limits, pan or zoom level, etc.  In fact
@@ -300,7 +299,7 @@
 ###############################################################################
 # .. note::
 #
-#   The blended transformations where x is in data coords and y in axes
+#   The blended transformations where x is in *data* coords and y in *axes*
 #   coordinates is so useful that we have helper methods to return the
 #   versions Matplotlib uses internally for drawing ticks, ticklabels, etc.
 #   The methods are :meth:`matplotlib.axes.Axes.get_xaxis_transform` and
@@ -357,14 +356,14 @@
 #
 #   trans = ScaledTranslation(xt, yt, scale_trans)
 #
-# where `xt` and `yt` are the translation offsets, and `scale_trans` is
-# a transformation which scales `xt` and `yt` at transformation time
+# where *xt* and *yt* are the translation offsets, and *scale_trans* is
+# a transformation which scales *xt* and *yt* at transformation time
 # before applying the offsets.
 #
 # Note the use of the plus operator on the transforms below.
 # This code says: first apply the scale transformation ``fig.dpi_scale_trans``
 # to make the ellipse the proper size, but still centered at (0, 0),
-# and then translate the data to `xdata[0]` and `ydata[0]` in data space.
+# and then translate the data to ``xdata[0]`` and ``ydata[0]`` in data space.
 #
 # In interactive use, the ellipse stays the same size even if the
 # axes limits are changed via zoom.
@@ -392,7 +391,7 @@
 #   in data space to the correct spot.
 #   If we had done the ``ScaledTranslation`` first, then
 #   ``xdata[0]`` and ``ydata[0]`` would
-#   first be transformed to ``display`` coordinates (``[ 358.4  475.2]`` on
+#   first be transformed to *display* coordinates (``[ 358.4  475.2]`` on
 #   a 200-dpi monitor) and then those coordinates
 #   would be scaled by ``fig.dpi_scale_trans`` pushing the center of
 #   the ellipse well off the screen (i.e. ``[ 71680.  95040.]``).
@@ -406,7 +405,7 @@
 # a new transformation that is
 # offset from another transformation, e.g., to place one object shifted a
 # bit relative to another object.  Typically you want the shift to be in
-# some physical dimension, like points or inches rather than in data
+# some physical dimension, like points or inches rather than in *data*
 # coordinates, so that the shift effect is constant at different zoom
 # levels and dpi settings.
 #
@@ -418,8 +417,8 @@
 # Here we apply the transforms in the *opposite* order to the use of
 # :class:`~matplotlib.transforms.ScaledTranslation` above. The plot is
 # first made in data units (``ax.transData``) and then shifted by
-# ``dx`` and ``dy`` points using `fig.dpi_scale_trans`.  (In typography,
-# a`point <https://en.wikipedia.org/wiki/Point_%28typography%29>`_ is
+# ``dx`` and ``dy`` points using ``fig.dpi_scale_trans``.  (In typography,
+# a `point <https://en.wikipedia.org/wiki/Point_%28typography%29>`_ is
 # 1/72 inches, and by specifying your offsets in points, your figure
 # will look the same regardless of the dpi resolution it is saved in.)
 
@@ -464,7 +463,7 @@
 #
 # The ``ax.transData`` transform we have been working with in this
 # tutorial is a composite of three different transformations that
-# comprise the transformation pipeline from `data` -> `display`
+# comprise the transformation pipeline from *data* -> *display*
 # coordinates.  Michael Droettboom implemented the transformations
 # framework, taking care to provide a clean API that segregated the
 # nonlinear projections and scales that happen in polar and logarithmic
@@ -485,11 +484,11 @@
 #
 # We've been introduced to the ``transAxes`` instance above in
 # :ref:`axes-coords`, which maps the (0, 0), (1, 1) corners of the
-# axes or subplot bounding box to `display` space, so let's look at
+# axes or subplot bounding box to *display* space, so let's look at
 # these other two pieces.
 #
 # ``self.transLimits`` is the transformation that takes you from
-# ``data`` to ``axes`` coordinates; i.e., it maps your view xlim and ylim
+# *data* to *axes* coordinates; i.e., it maps your view xlim and ylim
 # to the unit space of the axes (and ``transAxes`` then takes that unit
 # space to display space).  We can see this in action here
 #
@@ -516,7 +515,7 @@
 #     Out[87]: array([ 0.5,  0.5])
 #
 # and we can use this same inverted transformation to go from the unit
-# `axes` coordinates back to `data` coordinates.
+# *axes* coordinates back to *data* coordinates.
 #
 # .. sourcecode:: ipython
 #

tutorials/advanced/transforms_tutorial.py

@@ -45,7 +45,7 @@
 #
 # The second example illustrates the use of a
 # :class:`~matplotlib.colors.ListedColormap` which generates a colormap from a
-# set of listed colors, :func:`colors.BoundaryNorm` which generates a colormap
+# set of listed colors, `.colors.BoundaryNorm` which generates a colormap
 # index based on discrete intervals and extended ends to show the "over" and
 # "under" value colors. Over and under are used to display data outside of the
 # normalized [0, 1] range. Here we pass colors as gray shades as a string

tutorials/colors/colorbar_only.py

@@ -49,7 +49,7 @@
 # ListedColormap
 # --------------
 #
-# `ListedColormap` s store their color values in a ``.colors`` attribute.
+# `.ListedColormap` s store their color values in a ``.colors`` attribute.
 # The list of colors that comprise the colormap can be directly accessed using
 # the ``colors`` property,
 # or it can be accessed indirectly by calling  ``viridis`` with an array
@@ -69,7 +69,7 @@
 ##############################################################################
 # LinearSegmentedColormap
 # -----------------------
-# `LinearSegmentedColormap` s do not have a ``.colors`` attribute.
+# `.LinearSegmentedColormap` s do not have a ``.colors`` attribute.
 # However, one may still call the colormap with an integer array, or with a
 # float array between 0 and 1.
 
@@ -238,7 +238,7 @@ def plot_linearmap(cdict):
 #
 # The above described is a very versatile approach, but admitedly a bit
 # cumbersome to implement. For some basic cases, the use of
-# `LinearSegmentedColormap.from_list` may be easier. This creates a segmented
+# `.LinearSegmentedColormap.from_list` may be easier. This creates a segmented
 # colormap with equal spacings from a supplied list of colors.
 
 colors = ["darkorange", "gold", "lawngreen", "lightseagreen"]

tutorials/colors/colormap-manipulation.py

@@ -35,13 +35,12 @@
 Logarithmic
 -----------
 
-One of the most common transformations is to plot data by taking
-its logarithm (to the base-10).  This transformation is useful to
-display changes across disparate scales.  Using :func:`colors.LogNorm`
-normalizes the data via :math:`log_{10}`.  In the example below,
-there are two bumps, one much smaller than the other. Using
-:func:`colors.LogNorm`, the shape and location of each bump can clearly
-be seen:
+One of the most common transformations is to plot data by taking its logarithm
+(to the base-10).  This transformation is useful to display changes across
+disparate scales.  Using `.colors.LogNorm` normalizes the data via
+:math:`log_{10}`.  In the example below, there are two bumps, one much smaller
+than the other. Using `.colors.LogNorm`, the shape and location of each bump
+can clearly be seen:
 """
 import numpy as np
 import matplotlib.pyplot as plt
@@ -76,7 +75,7 @@
 # Similarly, it sometimes happens that there is data that is positive
 # and negative, but we would still like a logarithmic scaling applied to
 # both.  In this case, the negative numbers are also scaled
-# logarithmically, and mapped to smaller numbers; e.g., if `vmin=-vmax`,
+# logarithmically, and mapped to smaller numbers; e.g., if ``vmin=-vmax``,
 # then they the negative numbers are mapped from 0 to 0.5 and the
 # positive from 0.5 to 1.
 #
@@ -112,7 +111,7 @@
 #
 # Sometimes it is useful to remap the colors onto a power-law
 # relationship (i.e. :math:`y=x^{\gamma}`, where :math:`\gamma` is the
-# power).  For this we use the :func:`colors.PowerNorm`.  It takes as an
+# power).  For this we use the `.colors.PowerNorm`.  It takes as an
 # argument *gamma* (*gamma* == 1.0 will just yield the default linear
 # normalization):
 #
@@ -142,11 +141,10 @@
 # Discrete bounds
 # ---------------
 #
-# Another normaization that comes with Matplotlib is
-# :func:`colors.BoundaryNorm`.  In addition to *vmin* and *vmax*, this
-# takes as arguments boundaries between which data is to be mapped.  The
-# colors are then linearly distributed between these "bounds".  For
-# instance:
+# Another normalization that comes with Matplotlib is `.colors.BoundaryNorm`.
+# In addition to *vmin* and *vmax*, this takes as arguments boundaries between
+# which data is to be mapped.  The colors are then linearly distributed between
+# these "bounds".  For instance:
 #
 # .. ipython::
 #

tutorials/colors/colormapnorms.py

@@ -21,7 +21,7 @@
   color cycle): ``{'tab:blue', 'tab:orange', 'tab:green', 'tab:red',
   'tab:purple', 'tab:brown', 'tab:pink', 'tab:gray', 'tab:olive', 'tab:cyan'}``
   (case-insensitive);
-* a "CN" color spec, i.e. `'C'` followed by a number, which is an index into
+* a "CN" color spec, i.e. ``'C'`` followed by a number, which is an index into
   the default property cycle (``matplotlib.rcParams['axes.prop_cycle']``); the
   indexing is intended to occur at rendering time, and defaults to black if the
   cycle does not include color.

tutorials/colors/colors.py

@@ -335,7 +335,7 @@ def example_plot(ax, fontsize=12, nodec=False):
 # ========
 #
 # There are five :ref:`rcParams<matplotlib-rcparams>` that can be set,
-# either in a script or in the `matplotlibrc` file.
+# either in a script or in the :file:`matplotlibrc` file.
 # They all have the prefix ``figure.constrained_layout``:
 #
 # - ``use``: Whether to use constrained_layout. Default is False
@@ -504,8 +504,8 @@ def docomplicated(suptitle=None):
 # ----------------------
 #
 # ``constrained_layout`` will not work on subplots
-# created via the `subplot` command.  The reason is that each of these
-# commands creates a separate `GridSpec` instance and ``constrained_layout``
+# created via the `.pyplot.subplot` command.  The reason is that each of these
+# commands creates a separate `.GridSpec` instance and ``constrained_layout``
 # uses (nested) gridspecs to carry out the layout.  So the following fails
 # to yield a nice layout:
 

tutorials/intermediate/constrainedlayout_guide.py

@@ -9,7 +9,7 @@
         Perhaps the primary function used to create figures and axes.
         It's also similar to :func:`.matplotlib.pyplot.subplot`,
         but creates and places all axes on the figure at once.  See also
-        `matplotlib.Figure.subplots`.
+        `matplotlib.figure.Figure.subplots`.
 
     :class:`~matplotlib.gridspec.GridSpec`
         Specifies the geometry of the grid that a subplot will be