Fixed style

Signed-off-by: Gonzalo de Pedro <[email protected]>

source/Concepts/Advanced/About-Internal-Interfaces.rst

@@ -193,25 +193,28 @@ The ``rcutils`` |API| and implementation are located in the `ros2/rcutils <https
 For a complete definition of the ``rcutils`` |API|, see `the rcutils docs <https://docs.ros.org/en/{DISTRO}/p/rcutils/>`_.
 
 Automatic code generation using template files
-=========================
+==============================================
 
 As mentioned above, in order to deal with different DDS implementations, code has to be generated. Code generation is handled by a clever usage
 of CMake and Ament. To simplify the explanation of this mechanism let's separate ROS2 projects that generate or need code to be generated in two types.
-   * *Generator* projects, which are the ones that have the templates and logic to generate code.
-   * *Client* projects, which are the ones that need code to be generated, they have the parameters to generate code.
-For instance, typesupport packages that generate code for a particular dds implementation are *Generator* packages, same case that rosidl which 
+
+-  ``Generator`` projects, which are the ones that have the templates and logic to generate code.
+-  ``Client`` projects, which are the ones that need code to be generated, they have the parameters to generate code.
+
+For instance, typesupport packages that generate code for a particular dds implementation are ``Generator`` packages, same case that rosidl which
 generates code from ros idl (.msg, .action, etc) files.
-*Client* projects are typically projects that define messages, actions and services. Which have .msg files with rosidl defined on them which are
-used by *Generator* projects to crete code. A package that calls rosidl_generate_interfaces CMake macro is a *Client* project.
+
+``Client`` projects are typically projects that define messages, actions and services. Which have .msg files with rosidl defined on them which are
+used by ``Generator`` projects to crete code. A package that calls rosidl_generate_interfaces CMake macro is a ``Client`` project.
 
 Code generation workflow
 -------------------------
 
-On workspace build, the *generator* packages, registers portions of CMake code as an ament_extension under different keys:
-   * 'rosidl_create_type_descriptions_extensions' : Calls type support description extensions(generate hashes for typessupports)
-   * 'rosidl_write_generator_arguments_extensions': Generate the arguments files.
-   * 'rosidl_generate_idl_interfaces': After files are generated, create artifacts, export dependencies.
+On workspace build, the ``generator`` packages, registers portions of CMake code as an ament_extension under different keys:
 
+-  ``rosidl_create_type_descriptions_extensions`` : Calls type support description extensions(generate hashes for typessupports)
+-  ``rosidl_write_generator_arguments_extensions``: Generate the arguments files.
+-  ``rosidl_generate_idl_interfaces``: After files are generated, create artifacts, export dependencies.
 
 Hook registration on CodeGenerator project build
 
@@ -220,8 +223,8 @@ Hook registration on CodeGenerator project build
 
    Figure: sequence diagram of "code generator" interaction with CMake extensions.
 
-When the *client* package, during its build process, calls the 'rosidl_generate_interfaces' macro, the extensions that were registered for each of the
-*generator* packages, get called. On 'rosidl_write_generator_arguments_extensions' arguments files are generated with all parameters required to call the templates engine. 
+When the ``client`` package, during its build process, calls the 'rosidl_generate_interfaces' macro, the extensions that were registered for each of the
+``generator`` packages, get called. On 'rosidl_write_generator_arguments_extensions' arguments files are generated with all parameters required to call the templates engine.
 After collecting all the arguments files, the extension calls the template engine for all the arguments files at once. Once code is generated,
 the 'rosidl_generate_idl_interfaces' extensiones are called to get code added to an artifact (a library) and export dependiences.