Fix HTML entities

articles/serialization.md

@@ -92,7 +92,7 @@ The message fields can be serialized directly into the wire format using custom
 The message delegates the data storage to an internally held storage backend, e.g. the serialization library specific message representation. Since the data is stored directly in the serialization library specific representation copying the data before serializing it is not necessary anymore.
 This assumes that the API of the serialization library specific representation can be wrapped inside the ROS message API. [See Open Issues → Variances in field types]
 
-i<img src="{{ site.baseurl }}/img/serialization_pipeline_c.png"/>
+<img src="{{ site.baseurl }}/img/serialization_pipeline_c.png"/>
 
 ### Select message storage
 
@@ -141,16 +141,16 @@ As the results of produce_consume_method and produce_consume_backend_plain show
 Different serialization libraries specify different field type when e.g. generating C++ code for the messages. The major problem is the mapping between those types in an efficient manner. From a performance point of view the message interface should expose const references (especially to “big” fields). But those can only be mapped to the specific API of the serialization library if the types are exchangeable.
 But for example a byte array is represented differently in C++ in the various serialization libraries:
 - Protobuf:
- - dyn. array<T>: RepeatedField<T> (STL-like interface)
- - fix. array<T>: ---
+ - dyn. array&lt;T&gt;: RepeatedField&lt;T&gt; (STL-like interface)
+ - fix. array&lt;T&gt;: ---
  - binary/string: std::string
 - Thrift:
- - dyn. array<T>: std::vector<T>
- - fix. array<T>: ---
+ - dyn. array&lt;T&gt;: std::vector&lt;T&gt;
+ - fix. array&lt;T&gt;: ---
  - binary/string: std::string
 - ROS:
- - array<T>: std::vector<T>
- - fix. array<T, N>: boost::array<T, N>
+ - array&lt;T&gt;: std::vector&lt;T&gt;
+ - fix. array&lt;T, N&gt;: boost::array&lt;T, N&gt;
  - string: std::string
 
 Furthermore the serialization library specific message API might not expose mutable access which could therefore not be provided by RO either when using pipeline C.