Fixed style errors

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

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

@@ -197,12 +197,15 @@ 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.
+used by *Generator* projects to create code. A package that calls rosidl_generate_interfaces CMake macro is a *Client* project.
 
 Code generation workflow
 ------------------------
@@ -217,11 +220,10 @@ 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. Said extensions have the code to generate sources for each of the IDL interfaces. Then, code is added to an artifact 
+*generator* packages, get called. Said extensions have the code to generate sources for each of the IDL interfaces. Then, code is added to an artifact
 (a library) and dependiences are exported for code to be build and installed.
 
 .. figure:: ../images/generator_client.png
    :alt: generator client sequence diagram
 
    Figure: sequence diagram of "generator client" interaction with CMake extensions.
-