Documentation: Fixes instances where backticks were not correctly interpreted plus some general indentation issues.

5 files changed, 20 insertions, 22 deletions

diff --git a/doc/src/API.rst b/doc/src/API.rst
index c7a0320c3..6d16d52c2 100644
--- a/doc/src/API.rst
+++ b/doc/src/API.rst
@@ -719,7 +719,7 @@ Return Codes from ``gsapi_*()``
    * - 0
      - No errors
    * - gs_error_Quit
-     - "quit" has been executed. This is not an error. ```gsapi_exit()`` must be called next.
+     - "quit" has been executed. This is not an error. ``gsapi_exit()`` must be called next.
    * - gs_error_interrupt
      - The polling callback function returned a negative value, requesting Ghostscript to abort.
    * - gs_error_NeedInput
@@ -1364,13 +1364,13 @@ On exit, the values should be updated appropriately. The implementor is expected
 
 ``memory`` should be updated to point to a block of memory to use for the rendered output. Pixel (``*ox``, ``*oy``) is the first pixel represented in that block.
 
-``*raster`` is the number of bytes difference between the address of component 0 of Pixel(``*ox``, ``*oy``) and the address of component 0 of Pixel(``*ox``, 1+``*oy``).
+``*raster`` is the number of bytes difference between the address of component 0 of Pixel(``*ox``, ``*oy``) and the address of component 0 of Pixel(``*ox``, 1 + ``*oy``).
 
 ``*plane_raster`` is the number of bytes difference between the address of component 0 of Pixel(``*ox``, ``*oy``) and the address of component 1 of Pixel(``*ox``, ``*oy``), if in planar mode, 0 otherwise. ``*x``, ``*y``, ``*w`` and ``*h`` give the rectangle requested within that memory block.
 
 Any set of rectangles can be rendered with this method, so this can be used to drive Ghostscript in various ways. Firstly, it is simple to request a set of non-overlapping "bands" that cover the page, to drive a printer. Alternatively, rectangles can be chosen to fill a given block of memory to implement a window panning around a larger page. Either the whole image could be redrawn each time, or smaller rectangles around the edge of the panned area could be requested. The choice is down to the caller.
 
-Some examples of driving this code in full page mode are in ```dwmain.c``(Windows), ``dpmain.c`` (OS/2) and ``dxmain.c`` (X11/Linux), and ``dmmain.c`` (MacOS Classic or Carbon).
+Some examples of driving this code in full page mode are in ``dwmain.c`` (Windows), ``dpmain.c`` (OS/2) and ``dxmain.c`` (X11/Linux), and ``dmmain.c`` (MacOS Classic or Carbon).
 
 Alternatively an example that drives this code in both full page and rectangle request mode can be found in ``api_test.c``.
 
diff --git a/doc/src/Drivers.rst b/doc/src/Drivers.rst
index aadb41aaf..28099d493 100644
--- a/doc/src/Drivers.rst
+++ b/doc/src/Drivers.rst
@@ -988,13 +988,13 @@ The ``fill_*`` drawing operations all use the center-of-pixel rule: a pixel is c
    Fill a trapezoid. The bottom and top edges are parallel to the x axis, and are defined by ``ybot`` and ``ytop``, respectively. The left and right edges are defined by ``left`` and ``right``. Both of these represent lines (``gs_fixed_edge`` is defined in ``gxdevcli.h`` and consists of ``gs_fixed_point`` start and end points). The y coordinates of these lines need not have any specific relation to ``ybot`` and ``ytop``. The routine is defined this way so that the filling algorithm can subdivide edges and still guarantee that the exact same pixels will be filled. If ``swap_axes`` is set, the meanings of X and Y are interchanged.
 
 ``int (*fill_parallelogram)(gx_device *dev, fixed px, fixed py, fixed ax, fixed ay, fixed bx, fixed by, const gx_drawing_color *pdcolor, gs_logical_operation_t lop) [OPTIONAL]``
-   Fill a parallelogram whose corners are (``px``,``py``), (``px+ax``,``py+ay``), (``px+bx``,``py+by``), and (``px+ax+bx``,``py+ay+by``). There are no constraints on the values of any of the parameters, so the parallelogram may have any orientation relative to the coordinate axes.
+   Fill a parallelogram whose corners are (``px``, ``py``), (``px+ax``, ``py+ay``), (``px+bx``, ``py+by``), and (``px+ax+bx``, ``py+ay+by``). There are no constraints on the values of any of the parameters, so the parallelogram may have any orientation relative to the coordinate axes.
 
 ``int (*fill_triangle)(gx_device *dev, fixed px, fixed py, fixed ax, fixed ay, fixed bx, fixed by, const gx_drawing_color *pdcolor, gs_logical_operation_t lop) [OPTIONAL]``
-   Fill a triangle whose corners are (``px``,``py``), (``px+ax``,``py+ay``), and (``px+bx``,``py+by``).
+   Fill a triangle whose corners are (``px``, ``py``), (``px+ax``, ``py+ay``), and (``px+bx``, ``py+by``).
 
 ``int (*draw_thin_line)(gx_device *dev, fixed fx0, fixed fy0, fixed fx1, fixed fy1, const gx_drawing_color *pdcolor, gs_logical_operation_t lop) [OPTIONAL]``
-   Draw a one-pixel-wide line from (``fx0``,``fy0``) to (``fx1``,``fy1``).
+   Draw a one-pixel-wide line from (``fx0``, ``fy0``) to (``fx1``, ``fy1``).
 
 
 Linear color drawing
diff --git a/doc/src/Lib.rst b/doc/src/Lib.rst
index 1698042b1..6dafe694d 100644
--- a/doc/src/Lib.rst
+++ b/doc/src/Lib.rst
@@ -35,7 +35,7 @@ The highest level of the library, which is the one that most clients will use, d
 
 Nearly every procedure returns an integer code which is ``>= 0`` for a successful return or ``<0`` for a failure. The failure codes correspond directly to PostScript errors, and are defined in ``gserrors.h``.
 
-The library implements all the operators in the following sections of the PostScript Language Reference Manual, with the indicated omissions and with the APIs defined in the indicated ``.h`` files. A header of the form ``A.h``(``B.h``) indicates that ``A.h`` is included in ``B.h``, so ``A.h`` need not be included explicitly if ``B.h`` is included. Operators marked with * in the "omissions" column are not implemented directly; the library provides lower-level procedures that can be used to implement the operator.
+The library implements all the operators in the following sections of the PostScript Language Reference Manual, with the indicated omissions and with the APIs defined in the indicated ``.h`` files. A header of the form ``A.h`` (``B.h``) indicates that ``A.h`` is included in ``B.h``, so ``A.h`` need not be included explicitly if ``B.h`` is included. Operators marked with * in the "omissions" column are not implemented directly; the library provides lower-level procedures that can be used to implement the operator.
 
 There are slight differences in the operators that return multiple values, since C's provisions for this are awkward. Also, the control structure for the operators involving callback procedures (``pathforall``, ``image``, ``colorimage``, ``imagemask``) is partly inverted: the client calls a procedure to set up an enumerator object, and then calls another procedure for each iteration. The ``...show`` operators, ``charpath``, and ``stringwidth`` also use an inverted control structure.
 
diff --git a/doc/src/Psfiles.rst b/doc/src/Psfiles.rst
index c2e887a50..1334dd27d 100644
--- a/doc/src/Psfiles.rst
+++ b/doc/src/Psfiles.rst
@@ -324,7 +324,7 @@ These files are found in the ``lib`` subdirectory of the Ghostscript source dist
 ``caption.ps``
    A file for putting a caption in a box at the bottom of each page, useful for trade show demos.
 
-``cat.ps```
+``cat.ps``
    Appends one file to another. Primarily used to overcome the 'copy' limitation of Windows command shell for ``ps2epsi``.
 
 ``cid2code.ps``
diff --git a/doc/src/Use.rst b/doc/src/Use.rst
index efba6bea4..6d72b7940 100644
--- a/doc/src/Use.rst
+++ b/doc/src/Use.rst
@@ -1581,36 +1581,36 @@ whereas ``-sXYZ=35`` is equivalent to:
 
    -pFoo="<< /Bar[1 2 3]/Baz 0.1 /Whizz (string) /Bang <0123> >>"
 
-   This means that ``-p`` can do the job of both ``-d`` and ``-s``. For example:
+This means that ``-p`` can do the job of both ``-d`` and ``-s``. For example:
 
 .. code-block:: bash
 
    -dDownScaleFactor=3
 
-   can be equivalently performed by:
+can be equivalently performed by:
 
 .. code-block:: bash
 
    -pDownScaleFactor=3
 
-   and:
+and:
 
 .. code-block:: bash
 
    -sPAPERSIZE=letter
 
-   can be equivalently performed by:
+can be equivalently performed by:
 
 .. code-block:: bash
 
    -pPAPERSIZE="(letter)"
 
 
-   .. note ::
+.. note ::
 
-     There are some 'special' values that should be set using ``-s``, not ``-p``, such as ``DEVICE`` and ``DefaultGrayProfile``. Broadly, only use ``-p`` if you cannot set what you want using ``-s`` or ``-d``.
+  There are some 'special' values that should be set using ``-s``, not ``-p``, such as ``DEVICE`` and ``DefaultGrayProfile``. Broadly, only use ``-p`` if you cannot set what you want using ``-s`` or ``-d``.
 
-   Also, internally, after setting an parameter with ``-p`` we perform an ``initgraphics`` operation. This is required to allow changes in parameters such as ``HWResolution`` to take effect. This means that attempting to use ``-p`` other than at the start of a page is liable to give unexpected results.
+Also, internally, after setting an parameter with ``-p`` we perform an ``initgraphics`` operation. This is required to allow changes in parameters such as ``HWResolution`` to take effect. This means that attempting to use ``-p`` other than at the start of a page is liable to give unexpected results.
 
 
 **-u** *name*
@@ -1788,16 +1788,14 @@ Page parameters
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    There are three possible values for this; even, odd or a list of pages to be processed. A list can include single pages or ranges of pages. Ranges of pages use the minus sign '-', individual pages and ranges of pages are separated by commas ','. A trailing minus '-' means process all remaining pages. For example:
 
-.. code-block:: bash
-
-   -sPageList=1,3,5 indicates that pages 1, 3 and 5 should be processed.
-   -sPageList=5-10 indicates that pages 5, 6, 7, 8, 9 and 10 should be processed.
-   -sPageList=1, 5-10, 12- indicates that pages 1, 5, 6, 7, 8, 9, 10 and 12 onwards should be processed.
+   - ``-sPageList=1,3,5`` indicates that pages 1, 3 and 5 should be processed.
+   - ``-sPageList=5-10`` indicates that pages 5, 6, 7, 8, 9 and 10 should be processed.
+   - ``-sPageList=1, 5-10, 12`` indicates that pages 1, 5, 6, 7, 8, 9, 10 and 12 onwards should be processed.
 
 
-   The PDF interpreter and the other language interpreters handle these in slightly different ways. Because PDF files enable random access to pages in the document the PDF inerpreter only interprets and renders the required pages. PCL and PostScript cannot be handled in ths way, and so all the pages must be interpreted. However only the requested pages are rendered, which can still lead to savings in time. Be aware that using the '``%d``' syntax for ``OutputFile`` does not reflect the page number in the original document. If you chose (for example) to process even pages by using ``-sPageList=even``, then the output of ``-sOutputFile=out%d.png`` would still be ``out0.png``, ``out1.png``, ``out2.png`` etc.
+The PDF interpreter and the other language interpreters handle these in slightly different ways. Because PDF files enable random access to pages in the document the PDF inerpreter only interprets and renders the required pages. PCL and PostScript cannot be handled in ths way, and so all the pages must be interpreted. However only the requested pages are rendered, which can still lead to savings in time. Be aware that using the '``%d``' syntax for ``OutputFile`` does not reflect the page number in the original document. If you chose (for example) to process even pages by using ``-sPageList=even``, then the output of ``-sOutputFile=out%d.png`` would still be ``out0.png``, ``out1.png``, ``out2.png`` etc.
 
-   Because the PostScript and PCL interpreters cannot determine when a document terminates, sending multple files as input on the command line does not reset the ``PageList`` between each document, each page in the second and subsequent documents is treated as following on directly from the last page in the first document. The PDF interpreter, however, does not work this way. Since it knows about individual PDF files the ``PageList`` is applied to each PDF file separately. So if you were to set ``-sPageList=1,2`` and then send two PDF files, the result would be pages 1 and 2 from the first file, and then pages 1 and 2 from the second file. The PostScript interpreter, by contrast, would only render pages 1 and 2 from the first file. This means you must exercise caution when using this switch, and probably should not use it at all when processing a mixture of PostScript and PDF files on the same command line.
+Because the PostScript and PCL interpreters cannot determine when a document terminates, sending multple files as input on the command line does not reset the ``PageList`` between each document, each page in the second and subsequent documents is treated as following on directly from the last page in the first document. The PDF interpreter, however, does not work this way. Since it knows about individual PDF files the ``PageList`` is applied to each PDF file separately. So if you were to set ``-sPageList=1,2`` and then send two PDF files, the result would be pages 1 and 2 from the first file, and then pages 1 and 2 from the second file. The PostScript interpreter, by contrast, would only render pages 1 and 2 from the first file. This means you must exercise caution when using this switch, and probably should not use it at all when processing a mixture of PostScript and PDF files on the same command line.
 
 .. _FIXEDMEDIA: